Estou tendo o mesmo problema. Também tentei remover o Network ARGS, conforme sugerido em outro problema. Ele ainda trava em waiting for control plane to be ready .

Você recarregou o Daemon e reiniciou o serviço kubelet depois de fazer as alterações. Funcionou depois de mudar o driver e comentar a rede. Demora 10 a 11 minutos para o avião de controle ficar pronto pela primeira vez para mim, eu sugiro deixá-lo por 15 minutos pela primeira vez.

Eu recarreguei o daemon e reiniciei o serviço kubelet todas as vezes. Eu até deixei a configuração intacta por toda a noite, mas ainda estava esperando o plano de controle.

Eu recarreguei o daemon ( systemctl daemon-reload ) e reiniciei o kubelet também. Eu corro kubeadm reset , edito a configuração do serviço, recarrego o daemon e executo kubeadm init .

Os contêineres do docker Apiserver e etcd falham ao serem executados após comentar as opções de rede. Eu também tentei instalar o weave-net manualmente para que o diretório de configuração do cni fosse preenchido, mas isso também não funcionou. Para fazer isso, instalei o weave, executei weave setup e weave launch . Eu realmente não sei como o Kubeadm configura o Docker para usar as configurações de CNI, mas talvez esteja faltando uma etapa aqui.

Parece que o kubelet não pode acessar o servidor kube api.

Percebi que o etcd não conseguiu ouvir na porta 2380, segui estas etapas novamente e meu cluster foi inicializado:

• Execute kubeadm reset para remover quaisquer alterações feitas no servidor.
• Retorne a máquina ao estado inicial. Ao reinstalar o kubeadm (para recuperar os arquivos de configuração originais).
• Remova os contêineres do docker relacionados ao kubernetes, se houver algum.
• Obtenha e instale o tecido. Não o execute.
• Reinicie o servidor.
• Certifique-se de que kubelet não seja executado.
• Corra weave setup e weave launch .
• Corra kubeadm init .

Se você quiser se livrar do gerenciamento de tecelagem à mão...

• Correr weave reset
• Aplique o addon weave para kubernetes 1.6.
• Reinicie o servidor.

A junção do Kubeadm deve funcionar em outros servidores.

@Yengas Você pode fornecer mais detalhes sobre as etapas de tecelagem? Você os executou em todos os nós ou apenas no mestre?

@jruels apenas o nó mestre. Weave é apenas um único binário. O comando setup sem nenhum argumento, baixa as imagens do docker weave e cria a configuração CNI. O comando launch sem nenhum argumento inicia os containers weave somente no host.

@Yengas Ainda não tenho certeza, o que você quer dizer com - "obter e instalar o weave. Não execute" Obviamente, não posso fazer kubectl apply -f https://git.io/weave-kube-1.6 então como faço para instalar o weave ?

O que dizem os logs do apiserver?

@rushabh268
Para instalar o weave, execute o seguinte no mestre
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
Então corra
weave setup
Quando isso terminar, execute
weave launch

você não precisa fazer isso. kubectl apply -f https://git.io/weave-kube-1.6 deve ser suficiente.

Os logs do servidor da API dizem exatamente o mesmo que mencionei no bug. Além disso, não consigo fazer o kubectl porque o Kubernetes não está instalado

@jruels vou experimentar e atualizar este tópico!

Na descrição do bug existem logs do kubeadm e logs do kubelet. Não há logs do apiserver.

@mikedanese Como obtenho os logs do apiserver?
@jruels eu sou capaz de tecer
@Yengas Mesmo depois de seguir seus passos, vejo o seguinte erro nos logs do kubelet:
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

Além disso, eu parei o firewall, então não tenho certeza por que estou recebendo a conexão recusada.

Estou com o mesmo problema relatado aqui.

Recorte das mensagens do meu sistema (Nó mestre) enquanto estava preso, apenas no caso, aponta algo. Btw, estou fazendo isso no Linode.

