Кластер CockroachDB при сбое подов Kubernetes

Я пытаюсь установить диаграмму CockroachDB Helm в кластере Kubernetes с двумя узлами, используя эту команду:

helm install my-release --set statefulset.replicas=2 stable/cockroachdb

Я уже создал 2 постоянных тома:

NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                          STORAGECLASS   REASON   AGE
pv00001   100Gi      RWO            Recycle          Bound    default/datadir-my-release-cockroachdb-0                           11m
pv00002   100Gi      RWO            Recycle          Bound    default/datadir-my-release-cockroachdb-1                           11m

У меня странная ошибка, я новичок в Kubernetes, поэтому не уверен, что делаю не так. Я пробовал создать StorageClass и использовать его с моими PV, но тогда PVC CockroachDB не привязывались к ним. Я подозреваю, что что-то не так с моей настройкой PV?

Я пробовал использовать kubectl logs, но вижу единственную ошибку:

standard_init_linux.go: 211: пользовательский процесс exec вызвал "ошибку формата exec"

и стручки рушатся снова и снова:

NAME                                    READY   STATUS             RESTARTS   AGE
my-release-cockroachdb-0            0/1     Pending            0          11m
my-release-cockroachdb-1            0/1     CrashLoopBackOff   7          11m
my-release-cockroachdb-init-tfcks   0/1     CrashLoopBackOff   5          5m29s

Есть идеи, почему стручки ломаются?

Вот kubectl describe для модуля init:

Name:         my-release-cockroachdb-init-tfcks
Namespace:    default
Priority:     0
Node:         axon/192.168.1.7
Start Time:   Sat, 04 Apr 2020 00:22:19 +0100
Labels:       app.kubernetes.io/component=init
              app.kubernetes.io/instance=my-release
              app.kubernetes.io/name=cockroachdb
              controller-uid=54c7c15d-eb1c-4392-930a-d9b8e9225a45
              job-name=my-release-cockroachdb-init
Annotations:  <none>
Status:       Running
IP:           10.44.0.1
IPs:
  IP:           10.44.0.1
Controlled By:  Job/my-release-cockroachdb-init
Containers:
  cluster-init:
    Container ID:  docker://82a062c6862a9fd5047236feafe6e2654ec1f6e3064fd0513341a1e7f36eaed3
    Image:         cockroachdb/cockroach:v19.2.4
    Image ID:      docker-pullable://cockroachdb/cockroach@sha256:511b6d09d5bc42c7566477811a4e774d85d5689f8ba7a87a114b96d115b6149b
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/bash
      -c
      while true; do initOUT=$(set -x; /cockroach/cockroach init --insecure --host=my-release-cockroachdb-0.my-release-cockroachdb:26257 2>&1); initRC="$?"; echo $initOUT; [[ "$initRC" == "0" ]] && exit 0; [[ "$initOUT" == *"cluster has already been initialized"* ]] && exit 0; sleep 5; done
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Sat, 04 Apr 2020 00:28:04 +0100
      Finished:     Sat, 04 Apr 2020 00:28:04 +0100
    Ready:          False
    Restart Count:  6
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-cz2sn (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-cz2sn:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-cz2sn
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  <unknown>             default-scheduler  Successfully assigned default/my-release-cockroachdb-init-tfcks to axon
  Normal   Pulled     5m9s (x5 over 6m45s)  kubelet, axon      Container image "cockroachdb/cockroach:v19.2.4" already present on machine
  Normal   Created    5m8s (x5 over 6m45s)  kubelet, axon      Created container cluster-init
  Normal   Started    5m8s (x5 over 6m44s)  kubelet, axon      Started container cluster-init
  Warning  BackOff    92s (x26 over 6m42s)  kubelet, axon      Back-off restarting failed container

person Alex W    schedule 03.04.2020    source источник
comment
Самое важное сообщение - это журналы Pod. Это показывает, что дуга изображения таракана не совпадает с узлами. Запустите kubectl get po -o wide, чтобы получить узлы, по которым бегает таракан, и проверить их арку.   -  person kitt    schedule 04.04.2020
comment
@kitt Пожалуйста, добавьте в ответ подробности, и я приму   -  person Alex W    schedule 06.04.2020


Ответы (3)


Когда поды выходят из строя, самое важное для устранения неполадок - это их описания (kubectl describe) и журналы.

Журналы неисправного стручка показывают, что дуга изображения таракана не совпадает с узлами.

Запустите kubectl get po -o wide, чтобы получить узлы, по которым бегает таракан, и проверить их арку.

person kitt    schedule 06.04.2020

Кластер CockroachDB с двумя узлами - это анти-шаблон < / а>. Вам нужно 3 или более узлов, чтобы избежать недоступности данных или всего кластера при выходе из строя одного узла. Посмотрите эти видеоролики, объясняющие как организованы данные в CockroachDB, а затем как узлы в кластере работают вместе, чтобы сохранить доступность данных в случае сбоя узла.

person jseldess    schedule 04.04.2020
comment
Я планирую в ближайшее время масштабировать его до более чем двух узлов, но я не думаю, что наличие двух узлов - это то, что вызывает сбой, не так ли? - person Alex W; 05.04.2020
comment
Возможно, проблема не в установке с двумя узлами, вы правы. Я спрошу в CockraochDB. - person jseldess; 05.04.2020
comment
Спасибо, мне интересно, нужно ли что-то настроить с помощью диаграммы Helm или PV, но я не уверен - person Alex W; 05.04.2020
comment
Я думаю, что комментарий Китта к вашему первоначальному сообщению на самом деле является ответом: похоже, вы работаете на руку, но CockroachDB публикует только образы докеров amd64. На данный момент вам нужно переключиться на серверы amd64, но не стесняйтесь также комментировать связанные с этим проблемы GitHub, требующие поддержки arm. - person jseldess; 06.04.2020

Только если у вас 3 узла (или больше), вы не рискуете потерять данные, если какая-либо из заметок будет повреждена. Кроме того, легче объяснить, как это сделать правильно, чем выяснить, что пошло не так, а чтобы выяснить, что пошло не так, нужно просмотреть журналы.

Если приложите журнал, я могу посмотреть.

Я также написал подробное руководство, в котором может быть указано, что нужно делать правильно. моего ответа. Я подробно рассказал обо всем процессе здесь < / а>.

person Michael Haephrati    schedule 27.10.2020