같은 문제가 있습니다. 또한 다른 문제에서 제안한 대로 네트워크 ARGS를 제거하려고 시도했습니다. 여전히 waiting for control plane to be ready 에서 멈춥니다.

변경 후 Daemon을 다시 로드하고 kubelet 서비스를 다시 시작했습니까? 드라이버 및 주석 네트워크를 변경한 후에 작동했습니다. 처음으로 컨트롤 플레인이 준비되는 데 10~11분이 걸리므로 처음에는 15분 동안 그대로 두는 것이 좋습니다.

데몬을 다시 로드하고 매번 kubelet 서비스를 다시 시작했습니다. 나는 밤새도록 설정을 방해하지 않고 그대로 두었지만 여전히 제어 평면을 기다리고있었습니다.

데몬( systemctl daemon-reload )을 다시 로드하고 kubelet도 다시 시작했습니다. kubeadm reset 를 실행하고 서비스 구성을 편집하고 데몬을 다시 로드한 다음 kubeadm init 를 실행합니다.

Apiserver 및 etcd 도커 컨테이너는 네트워킹 옵션을 주석 처리한 후 실행되지 않습니다. 또한 cni config 디렉토리가 채워지도록 weave-net을 수동으로 설치하려고 시도했지만 둘 다 작동하지 않았습니다. 이를 위해 weave를 설치하고 weave setup 및 weave launch 를 실행했습니다. Kubeadm이 CNI 설정을 사용하도록 Docker를 구성하는 방법을 잘 모르지만 여기에 누락된 단계가 있을 수 있습니다.

kubelet이 kube api 서버에 연결할 수 없는 것 같습니다.

나는 etcd가 포트 2380에서 수신 대기할 수 없다는 것을 알아차렸고, 이 단계를 다시 수행했고 내 클러스터가 시작되었습니다.

• kubeadm reset 를 실행하여 서버에 대한 변경 사항을 제거합니다.
• 기계를 초기 상태로 되돌립니다. kubeadm을 다시 설치하여(원래 구성 파일을 되돌리기 위해).
• kubernetes와 관련된 docker 컨테이너가 있는 경우 제거합니다.
• weave를 다운로드하여 설치합니다. 실행하지 마십시오.
• 서버를 재부팅합니다.
• kubelet 가 실행되지 않는지 확인하십시오.
• weave setup 및 weave launch 를 실행합니다.
• kubeadm init 를 실행합니다.

손으로 짜는 짜임새를 없애고 싶다면...

• weave reset 실행
• kubernetes 1.6용 weave 애드온을 적용합니다.
• 서버를 재부팅합니다.

Kubeadm 조인은 다른 서버에서 작동해야 합니다.

@Yengas 직조 단계에 대해 자세히 알려주실 수 있습니까? 모든 노드에서 실행했습니까, 아니면 마스터에서만 실행했습니까?

@jruels 는 마스터 노드일 뿐입니다. Weave는 단일 바이너리입니다. 인수가 없는 setup 명령은 weave docker 이미지를 다운로드하고 CNI 구성을 생성합니다. 인수 없이 실행 명령은 호스트에서만 weave 컨테이너를 시작합니다.

@Yengas 아직도 확실하지 않습니다. "weave를 가져와 설치하세요. 실행하지 마세요." kubectl apply -f https://git.io/weave-kube-1.6 을 할 수 없습니다. 그래서 weave를 어떻게 설치합니까? ?

apiserver 로그는 무엇을 말합니까?

@rushabh268
weave를 설치하려면 마스터에서 다음을 실행하십시오.
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
그런 다음 실행
weave setup
실행이 완료되면
weave launch

그렇게 할 필요가 없습니다. kubectl apply -f https://git.io/weave-kube-1.6 이면 충분합니다.

API 서버 로그는 버그에서 언급한 것과 정확히 동일합니다. 또한 Kubernetes가 설치되어 있지 않아 kubectl을 수행할 수 없습니다.

@jruels 시도해보고 이 스레드를 업데이트하겠습니다!

버그 설명에는 kubeadm 로그와 kubelet 로그가 있습니다. apiserver 로그가 없습니다.

@mikedanese apiserver 로그는 어떻게 얻나요?
@jruels 나는 직조를 키울 수 있습니다
@Yengas 귀하의 단계를 따른 후에도 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

또한 방화벽을 중지하여 연결이 거부되는 이유를 모르겠습니다.

동일한 문제가 여기에 보고되었습니다.

내 시스템 메시지(마스터 노드)가 멈춘 상태에서 스크랩합니다. 만일의 경우에 대비하여 무언가를 가리킵니다. Btw, 나는 Linode에서 이것을 수행하고 있습니다.

