Kubeadm: livenessprobe가 너무 공격적이기 때문에 apiserver가 시작되지 않습니다.

현재 컨트롤 플레인 포드에 대해 InitialDelaySeconds 및 TimeoutSeconds 를 모두 15로 설정 한 것 같습니다. 이는 kube-up.sh 도 마찬가지입니다. 모든 이미지를 한꺼번에 가져 오는 초기 시작이 느리다는 것을 알고 있지만 모든 이미지를 가져온 후 apiserver가 시작된 후 /healthz 검사에 응답하는 데 얼마나 걸리나요?

저전력 기계를 수용하기 위해이 두 값을 모두 조정해야 할 것입니다.

일단 시작되면 15 초 미만의 상태 확인에 응답 할 수 있습니다. 실제로 apiserver가 exec ()와 실제로 afaics 서비스를 제공 할 준비가 된 사이에 수행하는 모든 추가 작업입니다.

오, 그리고 도커 풀 타임은 InitialDelaySeconds afaics (좋음)에 포함되지 않습니다. 저속 네트워크 링크를 통해 더 큰 (일반 우분투) 이미지가있는 다른 예에서 가져 오기에 몇 분이 걸릴

나는 같은 문제를 겪고 있습니다. 느린 기계로 kubeadm 는 영원히 앉아 있습니다. v1.7.4 사용

@anguslees 및 @koalalorenzo , 수동으로 활성 프로브 설정을 변경하면 ( /etc/kubernetes/manifests/ 에서 매니페스트 파일을 편집하여) 문제가 해결되는지 확인할 수 있습니까? 또한 최근에 Slack에서 사용자가 동일한 증상을 보이지만 메모리가 더 많은 호스트 유형으로 이동할 때 문제가 해결 되었기 때문에 메모리 제약에 부딪 힐 가능성이있는 사례를 보았습니다.

코딩에 시간을 투자하기 전에이 접근 방식이 문제를 실제로 해결할 수 있는지 확인하고 싶습니다. 감사!

하드웨어 지원 가상화없이 QEMU에서 kubeadm을 사용하려고 할 때도이 문제가 발생합니다 (매우 느리기 때문에 나쁜 생각입니다). InitialDelaySeconds 및 TimeoutSeconds를 늘리면 도움이됩니다. 그러면 결국 클러스터가 나타납니다.

@pipejakob kubeadm 실행의 올바른 지점에서 다른 터미널에서 이것을 (내 bananapi에서) 실행하면 모든 것이 성공적으로 작동하는지 확인할 수 있습니다.

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(보통 수동으로 docker kill old / restart-looping apiserver 컨테이너, 정적 포드로 자동 정리되는지 확실하지 않습니다)

트윗 담아 가기 확인 해주셔서 감사합니다.

제 경우에는 라즈베리 파이 3에서이 문제가 발생했음을 확인할 수 있습니다. 180으로 변경하면 문제가 해결되었지만 제 경우에는 단순히 다음과 같이 사망 한 것처럼 문제 # 106도 발생했다고 생각합니다.

9 월 1 일 10:47:30 raspberrypi kubelet [6053] : W0901 10 : 47 : 30.020409 6053 kubelet.go : 1596] 미러 포드 "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1) 삭제 중
1e7-ae86-b827ebdd4b52) "가 오래 되었기 때문입니다.

kubelet 프로세스를 수동으로 HUP하여 다시 살아야했습니다.

나는 또한 이것을 가지고 있음을 확인할 수 있으며 제 정신을 구해 주셔서 감사합니다. 나는 Raspberry Pi 2B를 가지고 있으며 지난달 동안 init 단계에 머물 렀습니다. 제어 플레인을 기다리기 시작하면 한 줄짜리 라이너를 실행 한 후 앞으로 나아갔습니다.

이 문제는 kubeadm v1.8.0에 여전히 존재하며 kubeadm 자체가 이제 대부분의 작업에 대해 1 분 시간 초과가 있기 때문에 더 심각합니다. 1 분 제한 시간은 임의로 선택한 것으로 보이며, 안타깝게도 a) 문제를 해결하고 디버그 / 해결할 충분한 시간이 없습니다 (예 : sed hack), b) apiserver가 시작될 충분한 시간 (~ 나를 위해 90s), initialDelaySeconds가 확장 된 경우 에도 c) kubeadm afaics를 해킹 / 재 구축하지 않고는 늘릴 수 없습니다.

시간 초과는 특히 복잡한 최종 일관성 시스템에서 올바른 논리를 깨뜨립니다. "단지"때문에 추가해서는 안됩니다. kubeadm 은 (는) 더 큰 배포 시스템이 의존 할 수있는 빌딩 블록이라는 것을 이해합니다. 따라서 kubeadm 자체에서 모든 시간 제한을 제거 할 것을 대담하게 제안하고 (다양한 단계는 계속해서 계속 재 시도해야 함) 상위 수준의 컨텍스트에서 적절한 경우 전체 시간 제한을 추가하기 위해 상위 수준 프로세스에 의존합니다. 단순 / 직접 사용 사례에서는 다음과 같습니다. "사용자가 포기하고 ^ c를 누를 때까지 재시도"를 의미합니다. 그런 PR이 허용됩니까?

@anguslees 우리는 이전에 "영원히 기다림"행동을했습니다. 하지만 그것은 UX PoV에서 매우 차선책 이었기 때문에 이제 타임 아웃이 있습니다. 원하는 경우 이러한 제한 시간 중 일부를 늘릴 수 있습니다.

문제는 kubeadm의 사용이 두 배라는 것입니다. 우리 둘 다 사용자가 kubeadm을 대화 형으로 입력하여 어떤 일이 일어나고 있는지 또는 상위 수준의 소비자가 아닌지 알고 싶어합니다.

