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

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

我正在尝试通过我的 kubernetes 集群(1 个主节点,3 个节点)中的 bitnami helm chart 设置 mariadb-galera 集群。我修改了我的值.yaml包括existingClaim: dbstorage图像storageClass: "nfs-storage"存储库是10.5.9-debian-10-r52,我添加了root密码,并注释掉accessModes:尺寸因为这是在现有持久性卷声明中定义的。我没有在 db: 部分中定义任何内容,而是将其保留为默认值。我也没有在galera.mariabackuppassword 等部分下定义任何内容,而是保留了默认值。

当我运行 Helm Charthelm install helm install mariadb-galera-cluster -f mariadb-galera.values.yaml bitnami/mariadb-galera --namespace database并描述 Pod 时,我收到错误消息

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!

当检查容器中是否存在该 mysql.sock 时,结果确实如此,即它在该位置不可用。

我正在使用 NFS 配置程序来配置持久存储,它工作正常。在我的 nfs 服务器上,我可以看到正在创建的目录和存储在其中的数据。它是容器使用的 NFS3 目录。

当我访问容器并尝试运行文件夹中的脚本“run.sh”或“entrypoint.sh”时,/opt/bitnami/scripts/mariadb-galera我收到错误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.,但文件就在它应该在的文件夹中。所有组件(如状态集)都已正确创建并启动,因为我可以判断,只是容器(在我的情况下,它显然称为 mariadb-galera-cluster-0)由于找不到套接字而无法完成启动。

Helm 版本:

version.BuildInfo{Version:"v3.5.4", GitCommit:"1b5edb69df3d3a08df77c9902dc17af864ff05d1", GitTreeState:"clean", GoVersion:"go1.15.11"}

Kubernetes 版本

Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31:21Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:25:06Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/amd64"}

values.yaml 文件的版本

## Please, note that this will override the image parameters, including dependencies, configured to use the global v$
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
#   imageRegistry: myRegistryName
#   imagePullSecrets:
#     - myRegistryKeySecretName
#   storageClass: myStorageClass

## Bitnami MariaDB Galera image
## ref: https://hub.docker.com/r/bitnami/mariadb-galera/tags/
##
image:
  registry: docker.io
  repository: bitnami/mariadb-galera
  tag: 10.5.9-debian-10-r52
  ## Specify a imagePullPolicy
  ## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: IfNotPresent
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistryKeySecretName

  ## Set to true if you would like to see extra information on logs
  ##
  debug: false

## String to partially override common.names.fullname template (will maintain the release name)
##
# nameOverride:

## String to fully override common.names.fullname template
##
# fullnameOverride:

## Use an alternate scheduler, e.g. "stork".
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
# schedulerName:

## Specifies the Kubernetes Cluster's Domain Name.
##
clusterDomain: cluster.local

## StatefulSet controller supports relax its ordering guarantees while preserving its uniqueness and identity guaran$
## ref: https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#pod-management-policy
##
podManagementPolicy: OrderedReady

## Deployment pod host aliases
## https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/
hostAliases: []

## MariaDB Gallera K8s svc properties
##
service:
  ## Kubernetes service type and port number
  ##
  type: ClusterIP
  port: 3306
  # clusterIP: None

  ## Specify the nodePort value for the LoadBalancer and NodePort service types.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
  ##
  # nodePort: 30001

  ## Specify the externalIP value ClusterIP service type.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips
  ##
  # externalIPs: []

  ## Set the LoadBalancer service type to internal only.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
  ##
  # loadBalancerIP:

  ## Load Balancer sources
  ## https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/#restrict-access-$
  ##
  # loadBalancerSourceRanges:
  # - 10.10.10.0/24

  ## Provide any additional annotations which may be required. This can be used to
  ## set the LoadBalancer service type to internal only.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
  ##
  annotations: {}

  ## Headless service properties
  ##
  headless:
    ## Additional annotations for headless service.
    ## Can be useful in case peer-finder is used in a sidecar,
    ## e.g.: service.alpha.kubernetes.io/tolerate-unready-endpoints="true"
    ##
    annotations: {}

## Pods Service Account
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
##
serviceAccount:
  ## Specifies whether a ServiceAccount should be created
  ##
  create: false
  ## The name of the ServiceAccount to use.
  ## If not set and create is true, a name is generated using the common.names.fullname template
  ##
  name: ""

## An array to add extra environment variables
## For example:
## extraEnvVars:
##  - name: TZ
##    value: "Europe/Paris"
##
extraEnvVars:

## ConfigMap with extra env vars:
##
extraEnvVarsCM:

