/ 참조 @lukemarsden @luxas @mikedanese

#43474를 완전히 되돌리면 다시 0.2.0 CNI 플러그인을 중단하는 상황이 됩니다(https://github.com/kubernetes/kubernetes/issues/43014 참조).

https://github.com/kubernetes/kubernetes/pull/43284 와 같은 작업을 고려해야

또한 /cc @thockin

/ cc @ kubernetes / 서명 네트워크 버그

참조: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda --loglevel=5로 일부 kubelet 로그를 얻을 수 있습니까?

@yujuhong -- 의도한 대로 작동하고 있다고

현재 진행 중인 Slack 토론 -- https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

노드가 준비되지 않은 경우에도 DaemonSets가 계속 예약되는 것 같습니다. 이것은 정말로, 이 경우 kubeadm 가 너무 편집증적입니다.

우리가 테스트할 현재 계획은 kubeadm 가 더 이상 마스터 노드가 준비될 때까지 기다리지 않고 대신 등록되도록 하는 것입니다. 이것은 CNI DaemonSet이 CNI를 설정하도록 예약하기에 충분해야 합니다.

@kensimon 이 이것을 테스트하고 있습니다.

@jbeda 예, DaemonSet 컨트롤러는 주로 네트워크 상태를 완전히 모르기 때문에 계속 대기열에 넣을 것 같습니다. 우리는 이것을 더 일반적으로 수정해야 합니다. kube에서 즉시 할 수 있는 일이 있습니까? 아니면 지금은 모두 kubeadm에 있습니까?

Ubuntu 16.04에 kubeadm을 사용하여 kubernetes를 설치하려고 합니다. 이에 대한 빠른 수정이 있습니까?

@jbeda 패치된 버전이 있다면 기꺼이 테스트해 보세요..

kubeadm이 노드의 NotReady 상태를 넘어서고 있지만 node.alpha.kubernetes.io/notReady 오염으로 인해 실행되지 않는 더미 배포가 작동하지 않습니다. 허용 오차를 추가하는 것이 도움이 되지 않는 것 같습니다. 이 시점에서 어떻게 진행해야 할지 잘 모르겠습니다. notReady 오염을 허용하는 포드를 배포하는 방법에 대해 설명할 수 있는 사람이 있습니까?

노드를 notReady로 표시하지 않는 것과 같은 다른 옵션을 살펴보고 있지만 이것이 우리가 원하는 것이 확실하지 않습니다.

우리는 kubelet 명령줄에서 KUBELET_NETWORK_ARGS를 제거하여 이 문제를 해결했습니다. 그 후 kubeadm init가 잘 작동했고 canal cni 플러그인을 설치할 수 있었습니다.

@sbezverk 그 방법을 설명해 주시겠습니까?

@sbezverk (good find :)) 결과를 확인하고 /etc/systemd/system/10-kubeadm.conf를 조정하고 KUBELET_NETWORK_ARGS를 제거하면 centos에서 실행됩니다. 직조로 테스트했습니다.

@overip /etc/systemd/system/kubelet.service.d/10-kubeadm.conf를 편집해야 합니다.

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA_ARGS

$ KUBELET_NETWORK_ARGS 제거

그런 다음 bebeadm init가 작동해야 kubelet을 다시 시작합니다.

이것이 내가 한 일이다

kubeadm 재설정

다음에서 ENV 항목 제거:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemd 및 kube 서비스 다시 로드

systemctl 데몬 다시 로드
systemctl kubelet.service 재시작

초기화 다시 실행

kubeadm 초기화

모두 맞습니다. 그리고 우리가 그것에 있는 동안

다음과 같이 표시됩니다.
kubelet: 오류: Kubelet 실행 실패: kubelet 생성 실패: 잘못된 구성: kubelet cgroup 드라이버: "cgroupfs"가 docker cgroup 드라이버와 다릅니다: "systemd"

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf를 편집하고 --cgroup-driver="systemd" 플래그를 추가해야 합니다.

그리고 위와 같이

kuebadm 재설정
systemctl 데몬 다시 로드
systemctl kubelet.service 재시작
kubeadm 초기화.

kubelet CLI 플래그에서 --network-plugin=cni 를 조심스럽게 제거하면 kubelet이 기본적으로 no_op 플러그인을 사용하게 됩니다... calico/weave와 같은 일반적인 플러그인이 이 경우에도 작동한다면 놀랄 것입니다(하지만 그런 다음 이 플러그인이 아래에서 어떻게 작동하는지에 대한 나의 이해가 약간 제한적입니다.)

@kensimon 흠, 내 설정에 문제가 없었습니다. canal cni 플러그인을 배포했는데 잘 작동했습니다.

@sbezverk 호스트 간 네트워킹도 잘 작동합니까?

@resouer 는 확인할 수 없으며

@resouer @sbezverk 머신에 성공적으로 합류했습니다.

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

``` [ root@deploy-01 x86_64]# kubectl 포드 가져오기 -n kube-system
이름 준비 상태 다시 시작 연령
etcd-deploy-01 1/1 실행 0 50m
kube-apiserver-deploy-01 1/1 실행 0 51m
kube-controller-manager-deploy-01 1/1 실행 0 50m
kube-dns-3913472980-6plgh 3/3 실행 0 51m
kube-proxy-mbvdh 1/1 실행 0 4m
kube-proxy-rmp36 1/1 실행 0 51m
kube-scheduler-deploy-01 1/1 실행 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 실행 0 24m
weave-net-3t487 2/2 러닝 0 44m
weave-net-hhcqp 2/2 실행 0 4m

```

해결 방법이 작동하지만 플란넬이 작동하지 않습니다...

@stevenbower 최악의 시나리오에서는 이 설정을 되돌리고 kubeadm 비즈니스가 끝나면 kubelet을 다시 시작할 수 있습니다..

weave 작동하는 3노드 클러스터가 있습니다. 이 해킹으로 이것이 얼마나 안정적인지 확실하지 않지만 어쨌든 감사합니다! : 스마일 :

마스터의 초기화가 통과한 후 사이드 노드에서 $KUBELET_NETWORK_ARGS를 다시 넣을 수 있습니다. 실제로 내가 가입한 컴퓨터에서 제거하지 않고 cgroup-driver만 제거했습니다. 그렇지 않으면 kubelet과 docker가 함께 작동하지 않습니다.

그러나 kubeadm을 재설정할 필요는 없습니다. /etc/systemd/system/kubelet.service.d/10-kubeadm.conf를 변경하고 systemctl 댄스를 수행하면 됩니다.

systemctl 데몬 다시 로드
systemctl kubelet.service 재시작

KUBELET_NETWORK_ARGS를 삭제하고 보고하는 사용자에게:

제 경우에는 2개의 클러스터가 있습니다. 하나는 https://github.com/kubernetes/kubernetes/pull/43824 에서 패치를 적용하고 kubeadm이 초기화 시 정상적으로 진행하도록 하고 다른 하나는 KUBELET_NETWORK_ARGS를 삭제했습니다. KUBELET_NETWORK_ARGS가 제거된 클러스터에서 포드 간 트래픽이 실패합니다.

KUBELET_NETWORK_ARGS가 제거된 클러스터에서:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

일반 KUBELET_NETWORK_ARGS가 있지만 패치된 kubeadm이 있는 클러스터에서:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

KUBELET_NETWORK_ARGS를 비활성화한 사용자 중 하나인 경우 위의 내용이 효과가 있는지 확인하십시오.

노드 준비와 더미 배포 확인을 모두 삭제하는 것이 좋습니다.
모두 1.6용으로 사용하고 1.7용으로 유효성 검증 단계로 이동합니다.

2017년 3월 29일 오전 10시 13분에 "Dan Williams" [email protected]이 작성했습니다.

@jbeda https://github.com/jbeda 예, DaemonSet처럼 보입니다.
컨트롤러는 여전히 완전히 무지하기 때문에 주로 대기열에 넣습니다.
네트워크성. 우리는 이것을 더 일반적으로 수정해야 합니다. 거기 있니?
kube에서 즉시 수행할 작업이 있습니까? 아니면 지금은 모두 kubeadm에 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Ubuntu 16.04를 실행하는 다른 사람이 있습니까? systemd 서비스에서 KUBELET_NETWORK_ARGS 를 제거하고 systemd 데몬을 다시 로드했습니다. 마스터 노드를 활성화할 수 있지만 노드에 참여할 수는 없습니다. The requested resource is unavailable 오류와 함께 실패합니다.

KUBELET_NETWORK_ARGS가 제거되었으며 포드 간 트래픽이 실패합니다.

KUBELET_NETWORK_ARGS가 kubelet에 사용할 플러그인, 구성 및 바이너리를 찾을 위치를 알려주기 때문에 놀라지 않을 것입니다. 당신은 그것들이 필요합니다.

저는 #43835(및 1.6 체리 선택 #43837)를 1.6에 대한 수정 사항으로 추천합니다. 나는 둘 다 테스트했고 그들은 작동합니다. 나는 @jbeda 와 @luxas 가 깨어났을 때 검토하도록 지정했습니다.

두 PR 모두 합리적으로 보입니다. 하지만 대신 https://github.com/kubernetes/kubernetes/pull/43824를 사용하는 방법을 살펴봐야 한다고 생각합니다. 조금 더 복잡하지만 Daemonset을 사용하지 않고 CNI를 미리 구성하는 사용자가 해당 코드 경로를 유지합니다(저는 https://github.com/jbeda/kubeadm-gce-tf에서 이 작업을 수행하지 않지만 1.6으로 업데이트) 여전히 노드가 준비될 때까지 기다립니다.

보너스로, 이것은 @kensimon 의 Kubernetes에 대한 첫 번째 PR이며 그는 이 항목을 테스트하기 위해 중지를 꺼냈습니다. 하지만 솔직히 말해서, 둘 다 실행 가능하고 저는 정말 고쳐졌으면 합니다. :)

https://github.com/kubernetes/kubernetes/pull/43824를 놓쳐서 죄송합니다

둘 다 작동하면 나도 만족합니다.

@kensimon KUBELET_NETWORK_ARGS 동안 kubadm init KUBELET_NETWORK_ARGS 만 비활성화하면 저에게 효과적입니다. 당신의 지시 덕분에 나는 그것을 확인할 수있었습니다.

KUBELET_NETWORK_ARGS 동안 kubadm init KUBELET_NETWORK_ARGS 비활성화할 때만 작동하는 @webwurst 를 확인했습니다. 나는 그것을 선택하기 위해 kube-dns를 다시 시작해야했습니다. @kensimon 의 검사가 작동하고 dns가 해결됩니다.

나는 이것이 끔찍한 해킹이며 대부분의 사람들이 슬랙 채널을 보면서 따라하기에는 너무 끔찍하다는 데 동의합니다.

@kensimon 또는 @mikedanese의 패치가 더 나은 솔루션을 제공합니다.

@coeki 정확히 어떻게 kube-dns를 다시 시작하셨습니까? kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system 시도했는데 이제 kube-dns가 kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m 보류 상태로 유지됩니다.
KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , KUBELET_NETWORK_ARGS , 다시 sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
하지만 내 주인은 NotReady 머물러 있습니다. describe 나는

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

위에서 설명한 대로 kube-dns 다시 시작을 시도했지만 성공하지 못했습니다. 어떤 아이디어라도? 이번 morging에서 1.6.0 업그레이드에 실패한 후 클러스터를 다시 실행하려고 시도하는 중입니다.

@patte 그래서 난 그냥 delete pods kube-dns-3913472980-3ljfx -n kube-system 그리고 kube-dns가 다시 나타납니다.