.. 그래서 우리는 여기에 어떤 방향으로 갈까요? 현재 저는 10 배 많은 시간 제한이있는 kubeadm 포크를 사용하고 있으며, 언젠가는 표준 kubeadm 바이너리를 다시 사용할 수 있다고 믿고 싶습니다 _.

@anguslees 우리는 이전에 "영원히 기다림"행동을했습니다. 하지만 그것은 UX PoV에서 매우 차선책 이었기 때문에 이제 타임 아웃이 있습니다. 원하는 경우 이러한 제한 시간 중 일부를 늘릴 수 있습니다.

구성 가능하게 만드는 것은 어떻습니까? 모두를 소유하는 단일 옵션을 갖는 것이 합리적입니까?

/ 곧 중요

모두를 소유하는 단일 옵션을 갖는 것이 합리적입니까?

아마도, 또는 모든 시간 제한에 대해 어떤 종류의 "가중치"가 곱해질 수 있습니다. 그렇지 않으면 20 가지 다른 유형의 시간 제한 플래그로 구성 지옥에 들어갈 것입니다. :)

raspberry pi 2 클러스터에서 kubeadm 업그레이드를 사용하여 동일한 문제가 발생합니다. 과도한 시간 초과로 인해 업그레이드가 실패합니다. 매니페스트에서 활성 상태 프로브 설정을 변경해도 도움이되지 않습니다. 어떤 아이디어?

저는 kubeadm 코드베이스의 하위 수준에 임의의 시간 초과를 적용하는 대신 kubeadm 시간 초과가 호출 컨텍스트 (또는보다 정교한 오류 복구 전략의 일부)에서 상속되는 패턴을 제안합니다.

가장 간단한 형태로 이것은 kubeadm에서 모든 시간 초과를 제거하고 전체 "xx 분 동안 실행 한 다음 완료되지 않으면 중단"전역 타이머로 대체하는 것과 거의 똑같이 작동합니다 (kubeadm은 오류를 많이 처리 할 수 ​​없기 때문입니다). 더 오래 기다리는 것 이외의 회복).

원래 매니페스트 livenessProbe 시간 제한의 경우 말 그대로 한 줄짜리 패치입니다. 불행히도 "정상 == 오류로부터의 편차"오류가 kubeadm 코드베이스 전체에 더 퍼 졌기 때문에 livenessProbe 만 수정하는 것만으로는 더 이상 충분하지 않습니다. 문화적 인식을 바꾸는 것은 어렵 기 때문에 누군가가 라즈베리 파이에 설치하고 싶다면 그 동안 kubeadm의 포크 버전이 있습니다 . ( make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm 빌드)

@anguslees 패치 된 kubeadm의 컴파일 된 1.9.4 버전이 있습니까? 패치 된 버전을 컴파일하는 데 문제가 있습니다.

kubeadm이 플래그 뒤에이 동작이 없다는 것에 놀랐습니다. 아마도 PR이 순서대로입니까?

/ 할당 @liztio

그래서 우리는 1.11에서 이것에 영향을 미칠 수있는 두 가지 문제를 수정했습니다.

1. 시작하기 전에 etcd 이미지를 준비하십시오.
2. 시작시 경쟁 조건 확인을 수정합니다.
   ...

이것이 rasberry pi-gear에서만 발생한다면 최소 공통 분모를 한정하는 방법이 필요합니다.

지원할 계획 인 가장 낮은 대상 플랫폼은 무엇입니까?

Raspberry Pi 2는 Kubernetes를 실행하려는 가장 낮은 플랫폼이라고 생각합니다. 비 하드웨어 지원 QEMU를 사용한 테스트 는 고려하기에는 너무 이국적입니다.

Pi가 느린 I / O로 인해 많은 어려움을 겪고 있다는 점을 고려할 때 모든 이미지를 미리 풀링하면 이미 많은 도움이되지만 실제 시간 초과를 확인하려면 실제 테스트가 필요합니다.

imo rasberry pi2는 지원하기에 너무 오래되었습니다. http://socialcompare.com/en/comparison/raspberrypi-models-comparison 은 2015 년에 나왔습니다.

>= 3 이 더 합리적으로 보입니다.

