Kubeadm: Alterando o endereço IP mestre

Criado em 6 jul. 2017  ·  29Comentários  ·  Fonte: kubernetes/kubeadm

Estou usando um provedor que atribui dinamicamente endereços IP privados na inicialização do nó e parece interromper a configuração baseada em kubeadm.

Eu configurei um novo servidor mestre com kubeadm e funcionou bem, mas depois de desligar e trazer a máquina de volta, o endereço IP privado mudou e agora, ao usar kubectl, recebo um erro Unable to connect to the server: x509: certificate is valid for 10.96.0.1, 10.4.36.13, not 10.4.20.67
(Sendo o último o novo endereço IP do servidor mestre.)

Existe uma maneira de executar kubeadm init forma a redefinir a configuração? Por exemplo, quero manter os pods de cluster, RCs, etc., mas quero reiniciar o certificado para usar um nome de host em vez de endereço IP.

Quando tento executar o init novamente com o nome do host em vez do endereço IP padrão, ele discorda de mim:

[06:20 root<strong i="12">@scumbag01</strong> ~] > kubeadm init --apiserver-advertise-address scumbag01 --skip-preflight-checks
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.7.0
[init] Using Authorization modes: [Node RBAC]
[preflight] Skipping pre-flight checks
[certificates] Using the existing CA certificate and key.
[certificates] Using the existing API Server certificate and key.
[certificates] Using the existing API Server kubelet client certificate and key.
[certificates] Using the existing service account token signing key.
[certificates] Using the existing front-proxy CA certificate and key.
[certificates] Using the existing front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
a kubeconfig file "/etc/kubernetes/admin.conf" exists already but has got the wrong API Server URL

Ele pega o certificado agora inutilizável para 10.4.36.13, que é um endereço IP fora do meu controle em vez de redefini-lo.