## Secret with extra env vars:
##
extraEnvVarsSecret:

## Role Based Access
## Ref: https://kubernetes.io/docs/admin/authorization/rbac/
##
rbac:
  ## Specifies whether RBAC rules should be created
  ##
  create: false

## Pod Security Context
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
##
securityContext:
  enabled: true
  fsGroup: 1001
  runAsUser: 1001

## Database credentials for root (admin) user
##
rootUser:
  ## MariaDB admin user
  ##
  user: root
  ## MariaDB admin password
  ## Password is ignored if existingSecret is specified.
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb-galera#setting-the-root-password-on-first-run
  ##
  password: "ObviouslyIChangedThis"
  ## Option to force users to specify a password. That is required for 'helm upgrade' to work properly.
  ## If it is not force, a random password will be generated.
  ##
  forcePassword: false

## Use existing secret (ignores rootUser.password, db.password, and galera.mariabackup.password)
##
# existingSecret:

## Custom db configuration
##
db:
  ## MariaDB username and password
  ## Password is ignored if existingSecret is specified.
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb-galera#creating-a-database-user-on-first-run
  ##
  user: ""
  password: ""
  ## Database to create
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb-galera#creating-a-database-on-first-run
  ##
  name: my_database
  ## Option to force users to specify a password. That is required for 'helm upgrade' to work properly.
  ## If it is not force, a random password will be generated.
  ##
  forcePassword: false

## Galera configuration
##
galera:
  ## Galera cluster name
  ##
  name: galera

  ## Bootstraping options
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb-galera#bootstraping
  ##
  bootstrap:
    ## Node to bootstrap from, you will need to change this parameter in case you want to bootstrap from other node
    ##
    bootstrapFromNode:
    ## Force safe_to_bootstrap in grastate.date file.
    ## This will set safe_to_bootstrap=1 in the node indicated by bootstrapFromNode.
    ##
    forceSafeToBootstrap: false

  ## Credentials to perform backups
  ##
  mariabackup:
    ## MariaBackup username and password
    ## Password is ignored if existingSecret is specified.
    ## ref: https://github.com/bitnami/bitnami-docker-mariadb-galera#setting-up-a-multi-master-cluster
    ##
    user: mariabackup
    password: ""
    ## Option to force users to specify a password. That is required for 'helm upgrade' to work properly.
    ## If it is not force, a random password will be generated.
    ##
    forcePassword: false

## LDAP configuration
##
ldap:
  ## Enable LDAP support
  ##
  enabled: false
  uri: ""
  base: ""
  binddn: ""
  bindpw: ""
  bslookup:
  filter:
  map:
  nss_initgroups_ignoreusers: root,nslcd
  scope:
  tls_reqcert:

## TLS configuration
##
tls:
  ## Enable TLS
  ##
  enabled: false
  ## Name of the secret that contains the certificates
  ##
  # certificatesSecret:
  ## Certificate filename
  ##
  # certFilename:
  ## Certificate Key filename
  ##
  # certKeyFilename:
  ## CA Certificate filename
  ##
  # certCAFilename:

## Configure MariaDB with a custom my.cnf file
## ref: https://mysql.com/kb/en/mysql/configuring-mysql-with-mycnf/#example-of-configuration-file
## Alternatively, you can put your my.cnf under the files/ directory
mariadbConfiguration: |-
  [client]
  port=3306
  socket=/opt/bitnami/mariadb/tmp/mysql.sock
  plugin_dir=/opt/bitnami/mariadb/plugin
  [mysqld]
  default_storage_engine=InnoDB
  basedir=/opt/bitnami/mariadb
  datadir=/bitnami/mariadb/data
  plugin_dir=/opt/bitnami/mariadb/plugin
  tmpdir=/opt/bitnami/mariadb/tmp
  socket=/opt/bitnami/mariadb/tmp/mysql.sock
  pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
  bind_address=0.0.0.0
  ## Character set
  ##
  collation_server=utf8_unicode_ci
  init_connect='SET NAMES utf8'
  character_set_server=utf8
  ## MyISAM
  ##
  key_buffer_size=32M
  myisam_recover_options=FORCE,BACKUP
  ## Safety
  ##
  skip_host_cache
  skip_name_resolve
  max_allowed_packet=16M
  max_connect_errors=1000000
  sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTI$
  sysdate_is_now=1
  ## Binary Logging
  ##
  log_bin=mysql-bin
  expire_logs_days=14
  # Disabling for performance per http://severalnines.com/blog/9-tips-going-production-galera-cluster-mysql
  sync_binlog=0
  # Required for Galera
  binlog_format=row
  ## Caches and Limits
  ##
  tmp_table_size=32M
  max_heap_table_size=32M
  # Re-enabling as now works with Maria 10.1.2
  query_cache_type=1
  query_cache_limit=4M
  query_cache_size=256M
  max_connections=500
  thread_cache_size=50
  open_files_limit=65535
  table_definition_cache=4096
  table_open_cache=4096
  ## InnoDB
  ##
  innodb=FORCE
  innodb_strict_mode=1
  # Mandatory per https://github.com/codership/documentation/issues/25
  innodb_autoinc_lock_mode=2
  # Per https://www.percona.com/blog/2006/08/04/innodb-double-write/
  innodb_doublewrite=1
  innodb_flush_method=O_DIRECT
  innodb_log_files_in_group=2
  innodb_log_file_size=128M
  innodb_flush_log_at_trx_commit=1
  innodb_file_per_table=1
  # 80% Memory is default reco.
  # Need to re-evaluate when DB size grows
  innodb_buffer_pool_size=2G
  innodb_file_format=Barracuda
  ## Logging
  ##
  log_error=/opt/bitnami/mariadb/logs/mysqld.log
  slow_query_log_file=/opt/bitnami/mariadb/logs/mysqld.log
  log_queries_not_using_indexes=1
  slow_query_log=1
  ## SSL
  ## Use extraVolumes and extraVolumeMounts to mount /certs filesystem
  # ssl_ca=/certs/ca.pem
  # ssl_cert=/certs/server-cert.pem
  # ssl_key=/certs/server-key.pem
  [galera]
  wsrep_on=ON
  wsrep_provider=/opt/bitnami/mariadb/lib/libgalera_smm.so
  wsrep_sst_method=mariabackup
  wsrep_slave_threads=4
  wsrep_cluster_address=gcomm://
  wsrep_cluster_name=galera
  wsrep_sst_auth="root:"
  # Enabled for performance per https://mariadb.com/kb/en/innodb-system-variables/#innodb_flush_log_at_trx_commit
  innodb_flush_log_at_trx_commit=2
  # MYISAM REPLICATION SUPPORT #
  wsrep_replicate_myisam=ON
  [mariadb]
  plugin_load_add=auth_pam
  ## Data-at-Rest Encryption
  ## Use extraVolumes and extraVolumeMounts to mount /encryption filesystem
  # plugin_load_add=file_key_management
  # file_key_management_filename=/encryption/keyfile.enc
  # file_key_management_filekey=FILE:/encryption/keyfile.key
  # file_key_management_encryption_algorithm=AES_CTR
  # encrypt_binlog=ON
  # encrypt_tmp_files=ON
  ## InnoDB/XtraDB Encryption
  # innodb_encrypt_tables=ON
  # innodb_encrypt_temporary_tables=ON
  # innodb_encrypt_log=ON
  # innodb_encryption_threads=4
  # innodb_encryption_rotate_key_age=1
  ## Aria Encryption
  # aria_encrypt_tables=ON
  # encrypt_tmp_disk_tables=ON
## ConfigMap with MariaDB configuration
## NOTE: This will override mariadbConfiguration
##
# configurationConfigMap:

## Specify dictionary of scripts to be run at first boot
## Alternatively, you can put your scripts under the files/docker-entrypoint-initdb.d directory
##
# initdbScripts:
#   my_init_script.sh: |
#      #!/bin/sh
#      echo "Do something."

## ConfigMap with scripts to be run at first boot
## Note: This will override initdbScripts
##
# initdbScriptsConfigMap:

## MariaDB additional command line flags
## Can be used to specify command line flags, for example:
##
## extraFlags: "--max-connect-errors=1000 --max_connections=155"
##

## Desired number of cluster nodes
##
replicaCount: 3

## updateStrategy for MariaDB Master StatefulSet
## ref: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies
##
updateStrategy:
  type: RollingUpdate

## Additional labels for MariaDB Galera pods
## ref: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
##
podLabels: {}

## Additional annotations for MariaDB Galera pods
## ref: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
##
podAnnotations: {}

## Pod affinity preset
## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity
## Allowed values: soft, hard
##
podAffinityPreset: ""

## Pod anti-affinity preset
## Ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity
## Allowed values: soft, hard
##
podAntiAffinityPreset: soft

## Node affinity preset
## Ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity
## Allowed values: soft, hard
##
nodeAffinityPreset:
  ## Node affinity type
  ## Node affinity type
  ## Allowed values: soft, hard
  ##
  type: ""
  ## Node label key to match
  ## E.g.
  ## key: "kubernetes.io/e2e-az-name"
  ##
  key: ""
  ## Node label values to match
  ## E.g.
  ## values:
  ##   - e2e-az1
  ##   - e2e-az2
  ##
  values: []