미리 잡아 당기는 이미지는 도움이되지 않습니다. livenessProbe 타이머는 이미지를 가져올 때까지 시작되지 않습니다 ( 위에서 지적

수정 사항은 initialDelaySeconds 시간 제한을 연장하는 것 입니다. kubeadm의 현재 시간 초과 값은 오류 감지가 아닌 빠른 UX 경험을 "강제"하기 위해 오용되고 있습니다.

편집 : 그리고 확실히 시작하는 데 시간이 오래 걸립니다. apiserver intialDelaySeconds 시간 제한 (및 kubeadm 자체에서 사용되는 다른 설치 전용 시간 제한)을 늘리면 제어 클러스터가 3xRPi2에서 잘 작동합니다. 나는 왜 우리가 이것에 대해 여전히 이야기하고 있는지 이해하지 못합니다 : /

1.9.3에 ARM64 클러스터가 있고 1.9.7로 성공적으로 업데이트되었지만 1.9.7에서 1.10.2로 업그레이드하는 데 시간 초과 문제가 발생했습니다.

나는 심지어 kubeadm을 편집하고 다시 컴파일하여 동일한 결과로 타임 아웃 (마지막 커밋 https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork와 같이)을 늘려 보았습니다.

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

kubeadm이 사용되고 apiserver가 시작된 경우 처음 시작할 때 포인트 측정을 시도 할 수 있습니다. 아마도 첫 번째 초기화에서 측정에 적용되는 시간 제한에 대해 나중 단계에서 구성을 변경할 수 있습니다. 또한 로그를 보는 healtz 검사에 의해 apiserver가 쫓겨 난다는 것을 알아 내기가 어렵습니다. 적어도 문제를 인식하기 위해 더 나은 로깅을 확보 할 수 있습니다. livenessprobe가 문제라는 것을 알아내는 데 꽤 오랜 시간이 걸렸습니다. 나는 내가 초보자라는 것을 언급해야하며, 적어도 kubeadm의 실패 출력에서 ​​언급하는 것이 도움이 될 것입니다.

RaspberryPi 3는 미리 가져온 이미지에서도이 문제를 보여줍니다. API 서버는 페이지를 제공 할 수있는 위치에 도달하는 데 2-3 분 정도 걸립니다.

지금은 kubeadm이 실행되는 동안 백그라운드에서 YAML 파일을 패치하고 있기 때문에이를 구성 할 수 있으면 좋을 것입니다.

@carlosedp 업그레이드 중에 내가하는 일은 apiserver가 부팅되는 동안 kubelet을 다운시키는 것입니다. 일종의 해키이지만 apiserver가 가동 될 때까지 상태 검사가 실행되지 않도록합니다.

하지만 솔직히 kubeadm upgrade 와 ARM은 내 경험상 그렇게 잘 작동하지 않습니다.

@brendandburns 1.9까지 완벽하게 작동했습니다. 딸꾹질없이 1.8 클러스터를 배포 한 다음 1.9로 두 번 업그레이드했습니다. 1.10에서이 문제를 일으키는 원인이 무엇인지 알 수 없습니다.

시간 제한이 1.11에서 5 분으로 변경되는 것을 확인했습니다 (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). 1.11을 사용해 보셨습니까?

휴가를 마치고 돌아온 후이 해킹을 시도해 볼 것입니다. 팁 고마워!

트윗 담아 가기
예, 1.11을 시도하여 시간 초과 증가가 해결되었는지 확인하십시오.

/ cc @ kubernetes / sig-cluster-lifecycle-bugs

야! 이 문제도 발생합니다.
흥미롭게도 Raspberry 3에서 클러스터 마스터를 처음부터 빌드 할 수 있지만 3+에서는 지속적으로 실패합니다.
어쨌든 현재 사용하고있는 버전 (https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/의 단계별 문서에 따라)은 다음과 같습니다.
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

다른 것들과 마찬가지로 apiserver 컨테이너는 결국 일어나지 만 kubeadm이 구제되기 전에는 일어나지 않아서 수동으로 픽업하기에는 너무 경험이 없기 때문에 나를 림보에 남겨 둡니다.

빠른 업데이트 : 실행 중
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
별도의 터미널에서 내 클러스터가 일어나도록 허용했습니다.

안녕하세요.
1.11을 테스트 해 주셔서 감사합니다.

다른 것들과 마찬가지로 apiserver 컨테이너는 결국 일어나지 만 kubeadm이 구제되기 전에는 일어나지 않아서 수동으로 픽업하기에는 너무 경험이 없기 때문에 나를 림보에 남겨 둡니다.

귀하의 경우 apiserver가 시작되는 데 얼마나 많은 시간이 소요됩니까?
이것을 구성 가능하게 만들어야 할 것 같습니다.

말하기는 어렵지만 1 분 정도라고 생각하지만 제대로 측정하는 방법을 모르겠습니다.

또한 이제 마스터가 작동 중이므로 다른 시간 초과 문제로 보이는 노드를 추가하지 못했습니다.
`[프리 플라이트] 프리 플라이트 검사 실행
[경고 RequiredIPVSKernelModulesAvailable] : 다음 필수 커널 모듈이로드되지 않았기 때문에 IPVS 프록시가 사용되지 않습니다. [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] 또는 내장 커널 ipvs 지원 없음 : map [ip_vs_rr : {} ip_vs_rr : {} ip_vs_rr : {} ip_vs_rr : nf_conntrack_ipv4 : {} ip_vs : {}]
다음 방법으로이 문제를 해결할 수 있습니다.

1. 누락 된 커널 모듈을로드하려면 'modprobe-'를 실행하십시오.
   
   
   
   1. 누락 된 내장 커널 ipvs 지원 제공
   
   

I0708 19 : 02 : 20.256325 8667 kernel_validator.go : 81] 커널 버전 확인 중
I0708 19 : 02 : 20.256846 8667 kernel_validator.go : 96] 커널 구성 유효성 검사
[경고 SystemVerification] : docker 버전이 가장 최근에 검증 된 버전보다 높습니다. Docker 버전 : 18.03.1-ce. 최대 검증 버전 : 17.03
[발견] API 서버 "192.168.2.2:6443"에 연결 시도 중
[검색] 클러스터 정보 검색 클라이언트 생성, " https://192.168.2.2 : 6443"에서 정보 요청
[발견] 고정 된 공개 키에 대해 TLS의 유효성을 검사하기 위해 " https://192.168.2.2 : 6443"에서 다시 정보 요청
[발견] 클러스터 정보 서명 및 콘텐츠가 유효하며 TLS 인증서가 고정 된 루트에 대해 유효성을 검사하며 API 서버 "192.168.2.2:6443"을 사용합니다.
[발견] API 서버 "192.168.2.2:6443"과 성공적으로 연결
[kubelet] kube-system 네임 스페이스의 "kubelet-config-1.11"ConfigMap에서 kubelet 구성 다운로드
[kubelet] "/var/lib/kubelet/config.yaml"파일에 kubelet 구성 쓰기
[kubelet] "/var/lib/kubelet/kubeadm-flags.env"파일에 플래그가있는 kubelet 환경 파일 작성
[프리 플라이트] kubelet 서비스 활성화
[tlsbootstrap] kubelet이 TLS 부트 스트랩을 수행하기를 기다리는 중 ...
[kubelet-check] kubelet이 실행되지 않거나 정상이 아닌 것 같습니다.
[kubelet-check] kubelet이 실행되지 않거나 정상이 아닌 것 같습니다.
[kubelet-check] kubelet이 실행되지 않거나 정상이 아닌 것 같습니다.
[kubelet-check] kubelet이 실행되지 않거나 정상이 아닌 것 같습니다.
[kubelet-check] kubelet이 실행되지 않거나 정상이 아닌 것 같습니다.
안타깝게도 오류가 발생했습니다.
조건을 기다리는 시간이 초과되었습니다.

이 오류의 원인은 다음과 같습니다.
-kubelet이 실행되고 있지 않습니다.
-어떤 방식 으로든 노드의 잘못된 구성으로 인해 kubelet이 비정상 상태입니다 (필요한 cgroup 비활성화 됨).

systemd-powered 시스템을 사용하는 경우 다음 명령을 사용하여 오류 문제를 해결할 수 있습니다.
- 'systemctl 상태 kubelet'
- 'journalctl -xeu kubelet'
조건을 기다리는 시간이 초과되었습니다 .`

이 시간 동안 단일 도커 컨테이너가 내 노드에 표시되지 않습니다.

[경고 필수 IPVSKernelModulesAvailable] :

주제에서 벗어난 것에 대해 여기서 이야기하고 있습니다.
https://github.com/kubernetes/kubeadm/issues/975

또한 이제 마스터가 작동 중이므로 다른 시간 초과 문제로 보이는 노드를 추가하지 못했습니다.
[kubelet-check] 'curl -sSL http : // localhost : 10248 / healthz'와 동일한 HTTP 호출이 다음 오류와 함께 실패했습니다. Get http : // localhost : 10248 / healthz : dial tcp [:: 1] : 10248 : connect : 연결이 거부되었습니다.

kubelet을 시작할 수 없습니다. kubelet 로그를 더 잘 살펴보십시오.

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

활성 프로브는 구성 가능해야하지만 kubeadm 구성에서이를 수행하는 가장 좋은 방법에 대해 이야기해야합니다.

나는 이것이 사용되는 값이라고 생각하므로 kubeadm을 직접 빌드하는 경우 다음을 사용해보십시오.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
그러나 이렇게하면 모든 컨트롤 플레인 구성 요소에 대한 시간 초과가 증가합니다.

편집 : Github에서 주석 형식을 올바르게 지정하기에는 너무 어리석은 것 같습니다.

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

이 로그에는 오류가 표시되지 않습니다.

예,하지만 그것이 제가 믿는 문제의 일부입니다. 처음에 [ERROR]라는 단 하나의 결론을 찾을 수 없습니다. 그것이 나를 너무 실망시키는 것입니다 :-)