4월 12일 02:10:00 로컬 호스트 감사: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 주소=? 터미널=? res=성공'
4월 12일 02:10:00 로컬 호스트 감사: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 주소=? 터미널=? res=성공'
4월 12일 02:10:00 로컬 호스트 감사: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 주소=? 터미널=? res=성공'
Apr 12 02:10:00 localhost systemd: kubelet.service: 서비스 보류 시간 초과, 예약 재시작.
4월 12일 02:10:00 localhost systemd: 중지된 kubelet: Kubernetes 노드 에이전트.
4월 12일 02:10:00 localhost systemd: kubelet 시작: Kubernetes 노드 에이전트.
4월 12일 02:10:00 localhost systemd: 시스템 활동 계정 도구 시작 중...
4월 12일 02:10:00 로컬 호스트 감사: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" 호스트 이름= ? 주소=? 터미널=? res=성공'
4월 12일 02:10:00 로컬 호스트 감사: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" 호스트 이름= ? 주소=? 터미널=? res=성공'
4월 12일 02:10:00 localhost systemd: 시스템 활동 계정 도구를 시작했습니다.
4월 12일 02:10:00 localhost kubelet: I0412 02:10:00.924529 3445 feature_gate.go:144] 기능 게이트: 맵[]
Apr 12 02:10:00 localhost kubelet: I0412 02:10:00.928973 3445 docker.go:364] unix:///var/run/docker.sock에서 도커에 연결 중
Apr 12 02:10:00 localhost kubelet: I0412 02:10:00.929201 3445 docker.go:384] 요청 시간 제한이 2m0s인 도커 클라이언트 시작
Apr 12 02:10:00 localhost kubelet: W0412 02:10:00.941088 3445 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에 네트워크가 없습니다.
Apr 12 02:10:00 localhost kubelet: I0412 02:10:00.948892 3445 manager.go:143] 컨테이너에서 실행 중인 cAdvisor: "/system.slice"
Apr 12 02:10:00 localhost kubelet: W0412 02:10:00.974540 3445 manager.go:151] Rkt api 서비스에 연결할 수 없음: rkt: tcp 다이얼 rkt api 서비스: 다이얼 tcp [::1]:15441 getsockopt: 연결이 거부되었습니다.
Apr 12 02:10:00 localhost kubelet: I0412 02:10:00.997599 3445 fs.go:117] 파일 시스템 파티션: map[/dev/root:{mountpoint:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 블록 크기:0 }]
사월 12 2시 10분 1초 로컬 호스트 kubelet : I0412 02 : 10 : 01.001662 manager.go 3445 : 198] 기계 { NumCores는 1 개 CPU 주파수 : 2,799,998 로는 메모리 yCapacity : 1037021184 MachineID : 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID는 : 5e9a9a0b58984bfb8766dba9afa8a191 BootID : 7ed1a6ff-9848- 437b-9460-981eeefdfe5a 파일 시스템:[{장치:/dev/root 용량:15447539712 유형:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ 이름:nbd0 메이저:43 마이너:0 크기:0 스케줄러:없음 } 43:11:{ 이름:nbd11 메이저:43 마이너:11 크기:0 스케줄러:없음 } 43:12:{ 이름:nbd12 메이저:43 마이너:12 크기:0 스케줄러:없음 } 43:15: { 이름:nbd15 메이저:43 마이너:15 크기:0 스케줄러:없음 } 43:7:{ 이름:nbd7 메이저:43 마이너:7 크기:0 스케줄러:없음 } 8:0:{ 이름:sda 메이저:8 마이너 :0 크기:15728640000 스케줄러:cfq } 252:0:{ 이름:dm-0 메이저:252 마이너:0 크기:107374182400 스케줄러:없음 } 43:1:{ 이름:nbd1 메이저:43 마이너:1 크기:0 스케줄러 :없음 } 43:13:{ 이름:nbd13 메이저:43 마이너:13 크기:0 스케줄러:없음 } 43:8:{ 이름:nbd8 메이저:43 마이너:8 크기:0 스케줄러:없음 } 8: 16:{ 이름:sdb 메이저:8 마이너:16 크기:536870912 스케줄러:cfq } 9:0:{ 이름:md0 메이저:9 마이너:0 크기:0 스케줄러:없음 } 43:3:{ 이름:nbd3 메이저: 43 마이너:3 크기:0 스케줄러:없음 } 43:9:{ 이름:nbd9 메이저:43 마이너:9 크기:0 스케줄러:없음 } 43:10:{ 이름:nbd10 메이저:43 마이너:10 크기:0 스케줄러 :없음 } 43:14:{ 이름:nbd14 메이저:43 마이너:14 크기:0 스케줄러:없음 } 43:2:{ 이름:nbd2 메이저:43 마이너:2 크기:0 스케줄러:없음 } 43:4:{ 이름:nbd4 메이저:43 마이너:4 크기:0 스케줄러:없음 } 43:5:{ 이름:nbd5 메이저:43 마이너:5 크기:0 스케줄러:없음 } 43:6:{ 이름:nbd6 메이저:43 마이너: 6 Size:0 Scheduler:none }] NetworkDevices:[{ Name:dummy0 M acAddress:5a :34:bf:e4:23:cc Speed:0 Mtu:1500 } { Name:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 속도:-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 속도:0 Mtu:1462 } { 이름:ip6_vti0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 속도:0 Mtu:1500 } { 이름:ip6gre0 M acAddress:00 :00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00 속도:0 Mtu:1448 } { 이름:ip6tnl0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 속도:0 Mtu:1452 } { 이름:ip_vti0 마
Apr 12 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 }] 토폴로지:[{Id:0 메모리:1037021184 코어:[{Id:0 스레드] :[0] 캐시:[{ 크기:32768 유형:데이터 수준:1 } { 크기:32768 유형:명령 수준:1 } { 크기:4194304 유형:통합 수준:2 }]}] 캐시:[]}] Clou dProvider:Unknown 인스턴스 유형:알 수 없음 I nstanceID:없음 }
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.013353 3445 manager.go:204] 버전: {Kern elVersion:4.9.15-x86_64-linode81 Container OsVersion: Fedora2 6 CadvisorVersion: CadvisorRevision:}
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos가 활성화되었지만 --cgroup-root가 지정되지 않았습니다. /로 기본 설정
Apr 12 02:10:01 localhost kubelet: W0412 02:10:01.016562 3445 container_manager_linux.go:218] 스왑 실행은 지원되지 않습니다. 스왑을 비활성화하십시오! 이것은 K8s v1.6부터 기본적으로 치명적인 오류입니다! 그 동안 --experimental-fail-swap-on을 활성화하여 치명적인 오류가 발생하도록 선택할 수 있습니다.
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.016688 3445 container_manager_linux.go:245] 컨테이너 관리자 확인 사용자 지정 cgroup-root 존재: /
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.016717 3445 container_manager_linux.go:250] 노드 구성을 기반으로 컨테이너 관리자 객체 생성: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsRuntime:: PerdogroupQKubeletCgroupsRuntime : PerdogroupQ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocateableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable :map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] Syste mReserved :map [] HardEviction :LessThan 값:{ 수량:100Mi 비율:0 } Gr acePeriod:0s MinReclaim:}]} ExperimentalQO SReserved:map []}
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.016943 3445 kubelet.go:255] 매니페스트 파일 추가 중: /etc/kubernetes/manifests
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.016966 3445 kubelet.go:265] apiserver 보기
4월 12일 02:10:01 localhost kubelet: E0412 02:10:01.025058 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: *v1.Node를 나열하지 못함: https 가져오기: //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0: 다이얼 tcp 50.116.13.214:6443: getsockopt: 연결 거부
Apr 12 02:10:01 localhost kubelet: E0412 02:10:01.025342 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: *v1.Service: Get https: //50.116.13.214 :6443/api/v1/services?resourceVersion=0: 다이얼 tcp 50.116.13.214:6443: getsockopt: 연결 거부
4월 12일 02:10:01 localhost kubelet: E0412 02:10:01.025397 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: *v1.Pod 나열 실패: 가져오기 https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0: 다이얼 tcp 50.116.13.214:6443: getsockopt: 연결 거부
Apr 12 02:10:01 localhost kubelet: W0412 02:10:01.026574 3445 kubelet_network.go:70] 머리핀 모드가 "promiscuous-bridge"로 설정되었지만 kubenet이 활성화되지 않고 "hairpin-veth"로 돌아감
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.026599 3445 kubelet.go:494] 머리핀 모드가 "hairpin-veth"로 설정됨
Apr 12 02:10:01 localhost kubelet: W0412 02:10:01.026661 3445 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에 네트워크가 없습니다.
Apr 12 02:10:01 localhost kubelet: W0412 02:10:01.034194 3445 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에 네트워크가 없습니다.
Apr 12 02:10:01 localhost kubelet: W0412 02:10:01.043157 3445 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에 네트워크가 없습니다.
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.043183 3445 docker_service.go:187] cni에서 관리하는 Docker cri 네트워킹
Apr 12 02:10:01 localhost kubelet: 오류: Kubelet 실행 실패: kubelet 생성 실패: 잘못된 구성: kubelet cgroup 드라이버: "cgroupfs"가 docker cgroup 드라이버와 다릅니다: "systemd"
4월 12일 02:10:01 로컬 호스트 감사: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 주소=? 터미널=? res=실패'
4월 12일 02:10:01 localhost systemd: kubelet.service: 주 프로세스 종료, 코드=종료, 상태=1/FAILURE
4월 12일 02:10:01 localhost systemd: kubelet.service: 장치가 실패 상태로 들어갔습니다.
Apr 12 02:10:01 localhost systemd: kubelet.service: 'exit-code' 결과로 실패했습니다.