Se eu remover /etc/kubernetes/*.conf e reexecutar o init acima, ele ainda gravará server: https://10.4.20.67:6443 vez de usar o nome do host.

O kubeadm init deve sobrescrever a configuração e criar um novo certificado? Existe um plano para adicionar kubeadm reset ou funcionalidade semelhante que redefiniria o cluster ou destruiria todos os artefatos criados pelos kubeadm init para que eu possa começar do zero?

  • kubeadm version : & version.Info {Major: "1", Minor: "7", GitVersion: "v1.7.0", GitCommit: "d3ada0119e776222f11ec7945e6d860061339aad", GitTreeState: "clean", BuildDate: "2017-06-29T22: 55: 55: 19Z ", GoVersion:" go1.8.3 ", Compilador:" gc ", Plataforma:" linux / amd64 "}
  • Versão do Kubernetes : 1.7.0
  • Provedor de nuvem ou configuração de hardware : Scaleway, Intel ATOM x64
  • SO (por exemplo, de / etc / os-release): Debian Jessie
  • Kernel : 4.9.20
kinsupport

Comentários muito úteis

Eu sei que é um problema antigo, mas talvez meu comentário seja útil para alguém.
Infelizmente, a solução proposta por @patricklucas e @weisjohn não funcionou para mim, então criei a minha própria:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

Todos 29 comentários

Esta não é uma limitação do kubeadm, mas apenas uma prática geral de segurança.
O certificado é assinado para {your-old-IP-here} e a comunicação segura não pode acontecer com {your-new-ip-here}

Você pode adicionar mais IPs no certificado de antemão ...

Obrigado pela sua resposta.

Como os endereços IP são atribuídos pelo provedor de nuvem, gerar o certificado antecipadamente só funcionaria se eu pudesse defini-lo como um caractere curinga. (Desculpe, não sei nada sobre certificados.)

Ignorei que kubeadm reset realmente existe, uma vez que não é mencionado no guia de referência . Reset e init funcionaram bem para mim, e acho que vou evitar desligar a máquina master - presumo que meu problema seja raro e longe de qualquer caso de uso de produção. Ainda assim, me pergunto se existe uma maneira melhor. Acho que poderia imitar kubeadm reset etapas, mas manter a pasta de dados etcd para preservar minha configuração de cluster?

De qualquer forma, obrigado por todo o trabalho realizado no kubeadm! É mágico ver o cluster surgir em minutos - uso o Kubernetes desde 0.14, em produção desde 1.0.

@analytik eu tenho exatamente o mesmo problema que o seu. Minha rede corporativa bloqueia gcr.io. Portanto, estou usando um dongle para a instalação. No entanto, o IP do provedor continua mudando dinamicamente e não está sob meu controle. Até eu estou procurando uma solução. Mesmo se eu mantiver meu dongle conectado, às vezes devido a redefinições de rede as alterações de IP. Você tem alguma solução para isso? Como você está lidando com isso?
@luxas você poderia sugerir como posso proceder. Eu sou um novato no K8S. Perdido completamente com esta configuração. Você poderia me informar como posso corrigir esse problema de IP dinâmico?

Como vocês lidam com o IP mestre alterado?

Existe alguma atualização sobre este problema?

Mesmo problema aqui. Qualquer documentação para proceder a uma modificação de ip mestre sem redefinir todo o cluster, por favor?

Consegui fazer isso:

  • substituindo o endereço IP em todos os arquivos de configuração em / etc / kubernetes
  • fazendo backup de / etc / kubernetes / pki
  • identificando certificados em / etc / kubernetes / pki que têm o endereço IP antigo como nome alternativo [1]
  • excluindo o certificado e a chave de cada um deles (para mim era apenas apiserver e etcd / peer)
  • regenerando os certificados usando kubeadm alpha phase certs [2]
  • identificando o configmap no namespace kube-system que fazia referência ao IP antigo [3]
  • editar manualmente esses configmaps
  • reiniciar o kubelet e o docker (para forçar a recriação de todos os contêineres)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Nossa, eu não conhecia esses comandos. Ótimas informações, isso funcionou. Obrigado !

existe uma maneira de encontrar os configmaps manualmente e alterá-los?

Espero que o kubeadm possa cobrir esse processo em uma versão futura.

@patricklucas sério, obrigado por esse artigo. Isso salvou minha vida.

Para quem busca ainda mais clareza, aqui foram minhas experiências:

  1. substitua o endereço IP em todos os arquivos de configuração em /etc/kubernetes
    bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
  2. fazendo backup de /etc/kubernetes/pki
    bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
  3. identificando certificados em /etc/kubernetes/pki que têm o endereço IP antigo como um nome alternativo (isso pode ser limpo)
    bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done
  4. identifique o configmap no namespace kube-system que fez referência ao IP antigo, edite-os:

    # find all the config map names
    configmaps=$(kubectl -n kube-system get cm -o name | \
      awk '{print $1}' | \
      cut -d '/' -f 2)
    
    # fetch all for filename reference
    dir=$(mktemp -d)
    for cf in $configmaps; do
      kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
    done
    
    # have grep help you find the files to edit, and where
    grep -Hn $dir/* -e $oldip
    
    # edit those files, in my case, grep only returned these two:
    kubectl -n kube-system edit cm kubeadm-config
    kubectl -n kube-system edit cm kube-proxy
    
  5. altere o endereço IP (via CLI ou GUI para sua distribuição)
  6. exclua o certificado e a chave para cada identificado por grep na etapa anterior, regenere esses certificados

    NOTA: antes de recriar os certificados por meio de kubeadm admin phase certs ... , você precisará ter o novo endereço IP aplicado

    rm apiserver.crt apiserver.key
    kubeadm alpha phase certs apiserver
    
    rm etcd/peer.crt etcd/peer.key
    kubeadm alpha phase certs etcd-peer
    
  7. reinicie o kubelet e o docker
    bash sudo systemctl restart kubelet sudo systemctl restart docker
  8. copie sobre a nova configuração
    bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

outra coisa a ser observada, alterar os certificados era possível no modo offline, especificando a versão k8s em um arquivo de configuração: https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

@weisjohn Você também poderia atualizar seu comentário observando que:

kubectl edit cm -nkube-public cluster-info

também é necessário para o kubeadm?

Caso contrário, meus comandos de junção do kubeadm continuarão falhando usando o IP do apiserver antigo / errado na metade do processo.

Obrigado!

Apliquei todas as etapas de @michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338 # issuecomment-428340099) para substituir o endereço em todos os lugares.

Isso é usado para permitir que os kubernetes usem o endereço VPC recém-criado na eth1, em vez do IP público na eth0. Mesmo assim, quando executo kubeadm upgrade diff v1.12.3 ele ainda deseja reverter as alterações para --advertise-address em /etc/kubernetes/manifests/kube-apiserver.yaml .

Alguma pista?

Mesmo em kubectl get all --export=true --all-namespaces -o yaml o IP antigo não está presente em lugar nenhum

Atualização: acontece que kubeadm upgrade diff sugeriu uma mudança, mas kubeadm upgrade apply realmente não mudou o endereço. (um dos muitos bugs do kubernetes 1.13, como correções)

@weisjohn obrigado por

@patricklucas sério, obrigado por esse artigo. Isso salvou minha vida.

Para quem busca ainda mais clareza, aqui foram minhas experiências:

  1. substitua o endereço IP em todos os arquivos de configuração em /etc/kubernetes
    shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
  2. fazendo backup de /etc/kubernetes/pki
    shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
  3. identificando certificados em /etc/kubernetes/pki que têm o endereço IP antigo como um nome alternativo (isso pode ser limpo)
    shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done
  4. identifique o configmap no namespace kube-system que fez referência ao IP antigo, edite-os:

    # find all the config map names
    configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
    
    # fetch all for filename reference
    dir=$(mktemp -d)
    for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
    done
    
    # have grep help you find the files to edit, and where
    grep -Hn $dir/* -e $oldip
    
    # edit those files, in my case, grep only returned these two:
    kubectl -n kube-system edit cm kubeadm-config
    kubectl -n kube-system edit cm kube-proxy
    
  5. altere o endereço IP (via CLI ou GUI para sua distribuição)
  6. exclua o certificado e a chave para cada identificado por grep na etapa anterior, regenere esses certificados

    NOTA: antes de recriar os certificados por meio de kubeadm admin phase certs ... , você precisará ter o novo endereço IP aplicado

    rm apiserver.crt apiserver.key
    kubeadm alpha phase certs apiserver
    
    rm etcd/peer.crt etcd/peer.key
    kubeadm alpha phase certs etcd-peer
    
  7. reinicie o kubelet e o docker
    shell sudo systemctl restart kubelet sudo systemctl restart docker
  8. copie sobre a nova configuração
    shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Obrigado pelas etapas.
Você pode fornecer mais informações sobre quais mudanças precisamos fazer no nó mestre e, depois disso, qual procedimento precisamos aplicar para que o nó de trabalho antigo se junte a esse nó mestre reconfigurado?

Desde já, obrigado :)

Talvez seja bom mencionar que, ao mover o IP mestre para uma rede privada, pode ser útil atualizar a rede de sobreposição também. Calico não estava usando a interface VPC até que fosse vinculado a essa interface:

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadm alpha phase certs apiserver

@weisjohn kubeadm alpha phase certs apiserver não está funcionando na v1.13.0, mostrando "Este comando não deve ser executado sozinho. Veja a lista de subcomandos disponíveis." algum comentário atualizado disponível?

em 1.13 o comando é denominado kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

Passos muito úteis para remediar - obrigado @patricklucas e @weisjohn !

Uma dica extra se, como eu, você começar do estado de que o endereço IP já mudou, então você não pode entrar em contato com o api-server para alterar os configmaps na etapa 4:
O certificado do servidor api é assinado para o nome do host kubernetes , então você pode adicioná-lo como um apelido para o novo endereço IP em /etc/hosts e fazer kubectl --server=https://kubernetes:6443 ... .

@bboreham @weisjohn @patricklucas Muito obrigado pela sua experiência. Você poderia dar um conselho, o que devo fazer nos nós de trabalho após alterar o ip no nó mestre?
Excluir / adicionar ao cluster? Ou apenas altere _ / etc / kubernetes / kubelet.conf_ e _ / etc / kubernetes / pki / ca.crt_ manualmente?

Eu sei que é um problema antigo, mas talvez meu comentário seja útil para alguém.
Infelizmente, a solução proposta por @patricklucas e @weisjohn não funcionou para mim, então criei a minha própria:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@ valerius257 obrigado cara, você salva nosso fim de semana)

Obrigado @ valerius257 👍
Tentei todos os write-ups / instruções de @patricklucas e @weisjohn . Eles não funcionaram para o meu cluster. A parte boa é que essas instruções destacam alguns dos principais aspectos dos certificados e chaves e em que prazo eles precisam ser cuidados.

A instrução mencionada por @ valerius257 funcionou perfeitamente, até que encontrei problemas que são muito específicos para meu nó mestre kubeadm. Eu estava tentando recuperar o nó mestre kubeadm cujo IP foi alterado.

Pós continuação das etapas mencionadas por @ valerius257
Eu estava usando o plugin de flanela n / w em um único nó mestre.
Problema de flanela: kube-flannel-ds-xxxx back-off reiniciando contêiner com falha
Estado do pod: CrashLoopBackOff. Devido a isso, outros pods como core-dns-xxx também não aparecem.

Resolução: como iniciei o cluster com kubeadm init com cidr n / w (quando o IP era antigo ou durante o comissionamento do nó mestre), a etapa seguinte apagou as configurações de cidr de "/ etc / kubernetes / manifests / kube-controller-manager arquivo .yaml ".
kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd.

Portanto, se você iniciou o nó mestre kubeadm (com o endereço IP da primeira vez) com o comando "kubeadm init --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16" ", poste a alocação de novo IP você deve executar o seguinte comando com --pod-network-cidr = 10.244.0.0 / 16.
"kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16"

Ou modifique o arquivo "/etc/kubernetes/manifests/kube-controller-manager.yaml com os seguintes parâmetros incluídos, se eles estiverem ausentes em Spec: containers : command:

  • --allocate-node-cidrs = true
  • --cluster-cidr = 10.244.0.0 / 16

    • --node-cidr-mask-size = 24

      Referência: https://github.com/coreos/flannel/issues/728 , leia a solução de @wkjun

      Assim que as alterações acima estiverem em vigor,

      docker systemctl stop kubelet

      dormir 20

      systemctl start docker kubelet

      Verifique se todos os pods estão funcionando, incluindo flanela.

      kubect get pods -n kube-system

Edição 2:
Todos os pods no namespace do aplicativo ou no sistema kube começam a mostrar erros em comandos de pod de descrição, como:
"Warning FailedScheduling default-scheduler 0/1 nodes estão disponíveis: 1 node (s) tinha manchas que o pod não tolerou."
Execute o comando: kubectl taint nodes --all node-role.kubernetes.io/master-
descreva todos os pods em execução no espaço de trabalho de apps ou no espaço de nomes do sistema kube; os erros mencionados não serão observados. Em cluster de vários nós, você pode ter que ser extremamente cauteloso.

@patricklucas sério, obrigado por esse artigo. Isso salvou minha vida.

Para quem busca ainda mais clareza, aqui foram minhas experiências:

  1. substitua o endereço IP em todos os arquivos de configuração em /etc/kubernetes
    shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
  2. fazendo backup de /etc/kubernetes/pki
    shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
  3. identificando certificados em /etc/kubernetes/pki que têm o endereço IP antigo como um nome alternativo (isso pode ser limpo)
    shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done
  4. identifique o configmap no namespace kube-system que fez referência ao IP antigo, edite-os:

    # find all the config map names
    configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
    
    # fetch all for filename reference
    dir=$(mktemp -d)
    for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
    done
    
    # have grep help you find the files to edit, and where
    grep -Hn $dir/* -e $oldip
    
    # edit those files, in my case, grep only returned these two:
    kubectl -n kube-system edit cm kubeadm-config
    kubectl -n kube-system edit cm kube-proxy
    
  5. altere o endereço IP (via CLI ou GUI para sua distribuição)
  6. exclua o certificado e a chave para cada identificado por grep na etapa anterior, regenere esses certificados

    NOTA: antes de recriar os certificados por meio de kubeadm admin phase certs ... , você precisará ter o novo endereço IP aplicado

    rm apiserver.crt apiserver.key
    kubeadm alpha phase certs apiserver
    
    rm etcd/peer.crt etcd/peer.key
    kubeadm alpha phase certs etcd-peer
    
  7. reinicie o kubelet e o docker
    shell sudo systemctl restart kubelet sudo systemctl restart docker
  8. copie sobre a nova configuração
    shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

no lugar de newip qual ip devemos dar?
podemos criar um ip próprio?

@VipinKrizz o contexto deste problema é que o IP já mudou devido a fatores dentro da infraestrutura. Ninguém pode responder qual IP você deve usar, exceto alguém familiarizado com sua configuração específica.

Talvez você possa encontrar alguém para conversar sobre isso no Slack? Os problemas do Kubeadm não são o lugar certo.

@ valerius257 muito obrigado por esse script, agora vejo uma série de desvantagens em minha abordagem. Posso confirmar que sua solução funcionou, no entanto, há muitas pequenas arestas (como em todos os k8s). Tive de reaplicar quaisquer patches a serviços / integrados habilitados, dns, classes de armazenamento especiais, etc.

Mas sim, seu script salvou meu bacon hoje.

@ valerius257 Eu segui seu passo, mas conseguindo abaixo do problema

root @ ubuntu : / etc / kubernetes / pki # kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd
W0122 10: 15: 34.819150 102032 version.go: 101] não foi possível buscar uma versão do Kubernetes na Internet: não foi possível obter o URL " https://dl.k8s.io/release/stable-1.txt ": Obter https: //dl.k8s.io/release/stable-1.txt : disque tcp: lookup dl.k8s.io em 127.0.0.53:53: servidor com comportamento incorreto
W0122 10: 15: 34.819340 102032 version.go: 102] voltando para a versão do cliente local: v1.16.3
[init] Usando a versão do Kubernetes: v1.16.3
[preflight] Execução de verificações pré-voo
[AVISO IsDockerSystemdCheck]: detectou "cgroupfs" como o driver Docker cgroup. O driver recomendado é "systemd". Siga o guia em https://kubernetes.io/docs/setup/cri/
[AVISO DirAvailable - var-lib-etcd]: / var / lib / etcd não está vazio
[preflight] Extração de imagens necessárias para configurar um cluster Kubernetes
[preflight] Isso pode levar um ou dois minutos, dependendo da velocidade de sua conexão de internet
[preflight] Você também pode executar esta ação com antecedência usando 'kubeadm config images pull'
[kubelet-start] Gravando o arquivo de ambiente kubelet com sinalizadores no arquivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Gravando a configuração do kubelet no arquivo "/var/lib/kubelet/config.yaml"
[kubelet-start] Ativando o serviço kubelet
[certs] Usando a pasta certificateDir "/ etc / kubernetes / pki"
[certs] Usando autoridade de certificação ca existente
[certs] Gerando certificado e chave "apiserver"
[certs] apiserver servindo certificado é assinado para nomes DNS [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] e IPs [10.96.0.1 192.168.120.137]
[certs] Usando o certificado apiserver-kubelet-client existente e a chave no disco
[certs] Usando autoridade de certificação front-proxy-ca existente
[certs] Usando o certificado do cliente proxy frontal existente e a chave no disco
[certs] Usando autoridade de certificação etcd / ca existente
[certs] Usando o certificado etcd / servidor existente e a chave no disco
[certs] Gerando certificado e chave "etcd / peer"
[certs] etcd / peer serving cert é assinado para nomes DNS [ubuntu localhost] e IPs [192.168.120.137 127.0.0.1 :: 1]
[certs] Usando o certificado etcd / healthcheck-client existente e a chave no disco
[certs] Usando o certificado apiserver-etcd-client existente e a chave no disco
[certs] Usando a chave "sa" existente
[kubeconfig] Usando a pasta kubeconfig "/ etc / kubernetes"
[kubeconfig] Gravando o arquivo kubeconfig "admin.conf"
[kubeconfig] Gravando o arquivo kubeconfig "kubelet.conf"
[kubeconfig] Gravando o arquivo kubeconfig "controller-manager.conf"
[kubeconfig] Gravando o arquivo kubeconfig "scheduler.conf"
[control-plane] Usando a pasta de manifesto "/ etc / kubernetes / manifests"
[control-plane] Criando manifesto de pod estático para "kube-apiserver"
[control-plane] Criando manifesto de pod estático para "kube-controller-manager"
[control-plane] Criando manifesto de pod estático para "kube-scheduler"
[etcd] Criação de manifesto de pod estático para etcd local em "/ etc / kubernetes / manifests"
[wait-control-plane] Aguardando o kubelet inicializar o plano de controle como pods estáticos do diretório "/ etc / kubernetes / manifests". Isso pode levar até 4m0s
[kubelet-check] Tempo limite inicial de 40 segundos passado.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: conectar: ​​conexão recusou.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: conectar: ​​conexão recusou.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: conectar: ​​conexão recusou.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: conectar: ​​conexão recusou.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: conectar: ​​conexão recusou.

Infelizmente, ocorreu um erro:
expirou o tempo de espera pela condição

Este erro é provavelmente causado por:
- O kubelet não está funcionando
- O kubelet não está íntegro devido a uma configuração incorreta do nó de alguma forma (cgroups obrigatórios desativados)

Se você estiver em um sistema com base em systemd, pode tentar solucionar o erro com os seguintes comandos:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Além disso, um componente do plano de controle pode ter travado ou saiu quando iniciado pelo tempo de execução do contêiner.
Para solucionar o problema, liste todos os contêineres usando seus tempos de execução de contêiner preferidos CLI, por exemplo, docker.
Aqui está um exemplo de como você pode listar todos os contêineres Kubernetes em execução no docker:
- 'docker ps -a | grep kube | grep -v pause '
Depois de encontrar o contêiner com falha, você pode inspecionar seus registros com:
- 'docker logs CONTAINERID'
fase de execução de erro wait-control-plane: não foi possível inicializar um cluster Kubernetes
Para ver o rastreamento de pilha deste erro execute com --v = 5 ou superior

gentilmente ajude

Consegui fazer isso:

  • substituindo o endereço IP em todos os arquivos de configuração em / etc / kubernetes
  • fazendo backup de / etc / kubernetes / pki
  • identificando certificados em / etc / kubernetes / pki que têm o endereço IP antigo como nome alternativo [1]
  • excluindo o certificado e a chave de cada um deles (para mim era apenas apiserver e etcd / peer)
  • regenerando os certificados usando kubeadm alpha phase certs [2]
  • identificando o configmap no namespace kube-system que fazia referência ao IP antigo [3]
  • editar manualmente esses configmaps
  • reiniciar o kubelet e o docker (para forçar a recriação de todos os contêineres)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Funcionou para mim obrigado

A única coisa que você precisa é usar

 kubeadm init phase ..

Para as versões mais recentes do kubectl

@bboreham
Eu segui os passos mencionados por @patricklucas
como você mencionou na etapa 4, é necessário fazer algumas configurações em / etc / hosts porque o IP já foi alterado e não pode se conectar ao api-server.

Gerar certificado usando
kubeadm init --kubernetes-version = v1.16.3 phase certs apiserver

eu mudei em / etc / hosts

e tentei kubectl --server = https: //: 6443 ainda não funciona :(

alguma configuração específica precisa ser feita em / etc / hosts ??

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