어쨌든, 내 엉망진창을 포맷 해주셔서 감사합니다 :-D

그렇다면 좋은 다음 단계는 무엇일까요?

그렇다면 좋은 다음 단계는 무엇일까요?

앞서 언급했듯이 :

활성 프로브는 구성 가능해야하지만 kubeadm 구성에서이를 수행하는 가장 좋은 방법에 대해 이야기해야합니다.

나는 이것이 사용되는 값이라고 생각하므로 kubeadm을 직접 빌드하는 경우 다음을 사용해보십시오.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
그러나 이렇게하면 모든 컨트롤 플레인 구성 요소에 대한 시간 초과가 증가합니다.

oof 나는 kubeadm을 직접 빌드하지 않고 apt.kubernetes.io에서 apt를 통해 가져옵니다. 내 컴퓨터에서 이동하기위한 빌드 파이프 라인과 원격으로 유사한 것은 없습니다 (아직 다루지 않았습니다). 클러스터를 만들 때와 같이 클러스터에 가입 할 때 수정해야 할 유사한 파일이 있기를 바랐지만 이러한 값이 utils.go에 하드 코딩되어있는 것처럼 보입니다.

이 솔루션을 시도해 볼 수는 있지만 까다 롭습니다.
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

문제는 이것이 구성 변경이 필요하고 1.11.X 릴리스에 포함될 수 있다고 생각하지 않는다는 것입니다 (하지만 시도해 볼 수 있습니다). 또한 먼저 논의해야합니다.

마스터가 작동 중이라고 말한 주석에서 이미 수행 한 작업입니다 (내 watch -n 1.0 명령이 수행 한 작업입니다). 지금 일어나고있는 것은 kubeadm join이 작동하지 않는다는 것입니다. 그리고 제가 볼 수있는 한 kubeadm join은 어디에나 패치 할 yaml 파일을 배치하지 않습니다.

다른 문제가 발생할 수 있습니다. 말하기 어렵다.

사용 된 값이므로 kubeadm을 직접 빌드하는 경우 다음을 사용해보십시오.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

그래서 저는 여기서 InitialDelaySeconds 타임 아웃이 1 년 후 _still_ 15 초라는 것을 알았습니다. 그리고 그것이 실제로 현실을 나타내는 것으로 증가되지 않은 이유를 이해할 수 없습니다. 이 버그 보고서가 어떤 용도로 사용됩니까? 나는 이미 kubeadm 내부 서클에있는 누군가가 그것을 완료하고 몇 분 안에 합칠 수 있다고 느꼈기 때문에 처음에이 번호를 변경하기위한 PR을 제안하지 않았습니다. 그러나 "PR 부족"이 있다면 그렇게하게되어 기쁩니다. 우리가 앞으로 나아 가지 않은 유일한 이유입니다.