kubeadm 초기화 후에 KUBELET_NETWORK_ARGS 하고 다시 sudo systemctl daemon-reload && sudo systemctl restart kubelet.service weave 또는 calico와 같은 포드 네트워크를 설치했습니까? 먼저 추가하면 작동하도록 할 수 있습니다.

나는 centos7에서 시도하고 테스트했으며 우분투/xenial에서 했기 때문에 작동해야 합니다.

내가 한 일을 요약하자면:

KUBELET_NETWORK_ARGS 제거
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

KUBELET_NETWORK_ARGS 다시 추가
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

시스템에 가입하면 일반적으로 방랑자에 있으므로 10.96.0.0(클러스터 IP)에 고정 경로를 추가해야 합니다.
$TOKEN과 함께 사용하지만 이 단계는 추가 단계입니다.

그 다음에:

delete pods kube-dns-3913472980-3ljfx -n kube-system

좀 기다려

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

끔찍한 해킹이지만 나를 위해 일합니다.)

kubernetes 개발 커뮤니티가 공식 수정을 위한 ETA를 제공하지 않았다는 사실에 정말 놀랐습니다. 이것은 코드 테스트 중에 쉽게 잡아야 하는 끔찍한 버그라는 뜻입니다. 최소한 1.6.1은 수정과 함께 최대한 빨리 푸시되어 사람들이 클러스터 해킹을 중단하고 생산적인 일을 시작할 수 있도록 해야 합니다. ;). 내가 여기서 틀렸어?

모두 안녕,

이번 주에 조금 정신이 없었습니다. 이것은 다음으로 가득 찬 긴 스레드입니다.
kubeadm 물건은 잘 모르겠습니다. 누군가 나를 위해 요약할 수 있습니까? NS
버그의 요점은 알지만 제안된 솔루션은 무엇이며
무엇이 그들을 끔찍하게 만드는가?

2017년 3월 30일 목요일 오전 8:13 Serguei Bezverkhi < 알림 @github.com

썼다:

kubernetes 개발 커뮤니티가
공식 수정을 위해 ETA를 제공했습니다. 나는 이것이 끔찍한 버그라는 것을 의미합니다.
코드 테스트 중에 쉽게 잡아야 합니다. 하지 않았기 때문에,
최소한 1.6.1은 수정 사항과 함께 최대한 빨리 푸시되어야 합니다.
클러스터 해킹을 중단하고 생산적인 일을 시작하십시오 ;). 나는?
여기 잘못?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

kubelet의 변경(#43474)으로 인해 kubelet이 cni 플러그인이 초기화되기 전에 네트워크가 준비되지 않았다고 올바르게 보고하기 시작했습니다. 이것은 우리가 의존하고 있던 일부 순서를 깨고 kubeadm 마스터 초기화에서 교착 상태를 야기했습니다. 이 변경에 앞서 며칠 동안 kubeadm e2e 테스트가 중단되었기 때문에 우리는 그것을 포착하지 못했습니다.

현재 제안된 수정 사항은 #43824 및 #43835입니다.

좋아, 그게 내가 이해 한 것입니다. 네트워크 플러그인 간 연동
현재 노드 준비 상태가 약간 끔찍합니다.

2017년 3월 30일 목요일 오전 8시 28분, Mike Danese [email protected]
썼다:

kubelet의 변경 사항(#43474
https://github.com/kubernetes/kubernetes/pull/43474 ) kubelet이
cni 플러그인이 준비되기 전에 네트워크가 준비되지 않았음을 올바르게 보고하기 시작하십시오.
초기화. 이것은 우리가 의존하고 있던 일부 주문을 깨뜨렸고
kubeadm 마스터 초기화의 교착 상태. 우리는 그것을 잡지 못했기 때문에
kubeadm e2e 테스트는 이 변경에 앞서 며칠 동안 중단되었습니다.

현재 제안된 수정 사항은 #43824입니다.
https://github.com/kubernetes/kubernetes/pull/43824 및 #43835
https://github.com/kubernetes/kubernetes/pull/43835 .

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

나는 여전히 #43835를 선호한다. 더 간단한 변경입니다. e2e 검사가 있는 곳에서 수행되어야 한다고 생각하지 않으며 #43824가 여전히 작동하지 않는다는 보고가 있습니다. 오늘 이 문제를 해결하기 위해 밀어붙이겠습니다.

해결 방법의 담보를 처리하는 데 많은 노력이 낭비되므로 오늘 해결하려면 +1입니다.

1.6.0이 출시되기 전에 아무도 kubeadm 1.6.0을 시도했다는 것이 믿기지 않습니다....

그리고 kubelet 1.5.6 + kubeadm 1.5.6도 깨졌습니다. /etc/systemd/system/kubelet.service.d/10-kubeadm.conf는 /etc/kubernetes/pki/ca.crt를 참조하지만 kubeadm은 생성하지 않습니다. ca.crt에도 ca.pem이 있습니다.

현재 1.6.0 및 1.5.6은 k8s apt 저장소의 유일한 왼쪽 릴리스입니다...

"상자에서 나온 것", 오늘 배운 단어.

나는 여전히 #43835를 선호한다. 더 간단한 변경입니다. e2e 검사가 있는 곳에서 수행되어야 한다고 생각하지 않으며 #43824가 여전히 작동하지 않는다는 보고가 있습니다. 오늘 이 문제를 해결하기 위해 밀어붙이겠습니다.

이것에 대해 Mike와 동의하십시오. #43835는 더 간단한 변경이며 검증(필요한 경우)은 별도의 단계에서 수행할 수 있습니다.

@thockin 우리는 특히 ho stNetwork:true의 경우 네트워킹을 위한 보다 세분화된 조건과 상태가 필요

nodeNetworkUnavailable은 클라우드 제공자에게만 해당되기 때문에 사용할 수 없습니다. Net workReady:false 가 있는 노드에서 hostNetwork:true 포드를 허용하거나 준비되지 않은 노드에서

동의하다. 좋은 답변이 없어서 문제를 미루고 있었는데,
하지만 우리는 이것을 1.7에서 얻을 필요가 있습니다

2017년 3월 30일 목요일 오전 10시 2분, Dan Williams [email protected]
썼다:

@thockin https://github.com/thockin 우리는 더 세밀한 것이 필요합니다.
특히 hostNetwork:true의 경우 네트워킹에 대한 조건 및 상태입니다
노드는 일부 포드에 대해 준비될 수 있지만 다른 포드에는 준비되지 않을 수 있습니다.

nodeNetworkUnavailable을 사용할 수 없습니다. 클라우드에만 해당되기 때문입니다.
공급자. 우리는 아마도 다른 것이 필요하거나 스케줄러가
Net workReady:false가 있는 노드에서 ho stNetwork:true 포드를 허용하거나
taint는 준비되지 않은 노드에서 작동합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin 선호하는 솔루션이 있습니까? 노드 준비 상태를 차단하고 이미 수행한 것처럼 IsNodeReady()를 사용하는 사람을 알아내거나 다른 노드 조건을 추가한 다음 다른 곳에서 누가 알고 있는지 코드베이스의 비트를 수정할 수 있습니다. 아니면 다른 옵션이 있을 수도 있습니다.

nodeNetworkUnavailable은 클라우드 제공자에게만 해당되기 때문에 사용할 수 없습니다. Net workReady:false 가 있는 노드에서 hostNetwork:true 포드를 허용하거나 준비되지 않은 노드에서

스케줄러는 준비되지 않은 모든 노드를 완전히 배제하는 대신 오염과 허용 오차를 존중하도록 수정될 수 있다고 생각합니다.
누군가는 ho stNetwork:true 포드에 허용

/cc @davidopp @dchen1107

또한 내 또는 michael의 패치를 시도하고 다가오는 제어 플레인에 전화를 끊는 사람에게는 v1.6.0 클러스터를 관리하도록 할 때 master 에서 kubeadm을 빌드하는 것이 작동하지 않는 것처럼 보입니다. , kubeadm이 잘못된 인수로 kube-apiserver를 시작하려고 하기 때문에:

unknown flag: --proxy-client-cert-file

v1.6.0 클러스터에 대해 광산 또는 마이클의 변경 사항을 테스트하려면 지금은 마스터 위에 구축하는 대신 v1.6.0에 대해 선택하십시오.

@yujuhong 스케줄러는 이미 포드에 허용

모든 오염과 준비 상태에 대한 명확한 그림이 없습니다.
이 시점에서 네트워크. 댄, 30분 안에 글을 쓸 시간이 있습니까?
현재 상태, 그래서 우리는 그것을 분리하기 시작할 수 있습니까? 나는 당신이 그것을 알고 있다고 생각합니다
베스트. 우리가 가지고 있는 여러 가지 세부적인 문제가 있다고 생각합니다.
지금까지 담요 덮었다.

2017년 3월 30일 목요일 오전 10시 22분, Ken Simon 알림 @github.com
썼다:

@yujuhong https://github.com/yujuhong 이미 스케줄러
포드에 허용 오차를 자동 적용합니다(#41414 참조).
https://github.com/kubernetes/kubernetes/pull/41414 ), 이것은
충분히 유사한 사용 사례

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin 할 수 있는데 어디에 넣어야 하나요?

몇 가지 관련 문제가 있습니다. 그 중 하나의 제목을 변경하고 게시할 수 있습니다.
현재 상태 요약 및 거기에서 이동?

2017년 3월 30일 목요일 오전 10시 50분, Dan Williams [email protected]
썼다:

@thockin https://github.com/thockin 할 수 있어요 어디에 넣어야 하나요
그것?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMhlLZks5rq-t-gaJpZM4MtMRe
.

이 수정 사항이 CentOS 리포지토리로 이식될 시기에 대한 정보가 있습니까?

1.6에서 기본적으로 코어 Kubernetes는 노드에 어떤 taint도 자동으로 적용하지 않습니다. 스케줄러는 kubeadm, kops 등과 같은 배포 시스템에 의해 추가되거나 사용자가 수동으로 추가한 taint를 존중합니다(그리고 pod에 추가되는 해당 허용 오차를 존중합니다).

기본적으로 1.6에서 Kubernetes 스케줄러는 네트워크를 사용할 수 없는 것을 포함하여 특정 노드 조건을 보고하는 경우 노드를 고려 대상에서 제외합니다. 이에 대한 코드는 여기에 있습니다 . taint와는 아무 관련이 없습니다. 단지 노드 상태를 보는 것뿐입니다.

1.6에서는 NodeReady == "False" 또는 NodeReady == "Unknown"일 때마다 코어 Kubernetes(NodeController)가 NoExecute taint를 추가하도록 하는 알파 기능을 활성화할 수 있습니다. 이렇게 하면 노드에서 실행 중인 포드가 제거되고(오염을 허용하지 않는 경우) 새 포드가 노드로 일정을 잡는 것을 방지합니다(오염을 허용하지 않는 경우).

장기 계획은 "코어 Kubernetes가 일정 및 제거와 관련하여 노드 조건에 반응하는 방법" 논리를 모두 오염 및 허용 오차를 사용하도록 이동하는 것입니다(예: #42001). 그러나 우리는 아직 거기에 있지 않으며 한동안 없을 것입니다. 따라서 단기적으로는 포드가 NetworkUnavailable 또는 추가하기로 결정할 수 있는 다른 노드 조건을 "견인"할 방법이 없습니다.

@davidopp이 말한 것이

kubeadm의 경우 NetworkUnavailable이 유일한 경우입니다. kubeadm은 true를 반환할 수 있습니다. kubeadm 초기화 시간에 네트워킹/cni 플러그인이 전달되는 것을 원하지 않는 경우입니다.

내가 잘 이해한다면 적어도 kubeadm에 대해서는 이 기능을 기반으로 taint 및 toleration이 설정됩니다.

틀 렸으면 고쳐줘 ;)

이 문제에 부딪쳤고 짜증나기 때문에 이 스레드로 이동합니다.

네트워크 준비 상태가 노드의 네트워크 상태에 따라 kubelet이 추가 및 제거하는 오염이 될 수 없는 이유는 무엇입니까?
그런 식으로 노드는 네트워크 준비 상태 오염(포드 네트워크 앱)을 허용하는 모든 포드에 대해 "준비" 상태가 될 수 있습니다.

호스트 네트워크 포드의 경우 승인 컨트롤러가 포드 네트워크 준비 상태 오염에 대한 내성을 주입할 수 있습니다.

나는 그것이 davidopp의 의견에 있는 장기 계획과 일치한다고 생각합니다.

나는 그것이 davidopp의 의견에 있는 장기 계획과 일치한다고 생각합니다.

네, 맞습니다. 장기 계획은 모든 노드 조건에 대한 오염을 갖고 Kubernetes 내부에서 노드 조건에 주의를 기울이지 않도록 하는 것입니다. 우리는 내가 언급한 1.6 알파 기능으로 작업을 시작했습니다.

확인. v1.6 패치 릴리스에서 taint로 전환하지 않는 이유가 있습니까?

노드 조건을 기반으로 taint를 자동으로 추가하는 코드는 1.6에서 알파로 들어갔습니다. 의지할 준비가 되지 않았습니다. (그리고 현재 네트워크가 아닌 노드 준비 상태만 처리합니다).

따라서 제가 올바르게 이해했다면 현재로서는 https://github.com/kubernetes/features/issues/166 이 네트워크 가용성을 올바르게 오염시킬 수 있는 데 시간이 더 오래 걸리므로 해결 방법을 사용해야 합니다. https://github.com/kubernetes/features/issues/166 으로 수정하라는 주석과 함께 #43835와 같은 kubeadm에 대한 수정 사항을 최대한 빨리 푸시할 수 있다면 많은 사람들이 기뻐할 것입니다.

@davidopp "기대 하지 않음 "이라고 말한 것 같습니다. 네트워크 문제에 대해 직접적으로 kubelet 게시 taint와 함께 언급한 taint 논리에 대한 자동 조건 간의 관계가 여전히 누락되었습니다.

네 감사합니다 오타였네요 수정했습니다

예, Kubelet이 taint를 추가하도록 할 수 있습니다. Kubelet이 일부 노드 조건에 대한 taint를 추가하고 NodeController가 다른 노드 조건에 대해 추가하도록 하는 것은 이상적이지 않을 수 있습니다(후자는 마스터만 연결할 수 없는 노드를 감지할 수 있기 때문에 필요함). 그러나 이는 단지 소프트웨어 엔지니어링 주장일 뿐이며 근본적인 것은 아닙니다. 내 계획은 NodeController가 모든 노드 조건에 대한 taint를 추가하는 것이지만 그렇게 해야 한다는 강력한 요구 사항은 없습니다.

확인. 이 경우 단일 노드 조건에는 노드 컨트롤러가 식별할 수 없는 여러 속성이 관련되어 있습니다.
@mikedanese kubeadm init 의 기존 동작으로 인해 노드가 작동하는 것이 매력적이라고 ​​느낍니다. validation 단계를 추가해야 하는 요구 사항이 주로 이 문제를 기반으로 하지 않기를 바랍니다.
@dcbw @thockin @yujuhong kubelet 에서 노드 구성 문제를 나타내기 위해 것에 대한 생각이 있습니까?

새 taint가 노드의 현재 자동 필터링을 NetworkUnavailable로 대체하려면 앞서 언급한 기능을 수정해야 합니다(즉, 노드를 필터링하는 조건 집합에서 제거). 그 기능은 스케줄러 이외의 노드 목록에서 사용될 수 있기 때문에 다른 부작용이 무엇인지 모르겠습니다.

Ubuntu에서 작동해야 하는 1.5.6을 설치하는 방법이 있습니까? 있다면 어떻게 하는지 설명 부탁드립니다. 감사 해요!

새 taint가 노드의 현재 자동 필터링을 NetworkUnavailable로 대체하려면 앞서 언급한 기능을 수정해야 합니다(즉, 노드를 필터링하는 조건 집합에서 제거). 그 기능은 스케줄러 이외의 노드 목록에서 사용될 수 있기 때문에 다른 부작용이 무엇인지 모르겠습니다.

@davidopp 우리는 NetworkUnavailable 대 NodeReady에 대해 주의해야 합니다. 실제로 정리해야 하는 두 가지 별도의 조건이 있습니다.

nodeNetworkUnavailable - 이는 클라우드 경로에만 해당되며 노드 간 클라우드 경로가 설정된 경우 클라우드 경로 컨트롤러만 이 조건을 지웁니다. 오버레이를 생성하거나 노드 간에 L3 라우팅을 수행하지 않는 네트워크 플러그인은 이 조건을 원하지 않거나 사용하지 않습니다. 이 조건은 네트워크 플러그인에 의해 추가되지 않습니다. 특히 GCE 또는 AWS가 클라우드 공급자로 선택될 때 kubelet에 의해 추가됩니다. 별도의 조건이므로 NodeReady에 영향을 미치지 않습니다.

NodeReady - 네트워크 플러그인(예: CNI 또는 kubenet 또는 dockershim/CRI-O와 같은 원격 런타임)의 직접적인 영향을 받습니다.

고려해야 할 세 가지 개별 문제가 있습니다.

1. 클라우드 경로 - 클라우드 인프라 및 네트워크 플러그인에 클라우드 경로가 필요한 경우 클라우드 경로가 부족하면(예: NodeNetworkUnavailable=true) 예약 hostNetwork=false 포드를 차단해야 합니다.
2. 네트워크 플러그인 - 플러그인이 아직 준비되지 않은 경우 hostNetwork=false 포드의 일정을 차단해야 합니다. 플러그인은 클라우드 경로에 의존하지 않기 때문에 Routes Controller와 직접적인 상호 작용이 없을 수 있으므로 NodeNetworkUnavailable과 별개입니다. 예를 들어, kubenet은 노드 경로를 설정한 다른 항목(클라우드 경로, 플란넬 등)이 있는 경우 노드에서 로컬로 사용할 수 있습니다.
3. hostNetwork=true 포드는 이러한 모든 조건을 무시하고 예약해야 하지만 다른 적용 가능한 조건(디스크 공간 등)에 따라야 합니다.

NodeReady는 너무 큰 망치입니다. 네트워크 플러그인 준비 상태를 위한 추가 NetworkPluginReady 조건(클라우드 경로 준비 상태와는 별개입니다!)을 원하고 그런 다음 이를 관심 있는 장소로 연결해야 한다고 생각합니다.

주변의 또 다른 작업을 찾았습니다.

kubeadm이 '[apiclient] 첫 번째 노드가 등록되었지만 아직 준비되지 않았습니다.'를 계속 출력하는 동안 flanneld를 설치하는 'kube-flannel.yml'을 배포했습니다. 구성 파일을 변경하지 않고도 작동했습니다.

1) kubeadm 초기화 --pod-network-cidr=10.244.0.0/16 &
2) cp /etc/kubernetes/admin.conf ~/.kube/config
3) kubectl apply -f kube-flannel-rbac.yml (kubeadm 1.6에서 필요)
4) kubectl 적용 -f kube-flannel.yaml
https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml 에서 kube-flannel.yaml 사용

