как восстановиться после сбоя мастера с помощью kubeadm

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

Когда рабочий узел выходит из строя, восстановление выполняется просто: я создаю новый рабочий узел с нуля, запускаю kubeadm join, и все в порядке.

Однако я не могу понять, как восстановиться после сбоя главного узла (не прерывая развертывания, запущенные на рабочих узлах). Нужно ли мне делать резервную копию и восстанавливать исходные сертификаты, или я могу просто запустить kubeadm init, чтобы создать новый мастер с нуля? Как мне присоединиться к существующим рабочим узлам?


kubernetes kubeadm
person fabstab    schedule 25.03.2018    source источник

Ответы (3)


arrow_upward
3
arrow_downward

В итоге я написал CronJob в Kubernetes резервную копию данных etcd. Если вам интересно: я написал об этом в блоге: https://labs.consol.de/kubernetes/2018/05/25/kubeadm-backup.html

В дополнение к этому вы можете сделать резервную копию всего /etc/kubernetes/pki, чтобы избежать проблем с обновлением секретов (токенов).

Например, kube-proxy использует секрет для хранения токена, и этот токен становится недействительным, если выполняется резервное копирование только сертификата etcd.

person fabstab    schedule 25.05.2018
comment
Я попытался выполнить эти шаги и смоделировать основной сбой с помощью kubeadm reset, но после того, как я выполнил шаги по восстановлению и kubeadm init с соответствующими флагами, сеть, похоже, сломалась. Я могу удалить, а затем воссоздать ситцевые стручки, поэтому все кажется работает, но стручки ни к чему не могут подключиться по сети ... Сталкивались ли вы раньше с подобными проблемами? - person EyfI; 30.08.2018
comment
Я использую фланель, и она отлично работает. Я мало что знаю о ситце, но этому может быть несколько причин. Возможно, calico очень часто обновляет состояние etcd и не может выполнить сброс etcd до состояния предыдущей резервной копии. Или, может быть, calico хранит состояние где-то еще на мастере, за пределами etcd. - person fabstab; 02.09.2018
comment
Спасибо за ответ. Похоже, это не проблема ситца, я просмотрел журналы, и большинство стручков выдавали несанкционированные ошибки. Это привело меня к следующему: github.com/rancher/rancher/issues/8388 и Я попробовал описанные шаги по удалению токенов serviceaccount для calico и других компонентов, в которых были эти ошибки, и это помогло. Я не уверен, почему это происходит, и это меня раздражает, поскольку мне приходилось делать это для довольно многих приложений. Я не думаю, что вы знаете, что может вызвать такие проблемы? - person EyfI; 03.09.2018
comment
Нет простите. Я не очень люблю Каллико. Рад, что вы нашли обходной путь. - person fabstab; 05.09.2018
comment
вау, ты это сделал! Я подумал, что это было очень круто, когда увидел это (нашел до этого поста). Кстати, еще одна интересная вещь для проверки - это Heptio Ark. (Уникальный способ резервного копирования etcd и pv) - person neokyle; 08.10.2018
comment
Danke für den Artikel, Фабиан! Mein Master Node sollte nun sicher sein. - person Michael; 05.02.2021

arrow_upward
1
arrow_downward

В соответствии с вашим упоминанием о резервном копировании мастера, на самом деле, если вы имеете в виду процедуры резервного копирования (например, традиционные / устаревшие инструменты / технологии резервного копирования), не упоминаются непосредственно в официальной документации (насколько я знаю), но вы можете принять меры предосторожности с помощью некоторых параметров / обходных путей :

person EngSabry    schedule 27.03.2018

arrow_upward
0
arrow_downward

kubeadm init определенно не будет работать из коробки, так как при этом будет создан новый кластер, учетные данные, пространство IP и т. Д.

Как минимум, для восстановления главного узла потребуется резервная копия ваших данных etcd. Обычно он находится в каталоге / var / lib / etcd.

Вам также понадобится конфигурация kubeadm из кластера, который kubeadm config view должен вывести это. (выше v1.8)

Пошаговое восстановление главного узла на самом деле не так чисто, поэтому они вводят HA - High Availability. Это гораздо более безопасный способ поддерживать избыточность и время безотказной работы. В частности, потому что восстановление чего-либо из etcd может быть настоящей болью (по моему скромному мнению и опыту).

Если я могу немного отклониться от темы вашего вопроса, если вы все еще начинаете работать с Kubernetes и не слишком много инвестируете в kubeadm, я бы посоветовал вам вместо этого подумать о создании кластера с kops. Он уже поддерживает HA, и я обнаружил, что kops более надежен и проще в использовании, чем kubeadm и kube-aws (построитель кластеров coreos). https://kubernetes.io/docs/getting-started-guides/kops/ < / а>

person nelsonenzo    schedule 25.03.2018