<p>O kubeadm deve disponibilizar a opção --node-ip</p>

Atualmente, estou tendo problemas para configurar um cluster Kubernetes no DigitalOcean por causa disso. Por padrão, o kubelet vinculará e exporá / transmitirá o ip do gateway padrão, que, nesses casos, é o IP público voltado para o tráfego da Internet. Então, ao chegar ao ponto de configurar um complemento de rede de pod (como Weave), o inferno se solta porque o IP de anúncio do mestre é o endereço IP da rede interna, mas os nós de trabalho estão tentando expor o público: /

A solução é atualizar o arquivo de unidade colocado em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf para adicionar --node-ip=<private_worker_ip> , recarregar as unidades e reiniciar o kubelet para fazê-lo funcionar.

Se kubeadm puder fazer isso por padrão, passando a opção como @nkratzke, isso seria ótimo!

Só queria confirmar que adicionar a opção --node-ip=<private-worker-ip> às configurações do arquivo /etc/systemd/system/kubelet.service.d/10-kubeadm.conf não corrigirá esse problema para a configuração que expliquei antes. Mesmo que os nós estejam escutando nesta interface, o Kubernetes continua usando o gateway padrão para se comunicar entre os nós, que neste caso é o endereço IP público.

Estou tendo o mesmo problema. Tentei o seu método e também não funcionou para mim. Você conseguiu fazer funcionar?

@agsergi Eu estava tentando configurar um cluster k8s no DigitalOcean com a opção Private Networking habilitada, o que me levou a este problema. Desativar esse recurso fez tudo para mim, mas não tenho certeza se você está no mesmo barco.

Acho que esse problema ainda estará presente se você tiver mais de duas NICs conectadas à máquina.

Rapazes,
Eu tenho duas interfaces na minha VM, uma é para NAT e a segunda é para adaptador hostonly. Por padrão, o kubeadmin usava o IP da interface padrão (NAT no meu caso) se você quiser usar outra interface, use:
$ sudo kubeadm init --apiserver-advertise-address =

E funcionou para mim.

@luxas Por que isso está marcado como tipo / suporte? Existe alguma maneira de usar kubeadm com um ip de nó que não é a origem da rota padrão?

@evocage não há --apiserver-advertise-address =

Muito Obrigado.

Encontrei o mesmo problema no Scaleway.

Quando inicializei o mestre, passei --apiserver-advertise-address=<private_net_IP> mas quando quero adicionar um nó ( kubeadm join --toke=<token> <master_private_IP>:6443 ) os pods kube-proxy e weave-net não começam (pod de sincronização de erro)

Mas quando eu anexo um IP público ao meu nó e o reinicializo, tudo vai bem: pensando:

Qualquer ideia?

Mesmo problema ao tentar configurar kubernetes em um host de VM com IP único, onde apenas algumas portas podem ser encaminhadas para as VMs. Alguma solução alternativa para fazê-lo funcionar?

Queria apenas marcar com +1. Estou tentando executar em um conjunto de VMs Digitalocean com um IP privado em todos eles, mas o endereço público continua trabalhando seu caminho para o cluster de alguma forma.

Consegui fazer com que IPs privados funcionassem executando isto no mestre:

kubeadm init --apiserver-advertise-address=<private-master-ip> init

Adicionando --node-ip=<private-node-ip> a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , recarregando o daemon, reiniciando o kubelet e executando:

kubeadm join --token <token> <private-master-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>

@mongrelion Que tipo de comunicação entre o nó <-> mestre ainda está usando interfaces públicas? Não consegui replicar isso, então estou interessado em saber se o kubernetes está se comportando de maneira inesperada.

Isso foi o suficiente! A combinação de --apiserver-advertise-address para garantir que o mestre comece no lugar certo, e --node-ip na configuração do kubelet foi a combinação mágica.

De acordo com esta solicitação, porém, ter aquela opção --node-ip diretamente em kubeadm para que os arquivos de configuração sejam inicializados corretamente seria útil para iniciantes sem noção como eu tentando criar clusters :)