마스터 노드를 'Ready'로 만들 수 있습니다. 그러나 kube-dns가 메시지와 함께 실패했습니다.

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

네트워크 플러그인을 weave-net으로 변경한 후 작동했습니다.

@dcbw 정확히 무엇을 해야 하는지 알려줄 만큼 이 문제에서 논의된 특정 문제에 대해 충분히 알지 못합니다. 저는 taint의 현재 상태와 여기에 어떻게 적용될 수 있는지 설명하고 싶었습니다.

패치된 DEBS를 테스트하십시오

kubernetes-xenial-unstable 에는 이제 @pipejakob 와 제가 오늘 테스트한 패치된 빌드 1.6.1-beta.0.5+d8a384c1c5e35d-00 가 있습니다. 노드는 포드 네트워크가 생성될 때까지 준비되지 않은 상태로 유지됩니다(예: weave/flannel 구성 적용). 적합성 테스트 통과. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

taint가 거의 모든 것을 표현할 수 있는 일반적인 방향입니다.
조건은 모든 면에서 더 좋을 수 있으며 따라서 더 낫습니까?

더 세분화된 신호가 필요하다는 데 동의합니다. 우리는 여전히 정리해야합니다
kubelet, net 드라이버, 클라우드 컨트롤러 및 클라우드 공급자 간의 상호 작용
hostNetwork=false 포드를 잠금 해제하지만 hostNetwork=true가 아니어야 합니다.
막힌.

2017년 3월 30일 목요일 오후 7시 24분, Dan Williams [email protected]
썼다:

새 taint가 현재 자동을 대체하려면
NetworkUnavailable을 사용하여 노드를 필터링하려면 다음을 수정해야 합니다.
앞에서 언급한 기능(즉, 조건 세트에서 제거
노드를 필터링함). 또 어떤 부작용이 생길지 모르니
그 함수는 단지 다른 노드 목록에서 사용될 수 있기 때문에
스케줄러.

@davidopp https://github.com/davidopp 조심해야 할
NetworkUnavailable 대 NodeReady. 두 가지 별도의 조건이 있습니다.
정말 청소해야합니다 :

nodeNetworkUnavailable - 이는 클라우드 경로에만 해당되며 클라우드에만 해당됩니다.
경로 컨트롤러는 노드 간의 클라우드 경로가 다음과 같을 때 이 조건을 지웁니다.
설정되었습니다. 오버레이를 생성하거나 L3를 수행하지 않는 네트워크 플러그인
노드 간의 라우팅은 이 조건을 원하지 않거나 사용하지 않습니다. 이 조건은
네트워크 플러그인에 의해 추가되지 않았습니다. 특히 kubelet에 의해 추가된 경우
GCE 또는 AWS가 클라우드 공급자로 선택됩니다. 이후 NodeReady에 영향을 미치지 않습니다.
별도의 조건입니다.

NodeReady - 네트워크 플러그인(예: CNI 또는 kubenet
또는 dockershim/CRI-O와 같은 원격 런타임).

고려해야 할 세 가지 개별 문제가 있습니다.

1. Cloud Routes - 클라우드 인프라 및 네트워크 플러그인인 경우
   클라우드 경로가 필요한 다음 클라우드 경로가 부족합니다(예:
   NodeNetworkUnavailable=true) 예약을 차단해야 함 hostNetwork=false
   꼬투리
2. 네트워크 플러그인 - 플러그인이 아직 준비되지 않은 경우
   hostNetwork=false 포드의 블록 스케줄링
3. hostNetwork=true 포드는 이러한 모든 조건을 무시해야 하며
   예약되지만 다른 적용 가능한 조건(디스크 공간 등)에 따라 달라질 수 있습니다.