## Affinity for pod assignment. Evaluated as a template.
## Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
## Note: podAffinityPreset, podAntiAffinityPreset, and nodeAffinityPreset will be ignored when it's set
##
affinity: {}

## Node labels for pod assignment. Evaluated as a template.
## ref: https://kubernetes.io/docs/user-guide/node-selection/
##
nodeSelector: {}

## Tolerations for pod assignment. Evaluated as a template.
## ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
tolerations: []

## Enable persistence using Persistent Volume Claims
## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
##
persistence:
  ## If true, use a Persistent Volume Claim, If false, use emptyDir
  ##
  enabled: true
  # Enable persistence using an existing PVC
  existingClaim: dbstorage
  # Subdirectory of the volume to mount
  # subPath:
  mountPath: /bitnami/mariadb
  ## selector can be used to match an existing PersistentVolume
  ## selector:
  ##   matchLabels:
  ##     app: my-app
  ##
  selector: {}
  ## Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  storageClass: "nfs-storage"
  ## Persistent Volume Claim annotations
  ##
  annotations:
  ## Persistent Volume Access Mode
  ##
  #accessModes:
  #  - ReadWriteOnce
  ## Persistent Volume size
  ##
  #size: 8Gi

## Priority Class Name
#
# priorityClassName: 'priorityClass'

## Additional init containers
##
extraInitContainers: []
# - name: do-something
#   image: bitnami/minideb
#   command: ['do', 'something']

## Additional containers
##
extraContainers: []

## extraVolumes and extraVolumeMounts allows you to mount other volumes
## Example Use Cases:
##  mount certificates to enable data-in-transit encryption
##  mount keys for data-at-rest encryption using file plugin
# extraVolumes:
# - name: mariadb-certs
#   secret:
#     defaultMode: 288
#     secretName: mariadb-certs
# - name: mariadb-encryption
#   secret:
#     defaultMode: 288
#     secretName: mariadb-encryption
# extraVolumeMounts:
# - name: mariadb-certs
#   mountPath: /certs
#   readOnly: true
# - name: mariadb-encryption
#   mountPath: /encryption
#   readOnly: true

## MariaDB Galera containers' resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources:
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  limits: {}
  #   cpu: 0.5
  #   memory: 256Mi
  requests: {}
  #   cpu: 0.5
  #   memory: 256Mi

## MariaDB Galera containers' liveness and readiness probes
## ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
##
livenessProbe:
  enabled: true
  ## Initializing the database could take some time
  ##
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
readinessProbe:
  enabled: true
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
startupProbe:
  enabled: false
  ## Initializing the database could take some time
  ##
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  ## Let's wait 600 seconds by default, it should give enough time in any cluster for mysql to init
  ##
  failureThreshold: 48

## Pod disruption budget configuration
##
podDisruptionBudget:
  ## Specifies whether a Pod disruption budget should be created
  ##
  create: false
  minAvailable: 1
  # maxUnavailable: 1