Obrigado @jamiehannaford por esse resumo. Achamos que devemos documentar isso de forma mais visível?

@luxas Sim, acho que ter esse caso de uso explicitamente documentado seria útil

@jamiehannaford Se você também quiser adicionar isso à reformulação do documento para v1.9, envie-me um parágrafo para adicionar a https://github.com/kubernetes/website/pull/6103

@fabriziopandini Claro! Feito

Oi,

Eu gostaria de dar alguns comentários também. Estou tentando usar o kubeadm para construir um cluster de nó único seguro.
Gostaria que todos os serviços do kubernetes se vinculassem ao localhost, mas isso não funciona.

Estou usando este comando e o cluster é criado:
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=127.0.0.1 \ --apiserver-cert-extra-sans=127.0.0.1,staging.my-server.net
No entanto, /etc/kubernetes/admin.conf e amigos contêm o endereço IP público do mestre.
server: https://75.xx.yy.zz:6443

Vou tentar a abordagem --node, mas agradeceria se você pudesse me ajudar a encontrar uma solução para isso.

Meu caso de uso:

Tenho uma máquina robusta que desejo usar como ambiente de teste e talvez como ambiente de produção para pequenos projetos onde não me importo com HA. Posso usar SSH e usar kubectl para controlar o cluster.

Obrigado,

Eu tive exatamente o mesmo problema que @ Mosho1 aqui e cheguei ao fundo disso.

Eu uso DO e CoreOS, mas isso realmente não está relacionado a nenhum dos dois e pode acontecer em outros provedores e distribuições. Também não está relacionado com redes privadas do DO sendo habilitadas ou desabilitadas: Eu reproduzi o problema em ambos os casos.

O que acontece é que kubelet conforme configurado por kubeadm olha as interfaces e decide trazer sua própria sub-rede privada para a mistura, independentemente dos IPs atribuídos ou interfaces disponíveis, e quer fazê-lo em o mesmo que ele considera "principal" (primeiro? WAN um? Não sei). Este não é visível por meio de ifconfig mas prontamente por meio de ip addr , e uma rota também está configurada, mas não há chance de que sobreviva a rede DO que conecta os nós eth0 .

EDIT: Graças a @klausenbusk , parece que o kubelet pega o IP âncora sob a suposição de que pode ser útil quando não é. Veja os detalhes abaixo.

A solução é informar ao kubelet qual é o IP a ser usado. Pode ser o público ou o privado se você usar a rede privada opcional.

Veja como eu usei --node-ip . Cuidado, isso assume que KUBELET_EXTRA_ARGS ainda não foi definido no arquivo de unidade.

$ DROPLET_IP_ADDRESS=$(ip addr show dev eth0 | awk 'match($0,/inet (([0-9]|\.)+).* scope global eth0$/,a) { print a[1]; exit }')
$ echo $DROPLET_IP_ADDRESS  # check this, jus tin case
$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=$DROPLET_IP_ADDRESS\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet

@lloeki Obrigado pelo artigo. Você se importaria de atualizar a documentação, possivelmente aqui: https://github.com/kubernetes/website/blob/master/docs/setup/independent/trou troubleshooting-kubeadm.md

Portanto, ele escolhe a WAN (eth0), vê (ou ignora) um IP público e decide adicionar uma segunda sub-rede privada (como 10.19.0.0/255 no meu caso), provavelmente acreditando que todos os nós eth0 são no mesmo link.

Você tem certeza sobre isso? Pode ser apenas o ip âncora (compare com curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address )

@klausenbusk você está absolutamente correto, isso foi uma especulação divertida da minha parte, desculpe! O seguinte é do nó mestre, agora usando --node-ip .

Portanto, parece que o kubelet escolheu esse pressuposto de que poderia ser útil quando não é?

$ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
10.19.0.39
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet yyy.yyy.yyy.yyy/20 brd yyy.yyy.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.19.0.39/16 brd 10.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Você se importaria de atualizar os documentos

@jamiehannaford Parece que posso fazer isso :)