NodeReady는 너무 큰 망치입니다. 내 생각에 우리는 아마도
네트워크 플러그인 준비를 위한 추가 NetworkPluginReady 조건
(클라우드 경로 준비와는 별개입니다!) 그런 다음
관심있는 곳으로 :(

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

kubelet KUBELET_NETWORK_ARGS 구성 라인을 제거하여 임시 수정을 시도하는 사람을 위해 @jc1arke 는 더 간단한 해결 방법을 찾았습니다. 새 마스터에 대해 두 개의 세션을 갖고 첫 번째 노드가 준비되기를 기다리는 동안 두 번째 노드에서 노드 네트워크 구성을 적용합니다. 세션:
kubeadmin init 실행 후 첫 번째 세션:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
...

두 번째 세션(Calico 사용. 선택은 물론 다를 수 있음):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

첫 번째 세션으로 돌아가기:

...
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

taint가 거의 모든 것을 표현할 수 있는 일반적인 방향입니다.
조건은 모든 면에서 더 좋을 수 있으며 따라서 더 낫습니까?

꽤 많이. 이전 버전과의 호환성 문제로 인해 노드 조건을 제거할 수는 없지만 이를 기반으로 조치를 취하는 마스터의 모든 논리(예: 일정 차단 또는 포드 제거)를 제거할 수 있습니다. 행동을 더 명확하게 만드는 것 외에도(어떤 조건이 일정을 차단하는지, 퇴거를 유발하는지, 퇴거를 기다리는 시간 등을 외울 필요가 없음) 조건에 대한 반응은 포드별로 구성할 수 있습니다.

@mikedanese 및 @pipejakob 의 debs를 방금 테스트

우분투/xenial에서 테스트:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mikedanese 및 @pipejakob 의 debs를 방금 테스트 춥니다 .
[apiclient] Created API client, waiting for the control plane to become ready

5분정도 기다렸는데 달라진게 없네요.
그리고 어제 계속 반복
[apiclient] First node has registered, but is not ready yet

TTI는 문제가 여전히 해결책이 아니라고 생각합니까?

Ubuntu 16.04에서 테스트:
kubeadm 버전: version.Info{주요:"1", 부:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808def7"babtree41" -03-31T04:20:36Z", GoVersion:"go1.7.5", 컴파일러:"gc", 플랫폼:"linux/amd64"}

@myqq0000 사용 중인 버전을 게시할 수 있습니까?

kubeadm version

@coeki 아, 잊어버렸습니다. 방금 수정했고 이전 댓글에 버전을 게시했습니다. :)

@mikedanese centos yum repo를 업데이트할 계획이 있습니까? 아니면 이미 yum repo에 배포되어 있습니까?

방금 1.6.1-beta.0.5+d8a384c1c5e35d-00 시도했습니다(https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036에 언급된 1.6.1-beta.0.5+48c6a53cf4ff7d-00 는 존재하지 않는 것 같습니다).

잘 작동하는 것 같습니다.
관련 없음: weave를 사용하는 경우 'default' https:/ 대신 https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml 을 적용해야 합니다 . /git.io/weave-kube

@mausch 이 debs를 얻는 방법을 알려주시겠습니까?

@srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

@mikedanese 패치된 debs가 저에게 효과적입니다. 모든 작업에 감사드립니다! :웃다:

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch 감사합니다. 그들은 weave 네트워크 공급자와도 함께 일합니다.

Centos에 대해서도 동일한 수정 사항을 빌드할 기회가 있습니까? 우리의 게이팅 시스템은 주로 kubernetes 클러스터 기반에 centos를 사용합니다. centos 버전이 있으면 대략적으로 보장할 수 있습니다. 테스트로 하루에 kubeadm init를 100번 실행합니다.

@mikedanese 패치된 debs는 부분적으로 저에게 효과적입니다. kubeadm 는 클러스터가 준비되었음을 알리지만 노드 자체는 준비되지 않았습니다.

@squall0gd 노드는 포드 네트워크가 적용될 때 준비가 되어야 합니다(예: kubectl apply -f https://git.io/weave-kube-1.6

내 테스트 환경(centos/7 시스템 기반 vagrant)에서 kubeadm이 중단됩니다. strace를 사용하면 마스터의 kubelet 서버에 연결을 시도하고 FUTEX_WAIT, epoll_wait 재시도 루프를 수행하는 것을 볼 수 있습니다. 그러나 그것에서 오는 출력은 한 줄도 없습니다.

kubelet이 시작되지 않는 것이 그 이유인 것 같습니다.
(하지만 kublet이 시작되지 않는 이유를 알 수 없습니다.)

이것이 이 문제의 문제입니까?

http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 저장소에서 바이너리를 얻습니다.
또한 https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ 에서 바이너리를 업데이트하려고 합니다.

==> 테스트용으로 패치된 kubeadm 버전을 어디에서 받을 수 있습니까? <==

참고: https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (패치된 버전은 다음과 같습니다: https://heptio-aws-quickstart test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), 하지만 그것은 나를 위해 작동하지 않습니다. 동작은 여전히 ​​동일합니다(출력 없음)...

@squall0gd 보고 계신 정확한 메시지를 보여주시겠습니까? 설명하신 내용에 따르면 실제로 새 .debs를 선택했는지 아니면 이전에 캐시된 버전을 사용하고 있었는지 궁금합니다.

@thockin @davidopp 팀의 제안에 따라 기존 문제를 지휘하거나 네트워크 준비 상태를 풀기 위해 새 문제를 제출하고 실제 조건 대신 전체를 오염으로 변환하고 대부분의 https://github에 복사

다음은 unstable repo(마스터 자체만 테스트)에서 저에게 효과가 있는 것 같습니다.

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

이것은 한 지점에서 error: taint "dedicated:" not found 를 뱉어내지

1.6 브랜치에서 이 테스트를 실행하지 않습니까?

@davidopp 노드 조건은 이유, 메시지 및 전환 시간과 같은 진행 상황을 이해하기 위해 인간에게 추가 정보를 제공하기 위한 것입니다.

kubeadm은 릴리스 분기에서 테스트된 것처럼 보이지 않습니다.
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 분명히 kubeadm e2e 테스트는 IIRC 1.6 릴리스까지 약 일주일 동안 비활성화/비작동했습니다.

노드 조건은 이유, 메시지 및 전환 시간과 같은 진행 상황을 이해하기 위해 인간에게 추가 정보를 제공하기 위한 것입니다.

@bgrant0607 주로 인간 정보를 위한 것

@dcbw Taints는

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

노드에 taint를 추가하려면 다음을 고려해야 합니다.

a) 마스터 taint와 같은 하위 호환성: https://github.com/kubernetes/kubernetes/pull/43537

b) 버전 왜곡. 클러스터를 1.6으로 업그레이드할 때 kubelet은 혼합 릴리스가 될 것이며 일부는 1.4만큼 오래된 것일 수 있습니다.

요약하거나 내가 이것을 구문 분석 할 때 :

@dcbw 기반

nodeNetworkUnavailable은 kubeadm atm에 연결되지 않은 클라우드 제공업체이므로 이 문제가 발생할 수 있습니다.

그러나 루프의 근본 원인인 NodeReady는 더 세분화해야 합니다. 이것은 @davidopp 이 프로브/활성, CNI 준비 등과 관련하여 상자를 체크 표시하는 목록을 기반으로 하는 오염이 되기를 원하는 것입니다.

좋아, 당신이 논쟁할 수 있지만, 왜 레이블을 붙이지 않습니까?

하지만 @dcbw 이 토론에 더 적합한 스레드를 찾았습니까? 이것은 실제로 문제의 근본이 아니라 배포 문제에 대한 버킷이 되기 때문입니다.

나는 실제로 문제에 접근하지 않고 해킹을 게시하는 일부였습니다. :)

그러나 어쨌든 우리는 다른 곳에서 기본 사항을 논의하고 수정에 대한 ETA가 여기에 배치되었는지 확인하고 계속 진행해야 합니다.

날렵하진 않지만 좋아요 :)

추신 예 @bgrant0607 우리는 이것을 더 테스트했어야 했습니다
PS2 내가 이것을 잘못 본다면, 당신은 나를 비난 할 수 있습니다 ;)

@coeki 또한 N-1 버전이 rpm/deb

@kfox1111 게이팅도 문제입니다.... 더 나은 전략이 필요합니다 :)

이전 릴리스를 아예 삭제하는 이유는 무엇입니까? 이는 사람들의 자동화를 쉽게 중단시키고 반복 가능한 설치를 방지할 수 있습니다.

노드 조건은 이유, 메시지 및 전환 시간과 같은 진행 상황을 이해하기 위해 인간에게 추가 정보를 제공하기 위한 것입니다.

동의. UX는 분명히 우리가 노드 조건을 제거할 수 없는 주요 이유입니다. 그러나 마스터 작업(예: 축출 및 일정 차단)에 대한 트리거로 노드 조건의 모든 사용을 제거하고 대신 오염을 사용할 수 있다고 생각합니다.

장기적으로(예: v2 API 장기 실행) 이유와 메시지를 taint에 추가한 다음 노드 조건을 제거할 수 있다고 생각할 수 있습니다. (우리는 이미 TimeAdded라는 한 방향으로의 전환 시간에 해당하는 것을 가지고 있습니다.)

@coeki 아니, 내가 말한 것은 게이팅과 관련이 없습니다. 게이팅은 가능한 모든 것을 테스트하는 게이트가 없으면 모든 문제를 찾을 수 없습니다. 운영자는 자신의 환경에서 이상한 일을 하는 것을 좋아합니다. :) 가능한 모든 것을 테스트하려면 엄청나게 비쌉니다.

새 릴리스가 최소한 첫 번째 bugfix 릴리스를 통해 만들기 전에 이전 릴리스를 삭제하지 않도록 요청합니다. 이 예의 경우 1.6.1. 최소한. 더 많은 이전 버전을 유지하는 것이 훨씬 좋습니다. 이것은 새 버전의 버그가 해결되는 동안 운영자가 계속 진행할 수 있도록 하는 모범 사례입니다.

@kfox1111 , 그것이 게이팅이 하는 일입니다. 좋은 것처럼 보이는 것과

@davidopp 레이블과 하지만 지금은

어쨌든, 당신은 나를 토론으로 유인합니다. 우리는 이 문제에 대해 정말로 가지고 있지 않습니다. 그것이 제 요점이었습니다.

다시 묻고 싶습니다. "kubeadm init"가 출력 없이 거기에 매달려 있는 경우(시작하지 못한 kubelet 서버에 연결하려고 시도함), 제가 이 문제를 겪고 있는 것입니까? 그리고 이것이 사실이라면 #43835가 나를 위한 해결책입니까?

이제 어디서 얻을 수 있습니까?

• kubeadm / kubectl / kubelet의 이전(1.6.0 이전) 버전
• 또는 패치된 버전의 kubeadm(#43835 또는 기타 수정 사항 포함)?

감사 해요!

(참고: 위에서 언급한 커밋에서 참조된 kubeadm의 패치 버전은 저에게 적합하지 않습니다 ...)

@obnoxxx 릴리스 1.6 분기의 팁을 시도하십시오.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese 감사합니다! 견딜 수 없는...

os 패키지를 설치하지 않고 kubeadm을 실행하는 경우 다음을 수행해야 합니다.

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf에서

@mikedanese 감사합니다. (kube repo에서) os 패키지를 설치한 다음 rpms의 바이너리 위에 웹 URL의 바이너리를 설치하고 있습니다...

1.6.1-beta.0.12 버전은 저에게 효과가 없었 습니다.
kubeadm는 출력하지 않고 여전히 중단을 초기화하기. (kubelet에 연결하려고 시도 중)

centos인 경우 시스템 드라이버도 잊지 마십시오.

시스템 드라이버?

https://github.com/kubernetes/release/issues/306

이런, 감사합니다, 그게 더 좋습니다! :-)

@pipejakob 지금은이 로그에 대한 액세스 권한이없는,하지만 난 kubeadm 버전을 확인했고 @webwurst가 가지고로 동일한 버전이었다. 또한 apt-cache policy kubeadm 가능한 kubeadm 버전을 확인했습니다. 그리고 kubernetes-xenial-unstable에서 단 하나의 항목이 있었습니다.
@mikedanese 게시하기 전에 플란넬로 시도했습니다 ;)
편집: 나는 전체 플랫폼을 재구축했고 kubadm 가 잘 작동합니다 :+1:

얘들아, 수정에 대한 현상 유지는 무엇입니까? 곧 안정적인 저장소로 이동할 예정입니까?

@mikedanese 패치된 debs는 동일한 "네트워크 플러그인이 준비되지 않았습니다"라는 작업을 수행하고 있습니다.

rhel(rpm)용 kubeadm의 패치 버전을 빌드하는 방법을 알려줄 수 있는 사람이 있습니까?

@mikedanese with patched debs init은 성공을 보고하지만 "네트워크 플러그인이 준비되지 않았습니다: cni config uninitialized" 메시지가 지속됩니다.

마스터 노드는 NotReady 있습니다.

weave-net (weaveworks/weave-kube:1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml)은 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

kube-dns 포드는 0/3 Pending 있습니다.

@ChipmunkV 사용자 공간에서 실행되도록 kube-proxy를 구성해야 할 수도 있습니다. 이것은 1.5에서도 문제가 되었습니다.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

그만한 가치가 있기 때문에 kubernetes-xenial-unstable 가 저에게 잘 맞습니다.

@pstadler , 내가 네트워크가 겹치는 것을 지적한 채팅의 @errordeveloper 덕분에 IPALLOC_RANGE 를 재구성했습니다.

@thenayr 감사합니다. Kubernetes 마스터를 불러올 수 있지만 kubeadm 조인을 사용하여 한 작업자를 여기에 연결할 수도 있습니다. 곧 더 많은 업데이트를 게시할 예정입니다.

@mikedanese 여기의 모든 댓글을 읽을 때까지 사용할 버전을 찾는 데 영원히 걸렸습니다. 우리는 주어진 버전에 대한 바이너리를 훨씬 쉽게 찾을 필요가 있습니다. 나는 ci-cross/latest.txt 가리키는 것(즉, v1.7.0-alpha.0.1982+70684584beeb0c )을 사용해 보았고 새로운 kube-apiserver 플래그(즉, --proxy-client-key-file in d8be13fee85075abfc087632b3dbc586a10897ad)를 도입했습니다. gcr.io/google_containers/kube-apiserver-amd64 의 최근 태그와 작동하지 않습니다 ...

버킷에 바이너리가 있는 개정판을 쉽게 알아낼 수 있는 방법은 무엇입니까? 디렉토리를 나열할 수 있는 것이 좋거나 간단한 맵 파일 또는 알거나 추측할 필요가 없는 모든 것이 있을 수 있습니다.

@errordeveloper 우리는 안정적인 브랜치에 대한 수정 사항을 푸시할 수 있도록 릴리스를 시도하고 있으며 O(일) 내에 완료되어야 합니다. 이 문제에 대한 설명에는 불안정한 상태의 패치된 debs에 대한 링크가 있습니다.

이전 릴리스 1.5.6은 CentOs 7에서 작동했지만 이제는 http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 에 있는 kubeadm의 유일한 버전이 손상된 1.6이기 때문에 롤백할 수도 없습니다. 0. kubeadm 1.5.6 RPM을 얻는 방법에 대한 제안 사항이 있습니까?

참으로 유감입니다. 이전 버전은 완전히 제거된 것 같습니다. :-(

내 결과는 centos 7에서 다음과 같습니다.

• kubectl에 대해 아무 것도 하지 않고 패치된 최신 kubeadm을 사용하더라도 kubadm init를 사용하여 결과를 전혀 얻을 수 없었습니다.
• @coeki의 지시로 kubectl을 시작할 수 있었고 kubeadm도 통과했습니다. 그러나 그 후에는 아무 것도 작동하지 않습니다. kubectl 라고

The connection to the server localhost:8080 was refused - did you specify the right host or port?

무슨 일이야?

@obnoxxx 기본적으로 apiserver는 8080에서 수신 대기하지 않고 보안 6443 포트에서 수신합니다. netstat -tunlp로 확인할 수 있습니다.
/etc/kubernetes에서 $HOME/.kube/config로 admin.conf를 복사해야 합니다.
$HOME/.kube/에 있는 파일에 대한 권한을 변경했는지 확인하십시오. 그런 다음 kubectl이 apiserver에 제대로 연결할 수 있어야 합니다. HTH. 세르게이

@apsinha 이 스레드를 알고 있습니까? 앞으로 몇 가지 중요한 시사점이 있을 것이라고 생각하기 때문에 일부 제품 사람들이 팔로우하는 것이 좋을 수 있습니다.

내 머리 꼭대기에서 :

• 1.6.0은 자동화된 테스트를 거치지 않았습니다: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• 이전 버전의 바이너리/패키지가 제거되었으므로 사람들은 안전하게 롤백할 수 없습니다. 계속 사용할 수 있다고 가정한 모든 설치 자동화를 중단했습니다. https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• 이것이 깨졌다는 사실에 대한 공개 발표(내가 본 것) 없음
• 수정 사항에 대한 일정 없음(저는 개발자이므로 "언제 수정될까요?"라는 질문이 얼마나 불쾌한지 압니다. 하지만 그럼에도 불구하고 사람들은 이렇게 묻습니다. 따라서 최소한 예상 기간을 제공하는 것이 좋습니다)
• 대화에 계속 참여하는 사용자는 상황, 해결 방법 및 수정 일정에 대해 혼란스러워 합니다.
• 기여자들 사이의 많은 기술적 토론(대부분 장기 전략에 관한 것)은 사용자가 현재 상황과 즉각적인 문제를 처리하는 방법을 파악하려고 하는 것과 동일한 스레드에서 결합됩니다.

Kubernetes를 있는 그대로 만드는 모든 위대한 사람들에 대한 무례한 행동은 아닙니다. Kubernetes가 신뢰할 수 있고 안정적이라는 대중의 인식 측면에서 보기에 좋지 않은 것처럼 보이는 "가르칠 수 있는 순간"이 여기에 있기를 바랄 뿐입니다. (허용된 kubeadm은 알파/베타이지만 여전히 가시성이 많습니다.)

kubernetes/release.rpm을 사용하여 kubeadm-1.5.6을 빌드했습니다.

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone 여기 에서 .spec을 조정해야 합니다.

@sbezverk 힌트 주셔서 감사합니다! 지금이 낫다...

이것은 궁금하다:

• 이전 릴리스에서 admin.conf를 복사하는 것이 필요했는지 기억나지 않습니다.
• 전에 kubectl -s localhost:6443 시도했지만 충분하지 않았습니다.

어쨌든 이제 계속할 수 있습니다. 다시 한번 감사합니다

v1.6.1이 출시되는 중입니다. EOD로 진행됩니다.

몇 가지 참고 사항:

1. 이전 패키지가 삭제되는 문제는 https://github.com/kubernetes/release/issues/234 에서 추적되었습니다 @bostone 귀하의 문제도 거기에서 참조됩니다)
2. 여기에서 추적되는 PR에 대한 kubeadm e2e 테스트: https://github.com/kubernetes/kubeadm/issues/190
3. 공개 발표에 관해서는 -- 트위터에 올렸지만 공식적인 것은 아닙니다. 이와 같은 중요한 문제에 대한 올바른 채널이 무엇인지 명확하지 않습니다.

이것들은 모두 PM에서 제기하기에 좋은 문제입니다. @pipejakob님 은 기꺼이 그 사후 조사를 함께

@obnoxxx 1.5에서는 API 서버가 안전하지 않은 포트를 노출했기 때문에 admin.conf를 복사/chown해야 하는 요구 사항이 이전에 필요했습니다. 1.6에서 변경했습니다. 이제 보안 자격 증명을 사용하여 API 서버에 액세스해야 합니다(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2 참조).

@mikedanese 좋은 소리, 감사합니다!
나는 더미를 위해 - 이 문제와 관련하여 이 릴리스 1.6.1의 효과는 무엇입니까?
kubelet은 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( @coeki 의 해결 방법)에 대한 변경 없이 시작됩니까, 아니면 #43835(나에게 영향을 미치지 않는 것 같았음)의 수정 사항이 포함됩니까?

@jbeda 설명 감사합니다!

@jbeda 나는 혼란이 공식 kubadm 설치 문서에서 YUM repo를 http://yum.kubernetes.io/repos/kubernetes-el7-x86_64로 설정하는 것에서 비롯된 것이라고 생각합니다

그리고 다시 실망스럽게도 1.5.6 rpm을 구축하고 설치하면 똑같은 문제가 발생했습니다. kubeadm init 실행하면 바로 같은 줄에 매달려 있습니다.

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

1.6.1 릴리스를 기다리며 희망을 가지겠습니다...

1.6.1이 종료되었습니다.

@mikedanese 이 버그를 닫기 전에 kubeadm을 테스트했습니까? 지금 나는 이미 10분 동안 [apiclient] Created API client, waiting for the control plane to become ready 를 바라보고 있다. 새로운 1.6.1이 설치된 CentOS 7에서

@bostone 이 문제가 발생할 수 있습니다. #43805

편집을 시도 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 및 추가 --cgroup-driver=systemd

systemctl daemon-reload; systemctl restart kubelet 를 실행하는 것을 잊지 마십시오.

@gtirloni는 우리의 제안에 나는이 말에 도착 kubeadm init 실행 kubectl에 그러나 모든 시도는이 오류가 발생합니다 : The connection to the server localhost:8080 was refused - did you specify the right host or port? 아니에요 어디서부터 어떻게 또는 오른쪽으로 포트에서 어떤 것을 변화 이 점?

이것이 관련이 있는지 확실하지 않지만 다음은 systemctl status kubelet 실행할 때 표시되는 내용입니다.
``` systemctl 상태 kubelet -l
● kubelet.service - kubelet: Kubernetes 노드 에이전트
로드됨: 로드됨(/etc/systemd/system/kubelet.service; 활성화됨, 공급업체 사전 설정: 비활성화됨)
드롭인: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
활성: 활성(실행 중) 이후 월요일 2017-04-03 17:31:07 PDT; 11분 전
문서: http://kubernetes.io/docs/
메인 PID: 10382(kubelet)
C그룹: /system.slice/kubelet.service
├─10382 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true - -network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain =cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=systemd
└─10436 저널ctl -k -f

Apr 03 17:41:56 sdl02269 kubelet[10382]: W0403 17:41:56.645299 10382 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Apr 03 17:41:56 sdl02269 kubelet[10382]: E0403 17:41:56.645407 10382 kubelet.go:2067] Container runtime network not ready: NetworkReady=false 이유:NetworkPluginNotReady 메시지 가 네트워크 플러그인이 준비되지 않았습니다. 초기화되지 않은```

예, 우리는 테스트했습니다. e2e 테스트가 릴리스 분기를 통과하고 있습니다. 다른 문제에 부딪힐 수 있습니다.

@bostone kubeadm init 이후에 이 단계가 누락 되었을 수 있습니까?

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

여기에 설명된 3단계도 수행해야 합니다. 그것은 당신이 얻는 cni 구성 오류와 관련된 것 같습니다.

또한 [apiclient] Created API 클라이언트를 보고 Ubuntu 16.04 및 1.6.1 새로 설치로 이미 10분 동안 컨트롤 플레인이 준비될 때까지 기다립니다.

@pingthing Slack Kubernetes 및 kubeadm 채널에 가입하는 것이 좋습니다. 우리는 당신이 거기에서 디버깅을 도울 수 있습니다.

다음 단계를 수행하여 centos-release-7-3.1611.el7.centos.x86_64에 Kubernetes 클러스터를 성공적으로 설정했습니다(Docker가 이미 설치되어 있다고 가정).

1) (/etc/yum.repo.d/kubernetes.repo에서) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> 최신 Kubernetes 1.6.1에서 불안정한 저장소를 사용하려면
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) 마지막 줄 끝에 "--cgroup-driver=systemd"를 추가합니다.
=> Docker는 cgroup-driver에 systemd를 사용하고 kubelet은 cgroup-driver에 cgroupfs를 사용하기 때문입니다.
4) systemctl은 kubelet을 활성화하고 && systemctl은 kubelet을 시작합니다.
5) kubeadm 초기화 --pod-network-cidr 10.244.0.0/16
=> --api-advertise-addresses를 추가했다면 대신 --apiserver-advertise-address를 사용해야 합니다.
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
내보내기 KUBECONFIG=$HOME/admin.conf
=> 이 단계가 없으면 kubectl get에서 오류가 발생할 수 있습니다.
=> 나는 1.5.2에서 그것을하지 않았다
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0은 역할 기반 액세스 제어를 도입하므로 Flannel 데몬셋을 생성하기 전에 ClusterRole 및 ClusterRoleBinding을 추가해야 합니다.
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Flannel 데몬셋 생성
9) (모든 슬레이브 노드에서) kubeadm join --token (귀하의 토큰) (ip):(port)
=> kubeadm init의 결과와 같이