@acloudiator kubeadm 구성에서 cgroup-driver를 설정해야 한다고 생각합니다.

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

그런 다음 kubelet 서비스를 다시 시작하십시오.

kubeadm이 cgroup 구성 문제를 어떤 식으로든 다룰 수 있다면 좋을 것입니다.
아이디어:

• 구성이 잘못된 경우 초기화 중단
• 사전에 Docker의 설정을 확인하고 Docker가 사용하는 것을 사용하십시오(여기에 어떤 의미가 있는지 확실하지 않음).

내가 시도한 해결 방법이 무엇이든 업데이트가 작동하지 않았습니다. 그래서 저는 마스터용으로 CentOS 7.3으로 옮겼고, 정말 매력처럼 작동합니다! 나는 CentOS 7.2에서 미니언을 유지했습니다.

@rushabh268 안녕하세요, Redhat Linux 7.2에서 동일한 문제가 있습니다. systemd를 업데이트하면 이 문제가 해결됩니다. 설치 전에 systemd 업데이트를 시도할 수 있습니다.
yum update -y systemd
kubelet의 오류 로그:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

CentOS 7.3에서 이 문제를 해결했습니다. docker-ce를 제거한 다음 docker-io를 설치하면 문제가 사라집니다.
그것이 근본 원인인지 확실하지 않습니다. 어쨌든 위의 방법이 작동하지 않으면 시도해 볼 수 있습니다.