/ assign @liztio

Dei uma olhada nisso e acho que o consenso, mesmo que os usuários solicitem que o argumento --node-ip seja adicionado ao kubeadm, é que modificar a configuração do kubelet e usar os parâmetros como @jamiehannaford sugeridos aqui é a abordagem recomendada:
https://github.com/kubernetes/kubeadm/issues/203#issuecomment -335416377

(ou talvez acrescentando $ KUBELET_EXTRA_ARGS antes de reiniciar o kublet).

dada a decisão de deixar de adicionar argumentos cmd extras ao kubeadm, acho que pode ser seguro encerrar esse problema ... a menos que haja planos para habilitar isso com as opções do kubeadm MasterConfig (de alguma forma ?? ... conforme confiamos o usuário editando a configuração do kubelet e descansando manualmente nas alterações).

editar: ou talvez com a configuração dinâmica do kubelet, se isso for possível?

todas as sugestões para alterações na documentação acima parecem estar mescladas.

@timstclair @liztio

Estou bem em fechar este.

Observe que, no Kubernetes 1.11, a configuração de KUBELET_EXTRA_ARGS em /etc/systemd/system/kubelet.service.d/20-custom.conf não funciona mais: deve ser definida em / etc / sysconfig / kubelet (uma sintaxe um pouco diferente desses arquivos).

@stepin Acabei de configurar um cluster 1.11 usando kubeadm e obtive isso depois cat: /etc/sysconfig/kubelet: No such file or directory

/etc/systemd/system/kubelet.service.d/20-custom.conf também não existe, então não tenho certeza do que você estava fazendo lá.

Se o que você disse for verdade, parece que o jogo da batata quente de configuração continua.

Consegui encontrar outro local para a configuração do kubelet aqui: /etc/default/kubelet

Para futuros viajantes (pelo menos na próxima semana), isso parece funcionar:

PRIVATE_IP=10.99.0.0
echo "KUBELET_EXTRA_ARGS=--node-ip=$PRIVATE_IP" > /etc/default/kubelet
systemctl daemon-reload
systemctl restart kubelet

Obviamente, você precisará alterar o IP para qualquer que seja o seu nesse nó específico.

Isenção de responsabilidade: estou apenas verificando o Kubernetes, então não garanto que isso não esteja fazendo algo terrível. Porém, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf aponta para /etc/default/kubelet , então acho que essa é a coisa certa a se fazer.

@jazoom - Obrigado por seu comentário, ele finalmente me levou a ler o arquivo de unidade do systemd mais de perto. Achei que estava ficando louco, pois poderia trazer a mesma configuração no 1.10 e tudo funcionou ... abrir a configuração no 1.11 e o --node-ip eu estava definindo não estava se aplicando. Mudar para adicionar args extras em /etc/default/kubelet corrigiu o problema para mim.

@geerlingguy De nada.

Pelo menos não era o caso de "funciona a cada segunda vez que abro um cluster 1.11". Esses problemas irreproduzíveis vão realmente deixar você louco.

Acabei de encontrar isso em "Kubeadm 1.13". Corrigido usando o seguinte:

1) Adicione "--node-ip" a '/var/lib/kubelet/kubeadm-flags.env':

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

2) Reinicie o Kubelet:

systemctl daemon-reload && systemctl restart kubelet

^ Se alguém souber como fazer isso funcionar com IPs flutuantes que não aparecem na NIC, por favor, me avise. Bem-sucedido caso contrário.

Oi,

Tente https://wiki.hetzner.de/index.php/Cloud_floating_IP_persistent/en .
Funciona para Hetzner, mas acho que é genérico.
Eugen

Isso funcionou perfeitamente. Obrigada.

Acabei de encontrar esse problema no "Kubeadm 1.13". O problema foi corrigido usando os seguintes métodos:

1. Adicione "--node-ip" em "/var/lib/kubelet/kubeadm-flags.env":

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

1. Reinicie o Kubelet:

systemctl daemon-reload && systemctl restart kubelet

muito obrigado, movendo