위의 모든 단계는 Kubernetes-1.6.0, 특히 kubeadm과 관련된 다양한 문제의 제안을 결합한 결과입니다.

시간을 절약할 수 있기를 바랍니다.

이것은 해결되지 않은 것 같습니다(Ubuntu LTS, kubeadm 1.6.1).

먼저 --apiserver-advertise-address 플래그를 사용할 때 "Created API 클라이언트, 컨트롤 플레인이 준비되기를 기다리는 중"에 kubeadm이 매달려 있는 것도 경험했습니다. 저널 로그에는 다음과 같이 나와 있습니다.

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

이 플래그를 제공하지 않으면 kubeadm이 통과하지만 kubelet 시작에 대해 다음 오류가 발생합니다.

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet이 제대로 시작하기를 거부하고 어떤 식으로든 kubectl 로 클러스터에 연결할 수 없습니다.

1.5.x kubeadm 버전이 centos 저장소뿐만 아니라 Ubuntu LTS에서도 제거된 것 같습니다. https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It 다운그레이드를 어렵게 만들고 실제로 이전 버전과의 호환성을 깨뜨립니다.

@보스톤

"제어 플레인이 준비될 때까지 기다리는 중"에서 멈추는 현상을 파악하셨습니까? 1.6.1에서 모든 변경 사항을 시도한 후에도 동일한 내용이 표시됩니다.

@gtirloni @srzjulio kubeadm init 다음에 이 단계를 추가해도 도움이 되지 않았습니다. kubelet 서비스가 failed 에서 active (running) 되었지만 여전히 The connection to the server localhost:8080 was refused - did you specify the right host or port? 메시지가 있습니다. 그리고 서비스 리스닝을 보면 8080은 어디에도 없습니다. 내가 볼 수 있는 것은 kubelet이 다음 포트에서 수신 대기하고 있다는 것입니다.

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

8080을 잘못 가리키는 잘못된(변경된?) 설정이 있습니까?

@bostone 필요한 kubelet 포트가 아니라 kube-apiserver이며 6443 포트에서 수신 대기해야 합니다.

@sbezverk 포트까지 기본값을 수정하지 않았습니다(지침에 없음) 8080에서 6443으로 전환하려면 어떻게 해야 합니까?

@bostone apiserver 매니페스트에서 아무 것도 수정하지 않은 경우 기본적으로 6443 포트에서 수신 대기합니다. /etc/kubernetes/admin.conf를 $HOME/.kube/config에 복사하고 구성 파일에 대한 권한을 변경하면 모든 설정이 완료됩니다.

@sbezverk BTW - 모든 설치 단계를 루트로 실행하고 있지만 kubeadm init 출력의 이 3개 명령줄은 sudo 사용자 사용을 제안합니다. 이에 대한 권장 사항은 무엇입니까? 모든 설치 단계를 sudo로도 실행해야 합니까?

좋아, 나는 처음부터 모든 단계를 수행했고 더 나은 것 같습니다. 다음은 지금까지 나를 위해 일한 단계이며 CentOS 7에서 루트로 실행 중입니다.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/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
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

10-kubeadm.conf에 -cgroup-driver=systemd 를 추가하고 저장합니다.

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

이 시점에서 kubectl get nodes 실행하고 목록에서 내 마스터 노드를 볼 수 있습니다.
제외 미니언의 모든 단계를 반복 kubeadm init 대신 실행 kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 에 의해 생성 된 kubeadm init
이 단계가 완료되고 마스터 및 미니언 노드를 볼 수 있습니다.

그리고 지금 - 문제:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

따라서 노드가 준비되지 않은 것처럼 보입니다. 어떤 제안?

나는 당신이
1.6 이전 yaml 파일.

"kubectl apply -f https://git.io/weave-kube-1.6 "을 시도

2017년 4월 4일 화요일 오후 12시 24분에 Bo Stone [email protected]에서 다음과 같이 썼습니다.

좋아, 나는 처음부터 모든 단계를 수행했고 더 나은 것 같습니다. 여기 있습니다
지금까지 나를 위해 일한 단계이며 루트로 실행 중입니다.

고양이 <

[쿠버네티스]
이름=쿠버네티스
baseurl= http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
활성화 = 1
gpgcheck=1
repo_gpgcheck=1
gpgkey= https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

세텐포스 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

10-kubeadm.conf에 -cgroup-driver=systemd를 추가하고 저장합니다.

systemctl 도커 활성화 && systemctl 도커 시작

systemctl kubelet 활성화 && systemctl kubelet 시작

sysctl -w net.bridge.bridge-nf-call-iptables=1

systemctl 방화벽을 중지합니다. systemctl 방화벽 비활성화

kubeadm 초기화

cp /etc/kubernetes/admin.conf $HOME/

chown $(id -u):$(id -g) $HOME/admin.conf

내보내기 KUBECONFIG=$HOME/admin.conf

kubectl 적용 -f https://git.io/weave-kube

이 시점에서 kubectl get nodes를 실행하고 내 마스터 노드를 볼 수 있습니다.
목록.
kubeadm 조인을 실행하는 과정을 제외하고 미니언에 대해 모든 단계를 반복합니다.
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 kubeadm에 의해 생성됨
초기화
이 단계가 완료되고 마스터 및 미니언 노드를 볼 수 있습니다.

그리고 지금 - 문제:

kubectl 가져오기 노드

이름 상태 나이 버전
abc02918 준비 안 됨 42m v1.6.1
abc04576 준비 안 됨 29m v1.6.1

kubectl은 노드 abc02918을 설명합니다.

이벤트:
SubObjectPath 유형 이유 메시지의 FirstSeen LastSeen 개수
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet, sdl02918 정상 시작 kubelet 시작 중.
43m 43m 1 kubelet, sdl02918 경고 ImageGCFailed 컨테이너에 대한 데이터를 찾을 수 없음/
43m 43m 29 kubelet, sdl02918 일반 NodeHasSufficientDisk 노드 sdl02918 상태는 현재 NodeHasSufficientDisk입니다.
43m 43m 29 kubelet, sdl02918 일반 NodeHasSufficientMemory 노드 sdl02918 상태는 현재 NodeHasSufficientMemory입니다.
43m 43m 29 kubelet, sdl02918 정상 NodeHasNoDiskPressure 노드 sdl02918 상태는 현재 NodeHasNoDiskPressure입니다.
42m 42m 1 kube-proxy, sdl02918 정상 시작 kube-proxy 시작 중.

따라서 노드가 준비되지 않은 것처럼 보입니다. 어떤 제안?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

CentOS 및 kubeadm 1.6.1-1 버전을 사용하고 위의 단계를 수행하면 약간 다른 동작이 나타납니다. 클러스터가 준비된 것으로 보고되지만 다음 메시지에서 멈춥니다.

[apiclient] Temporarily unable to list nodes (will retry)

그러나 로그에는 여전히 동일한 오류가 있습니다.

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning 그렇군요 ! 모든 것이 작동하는지 확인하기 위해 일부 이미지를 배포해야 하지만 Ready 상태의 모든 노드를 볼 수 있습니다! 여러분 감사합니다 (지금은)

@bostone 나는 당신이 사용한 것과 동일한 레시피를 따랐지만 다른 결과를 얻었습니다. 나는 kubeadm init를 지나치지 못했습니다. 어떤 도커 버전을 사용하고 있습니까? 아마도 그것이 내 경우의 차이점입니까?

@dcowden 내 시스템 Docker version 1.12.6, build 96d83a5/1.12.6 에서 yum이 선택하는 모든 것입니다. 또한 이전 설치를 수정하는 대신 사용하던 모든 VM을 다시 프로비저닝하는 데 도움이 되었습니다.

@보스톤 감사합니다. 작동 설정을 얻을 수 있는지 확인하기 위해 해당 버전으로 다운그레이드하겠습니다. 내 시스템에서 최신 버전은 이상한 17.03.1.ce 버전입니다(분명히 가장 최신 버전임)

일반적으로 유용한지 확실하지 않지만 다음과 같은 가능한 플레이북이 있습니다.
CentOS 7의 모든 단계를 수행합니다.

https://github.com/sjenning/kubeadm-playbook

YMMV이지만 최소한 프로세스를 문서화합니다. 나는 또한 몇 가지 일을
json 파일 로깅 및 오버레이 스토리지를 사용하도록 도커를 전환합니다.

실제로 플레이북을 실행하지 않더라도 참고용으로 유용할 수 있습니다.

2017년 4월 4일 화요일 오후 12:55 Dave Cowden [email protected]
썼다:

@bostone https://github.com/bostone 감사합니다. 나는 그것으로 다운 그레이드 할 것이다
내가 작동 설정을 얻을 수 있는지 확인하는 버전. 내 시스템에서 최신은
이상한 17.03.1.ce 버전(분명히 가장 최신 버전임)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning 감사합니다! 매우 도움이 됩니다!

자, 여기에 하나의 합병증이 있습니다. master 및 minion에서 kubeadm reset 를 실행하고 docker 및 kubelet 서비스를 다시 시작한 후 kubeadm init 가 다시 Created API client, waiting for the control plane to become ready 에 중단됩니다. 누군가 kubeadm 재설정을 위한 완전한 단계를 제공할 수 있습니까?
@sjenning 플레이북을 처음 실행한 후 다시 실행해

내 경우에는 @bostone /var/lib/etcd/ 이동하는 것이 트릭을 수행했습니다.

@autostatic 디렉토리가 비어 있었고 이름을 @sjenning you playbook 중단, 내가 당신을 위해 티켓을 만들었습니다

v1.6.1에서 대시보드 실행을 시도한 사람이 있습니까? 다음을 나타내는 오류가 발생합니다.

'금지(403)

