kubenetes/kubesphere搭建报错

一、prometheus问题

1.kubesphere 安装 prometheus-k8s 报以下错误：

MountVolume.SetUp failed for volume "secret-kube-etcd-client-certs" : secret "kube-etcd-client-certs" not found

原因是：kube-etcd-client-certs 这个证书没有找到。
解决方法：

kubectl -n kubesphere-monitoring-system create secret generic kube-etcd-client-certs \--from-file=etcd-client-ca.crt=/etc/kubernetes/pki/etcd/ca.crt \--from-file=etcd-client.crt=/etc/kubernetes/pki/etcd/healthcheck-client.crt \--from-file=etcd-client.key=/etc/kubernetes/pki/etcd/healthcheck-client.key

二、解决k8s集群中opensearch服务的各种问题

1. 前言

我使用的k8s版本是1.23.6，前面安装了Kubesphere可视化组件，然后开始的时候没有启用日志模块，而是在安装Kubesphere后启用日志系统（参考在安装后启用日志系统），安装一切正常，但是安装后验证，就出现opensearch-cluster-master-x和opensearch-cluster-data-x这些pod都是CrashLoopBackOff的状态，以下是一系列问题及解决。

2. 问题及解决

2.1. 虚拟内存的问题

看日志，发现：

ERROR: [1] bootstrap checks failed[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]ERROR: OpenSearch did not exit normally - check the logs at /usr/share/opensearch/logs/opensearch-cluster.log

目测是虚拟内存的问题，vm.max_map_count 是一个 Linux 内核参数，它控制着一个进程可以拥有的虚拟内存区域的数量，通常用于限制系统中的内存映射数量。这个参数的值表示允许的最大内存映射数量。

宿主机编辑/etc/sysctl.conf文件，增加以下配置：

vm.max_map_count = 262144

然后刷新内存里的配置：

sysctl -w vm.max_map_count=262144

重启docker服务：

systemctl restart docker

2.2. 服务频繁重启的问题

这个是因为服务还没起来，探针超时，然后将服务重启，最后形成死循环，这个需要修改探针配置。

受影响的pod都是由有状态服务（statefulset）启动的，分别为：

• opensearch-cluster-data
• opensearch-cluster-master

使用Kubesphere或者命令进行编辑：

kubectl edit sts opensearch-cluster-data -n kubesphere-logging-system

将startupProbe的initialDelaySeconds改为30。

同样对opensearch-cluster-master也进行同样的操作，然后重新创建就可以了。

2.3. OpenSearch Security not initialized

这个是安全配置未初始化，进入opensearch-cluster-master所在的pod譬如我的是opensearch-cluster-master-0，然后进入/usr/share/opensearch/plugins/opensearch-security/tools 目录，执行以下命令：

./securityadmin.sh -cd ../../../config/opensearch-security/ -rev -cacert ../../../config/root-ca.pem -cert ../../../config/kirk.pem -key ../../../config/kirk-key.pem

如果有步骤超时，则再执行一次试试。

注意，不同版本文件的位置可能不一样，其他的版本可以参考[3]和[4]中的教程。

3. 参考

[1] Elasticsearch: Max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

[2] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

[3] OpenSearch Security not initialized

[4] Applying changes to configuration files

三、k8s ingress 配置后访问返回502的问题

1. 问题

如上图所示，我在K8S集群中，创建了一个Ingress-nginx，用来反向代理service，另外，因为我在安装Ingress的时候，设置了hostNetwork: true和dnsPolicy: ClusterFirstWithHostNet，因此是可以直接通过配置hosts，然后通过域名去访问的，配置如下

192.168.1.100 k8s.api.myapp.cn

然而，遇到了一个诡异的情况，我在其他linux主机上，是可以直接通过域名去访问到服务的。

但是，在我的Windows主机就出问题了，直接返回502，而且看Ingress的日志是直接没到Ingress服务的。另外，我在主机的Wsl中，却可以正常访问。

2. 问题解决

根据上面的现象，可以猜测请求在主机端就已经给转发到别的地方去了，最大的可能是因为你开了代理，因此可以先关闭掉代理再尝试一下，我就是遇到了这个问题。

解决方法也很简单，打开代理软件，配置系统代理绕过的域名/IP网段，以Clash为例，这个配置在“设置-系统代理-系统代理绕过的域名/IP网段”，然后只要将你的域名配置上去即可。

如果不是代理的问题，则需要使用抓包工具进行抓包并分析了。

四、安装 SonarQube后sonarqube-sonarqube无法启动的问题解决

