[Системное администрирование, *nix, DevOps, Микросервисы, Kubernetes] Ломаем и чиним Kubernetes
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Kubernetes отличная платформа как для оркестрации контейнеров так и для всего остального. За последнее время Kubernetes ушёл далеко вперёд как по части функциональности так и по вопросам безопасности и отказоустойчивости. Архитектура Kubernetes позволяет с лёгкостью переживать сбои различного характера и всегда оставаться на плаву.Сегодня мы будем ломать кластер, удалять сертификаты, вживую реджойнить ноды и всё это, по возможности, без даунтайма для уже запущенных сервисов.
Итак приступим. Основной control-plane Kubernetes состоит всего из нескольких компонентов:
- etcd - используется в качестве базы данных
- kube-apiserver - API и сердце нашего кластера
- kube-controller-manager - производит операции над Kubernetes-ресурсами
- kube-scheduller - основной шедуллер
- kubelet'ы - которые непосредственно и запускают контейнеры на хостах
Каждый из этих компонентов защищён набором TLS-сертификатов, клиентских и серверных, которые используются для аутентификации и авторизации компонентов между ссобой. Они не хранятся где-либо в базе данных Kuberentes, за исключением определенных случаев, а представлены в виде обычных файлов:
# tree /etc/kubernetes/pki/
/etc/kubernetes/pki/
├── apiserver.crt
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt
├── ca.key
├── CTNCA.pem
├── etcd
│ ├── ca.crt
│ ├── ca.key
│ ├── healthcheck-client.crt
│ ├── healthcheck-client.key
│ ├── peer.crt
│ ├── peer.key
│ ├── server.crt
│ └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub
Сами компоненты описаны и запускаются на мастерах как static pods из директории /etc/kubernetes/manifests/На этом месте не будем останавливаться подробно, т.к. это тема для отдельной статьи. В данном случае нас в первую очередь интересует как из этого всего добра получить рабочий кластер. Но для начала давайте немного абстрагируемся, и представим что у нас есть вышеперечисленные компоненты Kubernetes, которые как-то коммуницируют между ссобой.Основная схема выглядит примерно так:
(стрелочки указывают на связи клиент --> сервер)Для коммуникации им нужны TLS-сертификаты, которые в принципе можно вынести на отдельный уровень абстракции и полностью довериться вашему инструменту деплоя, будь-то kubeadm, kubespray или что либо ещё. В этой статье мы разберём kubeadm т.к. это наиболее стандартный инструмент для развёртывания Kubernetes, а также он часто используется в составе других решений.Предположим, что у нас уже есть задеплоенный кластер. Начнём с самого интересного:
rm -rf /etc/kubernetes/
На мастерах данная директория содержит:
- Набор сертификатов и CA для etcd (в /etc/kubernetes/pki/etcd)
- Набор сертификатов и CA для Kubernetes (в /etc/kubernetes/pki)
- Kubeconfig для cluster-admin, kube-controller-manager, kube-scheduller и kubelet (каждый из них также имеет закодированный в base64 CA-сертификат для нашего кластера /etc/kubernetes/*.conf)
- Набор статик-манифеств для etcd, kube-apiserver, kube-scheduller и kube-controller-manager (в /etc/kubernetes/manifests)
Чиним control-planeЧтобы не было недоразумений, давайте также убедимся что все наши control-plane поды также остановлены:
crictl rm `crictl ps -aq`
Примечание: kubeadm по умолчанию не перезаписывает уже существующие сертификаты и кубеконфиги, для того чтобы их перевыпустить их необходимо сначала удалить вручную.
Давайте начнём с восстановления etcd, так как если у нас был кворум (3 и более мастер-нод) etcd-кластер не запустится без присутсвия большинства из них.
kubeadm init phase certs etcd-ca
- сгенерит новый CA для нашего etcd-кластера. Так как все остальные сертификаты должны быть им подписанны, скопируем его вместе с приватным ключём на остальные мастер-ноды:
/etc/kubernetes/pki/etcd/ca.{key,crt}
Теперь перегенерим остальные etcd-сертификаты и static-манифесты для него на всех control-plane нодах:
kubeadm init phase certs etcd-healthcheck-client
kubeadm init phase certs etcd-peer
kubeadm init phase certs etcd-server
kubeadm init phase etcd local
На этом этапе у нас уже должен подняться работоспособный etcd-кластер:
# crictl ps
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID
ac82b4ed5d83a 0369cf4303ffd 2 seconds ago Running etcd 0 bc8b4d568751b
Теперь давайте проделаем тоже самое, но для для Kubernetes, на одной из master-нод выполним:
kubeadm init phase certs all
kubeadm init phase kubeconfig all
kubeadm init phase control-plane all
cp -f /etc/kubernetes/admin.conf ~/.kube/config
Вышеописанные комманды удалят и перегенирируют все SSL-сертификаты нашего Kubernetes-кластера.Если вы используете kubeadm для джойна кубелетов, вам также потребуется обновить конфиг cluster-info в kube-public неймспейсе т.к. он до сих пор содержит хэш вашего старого CA.
kubeadm init phase bootstrap-token
Так как все сертификаты на других инстансах также должны быть подписаны одним CA, скопируем его на остальные control-plane ноды, и повторим вышеописанные комманды на каждой из них.
/etc/kubernetes/pki/{ca,front-proxy-ca}.{key,crt}
/etc/kubernetes/pki/sa.{key,pub}
Кстати, в качестве альтернативы ручного копирования сертификатов теперь вы можете использовать интерфейс Kubernetes, например следующая команда:
kubeadm init phase upload-certs --upload-certs
Зашифрует и загрузит сертификаты в Kubernetes на 2 часа, таким образом вы сможете сделать реджойн мастеров следующим образом:
kubeadm join phase control-plane-prepare all kubernetes-apiserver:6443 --control-plane --token cs0etm.ua7fbmwuf1jz946l --discovery-token-ca-cert-hash sha256:555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8 --certificate-key 385655ee0ab98d2441ba8038b4e8d03184df1806733eac131511891d1096be73
kubeadm join phase control-plane-join all
Стоит заметить, что в API Kubernetes есть ещё один конфиг, который хранит CA сертификат для front-proxy client, он используется для аутентификации запросов от apiserver в вебхуках и прочих aggregation layer сервисах. К счастью kube-apiserver обновляет его автоматически.Однако возможно вы захотите почистить его от старых сертификатов вручную:
kubectl get cm -n kube-system extension-apiserver-authentication -o yaml
В любом случае на данном этапе мы уже имеем полностью рабочий control-plane.??Чиним воркеровЭта компанда выведет список всех нод кластера, хотя сейчас все они будут в статусе NotReady:
kubectl get node
Это потому что они по прежнему используют старые сертификаты и с ожидают запросов apiserver, подписанных старым CA. Для того чтобы это исправить мы воспользуемся kubeadm, и сделаем реджойн нод в кластер.Когда как мастера имеют доступ к CA и могут быть присоеденены локально:
systemctl stop kubelet
rm -rf /var/lib/kubelet/pki/ /etc/kubernetes/kubelet.conf
kubeadm init phase kubeconfig kubelet
kubeadm init phase kubelet-start
То для джойна воркеров мы сгенерируем новый токен:
kubeadm token create --print-join-command
и на каждом из них выполним:
systemctl stop kubelet
rm -rf /var/lib/kubelet/pki/ /etc/kubernetes/pki/ /etc/kubernetes/kubelet.conf
kubeadm join phase kubelet-start kubernetes-apiserver:6443 --token cs0etm.ua7fbmwuf1jz946l --discovery-token-ca-cert-hash sha256:555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8
Внимание, удалять директорию /etc/kubernetes/pki/ на мастерах не нужно, так как она уже содержит все необходимые сертификаты.
Вышеописанная процедура переподключит все ваши kubelet'ы обратно к кластеру, при этом никак не повлияет на уже запущенные на них контейнеры. Однако если у вас в кластере много нод и вы сделаете это неодновременно, у вас может возникнуть ситуация когда controller-manger начнёт пересоздавать контейнеры с NotReady-нод и пытаться их запустить на живых нодах кластера.Чтобы это предотвратить мы можем временно остановить controller-manager, на мастерах:
rm /etc/kubernetes/manifests/kube-controller-manager.yaml
crictl rmp `crictl ps --name kube-controller-manager -q`
Последняя команда нужна просто для того, чтобы удостовериться что под с controller-manager действительно не запущен. Как только все ноды кластера будут присоеденены мы можем сгенерировать static-manifest для controller-manager обратно.Для этого на всех мастерах выполняем:
kubeadm init phase control-plane controller-manager
Учтите что делать это нужно на этапе когда вы уже сгенерировали join token, в противном случае операция подключения зависнет на попытке прочитать токен из cluser-info.
В случае если kubelet настроен на получение сертификата подписанного вашим CA (опция serverTLSBootstrap: true), вам также потребуется заново подтвердить csr от ваших kubelet'ов:
kubectl get csr
kubectl certificate approve <csr>
Чиним ServiceAccountsЕсть ещё один момент. Так как мы потеряли /etc/kubernetes/pki/sa.key - это тот самый ключ которм были подписанны jwt-токены для всех наших ServiceAccounts, то мы должны пересоздать токены для каждого из них.Сделать это можно достаточно просто, удалив все секреты типа kubernetes.io/service-account-token:
kubectl get secret --all-namespaces | awk '/kubernetes.io\/service-account-token/ { print "kubectl delete secret -n " $1 " " $2}' | sh -s
После чего kube-controller-manager автоматически сгенерирует новые, подписанные новым ключём.К сожалению далеко не все микросервисы умеют на лету перечитывать токен и скорее всего вам потребуется вручную перезапустить контейнеры, где они используются:
kubectl get pod --field-selector 'spec.serviceAccountName!=default' --no-headers --all-namespaces | awk '{print "kubectl delete pod -n " $1 " " $2}'
Например эта команда выведет список команд для удаления всех подов импользующих недефолтный serviceAccount. Рекомендую начать с неймспейса kube-system, т.к. там может быть установлен kube-proxy и CNI-плагин, жизненно необходимые для настройки коммуникации ваших микросервисов. На этом восстановление кластера можно считать оконченым. Спасибо за внимание! В следующей статье мы подробнее рассмотрим бэкап и восстановление etcd-кластера.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, Программирование, Кодобред, *nix, Оболочки] Консольный менеджер сертификатов для JKS/PCKS12
- [Высокая производительность, Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Микросервисы] Envoy как универсальный сетевой примитив
- [Microsoft Azure, DevOps, Облачные сервисы] Основы сервиса Microsoft Azure Blueprints
- [Настройка Linux, Open source, Системное администрирование, IT-инфраструктура, Серверное администрирование] Тиражирование Fedora из-под Fedora
- [Системное администрирование, IT-инфраструктура, Виртуализация] Exchange Server и правила его виртуальной жизни
- [PostgreSQL, Администрирование баз данных, DevOps, Kubernetes] Кластер PostgreSQL внутри Kubernetes: что нужно знать для успешного внедрения
- [Open source, Системное администрирование, Виртуализация, Openshift] Подробное руководство по релизам OpenShift и процессу обновления для администраторов
- [Интерфейсы, Промышленное программирование, Управление разработкой, Микросервисы] Энтерпрайз, который выжил. Доклад в Яндексе
- [Разработка веб-сайтов, *nix, Разработка под e-commerce, Управление e-commerce] Интернет-магазин «на минималках»
- [Облачные вычисления, DevOps, Kubernetes] Как предоставить доступ к кластеру Kubernetes с помощью клиентского сертификата: простое руководство (перевод)
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_*nix, #_devops, #_mikroservisy (Микросервисы), #_kubernetes, #_kubernetes, #_kubeadm, #_sertifikaty (сертификаты), #_administrirovanie (администрирование), #_administrirovanie_linuxsistem (администрирование linux-систем), #_kto_chitaet_tegi? (кто читает тэги?), #_sistemnoe_administrirovanie (
Системное администрирование
), #_*nix, #_devops, #_mikroservisy (
Микросервисы
), #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:28
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Kubernetes отличная платформа как для оркестрации контейнеров так и для всего остального. За последнее время Kubernetes ушёл далеко вперёд как по части функциональности так и по вопросам безопасности и отказоустойчивости. Архитектура Kubernetes позволяет с лёгкостью переживать сбои различного характера и всегда оставаться на плаву.Сегодня мы будем ломать кластер, удалять сертификаты, вживую реджойнить ноды и всё это, по возможности, без даунтайма для уже запущенных сервисов.  Итак приступим. Основной control-plane Kubernetes состоит всего из нескольких компонентов:
# tree /etc/kubernetes/pki/
/etc/kubernetes/pki/ ├── apiserver.crt ├── apiserver-etcd-client.crt ├── apiserver-etcd-client.key ├── apiserver.key ├── apiserver-kubelet-client.crt ├── apiserver-kubelet-client.key ├── ca.crt ├── ca.key ├── CTNCA.pem ├── etcd │ ├── ca.crt │ ├── ca.key │ ├── healthcheck-client.crt │ ├── healthcheck-client.key │ ├── peer.crt │ ├── peer.key │ ├── server.crt │ └── server.key ├── front-proxy-ca.crt ├── front-proxy-ca.key ├── front-proxy-client.crt ├── front-proxy-client.key ├── sa.key └── sa.pub  (стрелочки указывают на связи клиент --> сервер)Для коммуникации им нужны TLS-сертификаты, которые в принципе можно вынести на отдельный уровень абстракции и полностью довериться вашему инструменту деплоя, будь-то kubeadm, kubespray или что либо ещё. В этой статье мы разберём kubeadm т.к. это наиболее стандартный инструмент для развёртывания Kubernetes, а также он часто используется в составе других решений.Предположим, что у нас уже есть задеплоенный кластер. Начнём с самого интересного: rm -rf /etc/kubernetes/
crictl rm `crictl ps -aq`
Примечание: kubeadm по умолчанию не перезаписывает уже существующие сертификаты и кубеконфиги, для того чтобы их перевыпустить их необходимо сначала удалить вручную.
kubeadm init phase certs etcd-ca
/etc/kubernetes/pki/etcd/ca.{key,crt}
kubeadm init phase certs etcd-healthcheck-client
kubeadm init phase certs etcd-peer kubeadm init phase certs etcd-server kubeadm init phase etcd local # crictl ps
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID ac82b4ed5d83a 0369cf4303ffd 2 seconds ago Running etcd 0 bc8b4d568751b kubeadm init phase certs all
kubeadm init phase kubeconfig all kubeadm init phase control-plane all cp -f /etc/kubernetes/admin.conf ~/.kube/config kubeadm init phase bootstrap-token
/etc/kubernetes/pki/{ca,front-proxy-ca}.{key,crt}
/etc/kubernetes/pki/sa.{key,pub} kubeadm init phase upload-certs --upload-certs
kubeadm join phase control-plane-prepare all kubernetes-apiserver:6443 --control-plane --token cs0etm.ua7fbmwuf1jz946l --discovery-token-ca-cert-hash sha256:555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8 --certificate-key 385655ee0ab98d2441ba8038b4e8d03184df1806733eac131511891d1096be73
kubeadm join phase control-plane-join all kubectl get cm -n kube-system extension-apiserver-authentication -o yaml
kubectl get node
systemctl stop kubelet
rm -rf /var/lib/kubelet/pki/ /etc/kubernetes/kubelet.conf kubeadm init phase kubeconfig kubelet kubeadm init phase kubelet-start kubeadm token create --print-join-command
systemctl stop kubelet
rm -rf /var/lib/kubelet/pki/ /etc/kubernetes/pki/ /etc/kubernetes/kubelet.conf kubeadm join phase kubelet-start kubernetes-apiserver:6443 --token cs0etm.ua7fbmwuf1jz946l --discovery-token-ca-cert-hash sha256:555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8 Внимание, удалять директорию /etc/kubernetes/pki/ на мастерах не нужно, так как она уже содержит все необходимые сертификаты.
rm /etc/kubernetes/manifests/kube-controller-manager.yaml
crictl rmp `crictl ps --name kube-controller-manager -q` kubeadm init phase control-plane controller-manager
Учтите что делать это нужно на этапе когда вы уже сгенерировали join token, в противном случае операция подключения зависнет на попытке прочитать токен из cluser-info.
kubectl get csr
kubectl certificate approve <csr> kubectl get secret --all-namespaces | awk '/kubernetes.io\/service-account-token/ { print "kubectl delete secret -n " $1 " " $2}' | sh -s
kubectl get pod --field-selector 'spec.serviceAccountName!=default' --no-headers --all-namespaces | awk '{print "kubectl delete pod -n " $1 " " $2}'
=========== Источник: habr.com =========== Похожие новости:
Системное администрирование ), #_*nix, #_devops, #_mikroservisy ( Микросервисы ), #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:28
Часовой пояс: UTC + 5