A primeira mensagem de erro: não é possível carregar o arquivo CA do cliente /etc/kubernetes/pki/ca.crt: abra /etc/kubernetes/pki/ca.crt: não existe esse arquivo ou diretório

A primeira mensagem de erro: não é possível carregar o arquivo CA do cliente /etc/kubernetes/pki/ca.crt: abra /etc/kubernetes/pki/ca.crt: não existe esse arquivo ou diretório

oi, aqui estão algumas perguntas:
1) o kubeadm init termina e imprime um token boostrap?
2) versão do tempo de execução do contêiner?
3) o kubelet e o kubeadm são versão 1.12?

/ prioridade precisa de mais evidências

precisa executar systemctl start kubelet antes de kubeadm init

Estou tendo o mesmo problema, porque o núcleo da xícara é menor que 2

o mesmo problema

@javacppc como você resolveu isso? Quando executei systemctl start kubelet recebo error code

mesmo problema com kubernetes 1.12.2.
@Javacppc como você resolveu isso?

o mesmo problema

o mesmo problema

Ola pessoal,

Estou enfrentando o mesmo problema aqui, quando inicio o cluster, recebo a mensagem do token, mas não consigo instalar uma trama de nuvem:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" The connection to the server 192.168.56.104:6443 was refused - did you specify the right host or port?

Quando vou para os logs, recebo a mensagem sobre o nome do nó:

Dec 02 22:27:55 kubemaster5 kubelet[2838]: E1202 22:27:55.128645 2838 kubelet.go:2236] node "kubemaster5" not found

Alguém pode me enviar alguma luz?

Obrigado!

meu problema está resolvido e na verdade não é um bug, é porque o apiserver falhou ao iniciar por algum motivo.

"apiserver falhou ao iniciar por algum motivo"? Você pode dar alguns detalhes ??

Resolvi meu problema há vários dias. Atualização de 1.11.4 -> 1.12.3. Eu tenho:

1. api-server - rodando em uma interface virtual específica com sua própria rede. ( metal puro ).
   Depois de kubeadm init/join com o sinalizador apiserver-advertise-address ele começou em uma interface específica, mas os pacotes com configurações / verificações de saúde percorrem a rota padrão da tabela de roteamento (interface padrão). Parâmetro bind-address em /etc/kubernetes/manifests/kube-apiserver.yaml ajudado com vinculação ao IP da interface virtual.
2. flannel - a mesma situação com a rede após a criação de controller , scheduler pods. A implantação do DNS falhou por causa de connection refused para clusterIP do servidor API 10.96.0.1:443 . (tabela de roteamento padrão) Especifiquei node-ip do nó do cluster pelo sinalizador --node-ip em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf com IP da interface virtual.

Depois disso, eu tenho o nó pronto com a versão 1.12.3. A informação mais útil estava em docker logs + kubectl logs

mesmo problema aqui com v1.13.0

O mesmo problema aqui com o Kubernetes v1.13.0
CentOS 7
docker-ce 18.06 (última versão validada)
dockerd: ativo, em execução
kubelet: ativo, em execução
selinux: disabled
firewalld: desativado

ERROR é:
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/ etc / hosts contém o nó, é passível de ping, é alcançável - na verdade, fazendo um único mestre de trabalho único (ou seja, nó contaminado).

Onde o K8S procura esse valor? em / etc / hosts?
Posso solucionar problemas e fornecer mais evidências, se necessário.

-> o init do kubeadm termina e imprime um token boostrap?
Termina com um longo erro:

[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

NOTA: Nenhum dos comandos sugeridos após o tempo limite relatou algo que valha a pena mencionar aqui.

versão do kubelet e do kubeadm?
---> 1.13.0
kubeadm version: & version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.0", GitCommit: "ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState: "clean", BuildDate: "02-12-03T21: 01Z ", GoVersion:" go1.11.2 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

Além disso, não deveria definir uma mensagem de erro melhor do que "nó não encontrado" com um pouco mais de clareza / verbosidade nos logs do kube?

Obrigado

O mesmo problema...

$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Fri 2018-12-14 19:05:47 UTC; 2min 2s ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 9114 (kubelet)
    Tasks: 23 (limit: 4915)
   CGroup: /system.slice/kubelet.service
           └─9114 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-d

Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862262    9114 kuberuntime_manager.go:657] createPodSandbox for pod "kube-scheduler-pineview_kube-system(7f99b6875de942b000954351c4a
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862381    9114 pod_workers.go:186] Error syncing pod 7f99b6875de942b000954351c4ac09b5 ("kube-scheduler-pineview_kube-system(7f99b687
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906855    9114 remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to start san
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906944    9114 kuberuntime_sandbox.go:65] CreatePodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fai
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906981    9114 kuberuntime_manager.go:657] createPodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fa
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.907100    9114 pod_workers.go:186] Error syncing pod b7841e48f3e7b81c3cda6872104ba3de ("etcd-pineview_kube-system(b7841e48f3e7b81c3c
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.933627    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.033880    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.134064    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.184943    9114 event.go:212] Unable to write event: 'Post https://192.168.1.235:6443/api/v1/namespaces/default/events: dial tcp 192.

O mesmo problema:

Ubuntu 18.04.1 LTS
Kubernetes v1.13.1 (usando cri-o 1.11)

Seguiu as instruções de instalação em kubernetes.io:
https://kubernetes.io/docs/setup/independent/install-kubeadm/
https://kubernetes.io/docs/setup/cri/#cri -o

systemctl enable kubelet.service
kubeadm init --pod-network-cidr=192.168.0.0/16 --cri-socket=/var/run/crio/crio.sock

/etc/hosts

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       master01.mydomain.tld master01
::1             master01.mydomain.tld master01

/etc/hostname

systemctl status kubelet

● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Tue 2018-12-18 16:19:54 CET; 20min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 10148 (kubelet)
    Tasks: 21 (limit: 2173)
   CGroup: /system.slice/kubelet.service
           └─10148 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --resolv-conf=/run/systemd/resolve/resolv.conf

Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.795313   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.896277   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.997864   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.098927   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.200355   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.281586   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://192.168.178.27:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.282143   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:444: Failed to list *v1.Service: Get https://192.168.178.27:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.283945   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:453: Failed to list *v1.Node: Get https://192.168.178.27:6443/api/v1/nodes?fieldSelector=metadata.name%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.301468   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.402256   10148 kubelet.go:2266] node "master01" not found

@fhemberger Eu descobri meu problema. Ele estava usando snap para instalar o Docker. Se eu desinstalei e reinstalei usando apt , o kubeadm funcionou bem.

@cjbottaro Eu não uso o Docker, mas cri-o.

mesmo problema aqui com v1.13.1

Se você estiver usando systemd e cri-o, certifique-se de defini-lo como driver cgroup em /var/lib/kubelet/config.yaml (ou passe o trecho abaixo como parte de kubeadm init --config=config.yaml ).

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Se você perceber isso nos registros do kubelet:

remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = cri-o configured with systemd cgroup manager, but did not receive slice as parent: /kubepods/besteffort/…

Eu encontrei o mesmo problema hoje.

Corrigi- lo removendo

@JishanXing, obrigado! Isso também resolveu meu problema de execução no Raspbian Sketch Lite

Corrigi-lo removendo /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf

Seria melhor usar o comando kubeadm reset .

@fhemberger como resolvê-lo, a mesma pergunta, obrigado

Eu encontrei o mesmo problema quando atualizei o K8s de 1.13.3 para 1.13.4 ...
Eu resolvo depois de editar /etc/kubernetes/manifests/kube-scheduler.yaml . Modifique a versão da imagem
image: k8s.gcr.io/kube-scheduler:v1.13.3 ==> image: k8s.gcr.io/kube-scheduler:v1.13.4
o mesmo para kube-controller-manager.yaml e kube-apiserver.yaml.