모든 사람들이 원래 버그 보고서가 유효하지 않다고 선언하는 이유를 찾으려고하는 것 같습니다. 빠른 불투명 시간 초과 실패는 느린 성공보다 더 나은 UX입니다), 단지 initialDelay 시간 초과를 늘려 바이너리가 명확하게 보여주는 실제 initialDelay를 반영한 ​​다음 실제로 논의할만한 다른 것으로 이동하는 대신.

그래서 저는 여기서 InitialDelaySeconds 타임 아웃이 여전히 1 년 후 15 초라는 것에 주목하고, 왜 그것이 실제로 현실을 나타내는 것으로 증가되지 않았는지 이해하지 못합니다. 이 버그 보고서가 어떤 용도로 사용됩니까? 나는 이미 kubeadm 내부 서클에있는 누군가가 그것을 완료하고 몇 분 안에 합칠 수 있다고 느꼈기 때문에 처음에이 번호를 변경하기위한 PR을 제안하지 않았습니다. 그러나 "PR 부족"이 있다면 그렇게하게되어 기쁩니다. 우리가 앞으로 나아 가지 않은 유일한 이유입니다.

전체 문제가 새롭기 때문에 귀하의 질문에 답할 수는 없지만 이번 주에 이에 대해 이야기 할 수 있습니다. kubeadm 뒤에있는 팀은 큰 목표를 가진 소규모 팀이며 종종 이와 같은 특정 작업을 수행 할 사람이 없습니다.

모든 사람들이 원래 버그 보고서가 유효하지 않다고 선언하는 이유를 찾으려고하는 것 같습니다. 빠른 불투명 시간 초과 실패는 느린 성공보다 더 나은 UX입니다), 단지 initialDelay 시간 초과를 늘려 바이너리가 명확하게 보여주는 실제 initialDelay를 반영한 ​​다음 실제로 논의할만한 다른 것으로 이동하는 대신.

예, 옵션은 이미이 스레드에서 논의되었습니다. 올바른 옵션을 선택하고 구현하는 문제입니다.

실제로 전체 프로세스에 대한 시간 제한을 설정하는 옵션과 함께 "시간 제한 없음"으로 기본 설정하는 것이 합리적이라고 생각합니다 (이 문제의 앞부분에서 제안한대로).

이유는 내가 생각할 수있는 대부분의 사용 사례는 특정 단계가 X 초 내에 실행되는지 여부에 상관하지 않기 때문입니다. 분산 시스템에서 처리되는 모든 것이 최종 일관성 (경우에 따라 다른 노드를 스풀링하는 것이 더 저렴하기 때문)이기 때문입니다. 설정을 조작하는 것보다).

그러나 임시 솔루션으로서 kubeadm init 항목과 마찬가지로 구성 파일에서 kubeadm join에 대한 제한 시간 설정을 실제로 읽는 것으로 충분하므로 기내 제한 시간 대체를 사용한 해킹이 작동합니다. 해킹입니다. 다르게 생각하지 마세요.하지만 끔찍한 해킹이 해결 방법이없는 것보다 낫습니다.

나는 추측이 항상 잘못 될 수 있고,이 경우에는 실제로 목적에 부합하지 않을 수 있으며 (시간 초과를 극복하기위한 대처 전략이 단순히 구제되기 때문에) 합리적인 시간 초과를 "추측"하려는 시도에 반대하고 있습니다. 두 개의 동일한 시스템이 무수히 많은 이유로 서로 다르게 작동 할 수 있기 때문입니다.

@anguslees @DJGummikuh 우리는 최근 SIG 회의에서 그것에 대해 이야기했습니다.

이것은 까다로운 문제이지만 다음은 무작위 메모입니다.

메모:

• 우리 사람들 중 일부는 많은 경험을 가지고 있으며 이것이 apiserver 시작을 지연시키는 경쟁 조건처럼 냄새가 난다고 말합니다. 그렇게 오래 걸리지 않을 것입니다. 이것은 ARM 대 GOLANG 일 수 있습니다.
• SIG API 기계에 요청했지만 제안 된 활성 프로브 값 및 여기에서 다른 유형의 문제가 의심되는 경우 응답이 없습니다.
• 우리는 구성 옵션, 환경 변수 또는 명령 줄 매개 변수를 노출하는 것이 kubeadm에 대해 나쁜 생각이라는 데 동의했습니다 . 그 이유는 사용자에게 완전히 임의의 의미를 가질 수있는 매개 변수를 노출하고 싶지 않기 때문입니다.
• 팀원 중 누구도 느린 머신 (예 : 느린 VM)에서 이러한 문제를 본 적이 없습니다. 이는 RPi와 관련이있을 수 있으며 이것이 "느린"하드웨어 때문이라는 전체 주장이 유효하지 않음을 의미합니다.
• 이것을보세요 : https://github.com/kubernetes/kubernetes/issues/64357 사용자가 활성 프로브 문제를 전혀보고하지 않습니다. 왜 그런지 아세요?
• 이 스레드의 이론에 따르면 https://www.scaleway.com/ 과 같은 문제를 본 사람이 있습니까?
• 결론적으로 , 우리는 더 큰 시간 초과 / 지연 값을 하드 코딩하는 것이 kubeadm에 대해 그다지 중요하지 않다고 논의 했으므로 누군가 PR을 제출하고 싶다면 계속 진행하십시오. ( @anguslees )

이것을보세요 : kubernetes / kubernetes # 64357 사용자가 활성 프로브 문제를 전혀보고하지 않습니다. 왜 그런지 아세요?