사용자 " system:serviceaccount :kube- system:default "는 클러스터 범위에서 네임스페이스를 나열할 수 없습니다. (네임스페이스 가져오기)
`

Flannel을 실행하기 위해 필요한 것처럼 더 많은 RBAC를 구성해야 한다고 생각하십니까?

@srzjulio 이에 대한 새로운 문제를

@srzjulio RBAC 규칙을 업데이트해야 합니다. 다음을 사용하여 진행했습니다.

API 버전: rbac.authorization.k8s.io/v1alpha1
종류: ClusterRoleBinding
메타데이터:
이름: 클러스터 관리자
역할 참조:
API 그룹: rbac.authorization.k8s.io
종류: ClusterRole
이름: 클러스터 관리자
과목:

• 종류: 그룹
  이름: 시스템:마스터
• 종류: 그룹
  이름: 시스템:인증됨
• 종류: 그룹
  이름: 시스템:인증되지 않음

주의 -- @sbezverk 가 가지고 있는 바인딩은 본질적으로 RBAC를 끕니다. 그렇게하면 매우 안전하지 않은 클러스터가 생깁니다.

kind: Group
name: system:unauthenticated

이것은 특히 나쁩니다. 이는 자격 증명 없이도 API 서버에 접속할 수 있는 모든 사람이 임의의 명령을 실행할 수 있음을 의미합니다.

@jbeda 그것은 1.5.6에서 바로 사용했던 동작과 일치합니다. 새로운 보안 규칙으로 아무것도 할 수 없는 대신 보안 구성을 검토하고 점진적으로 조정할 수 있는 기회를 사람들에게 제공합니다.

실제로 system:unauthenticated 를 클러스터 관리자로 만드는 것은 1.5.6보다 훨씬 나쁩니다.

권한 부여를 원하지 않으면 AlwaysAllow 권한 부여자를 사용하십시오.

감사하는 동안 모두를 허용하려면 RBAC,AlwaysAllow를 조합하여 사용하십시오.

그러면 익명 요청이 비활성화되고 API 서버 로그에 RBAC 거부가 기록되지만 인증된 모든 요청은 계속해서 원하는 작업을 수행할 수 있습니다.

죄송합니다. 다시 반복합니다. 이것은 원래 문제와 관련이 없습니다. 그리고 타당한 문제와 문제이기는 하지만 대화를 다른 곳으로 옮겨야 합니다.

다시 한 번 죄송합니다. 너무 빨리 Enter 키를 누르십시오. 그러나 상황은 다음과 같습니다.

1 - 릴리스 1.6.0으로 인해 문제가 발생함
2 - 모두 고정되지 않음
3 - RBAC로 이동(내 의견으로는 좋음)하지만 문제가 있습니다. 이유는 무엇입니까? 4번 항목 참조
4 - 이것은 잘 전달되지 않았으며 문서/블로그 또는 설명할 문서가 많지 않습니다.
5 - 나는 구조를 시도하는 모든 ppl에게 절하지만 우리는 이것을 하기 위한 더 나은 방법이 필요합니다

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions는 권한을 여는 데 사용할 수 있는 가장 작은 세부 옵션에 대한 좋은 가이드입니다.

kublet 에 "

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

native.cgroupdriver=systemd 가 docker 데몬에 설정되어 있음을 분명히 알 수 있습니다.

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng 도커를 1.12.6으로 업데이트하지 않는 이유는 무엇입니까? 이 버전에서는 매력처럼 작동합니다.

@sbezverk : 방금 1.12.5로 업데이트했고 이제 작동합니다! 감사합니다!

도움을 주셔서 감사합니다.
마지막으로 플란넬이 있는 k8s 1.6.1이 완전히 작동합니다. 이제 모든 것이 가능한 플레이북에 있습니다.
Centos/RHEL에서 테스트되었습니다. Debian 기반(예: Ubuntu)에 대한 준비도 시작되었지만 약간의 개선이 필요할 수 있습니다.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

추신: sjenning/kubeadm-playbook 기반 작업 - @sjenning에 감사

@sjenning @ReSearchITEng
안녕하세요, 귀하가 만든 것과 매우 유사한 vagrant+ansible 플레이북 [0]이 있지만 네트워킹 설정에서 실패하고 있기 때문에 여전히 작동시킬 수 없습니다. 나는 옥양목, 직조 및 플란넬로 시도했지만 세 가지 모두 실패했습니다(다른 증상이 있음에도 불구하고).

다음 버전을 실행하고 있습니다.
[ vagrant@master ~]$ docker --version
Docker 버전 1.12.6, 빌드 3a094bd/1.12.6
[ vagrant @master ~]$ kubelet --version
쿠버네티스 v1.6.1
[ vagrant @master ~]$ kubeadm 버전
kubeadm 버전: version.Info{주요:"1", 부:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:-"clean"20, BuildDate:2 27Z", GoVersion:"go1.7.5", 컴파일러:"gc", 플랫폼:"linux/amd64"}

오류:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

이것은 핵심 정보처럼 보이지만 어떻게 수정해야 할지 잘 모르겠습니다.

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

어떤 도움이라도 대단히 감사하겠습니다 ...

[0]- https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

나는 당신의 문제가 무엇인지 확인할 수 없습니다.
https://github.com/ReSearchITEng/kubeadm-playbook 에서 플레이북을 사용하여 별도의 설치를 만들고 차이점이 무엇인지 확인하는 것이 좋습니다.
추신: 내 마지막 테스트는 1.6.2 , kube* 및 이미지 모두에서 수행되었으며 괜찮은 것 같습니다.

@kelseyhightower

@ReSearchITEng 죄송합니다. 다시 보고하는 것을 잊었지만 결국 작동하게 되었습니다. 내 vagrant+ansible 파일은 여기에 있습니다: https://github.com/thiagodasilva/kubernetes-swift

나도 같은 문제가 발생했지만 마스터 노드의 cni 구성을 작업자 노드의 해당 위치에 복사하면 OK가되었습니다.

systemctl 상태 kubelet.service -l

● kubelet.service - kubelet: Kubernetes 노드 에이전트
로드됨: 로드됨(/etc/systemd/system/kubelet.service; 활성화됨, 공급업체 사전 설정: 비활성화됨)
드롭인: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
활성: 활성(실행 중) 이후 화요일 2017-06-06 10:42:00 CST; 18분 전
문서: http://kubernetes.io/docs/
메인 PID: 4414(kubelet)
메모리: 43.0M
C그룹: /system.slice/kubelet.service
├─4414 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --network-plugin=cni - -cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --권한 부여 -ca-file=/etc/kubernetes/pki/ca.crt --cgroup-driver=cgroupfs
└─4493 저널ctl -k -f

Jun 06 10:59:46 contiv1.com kubelet[4414]: W0606 10:59:46.215827 4414 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Jun 06 10:59:46 contiv1.com kubelet[4414]: E0606 10:59:46.215972 4414 kubelet.go:2067] Container runtime network not ready: NetworkReady=false ready message:docker : 네트워크 플러그인이 준비되지 않음: cni 초기화되지 않은
Jun 06 10:59:51 contiv1.com kubelet[4414]: W0606 10:59:51.216843 4414 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Jun 06 10:59:51 contiv1.com kubelet[4414]: E0606 10:59:51.216942 4414 kubelet.go:2067] Container runtime network not ready: NetworkReady=false ready message:docker : 네트워크 플러그인이 준비되지 않음: cni 초기화되지 않은
Jun 06 10:59:56 contiv1.com kubelet[4414]: W0606 10:59:56.217923 4414 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Jun 06 10:59:56 contiv1.com kubelet[4414]: E0606 10:59:56.218113 4414 kubelet.go:2067] Container runtime network not ready: NetworkReady=false ready message:docker : 네트워크 플러그인이 준비되지 않음: cni 초기화되지 않은
Jun 06 11:00:01 contiv1.com kubelet[4414]: W0606 11:00:01.219251 4414 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Jun 06 11:00:01 contiv1.com kubelet[4414]: E0606 11:00:01.219382 4414 kubelet.go:2067] Container runtime network not ready: NetworkReady=false ready message:docker : 네트워크 플러그인이 준비되지 않음: cni 초기화되지 않은
Jun 06 11:00:06 contiv1.com kubelet[4414]: W0606 11:00:06.220396 4414 cni.go:157] cni 구성을 업데이트할 수 없음: /etc/cni/net.d에서 네트워크를 찾을 수 없음
Jun 06 11:00:06 contiv1.com kubelet[4414]: E0606 11:00:06.220575 4414 kubelet.go:2067] Container runtime network not ready: NetworkReady=false ready message:docker : 네트워크 플러그인이 준비되지 않음: cni 초기화되지 않은

모든 노드의 상태:
[ root@swarm net.d]# kubectl 노드 가져오기
이름 상태 나이 버전
contiv1.com 준비 1시간 v1.6.4
contiv2.com 준비 1시간 v1.6.4
swarm.com 준비 1h v1.6.4

이것에 대한 어떤 해결책? 언급 된 모든 해결 방법을 시도한 후에도이 작업을 수행 할 수 없었습니다.

Kubernetes 설정이 처음이어서 매우 혼란스럽습니다. 네트워크에 weave-kube를 사용하는 https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929를 시도했지만 동일한 문제가 발생했습니다. . 이 문제를 해결할 수 있는 방법이 있습니까?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

이것이 여전히 문제인 이유는 무엇입니까? Ubuntu 16.04/CentOS 7.3(최신 업데이트 포함) 1.6.4의 공식 k8s 저장소를 사용하고 여기에 설명된 단계를 따릅니다. https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen 아니요, 이는 _v1.6.0_에만 영향을

kubectl apply -f https://git.io/weave-kube-1.6

Weave Net을 설치하면 이러한 문제가 사라집니다. Flannel, Calico, Canal 또는 원하는 경우 CNI 네트워크를 설치하도록 선택할 수 있습니다.

@luxas 이것에 대한 참조가 계속 표시되지만 실행되지 않는 클러스터에 무언가를 적용하려면 어떻게 해야 합니까? 연결할 것이 없습니다.

@drajen @luxas ' 요점은 이것이 설정에 대해 묻는 잘못된 장소라는 것입니다.
다양한 설정 가이드는 모든 것이 제대로 작동하기 시작하기 전에 네트워크 구성을 적용해야 한다는 점에서 luxas가 유용하게 언급한 이전 가이드에서 일반적으로 누락된 단계인 이 시점을 지나게 할 것입니다.

예, 분명하지 않을 수 있으며 죄송합니다. 하지만 거기에 하나의 공급자 이름도 가질 수 없습니다.

Slack에서 @drajen 과 채팅했고 문제는 cgroup과 관련이 있었고 kubelet은 비정상적이었고 Pod를 생성할 수 없었으므로 문제입니다.

내 특정 문제를 해결해 준 @luxas 에게 감사드립니다: https://github.com/kubernetes/kubeadm/issues/302

여전히 1.7의 아치에서 이것을 치고 있습니다. 어디에서나 빠른 수정이 있습니까?

편집하다:

kubectl apply -f https://git.io/weave-kube-1.6

트릭을 수행했습니다. CNI 실행이 필요한 것처럼 보입니다.

적어도 CentOS/RHEL의 경우 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf를 업데이트하고 --cgroup-driver="systemd" 플래그를 추가해야 합니다.

동일한 컴퓨터에 다시 설치하면 다음과 같이 완전히 올바르게 재설정됩니다.
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(이것은 특히 플란넬을 사용하는 경우 필요합니다)
모든 것을 하나로 하고 싶다면 전체 프로젝트를 사용하는 것이 좋습니다: https://github.com/ReSearchITEng/kubeadm-playbook/

나는이 문제에 부딪쳤고 위에서 읽은 것은 전혀 효과가 없었습니다. 그래서 우분투에서 최신 CoreOS로 전환하고, 이전 버전의 k8s로 시작하고, 일반적으로 각 VM에 설치된 모든 마지막 항목에 대해 매우 분석적인 설정으로 훨씬 더 제어된 설정으로 다시 시도했습니다. 나는 kubeadm을 사용하지 않고 대신 vagrant와 asible의 조합을 사용합니다.

(왜? 나는 kubeadm에서 무슨 일이 일어나고 있는지 전혀 몰랐고, 최소한 내가 제어할 수 있고 지나치게 열성적인 실행 전 검사를 우회할 수 있을 것이라고 생각했기 때문에 일반적으로 더 많은 자동화 제어가 있다는 느낌은 말할 것도 없고, 또한 do-not-apply-alpha-software-in-production에 대한 경고에 대해 걱정할 필요가 없습니다.)

이전(1.4.3) 버전의 k8에서 이 설정을 시도했을 때 이 접근 방식은 완벽했습니다. 그런 다음 1.71로 업그레이드를 시도했습니다. 다시 한 번, kubeadm을 전혀 사용하지 않음에도 불구하고 여전히 동일한 문제를 겪고 있습니다.

마스터와 세 명의 잠재적 작업자를 포함하여 각 노드에서 옥양목을 실행하고 있음을 확인했습니다. 내 모든 노드가 NotReady로 보고되고 있으므로 weave(또는 다른 무엇이든)를 적용하여 실행할 수 있는지 잘 모르겠습니다.

이 모든 것은 치킨/달걀처럼 보입니다... 네트워킹이 실패했기 때문에 포드를 할당할 수 없지만 포드를 할당할 수 있으려면 /etc/cni/net.d에서 네트워크를 생성하기 위해 네트워킹이 실행되고 있어야 합니다. 그리고 다시, 이 모든 것이 몇 시간 전에 k8s 1.4.3에서 작동했습니다. 나는 매우 실망!

누구든지 제공할 수 있는 통찰력에 감사드립니다.

각주:

마스터에서: journalctl -r -u kubelet이 나에게 제공합니다.

Jul 24 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: E0724 00:48:16.592274 7647 kubelet.go:2136] 컨테이너 런타임 네트워크가 준비되지 않음: NetworkReady=false 메시지 가 준비되지 않음 :NetworkPlugin: Ready message: NetworkPlugin 네트워크 플러그인이 없습니다
Jul 24 00:48:16 rogue-kube-master-01 kubelet-wrapper[7647]: W0724 00:48:16.590588 7647 cni.go:189] cni 구성을 업데이트할 수 없음: /etc/cni/net에서 네트워크를 찾을 수 없음 .NS

도커 추신 | 그렙 옥양목

(가독성을 위해 잘림)
CDE ... quay.io/calico/의 선두 주자 - 선거인 @ SHA256 ... "/run.sh --election = C"8시간까지 전 8시간
f72... calico/ kube-policy-controller@sha256 :... "/dist/controller" 8시간 전 Up 8시간
c47... gcr.io/google_containers/pause-amd64:3.0 "/pause" 8시간 전 최대 8시간

/etc/cni/net.d가 없습니다.

내 kubectl 상자에서:
kubectl 가져오기 노드
10.0.0.111 준비 안 됨, 예약 비활성화됨 8h v1.7.1+coreos.0
10.0.0.121 준비 안 됨 8h v1.7.1+coreos.0
10.0.0.122 준비 안 됨 8h v1.7.1+coreos.0
10.0.0.123 준비 안 됨 8h v1.7.1+coreos.0

kubectl 적용 -f https://git.io/weave-kube-1.6

아무것도 수정하지 않았으며 실제로는 더 많은 문제만 발생시키는 것 같습니다.

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl 적용 -f https://git.io/weave-kube-1.6
serviceaccount "wea-net" 생성됨
clusterrolebinding "weave-net" 생성됨
데몬셋 "weave-net" 생성
서버 오류(금지됨): clusterroles.rbac.authorization.k8s.io "weave-net"이 금지됨: 추가 권한 부여 시도: [PolicyRule{Resources:["pods"], APIGroups:[""], 동사: ["get"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["pods"], APIGroups:[""], Verbs: ["watch"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["get"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs: ["list"]} PolicyRule{Resources:["namespaces"], APIGroups:[""], Verbs:["watch"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs: ["get"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs:["list"]} PolicyRule{Resources:["nodes"], APIGroups:[""], Verbs: ["watch"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], Verbs:["get"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], 동사:["list"]} PolicyRule{Resources:["networkpolicies"], APIGroups:["extensions"], 동사:["watch"]}] user=&{kube-admin [시스템:a 인증됨] 지도[]} ownerrules=[] 규칙ResolutionErrors=[]

bill@rogue :~/vagrant_rogue/rogue-cluster$ kubectl 포드 가져오기 --namespace=kube-system
이름 준비 상태 다시 시작 연령
kube-apiserver-10.0.0.111 1/1 1 8시간 실행
kube-controller-manager-10.0.0.111 1/1 1 8시간 실행
kube-dns-v20-fcl01 0/3 보류 중 0 8h
kube-proxy-10.0.0.111 1/1 실행 1 8시간
kube-proxy-10.0.0.121 1/1 실행 1 8시간
kube-proxy-10.0.0.122 1/1 실행 1 8시간
kube-proxy-10.0.0.123 1/1 실행 1 8시간
kube-scheduler-10.0.0.111 1/1 실행 1 8시간
kubernetes-dashboard-v1.4.1-29zzk 0/1 보류 중 0 8h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 실행 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

weave 오류에 대한 심층 조사는 (a) apiserver에 연결할 수 없거나 (b) "실행 중"으로 표시된 오류가 자체에 연결할 수 없다고 불평하고 있음을 나타냅니다.

@billmilligan 유사한 문제가 있는 경우 컨테이너가 시작된 후 몇 분 안에 DNS가 작동을 멈춥니다.

@Paxa @billmilligan 도움을 받고 싶다면 이 문제에 대해 언급하지 마십시오. 대신, 요청된 충분한 세부 정보와 함께 kubeadm 저장소에서 새 저장소를 여십시오.

@luxas 감사 kubeadm와 함께 점점로 kubeadm없이 K8S을 설정하는 동일한 결과를 얻고 있기 때문에,이 문제의 원인으로 kubeadm을 제거하는 것 같다. 아마도 이 문제의 이름을 적절하게 변경해야 합니까?

@billmilligan 정중하게, 문제는 kubeadm에 관한 것이고 kubeadm 없이 재생산할 수 있다면 파일을 제출하는 장소가 잘못된 건가요? 이 스레드가 kubeadm 문제를 해결했다고 생각합니다. 이것은 새로운 문제입니다. 새로운 이슈로 주목을 받을 것 같아요. 이 스레드의 사람들은 이미 해결되었다고 생각하고 무시하고 있습니다.

나는 kubeadm을 사용하고 이 문제의 영향을 받았고 1.6.1부터 해결되었습니다. 나는 그 이후로 k8의 분실물을 배치했기 때문에 당신에게 별도의 문제가 있다고 생각합니다.

@kfox1111 피드백 감사합니다. 나는 새로운 문제를 제기할 것이지만, 여전히 1.7.x의 다른 곳에서 그것을 직면하고 있는 것처럼 보이는 사람들의 수는 여전히 나를 의아하게 만든다.

TL;DR;

오류 메시지

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

반드시 나쁜 것은 아닙니다 .

해당 오류 메시지는 타사 CNI 사양 구현 공급자 에 플러그인해야 함을 알려줍니다.

CNI란 무엇이며 Kubernetes와 어떻게 통합됩니까?

CNI는 Container Network Interface의 약자이며 kubelet이 클러스터용 네트워크를 생성하기 위해 사용 하는 사양 을 이 페이지 를 참조하십시오.

Kubernetes 는 CNI 사양을 충족 하는 한 네트워크가 생성되는 방식을 신경 쓰지 않습니다 .

kubelet 는 새 Pod를 네트워크 에
kubelet 는 CNI 네트워크가 사용할 구성 디렉토리(종종 /etc/cni/net.d )를 읽습니다.
새 파드가 생성되면 kubelet은 구성 디렉토리에 있는 파일을 읽고 exec 는 구성 파일에 지정된 CNI 바이너리(바이너리는 /opt/cni/bin 경우가 많음)로 출력합니다. 실행될 바이너리는 제3자(예: Weave, Flannel, Calico 등)에 속하며 설치됩니다.

kubeadm 는 Kubernetes 클러스터를 스핀업하는 일반적인 도구 이며 원하는 네트워킹 솔루션을 알지 못하며 특정 사용자를 선호하지 않습니다. kubeadm init 가 실행된 후에 는 이러한 CNI 바이너리나 구성이 없습니다 . 이것은 kubeadm init 가 완전히 작동하는 클러스터를 시작하고 실행하기에 충분하지 않음을 의미합니다.

즉, kubeadm init 다음에 kubelet 로그가 다음과 같이 표시됩니다.

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

이것은 매우 기대됩니다. 그렇지 않았다면 우리는 특정 네트워크 제공자를 선호했을 것입니다.

그렇다면 이 오류를 어떻게 "수정"합니까?
kubeadm 시작하기 가이드의 다음 단계는 "Pod 네트워크 설치"입니다.
즉, 선호하는 CNI 네트워크 공급자의 kubectl apply 매니페스트입니다.

DaemonSet은 /opt/cni/bin 필요한 CNI 바이너리와 /etc/cni/net.d/ 필요한 구성을 복사합니다. 또한 노드 간에 네트워크를 설정하는 실제 데몬을 실행합니다(예: iptables 규칙 작성).

CNI 공급자가 설치된 후 kubelet은 "오 네트워크 설정 방법에 대한 정보가 있습니다"라는 메시지를 표시하고 타사 구성 및 바이너리를 사용합니다.

그리고 네트워크가 제3자 제공자에 의해 설정되면(kubelet이 이를 호출하여) 노드는 스스로를 Ready 합니다.

이 문제는 kubeadm과 어떤 관련이 있습니까?

v1.6 주기 후반에 kubelet이 Ready/NotReady 상태를 보고하는 방식을 변경한 PR이 병합되었습니다. 이전 릴리스에서 kubelet 는 CNI 네트워크 설정 여부에 관계없이 항상 Ready 상태를 보고했습니다. 이것은 실제로 일종의 잘못된 것이며 CNI 네트워크 상태를 존중하도록 변경되었습니다. 즉, NotReady CNI가 초기화되지 않은 때와 Ready 초기화 할 때.

v1.6.0의 kubeadm은 나머지 kubeadm init 작업을 진행하기 전에 마스터 노드가 Ready 상태가 될 때까지 잘못 기다렸습니다. CNI가 초기화되지 않았을 때 kubelet 동작이 NotReady 를 보고하도록 변경되면 kubeadm은 노드가 Ready 를 받을 때까지 영원히 기다립니다.

KUBEADM 측에서 잘못된 개념을 기다리는 것은 이 문제에 대한 것입니다.

그러나 v1.6.1에서 회귀를 빠르게 수정하고 v1.6.0 이후 며칠 후에 출시했습니다.

이에 대한 자세한 내용과 이 결함이 포함된 v1.6.0이 출시될 수 있는 이유에 대해서는 회고전 을 읽으십시오.

그렇다면 kubeadm v1.6.1+에서 이 문제를 발견했다면 어떻게 하시겠습니까?

글쎄요, 당신은 그렇지 않다고 생각합니다. 이 문제는 kubeadm init 가 교착 상태에 있는 경우에 관한 것입니다.
v1.6.1+에서 이를 본 사용자나 유지 관리자는 없습니다.

당신이 비록 볼 것은

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

v1.6 이상의 모든 버전 에서 kubeadm init 뒤에 있지만 나쁘지 않습니다.

어쨌든 kubeadm에서 예상치 못한 것을 발견하면 새로운 이슈를 열어주세요.

이 문제에 대해 더 이상 언급하지 마십시오. 대신 새 것을 여십시오.

@billmilligan 따라서 클러스터를 시작하고 실행하려면 CNI 공급자의 매니페스트 kubectl apply 만 있으면 됩니다.

나는 위에서 말한 것을 거의 요약하고 있지만 더 명확하고 자세한 방법을 바랍니다.
CNI 작동 방식에 대해 궁금한 점이 있으면 StackOverflow, 문제 또는 Slack과 같은 일반 지원 채널을 참조하십시오.

(마지막으로 너무 굵게 써서 죄송합니다만, 사람들의 관심을 끌기 위해서는 필요하다고 느꼈습니다.)