12 de abril 02:10:00 auditoria localhost: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? endereço=? terminal=? res=sucesso'
12 de abril 02:10:00 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? endereço=? terminal=? res=sucesso'
12 de abril 02:10:00 auditoria localhost: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? endereço=? terminal=? res=sucesso'
12 de abril 02:10:00 localhost systemd: kubelet.service: Tempo de espera do serviço encerrado, reinicialização do agendamento.
12 de abril 02:10:00 localhost systemd: kubelet interrompido: o agente do nó do Kubernetes.
12 de abril 02:10:00 localhost systemd: kubelet iniciado: The Kubernetes Node Agent.
Apr 12 02:10:00 localhost systemd: Iniciando a ferramenta de contabilidade de atividades do sistema...
12 de abril 02:10:00 localhost audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? endereço=? terminal=? res=sucesso'
12 de abril 02:10:00 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? endereço=? terminal=? res=sucesso'
12 de abril 02:10:00 localhost systemd: Ferramenta de contabilidade de atividade do sistema iniciada.
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.924529 3445 feature_gate.go:144] feature gates: map[]
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.928973 3445 docker.go:364] Conectando-se ao docker em unix:///var/run/docker.sock
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.929201 3445 docker.go:384] Iniciar cliente docker com tempo limite de solicitação = 2m0s
12 de abril 02:10:00 localhost kubelet: W0412 02:10:00.941088 3445 cni.go:157] Não é possível atualizar a configuração do cni: Nenhuma rede encontrada em /etc/cni/net.d
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.948892 3445 manager.go:143] cAdvisor rodando no container: "/system.slice"
12 de abril 02:10:00 localhost kubelet: W0412 02:10:00.974540 3445 manager.go:151] incapaz de se conectar ao serviço Rkt api: rkt: cannot tcp Disque rkt api service: disque tcp [::1]:15441: getsockopt: conexão recusada
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.997599 3445 fs.go:117] Partições do sistema de arquivos: map[/dev/root:{mountpoint:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 blockSize:0 }]
12 de abril 02:10:01 localhost kubelet: I0412 02: 10: 01.001662 3445 manager.go: 198] Máquina: { NumCores: um processador central Frequência: 2799998 Memor yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID: 5e9a9a0b58984bfb8766dba9afa8a191 bootid: 7ed1a6ff-9848- 437b-9460-981eeefdfe5a Sistemas de arquivos:[{Device:/dev/root Capacity:15447539712 Type:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ Name:nbd0 Major:43 Minor:0 Size:0 Agendador:nenhum } 43:11:{ Nome:nbd11 Maior:43 Menor:11 Tamanho:0 Agendador: nenhum } 43:12:{ Nome:nbd12 Maior:43 Menor:12 Tamanho:0 Agendador: nenhum } 43:15: { Name:nbd15 Major:43 Minor:15 Size:0 Scheduler:none } 43:7:{ Name:nbd7 Major:43 Minor:7 Size:0 Scheduler:none } 8:0:{ Name:sda Major:8 Minor :0 Tamanho:15728640000 Agendador:cfq } 252:0:{ Nome:dm-0 Maior:252 Menor:0 Tamanho:107374182400 Agendador:nenhum } 43:1:{ Nome:nbd1 Maior:43 Menor:1 Tamanho:0 Agendador :none } 43:13:{ Nome:nbd13 Major:43 Minor:13 Size:0 Scheduler:none } 43:8:{ Name:nbd8 Major:43 Minor:8 Size:0 Scheduler:none } 8: 16:{ Name:sdb Major:8 Minor:16 Size:536870912 Scheduler:cfq } 9:0:{ Name:md0 Major:9 Minor:0 Size:0 Scheduler:none } 43:3:{ Name:nbd3 Major: 43 Menor:3 Tamanho:0 Agendador: nenhum } 43:9:{ Nome:nbd9 Maior:43 Menor:9 Tamanho:0 Agendador: nenhum } 43:10:{ Nome:nbd10 Maior:43 Menor:10 Tamanho:0 Agendador :none } 43:14:{ Nome:nbd14 Major:43 Minor:14 Size:0 Scheduler:none } 43:2:{ Name:nbd2 Major:43 Minor:2 Size:0 Scheduler:none } 43:4:{ Nome:nbd4 Maior:43 Menor:4 Tamanho:0 Agendador: nenhum } 43:5:{ Nome:nbd5 Maior:43 Menor:5 Tamanho:0 Agendador: nenhum } 43:6:{ Nome:nbd6 Maior:43 Menor: 6 Tamanho:0 Agendador:nenhum }] Dispositivos de Rede:[{ Nome:dummy0 M acAddress:5a :34:bf:e4:23:cc Speed:0 Mtu:1500 } { Name:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 Speed:-1 Mtu:1500 } { Name:gre0 M acAddress:00 :00:00:00 Speed:0 Mtu:1476 } { Name:gretap0 M acAddress:00 :00:00:00:00 :00 Velocidade:0 Mtu:1462 } { Nome:ip6_vti0 M acEndereço:00 :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00Velocidade :0 Mtu:1500 } { Nome:ip6gre0 M acEndereço:00 :00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00 Velocidade:0 Mtu:1448 } { Nome:ip6tnl0 M acEndereço:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 Velocidade:0 Mtu:1452 } { Nome:ip_vti0 Ma
12 de abril 02:10:01 localhost kubelet: cAddress:00 :00:00:00 Speed:0 Mtu:1428 } { Name:sit0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 } { Name: teql0 MacAddress : Speed:0 Mtu:1500 } { Name:tunl0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 }] Topologia:[{Id:0 Memory:1037021184 Cores:[{Id:0 Threads :[0] Caches:[{ Size:32768 Type:Data Level:1 } { Size:32768 Type:Instruction Level:1 } { Size:4194304 Type:Unified Level:2 }]}] Caches:[]}] Clou dProvider:Unknown InstanceType:Unknown I nstanceID:Nenhum }
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.013353 3445 manager.go:204] Versão: {Kern elVersion:4.9.15-x86_64-linode81 Container OsVersion:Fedora 25 (Server Edition) Dock erVersion:1.12. 6 CadvisorVersion: CadvisorRevision:}
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos habilitado, mas --cgroup-root não foi especificado. padrão para /
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.016562 3445 container_manager_linux.go:218] A execução com swap ativado não é suportada, desative o swap! Este será um erro fatal por padrão a partir do K8s v1.6! Enquanto isso, você pode optar por tornar isso um erro fatal ativando --experimental-fail-swap-on.
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016688 3445 container_manager_linux.go:245] gerenciador de contêiner verificado pelo usuário especificado cgroup-root existe: /
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016717 3445 container_manager_linux.go:250] Criando o objeto Container Manager com base na configuração do nó: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contein erRuntime:docker Cgro upsPerQOS:true CgroupRoot:/ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable :map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] HardEvictionThresholds:[{ Signal:memory.available Operator :Menor que Valor:{ Quantidade:100Mi P ercentage:0 } Gr acePeriod:0s MinReclaim:}]} ExperimentalQO SReserved:map []}
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016943 3445 kubelet.go:255] Adicionando arquivo de manifesto: /etc/kubernetes/manifests
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016966 3445 kubelet.go:265] Assistindo apiserver
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025058 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Falha ao listar *v1.Node: Obter https: //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0: discar tcp 50.116.13.214:6443: getsockopt: conexão recusada
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025342 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Falha ao listar *v1.Service: Obter https: //50.116.13.214 :6443/api/v1/services?resourceVersion=0: discar tcp 50.116.13.214:6443: getsockopt: conexão recusada
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025397 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Falha ao listar *v1.Pod: Obter https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0: disque tcp 50.116.13.214:6443: getsockopt: conexão recusada
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.026574 3445 kubelet_network.go:70] Modo hairpin definido como "promiscuous-bridge", mas o kubenet não está ativado, voltando para "hairpin-veth"
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.026599 3445 kubelet.go:494] Modo hairpin definido como "hairpin-veth"
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.026661 3445 cni.go:157] Não é possível atualizar a configuração cni: Nenhuma rede encontrada em /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.034194 3445 cni.go:157] Não é possível atualizar a configuração cni: Nenhuma rede encontrada em /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.043157 3445 cni.go:157] Não é possível atualizar a configuração cni: Nenhuma rede encontrada em /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.043183 3445 docker_service.go:187] Docker cri networking gerenciado por cni
12 de abril 02:10:01 localhost kubelet: erro: falha ao executar Kubelet: falha ao criar kubelet: configuração incorreta: kubelet cgroup driver: "cgroupfs" é diferente do driver do docker cgroup: "systemd"
12 de abril 02:10:01 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? endereço=? terminal=? res=falhou'
12 de abril 02:10:01 localhost systemd: kubelet.service: Main process exited, code=exited, status=1/FAILURE
12 de abril 02:10:01 localhost systemd: kubelet.service: Unidade entrou em estado de falha.
12 de abril 02:10:01 localhost systemd: kubelet.service: Falha com resultado 'código de saída'.