아니요, 지금은 제 하드웨어에서 실제로 재현 할 수없는 것 같습니다. 노드 결합을위한 토큰이 경과했기 때문에 "도대체"라고 생각하고 kubeadm이 클러스터 마스터를 재설정하고 다시 초기화하려고 시도했습니다. 내 Raspberry Pi 3+의 마스터. 구성 시간 제한을 180 초에서 300 초로 차이없이 늘 렸습니다. 그래서 저는 이것이 경쟁 조건이라는 생각을 좋아합니다.
여전히 더 높은 시간 제한을 요청하라는 귀하의 제안을 환영합니다. 많이 아프지 않고 파이 (느린 하드웨어, 우리 모두 동의 할 수 있다고 생각합니다 :-)) 조금 더 많은 호흡 공간을 제공합니다.

apiserver의 ARM64 관련 문제 :
https://github.com/kubernetes/kubernetes/issues/64649

주말 동안 내 (여전히 실패 :-() Pi Cluster로 더 많은 연구를 수행했습니다.

OS를 다시 설치하지 않고 Pi 2에서 Pi 3+로 업데이트하면 문제가 발생할 수 있다고 생각했기 때문에 노드 중 하나를 다시 설치했습니다. 이것은 사실이 아니며 문제는 새로운 OS에서도 동일합니다.
또한 시간 초과가 늘어난 kubernetes를 컴파일하기 위해 노력하고 테스트했습니다. 또한 이것은 실제로 어떤 결과도 산출하지 못했습니다.
마스터를 시작할 수 있었지만 (구성 파일을 패치하기위한 시계 해결 방법으로) 클러스터를 두 번째 노드와 결합하는 것은 성공하지 못했습니다.

이 문제를 해결하기 위해 몇 가지 유용한 로그 출력을 추가하는 것이 정말 좋습니다. 그러나 kubernetes 구성 요소가 상호 작용하여 줄을 추가 할 위치를 알기에 충분하지 않습니다.

도전 할 사람이 있습니까? ^^

이것은 kubeadm 외부의 문제입니다 ...

API 기계 사람들은 문제에 대한 의견에 대한 내 요청을 보지 않았으므로 티켓이 이미 기록되지 않은 한 누군가가 kubernetes/kubernetes 저장소에 로그인하고 /sig api-machinery 태그를 지정해야합니다.

이 문제를 해결하기 위해 몇 가지 유용한 로그 출력을 추가하는 것이 정말 좋습니다. 그러나 kubernetes 구성 요소가 상호 작용하여 줄을 추가 할 위치를 알기에 충분하지 않습니다.

시작으로 systemd drop-in 파일에서 kubelet에 대해 --v 4 를 활성화하면 GLOG 로거에 높은 상세 정보를 사용할 수 있습니다.
다음과 같이 kubeadm 구성의 제어 플레인 구성 요소에 대해 동일한 작업을 수행 할 수도 있습니다.
https://kubernetes.io/docs/setup/independent/control-plane-flags/

이것은 내 Raspberry Pi 3 클러스터의 문제를 해결했습니다 : https://github.com/kubernetes/kubernetes/pull/66264

@joejulian 좋은 나는 그것을 패치 할 수 있었고 이제 내 클러스터도 시작됩니다. 마침내 몇 주 동안의 고뇌 끝에! 감사합니다 :-)

@joejulian 조사해 주셔서 감사합니다!
잠재적 인 수정 사항은 https://github.com/kubernetes/kubernetes/pull/66264 에서 찾을 수 있습니다.

추후 공지가있을 때까지 종료됩니다.

/닫기

kubeadm init 파일에 이러한 설정을 전달하는 방법이 있습니까? apiServerExtraArgs 일까요? 파일을 패치하기 위해 파일을 감시하는 것은 고통스럽고 자동화하기가 다소 어렵습니다.

없기. 아마도 그것은 추가하기 좋은 기능이 될 것입니다.

나중에 업데이트를 통해 확인해야 할 사항이 더 많이 추가되었으며 PR이 제공 한 연장 된 타임 아웃이 더 이상 충분하지 않았습니다. 타임 아웃 관리를 포기했습니다. 나를위한 해결책은 ecdsa 인증서를 사용하는 것이 었습니다.

또한 etcd를 포함한 컨트롤러 서비스는 이제 Raspberry Pi가 제어 플레인을 호스팅하는 노드 수를 두 배로하는 것보다 더 많은 램을 차지하므로 Rock64s로 업그레이드했습니다.

말장난은 실례하지만 내 조종기는 그 이후로 견고 해졌습니다.

방금 Raspberry Pi 3+에 설치하려고 시도했으며 설치가 실제로 실패하는지 확인할 수 있습니다. 위에 나열된 kube-apiserver.yaml에서 'watch'트릭을 사용하는 것은 일관되게 작동하는 것 같습니다.

너무 쉬워지는 순간, kubeadm은 이제 Docker (18.09) 버전이 지원되지 않는다고 불평합니다. 18.06으로 빠르게 되 돌리면 문제가 해결되었습니다.

kubeadm 1.13에서는 api 서버 시간 초과를 제어 할 수있는 ClusterConfig-> ApiServer 아래에 구성 플래그를 추가합니다.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

API 서버 시간 제한을 제어 할 수있는 ClusterConfig-> ApiServer 아래의 구성 플래그입니다.

코드베이스에서 TimeoutForControlPlane 하면 기본값이 4 분이라고 생각하며 kubeadm 자체가 apiserver가 정상이 될 때까지 대기하는 데 사용되는 지연에만 사용됩니다. 특히 kubelet 자체에서 사용하는 apiserver livenessprobe를 변경하지 _ 않습니다 _. 그 맞습니까?

이 문제에 대한 논의에서 반론이 제기 된 것을 본 적이 없다고 생각합니다. livenessProbe initialDelaySeconds를 늘리고 다른 문제로 이동하지 _ 않는 _ 이유가 있습니까?

