УСТРАНЕНИЕ НЕПОЛАДОК ETCD SPLIT-BRAIN В КЛАСТЕРЕ KUBERNETES

TROUBLESHOOTING THE ETCD SPLIT-BRAIN IN KUBERNETES CLUSTER

Vadim Radyushin

Masters’s student, Department of Mathematical Support of Computer and Information Systems, Saratov State University,

Russia, Saratov

АННОТАЦИЯ

В 21-м веке в сфере информационных технологий особо выделяется рост облачных вычислений. В тоже время все больше используется средство для оркестрации контейнеров Kubernetes, как основа для построения облака. Kubernetes использует базу данных типа ключ-значение etcd для хранения своей конфигурации, а также актуального и желанного состояний. В высокодоступной конфигурации кластера, кворум etcd подвержен проблеме типа split-brain, поэтому важным навыком для облачных инженеров является умение устранять данную проблему.

ABSTRACT

In the 21st century, the information technology industry has seen the rise of cloud computing stand out. At the same time, the Kubernetes container orchestration tool is increasingly being used as the basis for building the cloud. Kubernetes uses the etcd key-value database to store its configuration and actual and desired state. In a HA cluster configuration, the etcd quorum is subject to a split-brain problem, so troubleshooting this problem is an important skill for cloud engineers.

Ключевые слова: etcd; Split-brain; Kubernetes.

Keywords: etcd; Split-brain; Kubernetes.

База данных etcd [1] – это распределенное хранилище данных типа ключ-значение. Оно имеет открытый исходный код и написан на языке программирования Golang [2]. Для создания консенсуса etcd использует алгоритм Raft [7]. Так как etcd является распределенным хранилищем, и обладает высокой доступностью, он используется внутри популярного средства оркестрации контейнеров Kubernetes [3].

При высокодоступной конфигурации кластера Kubernetes, когда количество мастер-узлов больше одного (на практике часто используется 3 или 5 мастер-узлов), etcd также собирается в кластер, где количество его членов равно количеству мастер-узлов. Однако, в таком случае возможен сценарий, когда etcd не удается обеспечить консистентность данных. Данное состояния называется split-brain, по аналогии с термином из медицины. Для кластера Kubernetes такое состояние скорее всего приведет к его деградации, так как API серверы будут пытаться применять разные сущность и не смогут согласовать свои действия.

Основными симптомами данной проблемы являются наличие ошибок типа “panic: failed to unmarshal mvccpb.KeyValue” с последующей остановкой процесса etcd и разница в размерах хранилища, что видно на Рисунке 1. При этом Kubernetes может показывать не соотносящиеся с реальностью статусы узлов. В связи с этим некоторые поды будут мигрировать с одного узла на другой, что приводит к простою. В тоже время новые поды не смогут получить IP-адрес, а старые могут зависнуть в состоянии Terminating.

Рисунок 1. Разница в размерах хранилищ etcd

Для решения данной проблемы необходимо исключить из кворума тот член etcd, размер хранилища которого отличается от остальных. Затем снова включить его в кластер и перезагрузить. Также вместе с членом etcd надо выключить соответствующий API сервер, для того, чтобы он не оказывал воздействие на кластер. Данные действия проводятся на узле, на котором запущен неисправный член etcd.

Так как компоненты Kubernetes control-plane являются статическими подами [4], то есть их конфигурация лежит на узле, и они не контролируются никакими внешними сущностями по типу ReplicaSet [5] или StatefulSet [6], то их нельзя отключить, просто масштабировав данные сущности в ноль. Поэтому надо переместить манифесты данных подов в какую-нибудь временную папку, чтобы не потерять их в дальнейшем. Это делается с помощью команд:

• mkdir /etc/kubernetes/manifests-tmp
• mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests-tmp/
• mv /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests-tmp/

Далее необходимо удостовериться, что поды остановились, затем удалить папку с данными etcd (var/lib/etcd/member) на узле. После этого надо исключить данный член etcd из кворума и включаем его обратно с помощью команд:

• etcdctl member remove <member-id>
• etcdctl member add <host-id>

Здесь <member-id> - уникальный идентификатор члена etcd, <host-id> - доменное имя узла.

Далее, необходимо изменить конфигурацию неисправного пода, добавив опции –initial-cluster=<members-list> и –initial-cluster-state=existing, где <members-list> это список разделенных запятой членов etcd в формате hostname=https://hostname:2380. После этого можно вернуть файл манифеста обратно:

• mv /etc/kubernetes/manifests-tmp/etcd.yaml /etc/kubernetes/manifests/

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

Рисунок 2. Выравнивание размеров хранилищ etcd

После успешного восстановления etcd, необходимо вернуть обратно файл манифеста API сервера Kubernetes, по аналогии с манифестом etcd.

Список литературы:

1. etcd [электронный ресурс] URL: https://etcd.io (дата обращения 02.05.2023).
2. Golang [электронный ресурс] URL: https://go.dev (дата обращения 01.05.2023).
3. Kubernetes [электронный ресурс] URL: https://kubernetes.io (дата обращения 01.05.2023).
4. Kubernetes static pods [электронный ресурс] URL: https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/ (дата обращения 01.05.2023).
5. Kubernetes ReplicaSet [электронный ресурс] URL: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/ (дата обращения 01.05.2023).
6. Kubernetes StatefulSet [электронный ресурс] URL: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ (дата обращения 01.05.2023).
7. Raft [электронный ресурс] URL: https://raft.github.io/raft.pdf (дата обращения 02.05.2023).