Восстановить кластер etcd в кластере

Вопрос или проблема

mv /etc/kubernetes/manifests/kube-apiserver.yaml /root
mv /etc/kubernetes/manifests/etcd.yaml /root
rm -rf /var/lib/etcd

E0129 20:09:01.930710       1 status.go:71] "Unhandled Error" err="apiserver получил ошибку, которая не является metav1.Status: rpctypes.EtcdError{code:0x5, desc:\"etcdserver: requ │
│ ested lease not found\"}: etcdserver: requested lease not found" logger="UnhandledError"

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
  certSANs:
  - 10.1.0.4
  - 128.140.XX.XX
  - d84af09d.k8s.example.com
  - 10.1.0.1
  - 10.1.0.6
  - 10.1.0.7
  - example.test.dev.dc1.control-plane01
  - example.test.dev.dc2.control-plane01
  - example.test.dev.dc3.control-plane01
  extraArgs:
  - name: etcd-servers
    value: https://10.1.0.1:2379,https://10.1.0.6:2379,https://10.1.0.7:2379
clusterName: dev_ansible
controlPlaneEndpoint: d84af09d.k8s.example.com:6443
etcd:
  local:
    imageTag: 3.5.17-0
kubernetesVersion: 1.31.5
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
certificateKey: b3f714a1ee2c0fc13b0f65709c79e8fd32f974e1b11c2df5af6e2708907d01e5
localAPIEndpoint:
  advertiseAddress: 10.1.0.1
nodeRegistration:
  kubeletExtraArgs:
  - name: node-ip
    value: 10.1.0.1
  - name: cloud-provider
    value: external

---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: JoinConfiguration
controlPlane:
  certificateKey: b3f714a1ee2c0fc13b0f65709c79e8fd32f974e1b11c2df5af6e2708907d01e5
  localAPIEndpoint:
    advertiseAddress: 10.1.0.6
discovery:
  bootstrapToken:
    apiServerEndpoint: 10.1.0.4:6443
    caCertHashes:
    - sha256:27810e47508b591dd30f4496d512eeb6b2e8edaef6ca62a80610be427141b974
    token: 501s39.zgw9kf8bo5dx3rhw
nodeRegistration:
  kubeletExtraArgs:
  - name: node-ip
    value: 10.1.0.6
  - name: cloud-provider
    value: external
  - name: resolv-conf
    value: /run/systemd/resolve/resolv.conf
  name: example.test.dev.dc.control-plane01

---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Ответ или решение

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

Теория

Kubernetes использует etcd в качестве хранилища данных о состоянии всего кластера. Это децентрализованное хранилище ключей, отвечающее за хранение и репликацию данных конфигурации и состояния. В случае сбоя оно должно быть надежно восстановлено из резервной копии, чтобы избежать потери данных и конфигурации.

Прежде чем приступить к восстановлению, важно понять ключевые аспекты работы etcd для Kubernetes:

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

Пример

Вы описали процесс, в котором перемещаете конфигурационные файлы и очищаете базу данных etcd перед восстановлением из резервной копии. Однако, когда вы начинаете процесс на дополнительных управляющих узлах, возникает ошибка: etcdserver: requested lease not found.

Это указывает на проблемы с конфигурацией кластера и потоком данных между узлами. Проблемы происходят, когда другие узлы кластера не могут согласовать свое состояние с первым узлом, вследствие чего страдает функциональность.

Применение

Давайте подробно разберем, какие шаги необходимо предпринять для успешного восстановления кластера etcd:

1. Подтверждение резервной копии: сначала убедитесь, что ваша резервная копия актуальна и непротиворечива. Используйте команду etcdctl snapshot status backup.db для получения информации о слоте резервной копии.

2. Остановка kube-apiserver и etcd на всех управляющих узлах: перейдите на каждый управляющий узел и временно удалите манифесты kube-apiserver.yaml и etcd.yaml из директории /etc/kubernetes/manifests. Это предотвратит автоматический запуск контейнеров.

3. Восстановление на главном узле (например, control-plane-1):

   • Восстановите etcd из резервной копии с помощью команды etcdctl snapshot restore backup.db --data-dir /var/lib/etcd.
   • Переместите etcd.yaml и kube-apiserver.yaml обратно в /etc/kubernetes/manifests на этом узле.

4. Конфигурация оставшихся узлов:

   • Убедитесь, что новые данные узлов etcd и параметры совпадают с восстановленными. Измените конфигурацию etcd.yaml, чтобы все узлы etcd могли правильно подключаться друг к другу.
   • Используйте команду kubectl get endpoints -n kube-system etcd для проверки доступности всех узлов. Все должны быть готовы.

5. Синхронизация других управляющих узлов:

   • Переместите конфигурацию etcd.yaml и kube-apiserver.yaml в /etc/kubernetes/manifests на каждом оставшемся управляющем узле. Это должно автоматически запустить контейнеры и инициировать процесс синхронизации.

6. Проверка и отладка:

   • Убедитесь, что все службы работают правильно. Используйте команды kubectl get nodes, kubectl get pods --all-namespaces и kubectl get events -n kube-system для выявления проблем.
   • Проверьте состояние etcd с etcdctl member list и etcdctl endpoint health.

Заключение

Успех восстановления зависит от внимательности к деталям и правильной конфигурации всех компонентов кластера. Проведите проверку всех конфигураций на предмет согласованности и правильности, проверьте корректность действия всех узлов. Рассмотрите возможность автоматизации регулярных проверок и тестирования восстановления для минимизации подобных проблем в будущем.