1. 前言

我的环境：k8s集群（version 1.23.6），安装了Kubesphere（version v3.4）作为可视化界面，最近想要推动团队走CICD，于是在Kubesphere中启用了devops组件，参考：https://kubesphere.io/zh/docs/v3.4/pluggable-components/devops/ 。

组件安装完成后，需要将Sonarqube集成到流水线中，于是又安装了Sonarqube，参考：https://kubesphere.io/zh/docs/v3.4/devops-user-guide/how-to-integrate/sonarqube/ 。

按照步骤走完之后，不出意外的话意外又发生了，有两个工作负载没起来，分别是：

• sonarqube-sonarqube
• sonarqube-postgresql

通过查看Kubesphere观察，发现sonarqube-sonarqube一直在重启，于是我把存活探针与就绪探针暂时都去掉了。最后在日志发现报错如：

2020.11.27 09:55:47 INFO  web[][o.sonar.db.Database] Create JDBC data source for jdbc:postgresql://sonarqube-postgresql:5432/sonarDB
2020.11.27 09:55:47 ERROR web[][o.s.s.p.PlatformImpl] Web server startup failed
java.lang.IllegalStateException: Fail to connect to database

可以定位到时Postgresql有问题导致的，于是查看Postgresql服务的日志，发现：

Kubesphere sonarqube postgresql DETAIL: Role "sonarUser" does not exist

如果分析sonarqube-sonarqube和sonarqube-postgresql这两个工作负载配置文件可以发现，这个用户是sonarqube-postgresql在启动的时候创建的用户名，sonarqube-sonarqube也使用这个用户名去连接sonarqube-postgresql，密码存放在保密字典sonarqube-postgresql中。

通过上面的现象，可以分析出根本原因是sonarqube-postgresql在启动的时候根本没有创建sonarUser这个用户（可以通过sonarqube-postgresql的终端去验证）。

但是为什么sonarqube-postgresql没有成功创建出这个用户呢？

2. 原因分析

首先我把sonarqube-postgresql的两个探针都去掉了，重启，还是报同样的错误。

然后我把env中的POSTGRES_USER，POSTGRES_PASSWORD，POSTGRES_DB这三个值都改成新的值，重启，进入终端，发现还是无法创建用户。

这就很难办，最后通过查询，获得一个关键的信息（参考[1]）：

Warning: the Docker specific variables will only have an effect if you start the container with a data directory that is empty; any pre-existing database will be left untouched on container startup.

也就是说，之前第一次启动的时候，sonarqube-postgresql还没有初始化完，就给就绪探针给干掉了，导致只做了部分初始化而没有创建用户，重启的时候由于绑定的pv已经存在数据库了，于是又无法创建用户，整个过程如下：

3. 解决

要解决上面创建用户失败的问题，首先需要延长探针的时间initialDelaySeconds或者直接把探针先去掉，等创建完用户之后，再重新加进去，同时需要先删除已有的数据库，也就是说删除pv，于是必须先删除绑定的pvc，然后要删除pvc也必须先删除绑定的pod，由于statefulset的重启策略无法设定为Never，因此无法通过停止pod来删除pvc。套娃套到这里，就只能先保存sonarqube-postgresql的配置（如Postgresql.yaml），然后把这个statefulset先删除了，然后删除pvc和pv（pv对应的nfs路径下的数据也可以删除）。

# 删除Postgresql statefulset
kubectl delete statefulsets sonarqube-postgresql -n kubesphere-devops-system
# 删除pvc
kubectl delete pvc data-sonarqube-postgresql-0 -n kubesphere-devops-system
# 获取pv
PV=$(kubectl get pv -n kubesphere-devops-system | awk '$6 ~ /data-sonarqube-postgresql/ {print $1}')
# 查看pv对于的nfs路径
kubectl describe pv $PV | grep Path
# 删除pv
kubectl delete pv $PV
# （可选）登录nfs server所在主机，删除刚才获取的nfs路径

也可以通过Kubesphere进行操作。

然后删除Postgresql.yaml中的两个探针，重新创建statefulset，可以看到初始化过程还是很久的，在我的测试集群上差不多用了6分钟，日志如下：

