另外 SonarQube 容器运行的时候，不是以 root 用户运行的，所以需要确保挂载的目录要允许其他用户读写，否则容器启动会失败。
chmod -R 777 /opt/ops_ceph_data/sonarqube/sonar_data 2. 创建 Service使用 NodePort 类型将 SonarQube 端口映射出来，yaml 文件内容如下：
--- apiVersion: v1 kind: Service metadata: name: sonarqube-service labels: app: sonarqube-service spec: type: NodePort ports: - port: 9000 targetPort: 9000 nodePort: 30900 protocol: TCP selector: app: sonarqube 3. 创建 SonarQube 的 PodSonarQube 的 Pod 使用 Deployment 来创建，yaml 文件内容如下：
--- apiVersion: apps/v1 kind: Deployment metadata: name: sonarqube namespace: ns-sonar labels: app: sonarqube spec: replicas: 1 selector: matchLabels: app: sonarqube template: metadata: labels: app: sonarqube spec: initContainers: # 设置初始化镜像，用于执行 system 命令，此处的配置在下文会有说明 - name: init-sysctl image: busybox imagePullPolicy: IfNotPresent command: ["sysctl", "-w", "vm.max_map_count=262144"] # 设置vm.max_map_count这个值调整内存权限，否则启动可能报错 securityContext: privileged: true # 设置可以以 root 权限执行命令 containers: - name: sonarqube image: sonarqube:7.9.4-community ports: - containerPort: 9000 env: - name: SONARQUBE_JDBC_USERNAME # 设置 SonarQube 连接数据库使用的用户名 value: sonarUser - name: SONARQUBE_JDBC_PASSWORD # 设置 SonarQube 连接数据库使用的密码 value: sonar_admin - name: SONARQUBE_JDBC_URL # 设置 SonarQube 连接数据库使用的地址 value: "jdbc:postgresql://10.16.12.206:30543/sonarDB" # 这里可以指定 Node 节点的 IP 地址和 PostgreSQL 映射出来的端口 livenessProbe: # 设置容器存活检查策略，如果失败将杀死容器，然后根据 Pod 的 restartPolicy 来决定是否进行重启操作 httpGet: path: /sessions/new port: 9000 initialDelaySeconds: 60 # 设置在容器启动多长时间后开始探针检测，此处设置为 60s periodSeconds: 30 # 设置探针检查的频率，此处设置为每 30s 检查一次 readinessProbe: # 设置容器的就绪检查策略，查看容器是否准备好接受 HTTP 请求 httpGet: path: /sessions/new port: 9000 initialDelaySeconds: 60 # 设置在容器启动多长时间后开始探针检测，此处设置为 60s periodSeconds: 30 # 设置探针检查的频率，此处设置为每 30s 检查一次 failureThreshold: 6 # 在检查失败的情况下，重复检查的次数，此处设置为 6 resources: limits: cpu: 2000m memory: 2048Mi requests: cpu: 1000m memory: 1024Mi volumeMounts: - mountPath: /opt/sonarqube/conf name: sonarqube subPath: conf # 使用 subPath 在宿主机的挂载目录上设置一个子目录，用于存放上面指定目录的数据 - mountPath: /opt/sonarqube/data name: sonarqube subPath: data - mountPath: /opt/sonarqube/extensions name: sonarqube subPath: extensions volumes: - name: sonarqube persistentVolumeClaim: claimName: sonar-pvc #绑定上面创建的 PVC对于上面的 yaml 文件有些配置需要进行说明。
3.1 initContainersinitContainers 就是初始化容器，也就是在主容器启动之前，首先启动初始化容器。如果有多个初始化容器，会按照定义的顺序依次启动。只有在初始化容器启动完成后，主容器才会启动。
使用初始化容器有如下几个作用：
为主容器初始化环境：例如本文中的例子，由于 SonarQube 在启动服务的时候，要确保已经设置了 vm.max_map_count 这个值，但是由于 SonarQube 镜像本身不能执行这个命令，所以可以使用一个初始化容器来执行该命令（同一个Pod下的容器是共享文件系统的），并且保证该命令已经执行完成的情况下，主容器才会启动。或者另一种情况是主容器启动的时候需要安装一些依赖包，为了避免安装依赖包时间过长，影响健康检查策略，可以选择将这个安装的任务交给初始化容器去执行。
等待其他服务 Ready：例如一个 web 服务的 Pod 启动时，需要确保另一个数据库服务的 Pod 已经启动了并且可以接受连接（不然 web 服务可能会报错或者启动失败），所以可以在 web 服务的 Pod 中部署一个初始化容器，去检查数据库服务是否已经准备好，直到数据库可以开始连接，初始化容器才会推出。
初始化集群配置：例如可以使用初始化容器检测当前业务集群中已经存在的节点信息，并为主容器准备好集群的配置信息，这样集群启动时就可以根据这个配置信息加入到集群中。
需要注意的是，initContainers 是以 sideCar 模式运行在 Pod 中的。
3.2 健康检查策略关于健康检查策略，上面的 yaml 文件中已经给出了一些注释。其他的配置项可以参考官网文档：
3.3 subPath 配置上面的 yaml 文件中在存储挂载的部分使用了 subPath 配置，这是因为 SonarQube 中一共有三个需要挂载的目录：
/opt/sonarqube/conf
/opt/sonarqube/data
/opt/sonarqube/extensions