@ZongqiangZhang 내 노드에 도커 1.12.6이 설치되어 있습니다. @juntaoXie 시스템 업데이트도 시도했지만 여전히 멈췄습니다.

그래서 저는 Centos 7.3 w/1.6.4를 여러 컴퓨터에서 문제 없이 실행했습니다.

selinux를 비활성화했는지 확인 했습니까?

@timothysc CentOS 7.3이 아닌 CentOS 7.2가 있고 selinux가 비활성화되어 있습니다.

CentOS Linux 릴리스 7.3.1611(Core)이 있고 KubeAdm 1.6.4가 작동하지 않습니다.

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

산출:

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 kube-apiserver 로그를 조금 더 공유할 수 있습니까? (댓글 끝에 있는 것들)

이미 포함된 행 위의 행에 동일한 IP 주소가 언급되어 있습니까? 최근에 Ubuntu 16.04와 CentOS 7.3의 두 개의 새로운 KVM에서 k8을 실행해 보았습니다. 둘 다 이것을 주었다:

​[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

처음에 언급된 IP 주소는 x.x.x.x 이지만 localhost 는 y.y.y.y 로 확인됩니다(제 경우에는 동일한 물리적 서버에 있는 다른 KVM의 공개 IP였습니다). 결국 Ubuntu에서 kubeadm을 시작할 수 있지만 https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861과 유사한 방식으로 dnsmasq를 설치한 후에만 가능합니다. CentOS에서 동일한 해결 방법이 도움이 되지 않았습니다.

이것이 kubedns 또는 기타의 버그일 수 있습니까? 흥미롭게도 AWS VM의 동일한 단계에서 kubeadm이 실행되었습니다. 그러나 EC2 인스턴스는 내 개인 프로젝트에 너무 비쌉니다.

@paulobezerr과 같은 문제가 있습니다.

## 버전 :
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
도커 클라이언트-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
도커-1.12.6-28.git1398f24.el7.centos.x86_64

그래서
우나메 -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > CentOS Linux 릴리스 7.3.1611(코어)

## 다음 단계를 따릅니다.

    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

## API 서버 로그:
--> 37.247.XX.XXX는 공개 IP입니다.

[restful] 2017/06/08 10:45:19 log.go:30: [restful/swagger] 목록은 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/가 /swagger-ui/ 폴더에 매핑됩니다.
E0608 10:45:19.429839 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.Secret: https://localhost 가져오기를 나열하지 못했습니다. 6443/api/v1/secrets?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.430419 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.ResourceQuota 나열 실패: https://localhost 가져오기: 6443/api/v1/resourcequotas?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결이 거부되었습니다.
E0608 10:45:19.430743 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.ServiceAccount를 나열하지 못했습니다: https://localhost 가져오기: 6443/api/v1/serviceaccounts?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.431076 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *storage.StorageClass를 나열하지 못했습니다: https://localhost 가져오기: 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.431377 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.LimitRange를 나열하지 못했습니다: https://localhost 가져오기: 6443/api/v1/limitranges?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.431678 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.RoleBinding을 나열하지 못했습니다: https://localhost 가져오기: 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.431967 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.ClusterRoleBinding을 나열하지 못했습니다: https://localhost 가져오기: 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.432165 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.Namespace를 나열하지 못했습니다: https://localhost 가져오기: 6443/api/v1/namespaces?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.432386 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.ClusterRole을 나열하지 못했습니다: https://localhost 가져오기: 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
E0608 10:45:19.432619 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.Role을 나열하지 못했습니다: https://localhost 가져오기: 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결 거부
I0608 10:45:19.481612 1 Serve.go:79] 0.0.0.0:6443에 안전하게 서빙
W0608 10:45:19.596770 1 storage_extensions.go:127] 타사 리소스 동기화 실패: https://localhost :6443/apis/extensions/v1beta1/thirdpartyresources 가져오기: 다이얼 tcp 108.59.253.109:6444 연결 거부: 가져오기
E0608 10:45:19.596945 1 client_ca_hook.go:58] 게시물 https://localhost :6443/api/v1/namespaces: 다이얼 tcp 108.59.253.109:6443: getsockopt: 연결이 거부되었습니다.
F0608 10:45:19.597174 1 controller.go:128] 초기 IP 할당 확인을 수행할 수 없음: 서비스 IP 블록을 새로 고칠 수 없음: Get https://localhost :6443/api/v1/services: dial tcp 108.59.253.109: 6443: getsockopt: 연결이 거부되었습니다.

