<p>Сертификаты альфа-фазы kubeadm обновляются, все также должны обновлять сертификаты в файлах KubeConfig</p>

@MalloZup
конечно, но учтите, что фазы соединения имеют высокий приоритет.

звучит неплохо! большое спасибо.

Привет,

по этой теме есть еще кое-что.

kubeadm alpha phase kubeconfig all показывает это сообщение, если файлы conf присутствуют при выполнении команды:

[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

Он не проверяет, истек ли срок действия сертификатов, поэтому, на мой взгляд, up-to-date неверно.

Чтобы получить обновленные сертификаты в файлах, НЕОБХОДИМО удалить файлы заранее, чем будет выглядеть журнал:

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"   

В моем случае я хотя и в порядке, но через несколько дней со статическими модулями не удалось связаться из-за устаревших сертификатов.

Наилучшие пожелания
Андреас

Присвоен @MalloZup

@MalloZup : GitHub не разрешил мне назначить следующих пользователей: MalloZup.

Обратите внимание, что могут быть назначены только участники kubernetes и соавторы репо, а
Для получения дополнительной информации см. Руководство для авторов.

привет @adoerler спасибо за вопрос. Что касается вводящей в заблуждение информации, я отправил PR https://github.com/kubernetes/kubernetes/pull/73798.

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

@adoerler Я отправил DOC PR за ваше предложение. Не стесняйтесь взглянуть tia: rocket:
(https://github.com/kubernetes/website/pull/12579)

Привет @MalloZup!

спасибо за пиар!

Мне не хватает предложения о файлах kubeconfig, потому что certs renew - это только одна часть игры.
Что-то вроде:

После обновления сертификатов не забудьте воссоздать файлы KubeConfig, используя kubeadm alpha phase kubeconfig ...

Спасибо. Я не добавил документ, потому что думал, что на самом деле мы можем обновить также файлы kubeconfig. Остальные перезапускаемые модули мы можем делегировать пользователю и написать минимальный документ. @fabriziopandini @lubomir @ereslibre Мне что-то не хватает в этой реализации? Тиа

@MalloZup У меня нет глубоких знаний о том, как работает обновление сертификатов.

Лично я хотел бы немного прояснить общую историю, прежде чем предпринимать действия - включая то, что было предложено выше -:

• чем должен управлять kubeadm alpha phase certs renew
• что должно управляться автоматически во время kubeadm upgrade
• что должно быть задокументировано (и обработано пользователями)
• как это применимо к кластерам высокой доступности
• как на это влияют варианты кластера (например, внешний etcd, внешний CA)
• и т.п.

но последнее слово я оставляю людям более опытным, чем я в этой области

Я думаю, нам следует зарезервировать время на встрече, чтобы обсудить, какой должна быть наша рекомендуемая политика обновления сертификатов. на странице об управлении сертификатами может потребоваться дополнительная информация:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

и нам нужно написать небольшое руководство, по крайней мере, для кластеров с одной плоскостью управления.

пользователи сами во всем разбираются:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ этот комментарий и один выше содержат руководства пользователя.

это знак того, что нам нужно добавить официальное руководство.
Копия @timothysc @liztio

/ назначить @ereslibre

Наш кластер с парой сотен пользователей сейчас застрял. Могу ли я получить очень быстрое руководство, что делать с просроченным сертификатом?

@ dimm0

пользователи сами во всем разбираются:
# 581 (комментарий)
^ этот комментарий и один выше содержат руководства пользователя.

это единственные гиды, у нас есть банкоматы.

[root<strong i="5">@controller0</strong> ~]# kubeadm alpha phase certs apiserver --apiserver-advertise-address 1.2.3.4
Error: unknown flag: --apiserver-advertise-address
Usage:

Flags:
  -h, --help   help for phase

Global Flags:
      --log-file string   If non-empty, use this log file
      --rootfs string     [EXPERIMENTAL] The path to the 'real' host root filesystem.
      --skip-headers      If true, avoid header prefixes in the log messages
  -v, --v Level           log level for V logs

error: unknown flag: --apiserver-advertise-address
[root<strong i="6">@controller0</strong> ~]# kubeadm alpha phase certs apiserver
This command is not meant to be run on its own. See list of available subcommands.

в 1.13 этапы инициализации перешли к родительской команде инициализации:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

в 1.12 должен быть флаг:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 скоро перестанет поддерживать.

удаление жизненного цикла / активной метки.
переход на 1.15.

возможные варианты обновления документации здесь:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
Вопрос: в 1.14 с главной HA достаточно ли следовать https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 на одном мастере, или мы должны снова присоединиться к вторичным мастерам, чтобы повторно получить сертификаты?

воссоединение узлов вторичной плоскости управления кажется быстрым и жизнеспособным вариантом в 1,14.
у нас пока нет документации по ротации сертификатов высокой доступности.
(не говоря уже о том, что мы еще не добавили соответствующие шаги, такие как https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139).

Разве --experimental-upload-certs не является основой для более простого решения ротации сертификатов в HA?

один из способов сделать ротацию сертификатов высокой доступности:

• на одном узле плоскости управления выполните указанные выше шаги, чтобы обновить его сертификаты.
• при вызове того же узла CP:

kubeadm init phase upload-certs --experimental-upload-certs

хранить ключ сертификатов.

kubeadm token create --print-join-command

сохраните команду соединения с токеном.

повторно присоединитесь к остальным узлам плоскости управления, используя токен и ключ сертификатов, один за другим, используя --certs-key .... --experimental-control-plane-join

для рабочих: слить, присоединиться, используя новый жетон, uncordon, один за другим.

при желании удалить полученные токены.

@ neolit123
В кластерах с 3 главными серверами, как только мы изменим сертификаты на «основном» мастере, etcd перестанет работать, поскольку сертификаты изменены (а кворум должен быть не менее 51%)? Если да, то, может быть, нам нужно каким-то образом оцепить 2 вторичных мастера и только потом менять сертификаты? Возможен ли «кордонный хозяин»?

Я здесь не эксперт, но не думаю, что автоматическая копия сертификата должна попадать в эту картину.

Автоматическое копирование сертификатов обрабатывает CA, front-proxy-CA, etcd-CA (с 10-летним TTL) и ключ SA (без TTL)

Команда обновления сертификата касается всех других сертификатов (с TTL 1 год), которые различаются для разных мастеров.
AFAIK, в настоящее время нет ничего, что могло бы обновлять сертификаты для файлов kubeconfig.

хорошо, я не рассматривал, что на самом деле делает здесь «копия сертификатов».
в любом случае нам нужно написать правильные документы с вращением сертификатов.

/назначать
/ жизненный цикл активен

Я начинаю работать над этим вопросом.
Есть разные моменты, которые необходимо решить (_обновлено 14 мая 2019_)

• Даже при включенной ротации сертификатов kubelet.conf указывает на устаревшие сертификаты (уже отслеживаемые https://github.com/kubernetes/kubeadm/issues/1317)
• Ротация сертификатов не обновляет сертификаты apiserver / etcd / front-proxy-client (исправлено https://github.com/kubernetes/kubernetes/pull/76862)
• Сертификаты альфа-фазы команды kubeadm обновить все не обновляют файлы KubeConfig (исправлено https://github.com/kubernetes/kubernetes/pull/77180)
• Документация по обновлению сертификатов (с более подробной информацией о том, где следует запускать команду, когда, kubeconfig, HA)

И все они будут рассмотрены в отдельных PR.

@ neolit123 @fabriziopandini
шаги, которые вы упомянули, также для ротации сертификата CA? Можно ли это задокументировать? А как насчет ротации закрытых ключей, включая ключ для центра сертификации?

@ tushar00jain ротация сертификата CA отслеживается в другом выпуске https://github.com/kubernetes/kubeadm/issues/1350
Эта проблема касается только подписанных сертификатов

@fabriziopandini Я

Даже при включенной ротации сертификатов kubelet.conf указывает на устаревшие сертификаты (уже отслеживаемые # 1317)

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

При ротации сертификатов не обновляются сертификаты apiserver / etcd / front-proxy-client (исправлено kubernetes / kubernetes # 76862)

Сертификаты альфа-фазы команды kubeadm обновить все не обновляют файлы KubeConfig (исправлено kubernetes / kubernetes # 77180)

Документация по обновлению сертификатов (с более подробной информацией о том, где следует запускать команду, когда, kubeconfig, HA)

3 выше должны быть выполнены.

/Закрыть
Согласно приведенному выше комментарию, большая часть работы уже завершена; недостающий бит отслеживается в отдельном / специализированном выпуске

@fabriziopandini : закрытие этого вопроса.

Может кто-нибудь объяснить мне, как была адресована часть «Даже при включенной ротации сертификатов, kubelet.conf указывает на устаревшие сертификаты»? Единственная связанная проблема, в которой упоминается, что это явно закрыто в пользу других проблем, которые закрываются со словами «Я не уверен, что это проблема, поэтому откройте новую заявку, если это так».
Я использую 1.16, но не вижу никаких обновлений в kubelet.conf с sudo kubeadm alpha certs renew all . Что не хватает? @ neolit123

краткое изложение очень-очень долгой дискуссии.

1. ротация сертификатов для всех сертификатов, кроме kubelet.conf, теперь управляется kubeadm alphacert Renew.
2. ротацией сертификатов для kubelet.conf будет управлять сам kubelet (если пользователь не откажется от автоматической ротации сертификатов)

Этот второй пункт уже сегодня работает для всех узлов, кроме того, на котором вы запускаете kubeadm init; https://github.com/kubernetes/kubernetes/pull/84118 исправит это

@fabriziopandini Спасибо за это, это имеет смысл.

Для всех, кто сталкивается с проблемой устаревания сертификатов в kubelte.conf с настоящего момента и до момента исправления вышеуказанного, я нашел эту статью полезной:

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check -certificate-expiration

На узлах, созданных с помощью kubeadm init, до версии kubeadm 1.17, есть ошибка, из-за которой вам нужно вручную изменить содержимое kubelet.conf. После завершения kubeadm init вы должны обновить kubelet.conf, чтобы он указывал на повернутые клиентские сертификаты kubelet, заменив данные сертификата клиента и данные ключа клиента на:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

@AndrewSav Спасибо за это. Я использовал оператор promethes для мониторинга кластера. Недавно я получил предупреждение «Срок действия сертификата Kubernetes API истекает менее чем через 7 дней», я думаю, это связано с этой проблемой. Я обновил содержимое kubelet.conf на главных узлах. Но я все равно получаю предупреждение. У вас есть какие-нибудь предложения? Ткс.

@tannh, если вы установили кластер с помощью kubeadm, используйте kubeadm для проверки работы сертификатов. В противном случае ваша проблема, вероятно, не связана.

На узлах, созданных с помощью kubeadm init, до версии kubeadm 1.17, есть ошибка, из-за которой вам нужно вручную изменить содержимое kubelet.conf. После завершения kubeadm init вы должны обновить kubelet.conf, чтобы он указывал на повернутые клиентские сертификаты kubelet, заменив данные сертификата клиента и данные ключа клиента на:

это также будет в примечаниях к выпуску 1.17.

@adoerler Я все еще использую старую версию kubeadm, как мне обновить kubelet.conf, admin.con и т. д. после обновления сертификата?

Я запустил команду «kubeadm alpha certs Renew all», в результате которой были сгенерированы новые сертификаты, затем мне нужно отредактировать все .conf в / etc / kubernetes, как? куда именно они должны указывать?
и в случае нескольких главных узлов, следует ли мне запускать команду на всех мастерах?

Привет @SuleimanWA!

Я не могу сказать вам, что делать в среде с несколькими мастерами, в моей настройке был только один мастер.

Вот что я сделал:

Прежде всего, убедитесь, что вы удалили существующие файлы conf, потому что существующие файлы не будут перезаписаны!

mv /etc/kubernetes/admin.conf /backup
mv /etc/kubernetes/kubelet.conf /backup
mv /etc/kubernetes/controller-manager.conf /backup
mv /etc/kubernetes/scheduler.conf /backup

затем обновите эти файлы:

user<strong i="13">@master</strong>:~$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address=<INSERT-YOUR-APISERVER-IP-HERE>
I0124 21:56:14.253641   15040 version.go:236] remote version is much newer: v1.13.2; falling back to: stable-1.12
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"    

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

Не забудьте скопировать client-certificate-data и client-key-data из /etc/kubernetes/admin.conf в локальный .kube/config .

Надеюсь это поможет

Андреас

Есть идеи, как запустить эту команду на 1.14.10? Все, что я получаю, это:

kubeadm alpha phase kubeconfig all --apiserver-advertise-address=192.168.102.170 Error: unknown flag: --apiserver-advertise-address

Тогда документы говорят:
kubeadm alpha phase kubeconfig all
и я получаю:
This command is not meant to be run on its own. See list of available subcommands.

Спасибо

Привет @provgregoryabdo!

каков ваш выход kubeadm version ?

BR Андреас

@provgregoryabdo команды phase перемещены из альфа-версии в инициализацию в более поздних версиях, поэтому вы можете использовать что-то вроде

kubeadm init phase kubeconfig all --apiserver-advertise-address=<your_address>

@adoerler спасибо за помощь!