첫 번째 오류 메시지: 클라이언트 CA 파일을 로드할 수 없습니다. /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: 해당 파일 또는 디렉터리가 없습니다.

첫 번째 오류 메시지: 클라이언트 CA 파일을 로드할 수 없습니다. /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: 해당 파일 또는 디렉터리가 없습니다.

안녕하세요, 여기에 몇 가지 질문이 있습니다:
1) kubeadm init가 완료되고 부스트랩 토큰을 인쇄합니까?
2) 컨테이너 런타임 버전?
3) kubelet 및 kubeadm 버전 1.12입니까?

/우선순위 요구-더 많은 증거

kubeadm init 전에 systemctl start kubelet을 실행해야 합니다.

컵의 코어가 2보다 작기 때문에 동일한 문제가 발생합니다.

같은 문제

@javacppc 어떻게 해결하셨나요? systemctl start kubelet을 실행하면 error code

kubernetes 1.12.2와 동일한 문제입니다.
@Javacppc 어떻게 해결하셨나요?

같은 문제

같은 문제

안녕하세요 여러분,

여기서 동일한 문제에 직면하고 있습니다. 클러스터를 시작할 때 토큰에서 메시지를 받았지만 클라우드 위브를 설치할 수 없습니다.
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?

로그로 이동하면 노드 이름에 대한 메시지가 나타납니다.

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

아무도 나에게 약간의 빛을 보낼 수 있습니까?

감사합니다!

내 문제가 해결되었으며 실제로 버그가 아닙니다. apiserver가 어떤 이유로 시작하지 못했기 때문입니다.

"apiserver가 어떤 이유로 시작하지 못했습니다"? 자세히 알려주실 수 있나요??

나는 며칠 전에 내 문제를 해결했습니다. 1.11.4 -> 1.12.3에서 업데이트하십시오. 나는 가지고있다 :

1. api-server - 자체 네트워크가 있는 특정 가상 인터페이스에서 실행됩니다. ( 베어 메탈 ).
   kubeadm init/join 플래그 apiserver-advertise-address 에는 특정 인터페이스에서 시작되었지만 설정/상태 확인이 있는 패키지는 라우팅 테이블의 표준 경로(기본 인터페이스)를 통과합니다. /etc/kubernetes/manifests/kube-apiserver.yaml bind-address 매개변수를 가상 인터페이스의 IP에 바인딩하는 데 도움이 되었습니다.
2. flannel - controller , scheduler 포드를 생성한 후 네트워크와 동일한 상황입니다. api 서버 10.96.0.1:443 clusterIP 에 대한 connection refused 로 인해 DNS 배포에 실패했습니다. (기본 라우팅 테이블) 내가 지정된 node-ip 플래그에 의해 클러스터 노드의 --node-ip 에서 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 가상 인터페이스의 IP와.

이 후 버전 1.12.3의 준비된 노드가 있습니다. 가장 유용한 정보는 docker logs + kubectl logs

v1.13.0과 동일한 문제

Kubernetes v1.13.0과 동일한 문제
센트OS 7
docker-ce 18.06(최신 검증 버전)
dockerd: 활성, 실행 중
kubelet: 활성, 실행 중
selinux: 비활성화
방화벽: 비활성화

오류:
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/etc/hosts에는 노드가 포함되어 있고 ping이 가능하고 연결할 수 있습니다. 실제로 단일 마스터 단일 작업자(예: 오염된 노드)를 수행합니다.

K8S는 이 값을 어디에서 찾는가? /etc/hosts?
필요한 경우 문제를 해결하고 추가 증거를 제공할 수 있습니다.

--> kubeadm init가 완료되고 부스트랩 토큰을 인쇄합니까?
긴 오류로 끝납니다.