A forma mais recente é adicionar a opção --image-repository registry.aliyuncs.com/google_containers , minha versão do k8s é 1.14.0, docker Versão: 18.09.2,
`kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.14.0 --pod-network-cidr = 192.168.0.0 / 16
[init] Usando a versão do Kubernetes: v1.14.0
[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/
[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] Gerando certificado e chave "front-proxy-ca"
[certs] Gerando certificado e chave "front-proxy-client"
[certs] Gerando certificado e chave "ca"
[certs] Gerando certificado e chave "apiserver"
[certs] apiserver servindo certificado é assinado para nomes DNS [jin-virtual-machine kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] e IPs [10.96.0.1 192.168.232.130]
[certs] Gerando certificado e chave "apiserver-kubelet-client"
[certs] Gerando certificado e chave "etcd / ca"
[certs] Gerando certificado e chave "etcd / server"
[certs] etcd / server que serve o certificado é assinado para nomes DNS [jin-virtual-machine localhost] e IPs [192.168.232.130 127.0.0.1 :: 1]
[certs] Gerando certificado e chave "etcd / peer"
[certs] etcd / peer servindo cert é assinado para nomes DNS [jin-virtual-machine localhost] e IPs [192.168.232.130 127.0.0.1 :: 1]
[certs] Gerando certificado e chave "apiserver-etcd-client"
[certs] Gerando certificado e chave "etcd / healthcheck-client"
[certs] Gerando chave "sa" e chave pública
[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
[apiclient] Todos os componentes do plano de controle estão saudáveis ​​após 17.004356 segundos
[upload-config] armazenando a configuração usada no ConfigMap "kubeadm-config" no namespace "kube-system"
[kubelet] Criação de um ConfigMap "kubelet-config-1.14" no namespace kube-system com a configuração dos kubelets no cluster
[upload-certs] Pular fase. Por favor, veja --experimental-upload-certs
[mark-control-plane] Marcando o nó jin-virtual-machine como control-plane adicionando o rótulo "node-role.kubernetes.io/master= ''"
[mark-control-plane] Marcando o nó jin-virtual-machine como o plano de controle adicionando as manchas [node-role.kubernetes.io/ master: NoSchedule ]
[bootstrap-token] Usando o token: xucir0.o4kzo3qqjyjnzphl
[bootstrap-token] Configurando tokens de bootstrap, cluster-info ConfigMap, funções RBAC
[bootstrap-token] configurou regras RBAC para permitir que tokens de inicialização de nó postem CSRs para que os nós obtenham credenciais de certificado de longo prazo
[bootstrap-token] configurou regras RBAC para permitir que o controlador csrapprover aprove automaticamente CSRs de um Node Bootstrap Token
[bootstrap-token] configurou regras RBAC para permitir a rotação de certificados para todos os certificados de cliente de nó no cluster
[bootstrap-token] criando o ConfigMap "cluster-info" no namespace "kube-public"
[addons] Addon essencial aplicado: CoreDNS
[addons] Addon essencial aplicado: kube-proxy

Seu plano de controle do Kubernetes foi inicializado com sucesso!

Para começar a usar seu cluster, você precisa executar o seguinte como um usuário regular:

mkdir -p $ HOME / .kube
sudo cp -i /etc/kubernetes/admin.conf $ HOME / .kube / config
sudo chown $ (id -u): $ (id -g) $ HOME / .kube / config

Agora você deve implantar uma rede pod para o cluster.
Execute "kubectl apply -f [podnetwork] .yaml" com uma das opções listadas em:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Em seguida, você pode juntar qualquer número de nós de trabalho executando o seguinte em cada um como raiz:

kubeadm join 192.168.232.130:6443 --token xucir0.o4kzo3qqjyjnzphl
--discovery-token-ca-cert-hash sha256: 022048b22926a2cb2f8295ce2e3f1f6fa7ffe1098bc116f7d304a26bcfb78656
`