@acloudiator Acho que você precisa definir o cgroup-driver na configuração do kubeadm.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

E reinicie o serviço kubelet

Seria ótimo se o kubeadm pudesse de alguma forma lidar com o problema de configuração do cgroup.
Ideias:

• Abortando a inicialização em caso de configuração incorreta
• Verifique as configurações do Docker com antecedência e use o que o Docker está usando (não tenho certeza sobre quaisquer implicações aqui)

Apenas uma atualização, qualquer solução alternativa que tentei não funcionou. Então, mudei para o CentOS 7.3 para o master e funciona como um encanto! Eu mantive os minions no CentOS 7.2.

@rushabh268 oi, eu tenho o mesmo problema no Redhat Linux 7.2. Após atualizar o systemd, esse problema foi resolvido. Você pode tentar atualizar o systemd antes da instalação.
yum update -y systemd
e o log de erros do kubelet:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

Eu bati esse problema no CentOS 7.3. O problema desapareceu depois de desinstalar o docker-ce e instalar o docker-io.
Não tenho certeza se é a causa raiz. De qualquer forma, você pode tentar se os métodos acima não funcionarem.

@ZongqiangZhang Eu tenho o docker 1.12.6 instalado em meus nós. @juntaoXie Eu tentei atualizar o systemd também e ainda está preso