@albpal 일주일 전에 정확히 같은 문제가 발생했습니다. dial tcp X.X.X.X 에 이상한 IP 주소가 표시되었고 dnsmasq를 설치하고 호스팅 제공업체의 DNS 대신 Google DNS 서버로 전환한 후에도 CentOS에서 이 문제를 해결할 수 없었습니다. 호기심을 위해: 보고 있는 잘못된 IP 주소가 VM과 동일한 데이터 센터에 있는지 확인할 수 있습니까? http://ipinfo.io 를 사용하여 어느 정도 확실하게 추정하거나 경로를 추적할 수 있습니다.

제 경우에는 잘못된 IP 주소가 동일한 물리적 서버의 다른 KVM을 참조하고 있었습니다. 물리적 시스템의 DNS와 관련이 있을 수 있으며 kube api 또는 kube dns 내부에서 해결 방법이 필요할 수 있습니다. 그렇지 않으면 클러스터를 시작하는 것이 많은 신규 사용자에게 큰 고통이 됩니다! 나는 로그에서 잘못된 IP로 dial tcp 를 알아차리기 전에 몇 저녁을 낭비했습니다. 이것은 꽤 슬픈 첫 k8 경험이었습니다. 내 호스팅 제공업체( firstvds.ru )에 CentOS KVM을 위한 좋은 기본 솔루션이 아직 없습니다.

IP 주소에서 이 매우 이상한 불일치의 원인은 무엇입니까?

@albpal 새 문제를 열어주세요. 설명하신 내용과 이 문제에 대한 내용은 별개의 문제입니다(해당 정보를 기반으로 생각합니다).

@kachkaev 방금 제안하신 내용을 확인했습니다.

잘못된 IP가 CPANEL에서 끝나는 것을 발견했습니다: vps-1054290-4055.manage.myhosting.com.

반면에 내 VPS의 공용 IP는 이탈리아에서 왔고 이 잘못된 IP는 미국에서 온 것입니다... 그래서 잘못된 IP에 호스팅(CPANEL)과 관련된 것이 있음에도 불구하고 다른 KVM을 참조하는 것 같지 않습니다. 동일한 물리적 서버.

k8을 설치할 수 있었습니까?

@luxas 나는 같은 동작을 가지고 있지만 도커 로그를 복사했습니다.출력도.

/var/log/messages 및 kubeadm init의 출력은 모두 원래 문제와 동일합니다.

@albpal 그래서 VM과 두 번째 컴퓨터가 모두 CPANEL에 있습니까? 좋은 징조입니다. 그러면 내 경우가 동일하기 때문입니다! 동일한 물리적 기계라는 사실은 우연의 일치일 수 있습니다.

