Comments 20
Спасибо! Все как всегда по полочкам!
Подскажите, почему говорят не "управление" а "оркестрация". В чем разница?
Хороший вопрос. Думаю разницы в терминах особой нет, но попробую выразить своё субъективное мнение на этот счёт.
Формально управлением контейнеров занимается docker, containerd или другой CRI-демон. Kubernetes — грубо говоря, это плоскость управления для таких вот CRI, со своим API и шедуллером.
То есть вы сообщаете Kubernetes что конкретно должно быть запущенно, с какими параметрами и в скольких экземплярах. Он находит свободные ноды и и даёт команду на запуск контейнеров на них. Чем не оркестрация?
Мне трудно сказать есть ли эта разница в русском языке.
Но оркестрация в computing, если можно так сказать, это скорее мета-управление. Слово от "оркестр" где "орхестрированием" занимается дирижер, он не говорит как водить смычком или какие клавиши нажимать — это было бы уже управление более примитивными сущностями.
Дирижер имеет дело с самодостаточными профессионалами, которые и сами по семе могут играть а в оркестре они формируются во что-то новое.
Перенося аналогию на computing… у нас есть сервисы которы "умные" и в большей степени самодостаточны, вплодь до стандартных сервисов (авторизация, логирование, мониторинг, пользователи и т.д.). Они сами выполняют свои задачи, имеют свой лайфсайкл и т.д. — тут четкого опредиления нет, главное что ими не надо управлять из вне.
Но! их можно "орхестритовать" в новые задачи (flows). Например самодостаточный и не нуждающийся в управлении сервис аудита может быть орхестрирован в различные бизнес-процессы.
В ещё более узком понимании сейчас под оркестрацией на английских ресурсах все чаще подрузомевают автоматическую конфигурацию, развертывание и координацию аппликаций/сервисов. Например RedHat свою Ansible часто называет Orchestation tool, ну и kuberntes поэтому вполне можно так назвать и так и называют.
например RedHat свою Ansible часто называет Orchestation tool
очевидно, потому что этот тул умеет управлять кучей абсолютно разных серверов и более того — разнородных ресурсов. Так что здесь очень подходит именно аналогия с оркестром и дирижером. Соб-но, о чем Вы и пишете.
Ну да.
Просто я с универа это в контескте SOA помню ещё, тогда небыло облаков и DevOps, лет 15 назад и больше.
И там архитектуру оркестрации противопостовляли хореографии (как и сейчас с микросервисами).
Я помню про k8s изначально писали: "Оркестратор микросервисов", что удачно имхо, ну и видимо всем понравилось и теперь тянут на весь класс т.н. DevOps-инструментов.
Наверное примерно потому, что есть оркестр и есть дирижер, а не менеджер и команда :)
Наверное намек на более высокий/возвышенный уровень аьстракции, как-то так
На счет токенов сервис аккаунтов:
- Рестартить вам нужно будет и те поды, у которых дефолтный токен, иначе будет много 404 у API сервера да и просто дефолтный SA может использоваться. Если же поду не нужен доступ к API серверу, тогда нужно отключить автомонтирование дефолтного токена
automountServiceAccountToken: false. - Если вы потеряли только приватный ключ для подписи SA токенов, а сертификат у вас все еще есть, то можно сгенерить новую пару, сконфигурить новый приватный ключ controller-manager, добавить новый сертификат и оставить старый API серверу. Тогда ничего удалять не надо и ничего рестартить не надо.
- Пара сертификат-ключ который используется для SA один и тот же на всех инстансах API и controller-manager. Потому если потеряли на одном инстансе, то проще скопировать с других нод, тогда совсем ничего делать не надо.
Спасибо,
Рестартить вам нужно будет и те поды, у которых дефолтный токен, иначе будет много 404 у API
Но это при условии что данные поды ломятся в API, не так-ли?
добавить новый сертификат и оставить старый API серверу
А каким образом можно передать apiserver'у оба сертификата? — в смысле обычным бандлом?
На счёт 404 понял. Ошибка будет возникать при попытке кубелета смаунтить несуществующий секрет в под.
Кажется я нашёл более изящное решение: можно просто пропатчить все секреты, удалив из них .data.token и тогда controller-manager перегенирирует токены в секретах с тем же именем.
Статью обновил, огромное спасибо за наводку ;)
А каким образом можно передать apiserver'у оба сертификата? — в смысле обычным бандлом?
нет, там просто можно два раза флаг с ключем/сертфикатом передать
--service-account-key-file old.crt
--service-account-key-file new.crt
К сожалению далеко не все микросервисы умеют на лету перечитывать токен и скорее всего вам потребуется вручную перезапустить контейнеры, где они используются:
Тут не верное рассуждение, и наверное лучше поправить в статье. Когда генерируется новый токен для сервис акаунта то создаётся новый секрет, который должен быть примонтирован в под. Для пода эти поля являются неизменяемые. И только в момент создания пода, ServiceAccount Admission Controller прописывает секрет с токеном от ServiceAccount в под. Поэтому вам в любом случае необходимо удалить все поды, чтобы пересоздать их. Это всё верно если не используется фича BoundServiceAccountTokenVolume, и я не уверен, что её сейчас кто-то использует, т.к. она до сих пор в альфе.
Дельное замечание, спасибо, исправил!
PS: Использовал ServiceAccountTokenVolumeProjection для Konnectivity, очень удобно так как в этом случае токен перевыпускается и обновляются в поде автоматически.
UPD: Выше отписал что нашёл более изящное решение.
Имя секретов теперь не меняется, так что это утверждение вновь становится верным.
Ломаем и чиним Kubernetes