Ошибка CockroachDB на однокластерных Kube POD из-за CrashLoopBackOff

Использование VirtualBox и установки 4 x Centos7 OS.

После базовой установки кубернетов с одним кластером:

https://kubernetes.io/docs/setup/independent/install-kubeadm/ https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

[root@k8s-master cockroach]# kubectl get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   41m   v1.13.2
k8s-slave1   Ready    <none>   39m   v1.13.2
k8s-slave2   Ready    <none>   39m   v1.13.2
k8s-slave3   Ready    <none>   39m   v1.13.2

Я создал 3 x NFS PV на главном сервере, чтобы мои подчиненные могли подобрать их как часть cockroachdb-statefulset.yaml, как описано здесь:

https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/

Однако мои стручки тараканов просто постоянно не могут общаться друг с другом.

    [root@k8s-slave1 kubernetes]# kubectl get pods
NAME            READY   STATUS             RESTARTS   AGE
cockroachdb-0   0/1     CrashLoopBackOff   6          8m47s
cockroachdb-1   0/1     CrashLoopBackOff   6          8m47s
cockroachdb-2   0/1     CrashLoopBackOff   6          8m47s

[root@k8s-slave1 kubernetes]# kubectl get pvc
NAME                    STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
datadir-cockroachdb-0   Bound    cockroachdbpv0   10Gi       RWO                           17m
datadir-cockroachdb-1   Bound    cockroachdbpv2   10Gi       RWO                           17m
datadir-cockroachdb-2   Bound    cockroachdbpv1   10Gi       RWO                           17m

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

    [root@k8s-slave1 kubernetes]# kubectl logs cockroachdb-0
++ hostname -f
+ exec /cockroach/cockroach start --logtostderr --insecure --advertise-host cockroachdb-0.cockroachdb.default.svc.cluster.local --http-host 0.0.0.0 --join cockroachdb-0.cockroachdb,cockroachdb-1.cockroachdb,cockroachdb-2.cockroachdb --cache 25% --max-sql-memory 25%
W190113 17:00:46.589470 1 cli/start.go:1055  RUNNING IN INSECURE MODE!

- Your cluster is open for any client that can access <all your IP addresses>.
- Any user, even root, can log in without providing a password.
- Any user, connecting as root, can read or write any data in your cluster.
- There is no network encryption nor authentication, and thus no confidentiality.

Check out how to secure your cluster: https://www.cockroachlabs.com/docs/v2.1/secure-a-cluster.html
I190113 17:00:46.595544 1 server/status/recorder.go:609  available memory from cgroups (8.0 EiB) exceeds system memory 3.7 GiB, using system memory
I190113 17:00:46.600386 1 cli/start.go:1069  CockroachDB CCL v2.1.3 (x86_64-unknown-linux-gnu, built 2018/12/17 19:15:31, go1.10.3)
I190113 17:00:46.759727 1 server/status/recorder.go:609  available memory from cgroups (8.0 EiB) exceeds system memory 3.7 GiB, using system memory
I190113 17:00:46.759809 1 server/config.go:386  system total memory: 3.7 GiB
I190113 17:00:46.759872 1 server/config.go:388  server configuration:
max offset             500000000
cache size             947 MiB
SQL memory pool size   947 MiB
scan interval          10m0s
scan min idle time     10ms
scan max idle time     1s
event log enabled      true
I190113 17:00:46.759896 1 cli/start.go:913  using local environment variables: COCKROACH_CHANNEL=kubernetes-insecure
I190113 17:00:46.759909 1 cli/start.go:920  process identity: uid 0 euid 0 gid 0 egid 0
I190113 17:00:46.759919 1 cli/start.go:545  starting cockroach node
I190113 17:00:46.762262 22 storage/engine/rocksdb.go:574  opening rocksdb instance at "/cockroach/cockroach-data/cockroach-temp632709623"
I190113 17:00:46.803749 22 server/server.go:851  [n?] monitoring forward clock jumps based on server.clock.forward_jump_check_enabled
I190113 17:00:46.804168 22 storage/engine/rocksdb.go:574  opening rocksdb instance at "/cockroach/cockroach-data"
I190113 17:00:46.828487 22 server/config.go:494  [n?] 1 storage engine initialized
I190113 17:00:46.828526 22 server/config.go:497  [n?] RocksDB cache size: 947 MiB
I190113 17:00:46.828536 22 server/config.go:497  [n?] store 0: RocksDB, max size 0 B, max open file limit 60536
W190113 17:00:46.838175 22 gossip/gossip.go:1499  [n?] no incoming or outgoing connections
I190113 17:00:46.838260 22 cli/start.go:505  initial startup completed, will now wait for `cockroach init`
or a join to a running cluster to start accepting clients.
Check the log file(s) for progress.
I190113 17:00:46.841243 22 server/server.go:1402  [n?] no stores bootstrapped and --join flag specified, awaiting init command.
W190113 17:01:16.841095 89 cli/start.go:535  The server appears to be unable to contact the other nodes in the cluster. Please try:

- starting the other nodes, if you haven't already;
- double-checking that the '--join' and '--listen'/'--advertise' flags are set up correctly;
- running the 'cockroach init' command if you are trying to initialize a new cluster.

If problems persist, please see https://www.cockroachlabs.com/docs/v2.1/cluster-setup-troubleshooting.html.
I190113 17:01:31.357765 1 cli/start.go:756  received signal 'terminated'
I190113 17:01:31.359529 1 cli/start.go:821  initiating graceful shutdown of server
initiating graceful shutdown of server
I190113 17:01:31.361064 1 cli/start.go:872  too early to drain; used hard shutdown instead
too early to drain; used hard shutdown instead

... есть идеи, как отлаживать это дальше?


kubernetes cockroachdb
person Gareth    schedule 13.01.2019    source источник
comment
Я могу войти в контейнер докеров, созданный для тараканов, однако сбой приводит к тому, что он воссоздается в течение 20 секунд, что не позволяет мне искать какие-либо проблемы.   -  person Gareth    schedule 14.01.2019

Ответы (3)


arrow_upward
0
arrow_downward

Я просмотрел файл * .yaml по адресу https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/cockroachdb-statefulset.yaml Я заметил, что внизу не упоминается storageClassName, что означает, что во время процесса запроса тома контейнеры собираются ищите стандартный класс хранения. Я не уверен, использовали ли вы аннотацию ниже при подготовке 3 томов NFS -

storageclass.kubernetes.io/is-default-class=true

Вы должны иметь возможность проверить то же самое, используя -

kubectl get storageclass

Если в выходных данных не отображается класс хранилища Standard, я бы предложил либо перенастроить определения постоянных томов, добавив аннотацию, либо добавить пустую строку в качестве storageClassName в конец файла cockroach-statefulset.yaml.

Больше журналов можно просмотреть, используя -

kubectl describe cockroachdb-{statefulset}
person Mukesh Sharma    schedule 13.01.2019
comment
Спасибо. Я не уверен, что это проблема с хранением, поскольку каждый набор состояний таракана, привязанный к pv и проверяющий файловую систему, я вижу, что таракан создал свои файлы и каталоги по умолчанию. Описание просто показывает мне те же сообщения журналов, что и выше. Интересно, можно ли добавить многословности в команду запуска таракана. Я проверю это. - person Gareth; 13.01.2019
comment
К вашему сведению, я провел тест, изменив свой PV, чтобы он имел строку с именем mypv, а затем использовал то же определение в спецификации statefulset. Опять же, это сработало нормально, и стада тараканов привязались к клипам. PODS просто продолжают падать :( - person Gareth; 14.01.2019

arrow_upward
0
arrow_downward

Хорошо, дело дошло до того, что у меня был NAT в качестве внешнего сетевого адаптера виртуального бокса. Я изменил его на Bridged, и все стало отлично работать. Если бы кто-нибудь мог сказать мне, почему, это было бы здорово :)

person Gareth    schedule 26.01.2019

arrow_upward
0
arrow_downward

В моем случае с использованием диаграммы штурвала, как показано ниже:

$ helm install stable/cockroachdb \
  -n cockroachdb \
  --namespace cockroach \
  --set Storage=10Gi \
  --set NetworkPolicy.Enabled=true \
  --set Secure.Enabled=true

Подождите, чтобы закончить добавление csr для таракана:

$ watch kubectl get csr

На рассмотрении находятся несколько csr:

$ kubectl get csr
NAME                                         AGE    REQUESTOR                                                   CONDITION
cockroachdb.client.root                      130m   system:serviceaccount:cockroachdb:cockroachdb-cockroachdb   Pending
cockroachdb.node.cockroachdb-cockroachdb-0   130m   system:serviceaccount:cockroachdb:cockroachdb-cockroachdb   Pending
cockroachdb.node.cockroachdb-cockroachdb-1   129m   system:serviceaccount:cockroachdb:cockroachdb-cockroachdb   Pending
cockroachdb.node.cockroachdb-cockroachdb-2   130m   system:serviceaccount:cockroachdb:cockroachdb-cockroachdb   Pending

Чтобы утвердить этот запуск, выполните команду:

$ kubectl get csr -o json | \
  jq -r '.items[] | select(.metadata.name | contains("cockroach.")) | .metadata.name' | \
  xargs -n 1 kubectl certificate approve
person Bruno Wego    schedule 28.07.2019