## Prometheus exporter configuration
##
metrics:
  enabled: false
  ## Bitnami MySQL Prometheus exporter image
  ## ref: https://hub.docker.com/r/bitnami/mysqld-exporter/tags/
  ##
  image:
    registry: docker.io
    repository: bitnami/mysqld-exporter
    tag: 0.12.1-debian-10-r416
    pullPolicy: IfNotPresent
    ## Optionally specify an array of imagePullSecrets.
    ## Secrets must be manually created in the namespace.
    ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
    ##
    # pullSecrets:
    #   - myRegistryKeySecretName
  ## MySQL exporter additional command line flags
  ## Can be used to specify command line flags
  ## E.g.:
  ## extraFlags:
  ##   - --collect.binlog_size
  ##
  extraFlags: []
  ## MySQL Prometheus exporter containers' resource requests and limits
  ## ref: http://kubernetes.io/docs/user-guide/compute-resources/
  ##
  resources:
    # We usually recommend not to specify default resources and to leave this as a conscious
    # choice for the user. This also increases chances charts run on environments with little
    # resources, such as Minikube. If you do want to specify resources, uncomment the following
    # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
    limits: {}
    #   cpu: 0.5
    #   memory: 256Mi
    requests: {}
    #   cpu: 0.5
    #   memory: 256Mi
  ## MySQL Prometheus exporter service parameters
  ##
  service:
    type: ClusterIP
    port: 9104
    annotations:
      prometheus.io/scrape: "true"
      prometheus.io/port: "9104"

  ## Prometheus Operator ServiceMonitor configuration
  ##
  serviceMonitor:
    enabled: false
    ## Namespace in which Prometheus is running
    ##
    # namespace: monitoring

    ## Interval at which metrics should be scraped.
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
    ##
    # interval: 10s

    ## Timeout after which the scrape is ended
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
    ##
    # scrapeTimeout: 10s

    ## ServiceMonitor selector labels
    ## ref: https://github.com/bitnami/charts/tree/master/bitnami/prometheus-operator#prometheus-configuration
    ##
    selector:
      prometheus: kube-prometheus
    ## RelabelConfigs to apply to samples before scraping
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#relabelconfig
    ## Value is evalued as a template
    ##
    relabelings: []

    ## MetricRelabelConfigs to apply to samples before ingestion
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#relabelconfig
    ## Value is evalued as a template
    ##
    metricRelabelings: []
    #  - sourceLabels:
    #      - "__name__"
    #    targetLabel: "__name__"
    #    action: replace
    #    regex: '(.*)'
    #    replacement: 'example_prefix_$1'

  ## Prometheus Operator PrometheusRule configuration
  ##
  prometheusRules:
    enabled: false

    ## Additional labels to add to the PrometheusRule so it is picked up by the operator.
    ## If using the [Helm Chart](https://github.com/helm/charts/tree/master/stable/prometheus-operator) this is the $
    ##
    selector:
      app: prometheus-operator
      release: prometheus

    ## Rules as a map.
    ##
    rules: {}
    #  - alert: MariaDB-Down
    #    annotations:
    #      message: 'MariaDB instance {{ $labels.instance }} is down'
    #      summary: MariaDB instance is down
    #    expr: absent(up{job="mariadb-galera"} == 1)
    #    labels:
    #      severity: warning
    #      service: mariadb-galera
    #    for: 5m

编辑 从容器初始化中添加日志文件:

mariadb 13:59:39.44
mariadb 13:59:39.44 Welcome to the Bitnami mariadb-galera container
mariadb 13:59:39.45 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mariadb-galera
mariadb 13:59:39.45 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mariadb-galera/issues
mariadb 13:59:39.46
mariadb 13:59:39.47 INFO  ==> ** Starting MariaDB setup **
mariadb 13:59:40.30 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mariadb 13:59:40.41 DEBUG ==> Set Galera cluster address to gcomm://
mariadb 13:59:40.42 INFO  ==> Initializing mariadb database
mariadb 13:59:40.43 DEBUG ==> Ensuring expected directories/files exist
mariadb 13:59:40.46 WARN  ==> 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.
mariadb 13:59:40.49 DEBUG ==> Cleaning data directory to ensure successfully initialization
Installing MariaDB/MySQL system tables in '/bitnami/mariadb/data' ...

不幸的是,就是这样。容器现在处于“CrashLoopBackOff”状态。它已经重新启动了 7 次,但无法完成。我可以在 NFS 服务器上看到“data”目录已创建,其中包含 2 个文件,“aria_log_control”和“mysql-bin.index”。my.cnf 看起来像是由 root 拥有的,但据我在文档中找到的,该容器是非 root 容器,因此该文件不可写。但它肯定在那里。我检查了好几次。如果我描述 pod,我会收到上面提到的错误消息“就绪探测失败”。

结束编辑

编辑2 以下是关于就绪状态和活跃度探测的详细信息。

## MariaDB Galera containers' liveness and readiness probes
## ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
##
livenessProbe:
  enabled: true
  ## Initializing the database could take some time
  ##
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
readinessProbe:
  enabled: true
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
startupProbe:
  enabled: false
  ## Initializing the database could take some time
  ##
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  ## Let's wait 600 seconds by default, it should give enough time in any cluster for mysql to init
  ##
  failureThreshold: 48

结束编辑

编辑3 我别无选择,只能回复我的原始帖子。否则我将超出 stackoverflow 的字符限制。 结束编辑

如果您能提供任何帮助或提示,让集群启动并运行,我将不胜感激。

真影


所以我按照你的建议 @WytrzymałyWiktor 禁用了就绪性和活跃性探测。这样,所有 3 个实例都会立即启动。问题是它们之间没有通信。因此,尽管 pod 正在运行,但它们无法正常工作,也无法相互通信。

答案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 并默认挂载它,因此它不能被容器镜像读取/写入,这完全没问题,您不必担心。

答案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)

重要的部分是anonuidanongid以上。然后我为打算运行的每个 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

感谢你的帮助。

相关内容