кластер kubernetes mariadb-galera - диаграмма управления bitnami - ошибка проверки готовности

Я пытаюсь настроить кластер mariadb-galera через диаграмму управления битнами в моем кластере kubernetes (1 мастер, 3 узла). Я изменил myvalues.yaml , чтобы включить existingClaim: dbstorage и класс хранения : "nfs-storage" . Репозиторий образов - 10.5.9-debian-10-r52 , я добавил пароль root и закомментировал accessModes: , а также размер как это было определено в существующей заявке на постоянный объем . Я ничего не определил в разделе db: и оставил это значение по умолчанию. Я также ничего не определил в разделе galera.mariabackup , например пароль, и оставил значения по умолчанию.

Как только я запускаю диаграмму управления с помощью helm install helm install mariadb-galera-cluster -f mariadb-galera.values.yaml bitnami / mariadb-galera --namespace database и описываю модуль I получить сообщение об ошибке

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 , я получаю сообщение об ошибке Файл конфигурации mariadb '/opt/bitnami/mariadb/conf/my.cnf' недоступен для записи или не существует. Конфигурации, основанные на переменных среды, не будут применяться к этому файлу. , но файл находится прямо в папке, где он должен быть. Все компоненты, такие как набор с отслеживанием состояния, создаются и запускаются правильно, поскольку я могу сказать, что только контейнер, в моем случае он явно назывался 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, но, насколько я мог найти в документации, контейнер не является корневым, поэтому файл не будет доступен для записи. Но он определенно есть. Я проверял это несколько раз. Если я описываю модуль, я получаю упомянутое выше сообщение об ошибке «Ошибка проверки готовности».

КОНЕЦ РЕДАКТИРОВАНИЯ

РЕДАКТИРОВАНИЕ 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. End EDIT

Я был бы признателен за любую помощь или подсказку, которую вы можете предоставить, чтобы настроить и запустить кластер.

realshadow


Итак, я последовал вашему совету @ WytrzymałyWiktor и отключил зонды готовности и живучести. Таким образом, все 3 экземпляра запускаются сразу. Проблема в том, что они не общаются друг с другом. Журналы из Таким образом, несмотря на то, что модули работают, они не работают и не обмениваются данными между собой.

0
задан 6 May 2021 в 17:14
2 ответа

Как мы уже выяснили, возникла проблема с конфигурацией ваших зондов. Скорее всего, их параметры были настроены неправильно, поэтому Pod не мог запуститься из-за провала проверки готовности.

Чтобы модуль запускался должным образом, вы можете либо отключить их, либо настроить зонд в соответствии с вашими требованиями:

У зондов есть ряд полей, которые вы можете использовать для более точного управлять поведением проверок жизнеспособности и готовности:

  • initialDelaySeconds: количество секунд после запуска контейнера, прежде чем инициируются проверки живучести или готовности. По умолчанию 0 секунд. Минимальное значение равно 0.

  • periodSeconds: как часто (в секундах) выполнять проверку. По умолчанию 10 секунд. Минимальное значение равно 1.

  • timeoutSeconds: количество секунд, по истечении которых время ожидания зонда истекает. По умолчанию 1 секунда. Минимальное значение равно 1.

  • successThreshold: минимальное количество последовательных успешных попыток проверки, которые считаются успешными после сбоя. По умолчанию 1. Должно быть 1 для живости. Минимальное значение – 1.

  • failureThreshold: при сбое зонда Kubernetes будет пытаться выполнить failureThreshold раз, прежде чем сдаться. Сдача в случае живучести probe означает перезапуск контейнера. В случае готовности прощупать Pod будет помечен как Unreaded. По умолчанию 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 и монтирует ее по умолчанию, поэтому она недоступна для чтения/записи образом контейнера, что совершенно нормально и не должно вас беспокоить.

0
ответ дан 13 May 2021 в 12:24

Как я выяснил, проблема была связана с доступом к серверу NFS. Я использовал средство подготовки NFS для Kubernetes здесь. Этот поставщик работает от имени пользователя root, и это было проблемой с диаграммой битнами. В securityContext диаграммы пользователь и группа равны 1001:1001, что означает, что он не запускается от имени пользователя root. Мой сервер NFS также был настроен с корневым доступом. сначала мне нужно было изменить общий ресурс сервера NFS:

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

Важными частями являются anoniid и anongid выше. Затем я создал подпапки для каждого узла БД, который собираюсь запустить. Эти подпапки являются точками монтирования в pv позже. Я изменил владельца всего общего ресурса с помощью chown 1001:1001 -R /path/to/share. Это было для сервера NFS.

Затем я создал 3 pvs в кластере kubernetes, по одному для каждого узла БД.

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 на собственные настройки. После создания в кластере я смог успешно запустить диаграмму битнами. Я все еще получаю сообщение об ошибке, упомянутое в моем первоначальном посте выше

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 модуля уже запущены и работают нормально. Если вы следуете этим инструкциям, убедитесь, что в values.yaml вы настроили постоянные параметры громкости, чтобы отразить раздел label, упомянутый в PV выше. В противном случае рулевая диаграмма не подберет эти существующие тома и не создаст узлы.Для приведенных выше примеров этот раздел должен выглядеть так:

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

Спасибо за вашу помощь.

1
ответ дан 20 May 2021 в 16:13

Теги

Похожие вопросы