postgresql 06:38:52.24 postgresql 06:38:52.24 Welcome to the Bitnami postgresql containerpostgresql 06:38:52.25 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresqlpostgresql 06:38:52.25 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issuespostgresql 06:38:52.25 Send us your feedback at [e-mail] 06:38:52.25 postgresql 06:38:52.26 INFO  ==> ** Starting PostgreSQL setup **postgresql 06:38:52.34 INFO  ==> Validating settings in POSTGRESQL_* env vars..postgresql 06:38:52.35 INFO  ==> Loading custom pre-init scripts...postgresql 06:38:52.36 INFO  ==> Initializing PostgreSQL database...postgresql 06:38:52.50 INFO  ==> postgresql.conf file not detected. Generating it...postgresql 06:38:52.51 INFO  ==> pg_hba.conf file not detected. Generating it...postgresql 06:38:52.51 INFO  ==> Generating local authentication configurationpostgresql 06:43:21.36 INFO  ==> Starting PostgreSQL in background...postgresql 06:44:38.05 INFO  ==> Creating user sonarUserpostgresql 06:44:38.14 INFO  ==> Grating access to "sonarUser" to the database "sonarDB"postgresql 06:44:38.23 INFO  ==> Configuring replication parameterspostgresql 06:44:38.28 INFO  ==> Configuring fsyncpostgresql 06:44:38.41 INFO  ==> Loading custom scripts...postgresql 06:44:38.42 INFO  ==> Enabling remote connectionspostgresql 06:44:38.44 INFO  ==> Stopping PostgreSQL...postgresql 06:44:41.46 INFO  ==> ** PostgreSQL setup finished! **postgresql 06:44:41.54 INFO  ==> ** Starting PostgreSQL **

回到sonarqube-sonarqube服务，发现已经可以连接上了，并开始了初始化进程，观察日志：

2023.09.27 07:16:21 INFO  web[][o.sonar.db.Database] Create JDBC data source for jdbc:postgresql://sonarqube-postgresql:5432/sonarDB2023.09.27 07:16:21 INFO  web[][o.s.s.p.ServerFileSystemImpl] SonarQube home: /opt/sonarqube2023.09.27 07:16:21 INFO  web[][o.s.s.u.SystemPasscodeImpl] System authentication by passcode is disabled2023.09.27 07:16:21 WARN  web[][o.s.s.p.DatabaseServerCompatibility] The database must be manually upgraded. Please backup the database and browse /setup. For more information: https://docs.sonarqube.org/latest/setup/upgrading2023.09.27 07:16:21 WARN  app[][startup] ################################################################################2023.09.27 07:16:21 WARN  app[][startup] The database must be manually upgraded. Please backup the database and browse /setup. For more information: https://docs.sonarqube.org/latest/setup/upgrading2023.09.27 07:16:21 WARN  app[][startup] ################################################################################

连是连上了，但是要升级数据库，沃得法克……

查了一下Sonarqube支持的Postgresql版本，发现并不需要升级，参考：https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/release-upgrade-notes/ 。

看前面的日志，Sonarqube运行一半又给探针干掉了……

于是我先删除Postgresql statefulset，删除pvc和pv，并清理了pv对应的nfs下面的路径。

然后重新创建Postgresql statefulset，等待初始化完成。

最后删除Sonarqube的两个探针并应用配置，最终终于输出：

2023.09.27 09:35:18 INFO  ce[][o.s.ce.app.CeServer] Compute Engine is operational
2023.09.27 09:35:18 INFO  app[][o.s.a.SchedulerImpl] Process[ce] is up
2023.09.27 09:35:18 INFO  app[][o.s.a.SchedulerImpl] SonarQube is up

抬头一看，一天又过去了。

4. 参考

[1] SonarQube Community Edition on k8s Role “sonarUser” does not exist

五、Kubesphere安装DevOps时Jenkins报Readiness probe failed

1. 问题

安装Kubesphere官方文档，启用DevOps组件，然后等待安装完后，发现devops-jenkins-xxxx-xxxx的pod一直起不来，describe一下，发现报错：

Readiness probe failed: Get "http://10.244.36.83:8080/login": dial tcp 10.244.36.83:8080: connect: connection refused

2. 解决

这种情况非常典型，就是就绪探针检测到服务没起来，一定次数之后，就把服务干掉了。然后服务重启，在服务又没起来的时候又把服务干掉了……然后陷入死循环。

原因是Jenkins在第一次启动的时候会去下载一些插件，导致时间很长，因此建议先把就绪探针和存活探针都删掉，重启服务，等第一次启动完成后，再重新启动，观察从开始启动到完全启动完成的时间，我是按照输出下面信息来判断是否完成：

2023-09-26 09:32:49.747+0000 [id=24] INFO hudson.WebAppMain$3#run: Jenkins is fully up and running

然后根据这个时间去设置两个探针的initialDelaySeconds值。