참고 : 빠른 읽기에서 볼 수있는 한 TimeoutForControlPlane 은 (는) 여러 이미지를 가져 오는 동안 정체 또는 추가 시간 초과 + 재시도 루프와 같은 증가 된 apiserver 시작 지연에 대한 다른 비 실패 원인도 고려하지 않습니다. 모든 것이 초기 설치 시간에 수렴되는 동안 반복됩니다 (시간 초과 + 재 시도는 반복적으로 k8s 디자인 패턴입니다 ... 그리고 이것은로드 된 시스템에서 가끔 발생합니다. 예상하고 괜찮습니다). 개인적으로 4 분은 빠른 실패를 기대하는 성급한 대화 형 사용자에게는 너무 길고 예상되는 성공을 더 오래 기다릴 준비가 된로드 / 느린 / 자동 시스템의 설치 프로세스에는 너무 짧다고 생각합니다. 어떻게 도착했는지, 기본적으로 5 분으로 설정할 수 있습니까? SIGINT까지 계속 재 시도 할 수 있습니까? 호출 환경에서 상속하지 않고 내부적으로 인위적인 벽시계 마감일을 부과하는 이유는 무엇입니까?

Afaics TimeoutForControlPlane 는 단지 의도 된 유일한 UX가 마감일에 도달하지 않을 때까지 매개 변수를 증가시키는 것 뿐인 임의의 치명적인 내부 마감일을 매개 변수로 노출하는 것입니다. 또는, 우리는 애초에 임의의 치명적인 내부 기한을 부과하지 _ 않을 수 있습니다 _...

그것은 훌륭한 점이며 전적으로 동의합니다.

특히 kubelet 자체에서 사용하는 apiserver livenessprobe를 변경하지 않습니다. 그 맞습니까?

예, 아직 kubeadm에서 활성 상태 프로브를 수정할 계획이 없습니다.

이 rpi 문제는 sig-cluster-lifecyle 회의에서 "발생해서는 안되는 일", "거의 kubelet의 경쟁 조건과 비슷해 보임", "왜 rpi에서만 발생하고 다른 느린 장치에서는 발생하지 않는지"로 검증되었습니다. 느린 장치를 직접 테스트하지 않았 음을 인정해야합니다.

즉,이 값을 높이는 데 동의했습니다.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
좋은 수정이 아니며 다른 버그에 대한 해결 방법 인 것 같습니다.

어떻게 도착했는지, 기본적으로 5 분으로 설정할 수 있습니까?

1.11 이전에는 이미지 가져 오기를 고려했기 때문에 시간 제한은 4 분이되기 전에 30 분이었습니다.
4 분 대 5 분에 대한 의견이 있다면 주제에 대한 강점을 가진 잘 요약 된 PR이 1.14에서 성공할 수 있습니다.

이 rpi 문제는 sig-cluster-lifecyle 회의에서 "발생해서는 안되는 일", "거의 kubelet의 경쟁 조건과 비슷해 보임", "왜 rpi에서만 발생하고 다른 느린 장치에서는 발생하지 않는지"로 검증되었습니다.

이것들은 모두 다른 곳에서 다른 버그를 계속 찾아야하는 이유이지만, 그것들 중 어느 것도 initialDelaySeconds를 증가시키는 이유가 아닙니다. 실제로 initialDelaySeconds를 늘리는 데 단점이 있습니까?

다른 방향에서 접근하기 위해 kubeadm에서 사용할 수있는 해결 방법이있는 kubernetes의 다른 곳에서 문제가 있다는 것을 알고 있다면 순도에 대한 "선을 유지"하고 알려진 파손 된 결과를 생성하는 것이 kubeadm의 역할입니까? 그것은 사람들이 실제 배포에 실제로 사용할 것으로 기대하는 도구가되는 목표와 상충되는 것 같습니다. 지금까지 클러스터에 패치를 적용하지 않고 kubeadm을 사용하여 제한 시간을 늘릴 수 없었습니다 (1 년 이상 전에 패치로보고 했음에도 불구하고).

(이 문제에 대한 불만이 제 말투로 새어 나와서 사과드립니다)

4 분 대 5 분에 대한 의견이 있다면

한숨. kubeadm에서 _no_ timeout에 대한 사례를 만들려고했지만 아직 그 제안을 설득력있게 표현하는 방법을 찾지 못했습니다 (예를 들어이 문제와 다른 실패한 시도 참조).

이것들은 모두 다른 곳에서도 다른 버그를 계속 찾아야하는 이유이지만, 그것들 중 어느 것도 initialDelaySeconds를 증가시키지 않는 이유가 아닙니다. 실제로 initialDelaySeconds를 늘리는 데 단점이 있습니까?

약간의 변화이지만, 문제를 일으키지 않는 시스템에도 적용될 것이기 때문에이 증가를 추가하지 않기로 동의했습니다.

다른 방향에서 접근하기 위해 kubeadm에서 사용할 수있는 해결 방법이있는 kubernetes의 다른 곳에서 문제가 있다는 것을 알고 있다면 순도에 대한 "선을 유지"하고 알려진 파손 된 결과를 생성하는 것이 kubeadm의 역할입니까? 그것은 사람들이 실제 배포에 실제로 사용할 것으로 기대하는 도구가되는 목표와 상충되는 것 같습니다.

최종 사용자를 향하는 것이 kubeadm의 목표입니다. 사실입니다.
그러나 이것은 rpis에 대한 보고서 일 뿐이며 실제 버그는 sig-api-machinery (api 서버) 및 sig-node (kubelet)로 에스컬레이션되어야하며 가능한 경우 kubeadm 외부에서 재현되어야합니다.

