kubernetes mariadb-galera 集群-bitnami helm chart-就绪探测失败

Question 1

正如我们已经调查过的，您的 Probes 配置存在问题。很可能它们的参数未正确调整，因此 Pod 无法启动，因为它未通过就绪性检查。

为了使 Pod 正常启动，你可以禁用它们，或者调整你的探针配置为了满足您的要求：

探测器有许多字段，你可以使用它们来更精确地控制活性和就绪性检查的行为：

initialDelaySeconds：容器启动后到启动存活或就绪探测之间的时间间隔（秒）。默认为 0 秒。最小值为 0。

periodSeconds：执行探测的频率（以秒为单位）。默认为 10 秒。最小值为 1。

timeoutSeconds：探测超时后经过的秒数。默认为 1 秒。最小值为 1。

successThreshold：探测失败后，最少连续成功次数，才能被视为成功。默认为 1。必须为 1 才能表示活跃。最小值为 1。

failureThreshold：当探测失败时，Kubernetes 会尝试失败阈值次数，然后放弃。在存活探测的情况下放弃意味着重新启动容器。在就绪探测的情况下，Pod 将被标记为未就绪。默认值为 3。最小值为 1。

下面您将找到一些有用的资源，它们将对这一主题提供更多的见解：

此外，您看到的错误：

The mariadb configuration file '/opt/bitnami/mariadb/conf/my.cnf' is not writable or does not exist. Configurations based on environment variables will not be applied for this file.

意味着图表部署了一个 ConfigMap 并默认挂载它，因此它不能被容器镜像读取/写入，这完全没问题，您不必担心。

Answer

正如我们已经调查过的，您的 Probes 配置存在问题。很可能它们的参数未正确调整，因此 Pod 无法启动，因为它未通过就绪性检查。

为了使 Pod 正常启动，你可以禁用它们，或者调整你的探针配置为了满足您的要求：

探测器有许多字段，你可以使用它们来更精确地控制活性和就绪性检查的行为：

initialDelaySeconds：容器启动后到启动存活或就绪探测之间的时间间隔（秒）。默认为 0 秒。最小值为 0。

periodSeconds：执行探测的频率（以秒为单位）。默认为 10 秒。最小值为 1。

timeoutSeconds：探测超时后经过的秒数。默认为 1 秒。最小值为 1。

successThreshold：探测失败后，最少连续成功次数，才能被视为成功。默认为 1。必须为 1 才能表示活跃。最小值为 1。

failureThreshold：当探测失败时，Kubernetes 会尝试失败阈值次数，然后放弃。在存活探测的情况下放弃意味着重新启动容器。在就绪探测的情况下，Pod 将被标记为未就绪。默认值为 3。最小值为 1。

下面您将找到一些有用的资源，它们将对这一主题提供更多的见解：

此外，您看到的错误：

The mariadb configuration file '/opt/bitnami/mariadb/conf/my.cnf' is not writable or does not exist. Configurations based on environment variables will not be applied for this file.

意味着图表部署了一个 ConfigMap 并默认挂载它，因此它不能被容器镜像读取/写入，这完全没问题，您不必担心。

Question 2

我发现，这个问题与 NFS 服务器的访问方式有关。我使用了 Kubernetes 的 NFS 配置程序这里。该配置程序以 root 身份运行，这是 bitnami helm chart 的问题。在 chart 的 securityContext 中，用户和组为 1001:1001，这意味着它不以 root 身份运行。我的 NFS 服务器也设置为 root 访问权限。首先我需要更改我的 NFS 服务器共享：

/path/to/share *(rw,sync,no_subtree_check,no_root_squash,no_all_squash,insecure,anonuid=1001,anongid=1001)

重要的部分是anonuid和anongid以上。然后我为打算运行的每个 DB 节点创建了子文件夹。这些子文件夹稍后是 pv 中的挂载点。我用更改了整个共享的所有者chown 1001:1001 -R /path/to/share。这就是 NFS 服务器的全部内容。

接下来我在 kubernetes 集群上创建了 3 个 pv，每个 DB 节点一个。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: db-persistent-storage-0
  labels:
    app: mariadb-galera-cluster
  namespace: database
spec:
  capacity:
    storage: 1Gi
  mountOptions:
    - nolock
  accessModes:
    - ReadWriteMany
  nfs:
    server: SERVERIP
    path: /path/to/share/subfolder1
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: db-persistent-storage-1
  labels:
    app: mariadb-galera-cluster
  namespace: database
spec:
  capacity:
    storage: 1Gi
  mountOptions:
    - nolock
  accessModes:
    - ReadWriteMany
  nfs:
    server: SERVERIP
    path: /path/to/share/subfolder2
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: db-persistent-storage-2
  labels:
    app: mariadb-galera-cluster
  namespace: database
spec:
  capacity:
    storage: 1Gi
  mountOptions:
    - nolock
  accessModes:
    - ReadWriteMany
  nfs:
    server: SERVERIP
    path: /path/to/share/subfolder3

确保替换你的SERVERIP和/path/to/share以反映你自己的设置。在集群中创建后，我能够成功运行 bitnami 图表。我仍然收到上面原始帖子中提到的错误消息

Readiness probe failed: mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/opt/bitnami/mariadb/tmp/mysql.sock' (2)' 
Check that mysqld is running and that the socket: '/opt/bitnami/mariadb/tmp/mysql.sock' exists!

但这肯定是我没有更改的超时问题。所有 3 个 pod 现在都已启动并运行，并且似乎运行良好。如果您按照这些说明操作，请确保values.yaml调整持久卷设置以反映label上述 PV 中提到的部分。否则，helm chart 将不会获取这些现有卷并且不会创建节点。对于上述示例，该部分应如下所示：

persistence:
  ## If true, use a Persistent Volume Claim, If false, use emptyDir
  ##
  enabled: true
  ## selector can be used to match an existing PersistentVolume
  ##
  selector:
    matchLabels:
      app: mariadb-galera-cluster
  accessModes:
    - ReadWriteMany
  ## Persistent Volume size
  ##
  size: 1Gi

感谢你的帮助。

Answer