Kubeadm: A atualização do Kubeadm para 1.10 falha no cluster ha k8s / etcd

Criado em 20 mai. 2018  ·  13Comentários  ·  Fonte: kubernetes/kubeadm

RELATÓRIO DE ERRO

Versões

versão kubeadm : 1.10.2

Meio Ambiente :

  • Versão do Kubernetes : 1.9.3
  • Provedor de nuvem ou configuração de hardware : 3 x k8s master HA
  • OS : RHEL7
  • Kernel : 3.10.0-693.11.6.el7.x86_64

O que aconteceu?

Alguns meses atrás, criei um cluster HA do kubernetes 1.9.3 usando kubeadm 1.9.3 , seguindo a documentação 'oficial' https://kubernetes.io/docs/setup/independent/high-availability/ , configurando o Cluster etcd HA hospedando-o nos nós mestres usando pods estáticos

Eu queria atualizar meu cluster para k8s 1.10.2 usando o kubeadm mais recente; depois de atualizar kubeadm , ao executar kubeadm upgrade plan , recebo o seguinte erro:

[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

Eu investiguei o problema e encontrei as 2 causas básicas:

1) kubeadm não identifica etcd cluster como TLS habilitado

O guia instrui como usar o seguinte comando no pod etcd static

- 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 verifica (aqui: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) se etcd ativou o TLS verificando a presença dos seguintes sinalizadores no comando estático do 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=",

mas como os sinalizadores --client-cert-auth e --peer-client-cert-auth são usados ​​nas instruções sem nenhum parâmetro (sendo booleanos), kubeadm não reconheceu o cluster etcd para ter TLS ativado.

CORREÇÃO PESSOAL:
Eu atualizei meu comando de pod etcd static para usar - --client-cert-auth=true e - --peer-client-cert-auth=true

CORREÇÃO GERAL:
Atualize as instruções para usar --client-cert-auth=true e --peer-client-cert-auth=true e relaxe as verificações do kubeadm usando "--peer-cert-file" e "--peer-key-file" (sem os iguais)

2) kubeadm não usou os certificados corretos

após corrigir o ponto 1, o problema ainda persistia, pois kubeadm não estava usando os certificados corretos.
Seguindo o guia HA do kubeadm, na verdade, os certificados criados são ca.pem ca-key.pem peer.pem peer-key.pem client.pem client-key.pem mas o último kubeadm espera ca.crt ca.key``peer.crt peer.key``healthcheck-client.crt healthcheck-client.key vez disso.
Suas kubeadm-config Chaves de configuração principal etcd.caFile , etcd.certFile e etcd.keyFile são ignoradas.

CORREÇÃO PESSOAL:
.pem certificado renomeado para seu .crt e .key equivalente e atualizou a configuração de pod estático etcd para usá-los.

CORREÇÃO GERAL:
Use os valores kubeadm-config data.caFile , data.certFile e data.keyFile , deduza os certificados corretos a partir da definição estática do pod etcd (caminho do pod + caminho do host dos volumes) e / ou crie um novo certificado de cliente temporário para usar durante a atualização.

O que você esperava que acontecesse?

O plano de atualização deve ter sido executado corretamente

Como reproduzi-lo (o mínimo e precisamente possível)?

crie um cluster k8s ha usando kubeadm 1.9.3 seguindo https://kubernetes.io/docs/setup/independent/high-availability/ e tente atualizá-lo para k8s >= 1.10 usando o kubeadm mais recente

areHA areUX areupgrades documentatioimprovement kinbug prioritimportant-soon

Todos 13 comentários

este problema parece ter sido corrigido em kubeadm 1.10.3 , embora ele não atualize automaticamente o pod estático etcd pois ele o reconhece como 'externo'

Estou usando kubeadm 1.10.3 e tenho os mesmos problemas. Meu cluster é 1.10.2 com um etcd seguro externo

@brokenmass Os valores para suas correções

  caFile: /etc/kubernetes/pki/etcd/ca.crt
  certFile: /etc/kubernetes/pki/etcd/healthcheck-client.crt
  keyFile: /etc/kubernetes/pki/etcd/healthcheck-client.key

@detiber você pode ajudar por favor?

@FloMedja
no meu caso, os valores se parecem com:

  caFile: /etc/kubernetes/pki/etcd/ca.pem
  certFile: /etc/kubernetes/pki/etcd/client.pem
  keyFile: /etc/kubernetes/pki/etcd/client-key.pem

e 1.10.3 está funcionando corretamente

@brokenmass Então, com kubeadm 1.10.3 tudo funciona sem a necessidade de suas correções pessoais. Nesse caso, estou um pouco confuso. Eu tenho o kubeadm 1.10.3, mas a mesma mensagem de erro que você mencionou neste relatório de bug. Vou verificar minha configuração, posso cometer alguns erros em outro lugar

adicione aqui (ou junte-se ao kubernetes slack e envie-me uma mensagem direta) seu kubeadm-config, pods estáticos etcd yml e a saída completa de kubeadm upgrade plan

Minhas desculpas, estou vendo isso agora. @chuckha fez o trabalho original para os documentos de HA etcd de pod estático, irei trabalhar com ele nos próximos dias para ver se podemos ajudar a corrigir as atualizações de HA.

@detiber agradece a você. o plano de atualização finalmente funciona. mas eu enfrento alguns problemas de condições de corrida ao tentar atualizar o cluster. às vezes funciona, às vezes, tenho o mesmo erro que

Encontrei alguns empecilhos ao conseguir uma configuração de ambiente de teste para isso hoje e estou ficando sem tempo antes de meu fim de semana começar. Vou retomar isso no início da próxima semana.

/ assign @chuckha @detiber

@chuckha @detiber @stealthybox alguma atualização sobre isso?

Portanto, a atualização 1.9-> 1.10 HA não era um caminho com suporte ou verificado.

No momento, estamos atualizando nossa documentação de manutenção para 1.11-> 1.12, a qual planejamos manter no futuro.

Esta página foi útil?
0 / 5 - 0 avaliações