지금까지 클러스터에 패치를 적용하지 않고 kubeadm을 사용하여 제한 시간을 늘릴 수 없었습니다 (1 년 이상 전에 패치로보고 했음에도 불구하고).

kubeadm을 패치 할 필요가 없으며 대신 매니페스트 파일을 패치 할 수 있습니다.
kubeadm 1.13은 초기 단계를 최상위 명령으로 전환합니다. 예 : kubeadm init phase [phase-name]
단계는 주로 사용자가 제어 평면 노드가 생성되는 방식에 대한 사용자 지정 제어를 원하기 때문에 존재합니다.

kubeadm init --help 를 수행하면 단계가 실행되는 순서가 표시됩니다.

kubeadm init 명령을 적절한 단계로 나눌 수 있도록 제어 플레인 구성 요소에 대해 사용자 지정 매니페스트를 사용하고 control-plane 단계를 건너 뜁니다. 현재 --skip-phases 있습니다.

1.11과 1.12에서 이미 할 수 있지만 덜 간단합니다.

문제를 일으키지 않는 시스템에도 적용될 것이기 때문입니다.

그래서 .. 그게 뭐가 잘못된거야? 우리는 일부 시스템에서만 트리거되는 버그를 항상 수정합니다. 타임 아웃이있는 곳이면 어디에서나 환경의 일부가 아닌 가장 느린 시스템에 맞게 조정해야합니다.

이것에 대한 또 다른 각도는 작전 담당자로서 오버로드 상황, 특히 apiserver 자체에서 계단식 오류가 두렵다는 것입니다. Afaics, livenessprobe 타임 아웃 은 누군가의 "정상"아이디어에서 벗어날 때뿐만 아니라 작은 initialDelaySeconds는 장점이 없습니다 . kubeadm의 기본 livenessprobe는 모든 플랫폼에서 불필요하게 공격적입니다.

동일한 요점을 계속 반복해서 미안하지만 initialDelaySeconds를 확장하는 데에는 실용적이고 이론적 인 이유가 강력하고, 작게 유지하는 반대 주장을 이해하지 못하고 있습니다.

이 시점에서 kubeadm 구성 옵션을 추가 할 가능성은 거의 없습니다.

나는 이것이 이미 1.13에서 3 개의 명령으로 가능하다는 것을 설명하려고 해요 :

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

옵션을 원하지 않습니다. 현재 고정 값 (15)을 다른 고정 값 (위에 360이 제 안됨)으로 변경해야한다고 말하려고합니다.

..하지만 더 이상 끌어 내고 싶지 않습니다. 현재 가치를 고수하는 것이 분명한 결정이므로 패배를 철회하겠습니다. 양해 해 주셔서 감사합니다. :)

@ neolit123 그 조합은 훌륭해 보입니다. 내가 문서화 한 것보다 훨씬 쉬웠습니다. 컨트롤 플레인 세트를 기다린 다음 다른 터미널에서 sed를 빠르게 실행해야합니다. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

지침을 테스트하고 가이드를 업데이트 할 것입니다.

@ neolit123 이것은 RPi3 B +에서 위의 구성을 사용하여 얻은 것입니다.

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

kubeadm-config.yaml에서-192.168.0.26은 192.168.0.110을 가리키는 LB입니다.

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

외부 config / lb IP 없이도 동일한 결과를 얻습니다.

알렉스

나는 사람들에게 한동안 kubeadm을 사용하도록 촉구했으며 심지어 학교도 파이 클러스터에서 실행하기를 원했습니다. 코드 기반을 복잡하게 만들고 싶지 않다는 것을 이해하지만, 사용자 기반이 이러한 작은 장치에서 실행을 지원하는 것이 좋은 일이라고 생각합니다. 그것은 젊은 사람들이 그렇지 않으면 그렇지 않을 수도있는 치프 하드웨어에 쿠 버네 티스 타이어를 차게 해준다. 위의 해결 방법은 유효하지만이 사용 사례에서는 훨씬 더 어렵습니다.

타협은 어떻습니까? 구성 가능하게 만드는 대신 x86_64가 아니라면 기본 시간 제한을 더 높게 설정하는 간단한 휴리스틱을 추가 하시겠습니까?

[kubeconfig] "admin.conf"kubeconfig 파일 작성
[kubeconfig] "kubelet.conf"kubeconfig 파일 작성
패닉 : 런타임 오류 : 유효하지 않은 메모리 주소 또는 nil 포인터 역 참조
[신호 SIGSEGV : 분할 위반 코드 = 0x1 addr = 0x8 pc = 0xaa7204]

이상하게도 admin.conf 은 (는) 머신 생성이며 컨텍스트를 가리키는 current-context 파일이있는 유효한 Config 유형을 포함해야합니다.

공황은 다음 줄에서 비롯됩니다.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

위의 : point_up :과 똑같은 오류가 다음과 같이 표시됩니다.

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

다음 스크립트는 kubeadm 버전 1.12, 1.13 ( 대부분 의 경우)을 사용하여 문제를 해결합니다.

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

나는 같은 상황에 있었고 @ neolit123이 제안한 접근 방식과 동일한 오류가 발생
@stephenmoloney로 스크립트를 실행할 수 없었습니다. bash 스크립팅에 익숙하지 않습니다. 아마도 제 잘못 일 것입니다.

그래서 누구나 관심이있는 경우를 대비하여 스크립트를 python (Raspbian에 기본적으로 설치되므로 추가 종속성이 필요 없음)으로 이식했습니다.

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

실행하기 : sudo python however_you_name_the_file.py
@stephenmoloney 및 @ neolit123 솔루션을 알려 주셔서 감사합니다!

안녕하세요! 이 문제는 많은 도움이되었습니다

kustomize를 사용하여이 문제를 해결하는 멋진 방법을 찾았습니다.

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom