Один узел Kubernetes mariadb galera

Я пытаюсь установить galera mariadb в свой кластер. У меня только один узел, но я планирую масштабировать его в будущем. Вроде нормально устанавливается.

При развертывании пишет:

** Please be patient while the chart is being deployed **
Tip:
  Watch the deployment status using the command:
    kubectl get sts -w --namespace databases -l app.kubernetes.io/instance=galera
and then other things here

Он говорит мне проверить статус, но статус всегда:

galera-mariadb-galera   0/1     8m

kubectl описать pod/galera-mariadb-galera-0 --namespace databases

Name:           galera-mariadb-galera-0
Namespace:      databases
Priority:       0
Node:           <none>
Labels:         app.kubernetes.io/instance=galera
                app.kubernetes.io/managed-by=Helm
                app.kubernetes.io/name=mariadb-galera
                controller-revision-hash=galera-mariadb-galera-8d5cc8855
                helm.sh/chart=mariadb-galera-5.3.2
                statefulset.kubernetes.io/pod-name=galera-mariadb-galera-0
Annotations:    <none>
Status:         Pending
IP:             
IPs:            <none>
Controlled By:  StatefulSet/galera-mariadb-galera
Containers:
  mariadb-galera:
    Image:       docker.io/bitnami/mariadb-galera:10.5.8-debian-10-r26
    Ports:       3306/TCP, 4567/TCP, 4568/TCP, 4444/TCP
    Host Ports:  0/TCP, 0/TCP, 0/TCP, 0/TCP
    Command:
      bash
      -ec
      exec /opt/bitnami/scripts/mariadb-galera/entrypoint.sh /opt/bitnami/scripts/mariadb-galera/run.sh
      
    Liveness:  exec [bash -ec exec mysqladmin status -u$MARIADB_ROOT_USER -p$MARIADB_ROOT_PASSWORD
] delay=120s timeout=1s period=10s #success=1 #failure=3
    Readiness:  exec [bash -ec exec mysqladmin status -u$MARIADB_ROOT_USER -p$MARIADB_ROOT_PASSWORD
] delay=30s timeout=1s period=10s #success=1 #failure=3
    Environment:
      MY_POD_NAME:                          galera-mariadb-galera-0 (v1:metadata.name)
      BITNAMI_DEBUG:                        false
      MARIADB_GALERA_CLUSTER_NAME:          galera
      MARIADB_GALERA_CLUSTER_ADDRESS:       address-is-here-removed-unsure-if-private
      MARIADB_ROOT_USER:                    root
      MARIADB_ROOT_PASSWORD:                <set to the key 'mariadb-root-password' in secret 'galera-mariadb-galera'>  Optional: false
      MARIADB_USER:                         default-db-user
      MARIADB_PASSWORD:                     <set to the key 'mariadb-password' in secret 'galera-mariadb-galera'>  Optional: false
      MARIADB_DATABASE:                     default-db-name
      MARIADB_GALERA_MARIABACKUP_USER:      mariabackup
      MARIADB_GALERA_MARIABACKUP_PASSWORD:  <set to the key 'mariadb-galera-mariabackup-password' in secret 'galera-mariadb-galera'>  Optional: false
      MARIADB_ENABLE_LDAP:                  no
      MARIADB_ENABLE_TLS:                   no
    Mounts:
      /bitnami/mariadb from data (rw)
      /opt/bitnami/mariadb/.bootstrap from previous-boot (rw)
      /opt/bitnami/mariadb/conf/my.cnf from mariadb-galera-config (rw,path = "my.cnf")
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-8qzpx (ro)
Conditions:
  Type           Status
  PodScheduled   False 
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-galera-mariadb-galera-0
    ReadOnly:   false
  previous-boot:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  mariadb-galera-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      galera-mariadb-galera-configuration
    Optional:  false
  default-token-8qzpx:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-8qzpx
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason             Age    From                Message
  ----     ------             ----   ----                -------
  Warning  FailedScheduling   2m23s                      0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Warning  FailedScheduling   2m23s                      0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Normal   NotTriggerScaleUp  97s    cluster-autoscaler  pod didn't trigger scale-up (it wouldn't fit if a new node is added):