실험에서 두 개의 KVM을 사용했는데 하나는 Ubuntu 16.04이고 다른 하나는 CentOS 7.3입니다. 둘 다 동일한 dial tcp IP 주소 문제가 있었습니다. 결국 내 공급자의 DNS 서버를 제거하여 Ubuntu에서 kubeadm을 시작할 수 있었습니다. 솔루션은 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

이것은 Ubuntu의 로그에서 dial tcp 다음에 올바른 IP 주소를 가져왔고 몇 분 후에 kubeadm이 초기화되었습니다! CentOS에서 같은 방식으로 dnsmasq를 설정해 보았지만 문제가 해결되지 않았습니다. 그러나 저는 이 OS의 완전한 초보자이므로 일부 서비스를 다시 시작하거나 일부 캐시를 정리하는 것을 잊었을 수 있습니다. 이 아이디어를 시도해보세요!

어쨌든 DNS를 다시 구성하는 추가 단계를 수행하는 것은 매우 혼란스럽기 때문에 잘못된 것 같습니다. kubeadm이 공급자의 DNS 서버가 이상한 방식으로 작동하는지 감지하고 클러스터에서 필요한 모든 것을 자동으로 수정할 수 있기를 바랍니다.

k8s 팀의 누군가가 무슨 일이 일어나는지 보고 싶어한다면 몇 가지 새로운 FirstVDS KVM에 대한 루트 액세스를 공유하게 되어 기쁩니다. 이메일이나 트위터 DM만 주세요!

@kachkaev 감사합니다! 나는 내일 그것을 시도 할 것이다

cc @kubernetes/sig-network-bugs 위에서 DNS 확인이 실패한 이유를 알고 있습니까?

@kachkaev 감사합니다. 조사해보겠습니다. 나는 그것이 실제로 kubeadm 자체의 잘못이라고 생각하지 않지만 많은 사용자가 동일한 잘못된 구성에 갇혀 있으면 문제 해결 문서 등에 추가할 수 있습니다.

내 로그는 @albpal 로그일 가능성이 매우 높습니다.
그러나 나는 dnsmasq를 시도할 것이다. 다들 감사 해요!

@kachkaev , 작동하지 않습니다. 같은 문제 😢
전체 로그가 첨부되어 있습니다.

로그.txt

고칠 수 있었어요!! 힌트를 주신 @kachkaev 에게 감사드립니다!

제 생각에 문제는 다음과 같습니다.

### 시나리오:
다음 구성 스키마가 있는 VPS:

resolv.conf
[ root@apalau ~]# 고양이 resolv.conf
네임서버 8.8.8.8
네임서버 8.8.4.4
네임서버 2001:4860:4860::8888
네임서버 2001:4860:4860::8844

검색 도메인이 없습니다!

호스트
[ root@apalau ~]# 고양이 /etc/hosts
127.0.0.1 localhost.local도메인 localhost
37.XXX.XX.XXX 이름.vpshosting.com

로그에 따라 kubernetes 컨테이너는 다음에 연결을 시도합니다.

https://localhost :6443/api/v1/secrets?resourceVersion=0 가져오기

그리고 내가 요청할 때 :
$ nslookup "localhost.$(호스트 이름 -d)"
내가 얻은 IP는 잘못된 것, 즉 108.59.253.109입니다.

따라서 이러한 컨테이너가 localhost(도메인 없음)를 확인하려고 하고 잘못된 IP를 받고 있다고 생각합니다. 아마도 "localhost.$(hostname -d)"가 거의 모든 VPS 서비스에서 발생할 것이라고 생각하는 해당 IP로 해석되기 때문일 것입니다.

## VPS CentOS 7.3에서 문제를 해결하기 위해 수행한 작업(해당 단계는 https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm에 표시됨):

루트로:

1. kubeadm 재설정
2. yum 설치 dnsmasq
3. cp /etc/resolv.conf ~/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "이름 서버 127.0.0.1\n이름 서버 $(호스트 이름 -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr +i /etc/resolv.conf
8. echo -e "서버=8.8.8.8\n서버=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(호스트 이름 -i)\tlocalhost.$(호스트 이름 -d)" >> /etc/hosts
10. 서비스 dnsmasq 다시 시작
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl 방화벽 다시 시작
12. kubeadm 초기화

5단계에서 hostname -i를 추가했습니다. 그렇지 않으면 docker가 컨테이너의 resolv.conf에 8.8.8.8을 추가하기 때문입니다.