Então, estou executando o Centos 7.3 w/1.6.4 sem problemas em várias máquinas.

Você se certificou de que desativou o selinux?

@timothysc Eu tenho o CentOS 7.2 e não o CentOS 7.3 e o selinux está desabilitado

Eu tenho um CentOS Linux versão 7.3.1611 (Core) e o KubeAdm 1.6.4 não funciona.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

Saída:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr você pode compartilhar um pouco mais de kube-apiserver logs? (os que estão no final do seu comentário)

As linhas acima do que você já incluiu mencionam o mesmo endereço IP? Tentei executar o k8s em dois novos KVMs recentemente, um com o Ubuntu 16.04 e outro com o CentOS 7.3. Ambos deram isso:

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

Observe que primeiro o endereço IP mencionado é x.x.x.x , mas então localhost é resolvido para y.y.y.y (que no meu caso era um ip público de outro KVM sentado no mesmo servidor físico). Eu poderia iniciar o kubeadm no Ubuntu no final, mas somente depois de instalar o dnsmasq de maneira semelhante a https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861. A mesma solução alternativa no CentOS não ajudou.

Isso pode ser um bug no kubedns ou algo assim? Curiosamente, as mesmas etapas nas VMs da AWS trouxeram o kubeadm. Mas as instâncias do EC2 são muito caras para meus projetos pessoais.

Estou com o mesmo problema do @paulobezerr.

## Versões :
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
docker-client-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
docker-1.12.6-28.git1398f24.el7.centos.x86_64

ASSIM
uname -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > CentOS Linux versão 7.3.1611 (Núcleo)