[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

참고: 제한 시간 이후에 제안된 명령 중 아무 것도 여기에서 언급할 가치가 있는 내용을 보고하지 않았습니다.

kubelet 및 kubeadm 버전?
---> 1.13.0
kubeadm 버전: &version.Info{주:"1", 부:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"201a6d", 01Z", GoVersion:"go1.11.2", 컴파일러:"gc", 플랫폼:"linux/amd64"}

또한 kube 로그에서 좀 더 명확하고 상세하게 "노드를 찾을 수 없음"보다 더 나은 오류 메시지를 설정하면 안 되나요?

감사 해요

같은 문제...

$ 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.

같은 문제:

우분투 18.04.1 LTS
Kubernetes v1.13.1(cri-o 1.11 사용)

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 내 문제를 알아 냈습니다. snap 를 사용하여 Docker를 설치했습니다. 제거하고 apt 사용하여 다시 설치하면 kubeadm이 제대로 작동했습니다.

@cjbottaro 나는 cri-o 외에는 Docker를 전혀 사용하지 않습니다.

v1.13.1과 동일한 문제

systemd 및 cri-o를 사용하는 경우 /var/lib/kubelet/config.yaml 에서 cgroup 드라이버로 설정해야 합니다(또는 아래 스니펫을 kubeadm init --config=config.yaml 일부로 전달).

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

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/…

나는 오늘 같은 문제를 만났다.

rm -rf /var/lib/kubelet/을 제거 하고 다시 설치하여 수정했습니다.

@JishanXing 감사합니다! 이것은 또한 Raspbian Sketch lite에서 실행하는 문제를 해결했습니다.

/etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf를 제거하여 수정했습니다.

kubeadm reset 명령을 사용하는 것이 좋습니다.

@fhemberger 그것을 해결하는 방법, 같은 질문, 감사합니다

k8을 1.13.3에서 1.13.4로 업그레이드할 때도 같은 문제가 발생했습니다...
/etc/kubernetes/manifests/kube-scheduler.yaml 편집한 후 해결합니다. 이미지 버전 수정
image: k8s.gcr.io/kube-scheduler:v1.13.3 ==> image: k8s.gcr.io/kube-scheduler:v1.13.4
kube-controller-manager.yaml 및 kube-apiserver.yaml과 동일합니다.

최신 방법은 --image-repository registry.aliyuncs.com/google_containers 옵션을 추가하는 것입니다. 내 k8s 버전은 1.14.0,docker 버전: 18.09.2,
` kubeadm 초기화 --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.14.0 --pod-network-cidr=192.168.0.0/16
[초기화] Kubernetes 버전 사용: v1.14.0
[실행 전] 실행 전 검사 실행
[경고 IsDockerSystemdCheck]: "cgroupfs"를 Docker cgroup 드라이버로 감지했습니다. 권장 드라이버는 "systemd"입니다. https://kubernetes.io/docs/setup/cri/ 의 가이드를 따르십시오.
[프리플라이트] Kubernetes 클러스터 설정에 필요한 이미지 가져오기
[프리플라이트] 인터넷 연결 속도에 따라 1~2분 정도 소요될 수 있습니다.
[프리플라이트] 'kubeadm config images pull'을 사용하여 미리 이 작업을 수행할 수도 있습니다.
[kubelet-start] "/var/lib/kubelet/kubeadm-flags.env" 파일에 플래그가 있는 kubelet 환경 파일 쓰기
[kubelet-start] "/var/lib/kubelet/config.yaml" 파일에 kubelet 구성 쓰기
[kubelet-start] kubelet 서비스 활성화
[certs] certificateDir 폴더 "/etc/kubernetes/pki" 사용
[certs] "front-proxy-ca" 인증서 및 키 생성
[certs] "front-proxy-client" 인증서 및 키 생성
[certs] "ca" 인증서 및 키 생성
[certs] "apiserver" 인증서 및 키 생성
[인증서] apiserver 서빙 인증서는 DNS 이름 [jin-virtual-machine kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] 및 IP [10.96.0.1 192.168.232.130]에 대해 서명되었습니다.
[certs] "apiserver-kubelet-client" 인증서 및 키 생성
[certs] "etcd/ca" 인증서 및 키 생성
[certs] "etcd/server" 인증서 및 키 생성
[인증서] etcd/server 서빙 인증서는 DNS 이름 [jin-virtual-machine localhost] 및 IP [192.168.232.130 127.0.0.1 ::1]에 대해 서명되었습니다.
[certs] "etcd/peer" 인증서 및 키 생성
[인증서] etcd/피어 서비스 인증서는 DNS 이름 [jin-virtual-machine localhost] 및 IP [192.168.232.130 127.0.0.1 ::1]에 대해 서명되었습니다.
[certs] "apiserver-etcd-client" 인증서 및 키 생성
[certs] "etcd/healthcheck-client" 인증서 및 키 생성
[certs] "sa" 키 및 공개 키 생성
[kubeconfig] kubeconfig 폴더 "/etc/kubernetes" 사용
[kubeconfig] "admin.conf" kubeconfig 파일 작성
[kubeconfig] "kubelet.conf" kubeconfig 파일 작성
[kubeconfig] "controller-manager.conf" kubeconfig 파일 작성
[kubeconfig] "scheduler.conf" kubeconfig 파일 작성
[제어 평면] 매니페스트 폴더 "/etc/kubernetes/manifests" 사용
[제어 평면] "kube-apiserver"에 대한 정적 포드 매니페스트 생성
[제어 평면] "kube-controller-manager"에 대한 정적 Pod 매니페스트 만들기
[제어 평면] "kube-scheduler"에 대한 정적 포드 매니페스트 만들기
[etcd] "/etc/kubernetes/manifests"에서 로컬 etcd에 대한 정적 Pod 매니페스트 만들기
[wait-control-plane] kubelet이 "/etc/kubernetes/manifests" 디렉토리에서 정적 파드로 컨트롤 플레인을 부팅하기를 기다립니다. 최대 4m0초가 소요될 수 있습니다.
[apiclient] 모든 제어 평면 구성 요소는 17.004356초 후에 정상입니다.
[upload-config] ConfigMap "kubeadm-config"에서 사용된 구성을 "kube-system" 네임스페이스에 저장
[kubelet] 클러스터의 kubelet에 대한 구성을 사용하여 네임스페이스 kube-system에 ConfigMap "kubelet-config-1.14" 생성
[upload-certs] 건너뛰는 단계입니다. --experimental-upload-certs를 참조하십시오.
[mark-control-plane] "node-role.kubernetes.io/master=''" 레이블을 추가하여 노드 jin-virtual-machine을 제어 평면으로 표시
[mark-control-plane] taints를 추가하여 노드 jin-virtual-machine을 제어 평면으로 표시 [node-role.kubernetes.io/ master:NoSchedule ]
[bootstrap-token] 토큰 사용: xucir0.o4kzo3qqjyjnzphl
[bootstrap-token] 부트스트랩 토큰, 클러스터 정보 ConfigMap, RBAC 역할 구성
[bootstrap-token] 노드가 장기 인증서 자격 증명을 얻기 위해 노드 부트스트랩 토큰이 CSR을 게시할 수 있도록 RBAC 규칙을 구성했습니다.
[bootstrap-token] csrapprover 컨트롤러가 노드 부트스트랩 토큰에서 CSR을 자동으로 승인하도록 RBAC 규칙을 구성했습니다.
[bootstrap-token] 클러스터의 모든 노드 클라이언트 인증서에 대한 인증서 교체를 허용하도록 구성된 RBAC 규칙
[bootstrap-token] "kube-public" 네임스페이스에 "cluster-info" ConfigMap 생성
[애드온] 적용 필수 애드온: CoreDNS
[애드온] 적용 필수 애드온: kube-proxy

Kubernetes 제어 영역이 성공적으로 초기화되었습니다!

클러스터 사용을 시작하려면 일반 사용자로 다음을 실행해야 합니다.

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

이제 클러스터에 포드 네트워크를 배포해야 합니다.
다음에 나열된 옵션 중 하나를 사용하여 "kubectl apply -f [podnetwork].yaml"을 실행합니다.
https://kubernetes.io/docs/concepts/cluster-administration/addons/

그런 다음 각 작업자 노드에서 루트로 다음을 실행하여 원하는 수의 작업자 노드에 조인할 수 있습니다.

kubeadm 조인 192.168.232.130:6443 --token xucir0.o4kzo3qqjyjnzphl
--discovery-token-ca-cert-hash sha256:022048b22926a2cb2f8295ce2e3f1f6fa7ffe1098bc116f7d304a26bcb78656
`

GCP Ubuntu 18.04 VM에서 kubernetes v1.14.1 및 cri-o v1.14.0과 동일한 문제가 발생했습니다. 도커를 사용할 때 문제가 해결되었습니다. 참조: https://github.com/cri-o/cri-o/issues/2357

내 문제는 다른 cgroup 드라이버에 있었습니다. CRIO는 기본적으로 systemd를 사용하고 kubelet은 기본적으로 cgroupfs를 사용합니다.

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

이 경우 https://kubernetes.io/docs/setup/independent/install-kubeadm/#configure -cgroup-driver-used-by-kubelet-on-master-node를 참조하십시오.

파일만 쓰세요

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

그런 다음 kubeadm init를 실행하십시오. 또는 cgroup_manager를 cgroupfs

docker와 달리 cri-o 및 containerd는 cgroup 드라이버 감지 측면에서 관리하기가 약간 더 까다롭지만 kubeadm에서 이를 지원할 계획이 있습니다.

도커는 이미 처리되었습니다.

따라서 분명히 해결책은 없지만 클러스터 $(yes | kubeadm reset)를 재설정하는 것 외에는 제 생각에는 해결책이 아닙니다!

이미지 리포지토리를 변경하면 저에게 효과적이지만 이것은 좋은 해결책이 아닙니다.
--image-repository registry.aliyuncs.com/google_containers

내 경우는 이것으로 작동했습니다.

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

나는 같은 문제가 있습니다. 나는 kubeadm init --config=init-config.yaml 하고 실패했고, 이 파일은 kubeadm에 의해 생성되었습니다. advertiseAddress 기본값은 file 에 1.2.3.4 필드가 있으며, 이로 인해 etcd 컨테이너 시작이 실패합니다. 127.0.0.1로 변경하면 etcd contianer가 성공적으로 시작되고 kubeadm init success

이 문제를 해결하려면 docker ps -a list all container check를 사용하여 일부가 종료되면 docker logs CONTIANER_ID 사용하여 무슨 일이 일어났는지 확인하십시오. 도움이 되기를 바랍니다

여러분, 해결 방법 있으신 분 계신가요? 여기서도 같은 문제지만 k3s를 사용합니다.

@MateusMac k3에 대한 버그 보고서도 열어야 합니다.

kubeadm 를 얻기 위해 일주일 동안 일했습니다.
우분투 18.04
도커 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

kubelet 로그는 1루를 지나갈 노드를 찾을 수 없다는 것을 보여줍니다.

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

이러한 베어 메탈 시스템에 여러 NIC가 있다는 점에 유의해야 합니다.

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

그게 문제인지 모르겠지만 /etc/hosts 파일을 다음과 같이 설정했습니다.

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>:~$ 

따라서 NIC 10.1.1.4를 k8s의 "네트워크"로 보는 것이 설정(제 생각에는)입니다.

node-name에 대한 nslookup이 제대로 작동하는 것 같습니다.

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>:~$ 

kubeadm 설치 문서를 여러 번 살펴보았습니다.

기이 한. 네트워크를 찾지 못할 뿐입니다.

당황.

1.15.3 버전의 경우 다음을 추가하여 Ubuntu 18.04에서 이 문제를 해결할 수 있었습니다.

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

내 kubeadm 구성으로 이동한 다음 kubeadm init

Ubuntu 18.04에서 버전 1.15.3과 동일한 문제가 있습니다.
@kris-nova 이 구성 파일의 위치를 ​​지정해 주시면 정말 감사하겠습니다 :-)

업데이트: 이유는 알 수 없지만 지금은 구성을 변경하지 않고도 작동합니다!
(참고: 관련이 있는지는 모르겠지만 kubeadm init 를 다시 시도하기 전에 v.19.03.1에서 v.19.03.2로 docker를 업데이트했습니다.)

kubeadm init 즉 nodexx를 찾을 수 없음을 실행하는 동안 아래 오류가 발생했습니다.

[ root@node01 ~]# journalctl -xeu kubelet
Nov 07 10:34:02 node01 kubelet[2968]: E1107 10:34:02.682095 2968 kubelet.go:2267] 노드 "node01"을 찾을 수 없음
Nov 07 10:34:02 node01 kubelet[2968]: E1107 10:34:02.782554 2968 kubelet.go:2267] 노드 "node01"을 찾을 수 없음
Nov 07 10:34:02 node01 kubelet[2968]: E1107 10:34:02.829142 2968 reflector.go:123] k8s.io/client-go/informers/factory.go:134: *v1beta1.CSID를 나열하지 못했습니다.
Nov 07 10:34:02 node01 kubelet[2968]: E1107 10:34:02.884058 2968 kubelet.go:2267] 노드 "node01"을 찾을 수 없음
Nov 07 10:34:02 node01 kubelet[2968]: E1107 10:34:02.984510 2968 kubelet.go:2267] 노드 "node01"을 찾을 수 없음
Nov 07 10:34:03 node01 kubelet[2968]: E1107 10:34:03.030884 2968 reflector.go:123]

해결 방법:

세텐포스 0

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

같은 문제

제 경우에는 마스터 노드의 시간 드리프트로 인해 _전원이 차단된 후 발생했습니다.
나는 그것을 실행하여 고쳤다.

# 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

동일한 문제를 node "xxxx" not found 했습니다. 컨테이너 로그가 docker logs container_id 를 사용하는지 확인한 다음 apiserver가 127.0.0.1:2379 연결을 시도하고 파일 편집 · /etc/kubernetes/manifests/etcd.yaml , 다시 시작, 문제 해결 。