나는 그것이 다른 사람들에게도 도움이되기를 바랍니다.

감사 해요!!

@albpal이라는 소식을 듣게 되어 기쁩니다! kubeadm init 전에 귀하의 단계를 거쳤고 클러스터가 CentOS 7.3이 포함된 테스트 FirstVDS KVM 내에서 마침내 초기화되었습니다! 내가 해야 할 유일한 추가 작업은 포트 6443에 대한 외부 연결을 차단하는 방화벽을 중지하고 비활성화하는 것이었습니다.

systemctl disable firewalld
systemctl stop firewalld

_결과를 알지 못하기 때문에 이 작업을 수행하지 않는 것이 좋습니다. 이것은 내가 일반적으로 사용하지 않는 OS에서 테스트를 완료하는 데 도움이 되었습니다._

이제 저와 같은 초보자를 위한 설치 프로세스를 쉽게 하기 위해 무엇을 할 수 있는지 궁금합니다. Created API client, waiting for the control plane to become ready 에서 멈춘 것과 정리하는 것 사이의 경로는 여전히 거대합니다. 특히 이 문제를 파헤치고 모든 주석을 읽는 데 필요한 시간을 고려하면 더욱 그렇습니다. __무엇을 제안할 수 있습니까?__

첨부 파일에서 본 @paulobezerr 귀하의 문제가 약간 다르다고 생각합니다. 내 apiserver 로그에는 다음과 같은 내용이 포함되어 있습니다.

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

당신이 말하는 동안 :

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

(첫 번째 경우에는 localhost / RANDOM_IP 이고 두 번째 경우에는 항상 10.X.X.X 입니다)

불행히도 kubeadm init 때 다양한 --apiserver-advertise-address=??? 를 시도하는 것 외에는 조언해야 할 것이 없습니다( 문서 참조). 저의 k8s 실습 경험은 막 10일에 이르렀습니다. 그 중 대부분은 FirstVDS에서 단일 노드 클러스터를 시작하려는 헛된 시도였습니다 :-)

이 문제를 해결하고 다른 사람들과 솔루션을 공유하기를 바랍니다!

@kachkaev 다음 방화벽 규칙을 적용했다고 언급하는 것을 잊었습니다.

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl 방화벽 다시 시작

방화벽을 비활성화하지 않고 이 규칙을 적용하면 내 환경에서 제대로 작동합니다. 필요한 모든 단계를 수집하기 위해 이전 댓글에 추가하겠습니다.

@juntaoXie 감사합니다. 귀하의 의견 에 따라 systemd 버전을 업데이트하면 저에게 효과적이었습니다.