Encontrou o mesmo problema com kubernetes v1.14.1 e cri-o v1.14.0 em uma VM GCP Ubuntu 18.04. No entanto, as coisas funcionaram bem ao usar o docker. referência: https://github.com/cri-o/cri-o/issues/2357

Meu problema era com os diferentes drivers cgroup. CRIO usa systemd por padrão, kubelet usa cgroupfs por padrão.

cat /etc/crio/crio.conf | grep cgroup
# cgroup_manager is the cgroup management implementation to be used
cgroup_manager = "systemd"

Se for esse o seu caso, consulte https://kubernetes.io/docs/setup/independent/install-kubeadm/#configure -cgroup-driver-used-by-kubelet-on-master-node

Basta escrever o arquivo

echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" > /etc/default/kubelet

e execute o kubeadm init depois disso. Ou mude cgroup_manager para cgroupfs

ao contrário do docker, cri-o e containerd são um pouco mais complicados de gerenciar em termos de detecção de driver do cgroup, mas existem alguns planos para suportar isso a partir do kubeadm.

docker já foi manipulado.

Então, aparentemente, não há solução a não ser redefinir o cluster $ (yes | kubeadm reset), o que não é uma solução na minha opinião!

Alterar o repositório de imagens funcionou para mim, mas essa não é uma boa solução.
--image-repository registry.aliyuncs.com/google_containers

meu caso funcionou com isso

sed -i 's / cgroup-driver = systemd / cgroup-driver = cgroupfs / g' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Eu tenho o mesmo problema. Eu uso kubeadm init --config=init-config.yaml e falhou, este arquivo gerado pelo kubeadm. há um campo advertiseAddress que o padrão é 1.2.3.4 no arquivo, o que faz com que o etcd contianer start falhe. quando eu mudar para 127.0.0.1, o etcd contianer iniciará com sucesso e o init do kubeadm será bem-sucedido

para resolver este problema, use docker ps -a list all container, verifique se algum deles saiu, em caso afirmativo, use docker logs CONTIANER_ID ver o que aconteceu. espero que ajude

Olá a todos, alguém tem uma solução? O mesmo problema aqui, mas usando o k3s .

@MateusMac você provavelmente deve abrir um relatório de bug contra o k3s também.

Trabalhou por uma semana para conseguir kubeadm trabalhando em
Ubuntu 18.04
docker 18.06-2-ce
k8s 1.15.1
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Fails with:

[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

Os registros do kubelet mostram que ele simplesmente não consegue encontrar os nós para passar da primeira base:

warproot<strong i="15">@warp02</strong>:~$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2019-08-04 18:22:26 AEST; 5min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 12569 (kubelet)
    Tasks: 27 (limit: 9830)
   CGroup: /system.slice/kubelet.service
           └─12569 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-dri

Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322762   12569 kuberuntime_sandbox.go:68] CreatePodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)"
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322806   12569 kuberuntime_manager.go:692] createPodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322872   12569 pod_workers.go:190] Error syncing pod ecae9d12d3610192347be3d1aa5aa552 ("kube-scheduler-warp02_kube-system(ecae9d12d36101
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.373094   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.375587   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.473295   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.573567   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.575495   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.RuntimeClass: Get https://10.1.1.4:6
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.590886   12569 event.go:249] Unable to write event: 'Post https://10.1.1.4:6443/api/v1/namespaces/default/events: dial tcp 10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.673767   12569 kubelet.go:2248] node "warp02" not found

Devo observar que tenho vários NICs nessas máquinas bare-metal:

warproot<strong i="6">@warp02</strong>:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:feff:fe65:37f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:fe:65:03:7f  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 516 (516.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.2  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::32b5:c2ff:fe02:410b  prefixlen 64  scopeid 0x20<link>
        ether 30:b5:c2:02:41:0b  txqueuelen 1000  (Ethernet)
        RX packets 46  bytes 5821 (5.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70  bytes 7946 (7.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.4  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 fd42:59ff:1166:0:25a7:3617:fee6:424e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x20<link>
        inet6 fd9e:fdd6:9e01:0:1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x0<global>
        ether 18:03:73:44:56:94  txqueuelen 1000  (Ethernet)
        RX packets 911294  bytes 1361047672 (1.3 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 428759  bytes 29198065 (29.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

ib0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-10-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ib1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-20-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 25473  bytes 1334779 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25473  bytes 1334779 (1.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Não sei se isso é um problema, mas configurei meu arquivo /etc/hosts como

warproot<strong i="7">@warp02</strong>:~$ cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
# add our host name
10.1.1.4 warp02 warp02.ad.xxx.com
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
# add our ipv6 host name
fd42:59ff:1166:0:25a7:3617:fee6:424e warp02 warp02.ad.xxx.com

warproot<strong i="8">@warp02</strong>:~$ 

Então, está configurado (eu acho) para olhar para a NIC 10.1.1.4 como a "rede" para k8s

nslookup em relação ao nome do nó parece estar funcionando bem:

warproot<strong i="13">@warp02</strong>:~$ nslookup warp02
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   warp02.ad.xxx.com
Address: 10.1.1.4
Name:   warp02.ad.xxx.com
Address: fd42:59ff:1166:0:25a7:3617:fee6:424e

warproot<strong i="14">@warp02</strong>:~$ 

Consultei a documentação de instalação de kubeadm várias vezes.

Esquisito. Ele simplesmente não consegue encontrar a rede.

Perplexo.

Para a versão 1.15.3 , consegui corrigir isso no Ubuntu 18.04 adicionando

kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    cgroup-driver: "systemd"

para minha configuração kubeadm e, em seguida, executando kubeadm init

Tenho o mesmo problema aqui, com a versão 1.15.3, no Ubuntu 18.04
@ kris-nova Eu realmente apreciaria se você pudesse especificar onde este arquivo de configuração está localizado :-)

ATUALIZAÇÃO: Não sei dizer o porquê, mas funciona agora, sem alterar nenhuma configuração!
(observação: não sei se está relacionado, mas atualizei o docker de v.19.03.1 para v.19.03.2, antes de tentar novamente kubeadm init )

Eu estava recebendo o erro abaixo ao executar o kubeadm init, ou seja, nodexx não encontrado ..

[ root @ node01 ~] # journalctl -xeu kubelet
07 de novembro 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.682095 2968 kubelet.go: 2267] node "node01" não encontrado
07 de novembro 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.782554 2968 kubelet.go: 2267] node "node01" não encontrado
07 de novembro 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.829142 2968 reflector.go: 123] k8s.io/client-go/informers/factory.go:134: Falha ao listar * v1beta1.CSID
07 de novembro 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.884058 2968 kubelet.go: 2267] node "node01" não encontrado
07 de novembro 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.984510 2968 kubelet.go: 2267] node "node01" não encontrado
07 de novembro 10:34:03 node01 kubelet [2968]: E1107 10: 34: 03.030884 2968 reflector.go: 123]

Resolvido via:

setenforce 0

sed -i --follow-symlinks 's / SELINUX = enforcing / SELINUX = disabled / g' / etc / sysconfig / selinux

o mesmo problema

No meu caso, isso foi causado por um desvio de tempo no nó mestre, _que aconteceu após um corte de energia_.
Eu consertei isso correndo

# Correcting the time as mentioned here https://askubuntu.com/a/254846/861548
sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start
# Then restarting the kubelet
sudo systemctl restart kubelet.service
# I also had to run daemon-reload as I got the following warning
# Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.
sudo systemctl daemon-reload
# I also made another restart, which I don't know whether needed or not
sudo systemctl restart kubelet.service

consertei meu mesmo problema node "xxxx" not found , tente ver o log do contêiner usando os logs do docker container_id , então vejo o apiserver tentar conectar 127.0.0.1:2379, editar o arquivo · /etc/kubernetes/manifests/etcd.yaml , reiniciar, problema resolvido。