ОТЧЕТ ОБ ОШИБКЕ

Версии

версия kubeadm: 1.10.2

Окружающая среда :

• Версия Kubernetes : 1.9.3
• Облачный провайдер или конфигурация оборудования : 3 x k8s master HA
• ОС : RHEL7
• Ядро : 3.10.0-693.11.6.el7.x86_64

Что случилось?

Пару месяцев назад я создал кластер HA kubernetes 1.9.3, используя kubeadm 1.9.3 , следуя «официальной» документации https://kubernetes.io/docs/setup/independent/high-availability/ , настроив etcd Кластер HA, размещающий его на главных узлах с использованием статических модулей

Я хотел обновить свой кластер до k8s 1.10.2 используя последнюю версию kubeadm ; после обновления kubeadm при запуске kubeadm upgrade plan я получил следующую ошибку:

[root@shared-cob-01 tmp]# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/plan] computing upgrade possibilities
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.9.3
[upgrade/versions] kubeadm version: v1.10.2
[upgrade/versions] Latest stable version: v1.10.2
[upgrade/versions] FATAL: context deadline exceeded

Я исследую проблему и обнаружил 2 основные причины:

1) kubeadm не идентифицирует кластер etcd как включенный TLS

В руководстве предлагается использовать следующую команду в статическом модуле etcd

- etcd --name <name> \
  - --data-dir /var/lib/etcd \
  - --listen-client-urls http://localhost:2379 \
  - --advertise-client-urls http://localhost:2379 \
  - --listen-peer-urls http://localhost:2380 \
  - --initial-advertise-peer-urls http://localhost:2380 \
  - --cert-file=/certs/server.pem \
  - --key-file=/certs/server-key.pem \
  - --client-cert-auth \
  - --trusted-ca-file=/certs/ca.pem \
  - --peer-cert-file=/certs/peer.pem \
  - --peer-key-file=/certs/peer-key.pem \
  - --peer-client-cert-auth \
  - --peer-trusted-ca-file=/certs/ca.pem \
  - --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
  - --initial-cluster-token my-etcd-token \
  - --initial-cluster-state new

kubeadm >= 1.10 проверяет (здесь: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) if etcd включает TLS, проверяя наличие следующих флагов в команде static pod.

"--cert-file=",
"--key-file=",
"--trusted-ca-file=",
"--client-cert-auth=",
"--peer-cert-file=",
"--peer-key-file=",
"--peer-trusted-ca-file=",
"--peer-client-cert-auth=",

но поскольку флаги --client-cert-auth и --peer-client-cert-auth используются в инструкциях без каких-либо параметров (являются логическими), kubeadm не распознал кластер etcd имеющий TLS включено.

ЛИЧНОЕ ИСПРАВЛЕНИЕ:
Я обновил свою команду etcd static pod, чтобы использовать - --client-cert-auth=true и - --peer-client-cert-auth=true

ОБЩЕЕ ИСПРАВЛЕНИЕ:
Обновите инструкции, чтобы использовать --client-cert-auth=true и --peer-client-cert-auth=true и ослабьте проверки kubeadm, используя "--peer-cert-file" и "--peer-key-file" (без равенства)

2) kubeadm не использовал правильные сертификаты

после исправления точки 1 проблема все еще сохранялась, поскольку kubeadm не использовал правильные сертификаты.
Фактически, следуя руководству kubeadm HA, созданные сертификаты имеют вид ca.pem ca-key.pem peer.pem peer-key.pem client.pem client-key.pem но последний kubeadm healthcheck-client.key вместо этого ожидает ca.crt ca.key``peer.crt peer.key``healthcheck-client.crt healthcheck-client.key .
Ключи kubeadm-config MasterConfiguration etcd.caFile , etcd.certFile и etcd.keyFile игнорируются.

ЛИЧНОЕ ИСПРАВЛЕНИЕ:
Сертификат .pem переименован в их эквивалент .crt и .key и обновлена ​​статическая конфигурация модуля etcd для их использования.

ОБЩЕЕ ИСПРАВЛЕНИЕ:
Используйте значения kubeadm-config data.caFile , data.certFile и data.keyFile , выведите правильные сертификаты из определения статического модуля etcd (путь модуля + путь хоста томов) и / или создайте новый временный сертификат клиента для использования во время обновления.

Чего вы ожидали?

План обновления должен был быть выполнен правильно

Как это воспроизвести (максимально минимально и точно)?

создайте кластер k8s ha, используя kubeadm 1.9.3 следуя https://kubernetes.io/docs/setup/independent/high-availability/, и попробуйте обновить его до k8s >= 1.10 используя последнюю версию kubeadm