## Passos seguidos:

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## logs do servidor de API:
--> 37.247.XX.XXX é o IP público

[restful] 2017/06/08 10:45:19 log.go:30: [restful/swagger] a listagem está disponível em https://37.247.XX.XXX :6443/swaggerapi/
[restful] 2017/06/08 10:45:19 log.go:30: [restful/swagger] https://37.247.XX.XXX :6443/swaggerui/ está mapeado para a pasta /swagger-ui/
E0608 10:45:19.429839 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *api.Secret: Get https://localhost : 6443/api/v1/secrets?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.430419 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *api.ResourceQuota: Get https://localhost : 6443/api/v1/resourcequotas?resourceVersion=0: disque tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.430743 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *api.ServiceAccount: Get https://localhost : 6443/api/v1/serviceaccounts?resourceVersion=0: disque tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.431076 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *storage.StorageClass: Get https://localhost : 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.431377 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *api.LimitRange: Get https://localhost : 6443/api/v1/limitranges?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.431678 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *rbac.RoleBinding: Get https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.431967 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *rbac.ClusterRoleBinding: Get https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.432165 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *api.Namespace: Get https://localhost : 6443/api/v1/namespaces?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.432386 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *rbac.ClusterRole: Obter https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.432619 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Falha ao listar *rbac.Role: Get https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0: discar tcp 108.59.253.109:6443: getsockopt: conexão recusada
I0608 10:45:19.481612 1 serve.go:79] Servindo com segurança em 0.0.0.0:6443
W0608 10:45:19.596770 1 storage_extensions.go:127] sincronização de recursos de terceiros falhou: Get https://localhost :6443/apis/extensions/v1beta1/thirdpartyresources: dial tcp 108.59.253.109:6443: getsockopt: conexão recusada
E0608 10:45:19.596945 1 client_ca_hook.go:58] Post https://localhost :6443/api/v1/namespaces: disque tcp 108.59.253.109:6443: getsockopt: conexão recusada
F0608 10:45:19.597174 1 controller.go:128] Não é possível realizar a verificação inicial de alocação de IP: não é possível atualizar o bloco de IP do serviço: Get https://localhost :6443/api/v1/services: dial tcp 108.59.253.109: 6443: getsockopt: conexão recusada

@albpal Eu tive exatamente o mesmo problema há uma semana: dial tcp X.X.X.X estava mostrando um endereço IP estranho e não consegui resolver isso no CentOS mesmo depois de instalar o dnsmasq e mudar para os servidores DNS do google em vez do DNS do meu provedor de hospedagem. Só por curiosidade: você pode verificar se o endereço IP errado que você está vendo está no mesmo data center que sua VM? Você pode usar http://ipinfo.io para estimar isso com algum grau de certeza ou apenas traceroute.

No meu caso, o endereço IP errado estava se referindo a outro KVM no mesmo servidor físico. Pode ser algo relacionado ao DNS em uma máquina física, o que pode exigir uma solução alternativa dentro do kube api ou kube dns, caso contrário, iniciar um cluster se torna uma grande dor para muitos recém-chegados! Eu perdi algumas noites antes de perceber dial tcp com um IP errado nos logs, o que foi uma experiência muito triste no primeiro k8s. Ainda não tenho uma boa solução pronta para uso para KVMs CentOS no meu provedor de hospedagem ( firstvds.ru ).

O que pode causar essa incompatibilidade muito estranha nos endereços IP?

@albpal Por favor, abra um novo problema, o que você descreveu e sobre o que é esse problema são problemas separados (eu acho, com base nessas informações)

@kachkaev Acabei de verificar o que você sugeriu.

Descobri que o IP errado termina em um CPANEL: vps-1054290-4055.manage.myhosting.com.

Por outro lado, o IP público do meu VPS é da Itália e esse IP errado é dos EUA... mesmo servidor físico.

Você conseguiu instalar o k8s?

@luxas eu tenho o mesmo comportamento, mas copiei os logs do dockersaída também.

