versão kubeadm : 1.10.2
Meio Ambiente :
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:
kubeadm
não identifica etcd
cluster como TLS habilitadoO 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)
kubeadm
não usou os certificados corretosapó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 plano de atualização deve ter sido executado corretamente
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
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.