이틀 동안 여전히 이 문제가 발생하고 있으며 이 모든 것을 프록시 뒤에서 실행하고 있으며 문제가 없는 것 같습니다.
kubeadm init는 제어 평면이 준비될 때까지 대기합니다. docker ps를 수행하면 컨테이너가 당겨지고 실행되지만 할당된 포트가 뒤에 있지 않습니다. etcd도 잘 실행됩니다. 그러나 내 kubelet 서비스를 보면 Unable to update cni config: No network found in /etc/cni/net.d(https://github.com/kubernetes/kubernetes/issues/43815 )가 괜찮다고 말합니다. cni 네트워크를 적용해야 합니다.
https://www.weave.works/docs/net/latest/kubernetes/kube-addon/에 따라 수행합니다. 이제 kubectl은 8080이 거부되었다고 말합니다. 올바른 호스트 또는 포트를 지정했습니까? 닭고기와 계란 문제처럼 보입니다. 내 kubeadm 초기화가 중단될 때 cni 네트워크를 어떻게 적용합니까??? 너무 혼란스럽다

이것은 또한 cgroup 문제가 아니며 docker와 내 kubelet 서비스 모두 systemd를 사용합니다.

FWIW, GCP에서 이와 동일한 문제가 발생했습니다. 깨끗한 프로젝트에서 다음 명령을 사용하여 Ubuntu 16.04 및 CentOS를 사용해 보았습니다.

$ gcloud compute instance create test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' API 테스트를 위한 노드 1'

$ gcloud compute instance create test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' API 테스트를 위한 노드 2'

$ gcloud compute instance create test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' API 테스트를 위한 노드 3'

$ apt-get 업데이트

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

$ apt-get 업데이트 && apt-get install -qy docker.io && apt-get install -y apt-transport-https

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

$ apt-get 업데이트 && apt-get 설치 -y kubelet kubeadm kubernetes-cni

$ systemctl kubelet 재시작

$ kubeadm 초기화

그래서 몇 시간 동안 머리를 맞대고 나서 다음과 같이 결론을 내렸습니다.

$ gcloud beta container --project "weather-177507" 클러스터 생성 "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. 추가 " --num-nodes "3" --network "default" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

빈 이미지에서 할 수 없는 곳에서 클러스터를 가동하고 실행할 수 있었습니다.

Kubeadm 버전에서도 동일한 문제에 직면하고 있습니다.

에 갇히다
[apiclient] Created API client, waiting for the control plane to become ready

@paulobezerr 와 동일한 문제 - 내 환경: CentOS 7.4.1708 kubeadm 버전: &version.Info{주요:"1", 부:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a30",fec63e6a7a30" ", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", 컴파일러:"gc", 플랫폼:"linux/amd64"}

나에게 이 문제는 SELinux가 비활성화된 상태에서 실행되지 않았습니다. 단서는 그의 걸음걸이였다.

/etc/selinux/config를 편집하고 SELINUX=disabled로 설정하십시오.

CentOS용 설치 단계(https://kubernetes.io/docs/setup/independent/install-kubeadm/)는 다음과 같습니다.
"컨테이너가 호스트 파일 시스템에 액세스할 수 있도록 하려면 setenforce 0을 실행하여 SELinux를 비활성화해야 합니다."
그러나 (적어도 CentOS/RHEL/Fedora 탭에서는) /etc/selinux/config를 편집하고 SELINUX=disabled를 설정해야 한다고 언급하지 않습니다.

저에게는 setenforce 0을 실행했지만 여전히 동일한 오류가 발생했습니다. /etc/selinux/config를 편집하고 SELINUX=disabled로 설정한 다음 재부팅하면 문제가 해결되었습니다.

(잠재적으로 직교할 수 있는) 많은 문제가 여기에 있는 것 같으므로 상황이 분산되지 않도록 하고 싶습니다. 지금까지 우리는 3가지 문제를 정확히 지적한 것 같습니다.

1. DNS가 일부 컴퓨터에서 localhost를 올바르게 확인하지 못합니다. @kachkaev @paulobezerr 해결하셨나요? 우리의 요구 사항에서 이것을 더 명확하게 만드는 방법이 궁금합니다. 어떤 아이디어가 있습니까?

2. kubelet과 Docker 간의 잘못된 cgroup-driver 일치입니다. 이것을 요구 사항 목록에 추가해야 합니다.

3. SELinux는 비활성화되어 있지 않습니다. 이것을 요구 사항 목록에 추가해야 합니다.

3가지 모두가 PR로 해결되면 아마도 이것을 닫아야 하고 미래에 문제가 발생하는 사람들이 스스로 문제를 만들도록 해야 합니다. 이를 통해 하나의 스레드에서 많은 것을 저글링하는 것과는 대조적으로 보다 구조화된 정보를 수신하고 보다 세분화된 지원을 제공할 수 있습니다. @luxas는 어떻게 생각하세요?

나를 위해 나는 docker 17.06(17.03이 권장되지만 docker.io에서는 사용할 수 없음)을 사용하여 동일한 문제에서 실행했습니다. 17.09로 업그레이드하면 문제가 마술처럼 해결되었습니다.

이 스레드가 너무 길어지고 완전히 다른 문제가 많이 있을 수 있으므로 @jamiehannaford 의 훌륭한 의견 외에 추가할 수 있는 가장 생산적인 것은 모든 관련 로그/정보가 포함된 새로운 대상 문제를 여는 것입니다. 이전 버전보다 훨씬 더 나은 결함 상태를 자동으로 감지하는 _최신 kubeadm v1.8_에서 실패합니다. 우리는 또한 사람들의 시간을 절약할 수 있는 요구 사항 및 엣지 케이스에 대한 문서를 개선했습니다.

모두 감사합니다!

1.8이 설치된 CENTOS 7에서 1.8과 동일한 문제가 발생했습니까? 누구든지 같은 문제가 있거나 해결 방법을 알고 있습니다.

@rushins 보고 있는 가능한 문제에 대한 도움을 받으려면 여기에서 충분한 세부 정보가 포함된 새 문제를 여십시오.

connection refused localhost:6443/api 가 아닌 @rushabh268 과 같은 문제가 있습니다.
마지막으로 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
--------------------------

환경:
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> 도커 v17.12.0.ce
-> 개인 네트워크 xxx.xx.xxxx.org에서

신의 사랑을 위해 이것을 문서에 추가하십시오. 나는 nslookup localhost를 실행할 때 올바른 IP를 얻지 못하는 마스터 노드에 의해 완료되었습니다.

솔루션에 대해 @kachkaev 에게 감사드립니다.