A saída do /var/log/messages e do kubeadm init é a mesma do problema original.

@albpal para que sua VM e essa segunda máquina estejam no CPANEL? Bom sinal, porque então o meu caso é o mesmo! O fato de ser a mesma máquina física pode ser apenas uma coincidência.

Eu usei dois KVMs em meus experimentos, um com o Ubuntu 16.04 e outro com o CentOS 7.3 Ambos tinham o mesmo problema de endereço IP dial tcp . Consegui iniciar o kubeadm no Ubuntu no final, livrando-me dos servidores DNS do meu provedor. A solução foi baseada no conselho de crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

Isso trouxe o endereço IP correto após dial tcp nos logs no Ubuntu e o kubeadm inicializou após alguns minutos! Tentei configurar o dnsmasq no CentOS da mesma maneira, mas isso não resolveu o problema. Mas eu sou um novato total neste sistema operacional, então pode ser que eu tenha esquecido de reiniciar algum serviço ou limpar algum cache. Experimente esta ideia!

De qualquer forma, parece errado fazer uma etapa extra de reconfiguração do DNS porque é muito confuso (não sou um cara de servidor/devops e toda essa investigação pela qual passei quase me fez chorar :com medo:). Espero que o kubeadm consiga detectar se os servidores DNS do provedor estão funcionando de maneira estranha e corrigir automaticamente o que for necessário no cluster.

Se alguém da equipe k8s estiver disposto a ver o que está acontecendo, ficarei feliz em compartilhar o acesso root em alguns novos KVMs FirstVDS. Apenas me e-mail ou DM no twitter!

Obrigado @kachkaev ! vou tentar amanha

cc @kubernetes/sig-network-bugs Você tem uma ideia de por que a resolução do DNS falha acima?

Obrigado @kachkaev , tentaremos analisar isso. Eu não acho que seja realmente culpa do kubeadm em si, mas se muitos usuários estiverem presos na mesma configuração incorreta, podemos adicioná-lo aos documentos de solução de problemas ou algo assim ...

Meus logs são muito propensos a logs @albpal .
Mas vou tentar o dnsmasq. Obrigado a todos!

@kachkaev , não funciona. Mesmo problema 😢
O log completo está em anexo.

log.txt

consegui resolver!! Muito obrigado @kachkaev por suas dicas!

Acho que o problema foi:

### Cenário:
Um VPS com o seguinte esquema de configuração:

resolv.conf
[ root@apalau ~]# cat resolv.conf
servidor de nomes 8.8.8.8
servidor de nomes 8.8.4.4
servidor de nomes 2001:4860:4860::8888
servidor de nomes 2001:4860:4860::8844

Não há nenhum domínio de pesquisa!

anfitriões
[ root@apalau ~]# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
37.XXX.XX.XXX nome.vpshosting.com

De acordo com os registros, o contêiner do kubernetes tenta se conectar a:

Obtenha https://localhost :6443/api/v1/secrets?resourceVersion=0

E quando eu peço:
$ nslookup "localhost.$(hostname -d)"
O IP que recebo é o errado, ou seja, 108.59.253.109.

Então, acho que esses contêineres estão tentando resolver o host local (sem domínio) e estão recebendo um IP errado. Provavelmente porque "localhost.$(hostname -d)" está resolvendo para esse IP, o que acho que acontecerá em quase todos os serviços VPS.

## O que eu fiz para corrigir o problema em um VPS CentOS 7.3 (além das etapas mostradas em https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm):

Como raiz:

1. redefinição do kubeadm
2. yum instalar dnsmasq
3. cp /etc/resolv.conf ~/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "servidor de nomes 127.0.0.1\nservidor de nomes $(hostname -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr +i /etc/resolv.conf
8. echo -e "servidor=8.8.8.8\nservidor=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(hostname -i)\tlocalhost.$(hostname -d)" >> /etc/hosts
10. reinicialização do serviço dnsmasq
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld
12. kubeadm init