$: 

Я не уверен, что может быть причиной проблемы.

Если я сделаю:

kubectl logs pod/galera-mariadb-galera-0  --namespace databases

Ничего не показывает.

Если я сделаю:

 kubectl get pvc data-galera-mariadb-galera-0 --namespace databases


NAME                           STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
data-galera-mariadb-galera-0   Pending                                      do-block-storage   70m

kubectl описать pvc data-galera-mariadb-galera-0 --namespace databases

Name:          data-galera-mariadb-galera-0
Namespace:     databases
StorageClass:  do-block-storage
Status:        Pending
Volume:        
Labels:        app.kubernetes.io/instance=galera
               app.kubernetes.io/managed-by=Helm
               app.kubernetes.io/name=mariadb-galera
Annotations:   volume.beta.kubernetes.io/storage-provisioner: dobs.csi.digitalocean.com
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Mounted By:    galera-mariadb-galera-0
Events:
  Type     Reason                Age                   From                                                                                           Message
  ----     ------                ----                  ----                                                                                           -------
  Normal   ExternalProvisioning  3m59s (x26 over 10m)  persistentvolume-controller                                                                    waiting for a volume to be created, either by external provisioner "dobs.csi.digitalocean.com" or manually created by system administrator
  Normal   Provisioning          85s (x10 over 10m)    dobs.csi.digitalocean.com_master-cluster-id-here  External provisioner is provisioning volume for claim "databases/data-galera-mariadb-galera-0"
  Warning  ProvisioningFail

Вышеупомянутая проблема заключалась в том, что у меня было открыто слишком много существующих хранилищ. Я сейчас удалил их и передислоцировал.

Пожалуйста, добавьте вывод kubectl get pvc data-galera-mariadb-galera-0 к вашему вопросу

confused genius 16.12.2020 19:28

Спасибо, я добавил вывод в конец вопроса.

Peter 16.12.2020 19:35

PVC находится в состоянии pending, и пока он не перейдет в состояние Bound, POD не перейдет в состояние running. Пожалуйста, добавьте ``` kubectl description pvc data-galera-mariadb-galera-0 ``` также к вашему вопросу

confused genius 16.12.2020 19:42

добавил в низ, спасибо

Peter 16.12.2020 20:10

Спасибо, кажется, теперь работает, проблема была в существующих томах. Вы можете создать ответ сейчас, чтобы я подтвердил его.

Peter 16.12.2020 20:41
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
2
5
761
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий
  • Pod находится в состоянии «Ожидание» из-за того, что PVC «data-galera-mariadb-galera-0» находится в несвязанном состоянии. Как только PVC перейдет в состояние Bound, POD перейдет в рабочее состояние.

Опубликуйте это как Community Wiki, чтобы расширить комментарий и ответ выше.

Как правило, MariaDB не может быть развернут, так как для этой установки требуется PersistentVolume, который должен быть создан с использованием Dynamic Provisioning , поскольку OP использует облачную среду — DigitalOcean. Поскольку PersistentVolume не был создан, он не мог быть связан с PersistentVolumeClaim, поэтому pod застрял в состоянии Pedning.

Как заявил ОП в нижней части вопроса:

Вышеупомянутая проблема заключалась в том, что у меня было открыто слишком много существующих хранилищ. Я сейчас удалил их и передислоцировал.

Kubernetes не может его создать из-за DigitalOceanограничений. OP заявил, что использует один узел и уже имеет 10 хранилищ.

  • Неподтвержденные пользователи могут иметь до 10 томов на регион и до 500 ГБ дискового пространства на регион.
  • По умолчанию пользователи могут создать до 100 томов и до 16 ТиБ дискового пространства на регион. Вы можете связаться с нашей службой поддержки, чтобы запросить увеличение. Вы можете подключить максимум 7 томов к любому узлу или дроплету, и это ограничение не может быть изменено.

Другие вопросы по теме