Eu adicionei o hostname -i na etapa 5 porque se eu não fizer isso, o docker adicionará 8.8.8.8 ao resolv.conf nos contêineres.

Espero que ajude os outros também.

Obrigado!!

Fico feliz em saber disso @albpal! Eu segui suas etapas antes de kubeadm init e o cluster finalmente inicializou dentro do meu teste FirstVDS KVM com CentOS 7.3! A única coisa extra que tive que fazer foi parar e desabilitar o firewalld, pois estava bloqueando conexões externas à porta 6443:

systemctl disable firewalld
systemctl stop firewalld

_Não recomendo fazer isso porque não estou ciente das consequências - isso apenas me ajudou a concluir um teste em um sistema operacional que normalmente não uso._

Agora eu estou querendo saber o que poderia ser feito para facilitar o processo de instalação para iniciantes como eu. O caminho entre ficar preso em Created API client, waiting for the control plane to become ready e resolver as coisas ainda é enorme, especialmente se levarmos em conta o tempo necessário para desenterrar esse problema e ler todos os comentários. __O que vocês podem sugerir?__

@paulobezerr pelo que vejo em seu anexo acredito que seu problema seja um pouco diferente. Meus logs do apiserver contêm algo como:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

enquanto o seu diz:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(no primeiro caso é localhost / RANDOM_IP , enquanto no segundo caso é sempre 10.X.X.X )

Infelizmente, não sei o que aconselhar, exceto tentar vários --apiserver-advertise-address=??? quando você kubeadm init (consulte os documentos ). Minha experiência prática com o k8s chegou a 10 dias, a maioria dos quais foram tentativas vãs de iniciar um cluster de nó único no FirstVDS :-)

Espero que você resolva isso e compartilhe a solução com os outros!

@kachkaev Esqueci de mencionar que apliquei a seguinte regra de firewall:

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld

Funciona bem no meu ambiente quando aplicada esta regra sem desativar o firewall. Vou adicioná-lo ao meu comentário anterior para coletar todas as etapas necessárias.

@juntaoXie Obrigado. Atualizar a versão do systemd por seu comentário funcionou para mim.

Ainda com esse problema há dois dias, estou executando tudo isso atrás de um proxy e não parece haver um problema.
kubeadm init fica esperando que o plano de controle fique pronto. Quando eu faço o docker ps, os contêineres são puxados e executados, mas nenhuma porta está atrasada (não sei se é suposto, mas ok). etcd também está funcionando bem. No entanto, quando eu olho para o meu serviço kubelet, ele diz Unable to update cni config: No networks found in /etc/cni/net.d que https://github.com/kubernetes/kubernetes/issues/43815 diz que está ok, você necessidade de aplicar uma rede cni.
O que eu faço conforme https://www.weave.works/docs/net/latest/kubernetes/kube-addon/. Agora, o kubectl diz que 8080 foi recusado - você especificou o host ou porta correto? Parece um problema de galinha e ovo, como aplico uma rede cni quando meu kubeadm init trava?? Isso é tão confuso

Este também não é um problema do cgroup, tanto o docker quanto o meu serviço kubelet usam systemd.

FWIW, tive esse mesmo problema no GCP, tentei usar o Ubuntu 16.04 e o CentOS usando os seguintes comandos em um projeto limpo:

$ gcloud compute instances create test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nó 1 para teste de API'

$ gcloud compute instances create test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nó 2 para teste de API'

$ gcloud compute instances create test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nó 3 para teste de API'

$ apt-get atualização

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl reiniciar kubelet

$ kubeadm init

Então, depois de bater minha cabeça contra ele por várias horas, acabei indo com:

$ gcloud beta container --project "weather-177507" clusters criam "weather-api-cluster-1" --zone "us-west1-a" --username="admin" --cluster-version "1.6.7" --machine-type "f1-micro" --image-type "COS" --disk-size "100" --scopes " https://www.googleapis.com/auth/compute "," https:// www.googleapis.com/auth/devstorage.read_only "," https://www.googleapis.com/auth/logging.write "," https://www.googleapis.com/auth/monitoring.write "," https://www.googleapis.com/auth/servicecontrol "," https://www.googleapis.com/auth/service.management.readonly "," https://www.googleapis.com/auth/trace. append " --num-nodes "3" --network "default" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

Consegui colocar um cluster em funcionamento onde não podia a partir de uma imagem em branco.

Até eu estou enfrentando o mesmo problema com a versão Kubeadm:

está ficando preso em
[apiclient] Created API client, waiting for the control plane to become ready

Mesmo problema que @paulobezerr - meu env: CentOS 7.4.1708 kubeadm version: &version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean ", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compilador:"gc", Plataforma:"linux/amd64"}

Para mim, esse problema não estava sendo executado com o SELinux desativado. A pista foram seus passos, o comentário:

edite /etc/selinux/config e defina SELINUX=disabled

As etapas de instalação aqui (https://kubernetes.io/docs/setup/independent/install-kubeadm/) para CentOS dizem:
"Desabilitar o SELinux executando o setenforce 0 é necessário para permitir que os contêineres acessem o sistema de arquivos do host"
mas não menciona (pelo menos na guia CentOS/RHEL/Fedora) que você deve editar /etc/selinux/config e definir SELINUX=disabled

Para mim, mesmo tendo executado o setenforce 0, ainda estava recebendo os mesmos erros. Editando /etc/selinux/config e configurando SELINUX=disabled, a reinicialização corrigiu para mim.

Parece haver muitos problemas (potencialmente ortogonais) em jogo aqui, então estou ansioso para que não deixemos as coisas divergirem. Até agora, parece que identificamos 3 problemas:

1. O DNS não resolve o host local corretamente em algumas máquinas. @kachkaev @paulobezerr Você conseguiu consertar isso? Eu estou querendo saber como tornar isso mais explícito em nossos requisitos, alguma ideia?

2. Correspondência cgroup-driver incorreta entre o kubelet e o Docker. Devemos adicionar isso à nossa lista de requisitos.

3. O SELinux não está desabilitado. Devemos adicionar isso à nossa lista de requisitos.

Uma vez que todos os três são abordados com PRs, talvez devêssemos encerrar isso e deixar as pessoas que tiverem problemas no futuro criarem seus próprios problemas. Isso nos permitirá receber informações mais estruturadas e fornecer suporte mais granular, em vez de fazer malabarismos com muitas coisas em um thread. O que você acha @luxas?

Para mim, fui com o docker 17.06 (o 17.03 é recomendado, mas não está disponível no docker.io) e executei o mesmo problema. A atualização para 17.09 magicamente corrigiu o problema.

Como este tópico ficou tão longo e provavelmente há muitos problemas totalmente diferentes, a coisa mais produtiva que posso adicionar além do excelente comentário de @jamiehannaford é que, por favor, abra novos problemas direcionados com todos os logs / informações relevantes, caso algo falha _com o mais novo kubeadm v1.8_, que detecta automaticamente um estado defeituoso muito melhor do que as versões anteriores. Também melhoramos nossa documentação sobre requisitos e casos extremos que esperamos economizar tempo para as pessoas.

Obrigado a todos!

eu tive o mesmo problema com 1.8 no CENTOS 7 com 1.8? alguém teve o mesmo problema ou sabe como resolver.

@rushins Se você quiser obter ajuda com o possível problema que está vendo, abra um novo problema aqui com detalhes suficientes.

Eu tenho o mesmo problema que @rushabh268 que é connection refused e não localhost:6443/api .
Finalmente resolvi isso observando o domínio pesquisando search xxx.xx.xxxx.org .

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Ambiente:
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> Docker v17.12.0.ce
-> na rede privada xxx.xx.xxxx.org

Por favor, pelo amor de deus, adicione isso aos documentos. Eu tenho tentado configurar meu cluster por muitas noites depois do trabalho sob o pretexto de "se divertir e brincar com a tecnologia".

Obrigado a @kachkaev pela solução.