Kubeadm: 1.9.6에서 1.10.0으로의 업그레이드가 시간 초과로 실패 함

이 버그를 로컬에서 재현하는 중입니다.

이것을 10 번 재 시도한 후 마침내 작동했습니다.

다음은 내 etcd 매니페스트 diff입니다.
``` root @ vagrant : ~ # diff /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/tmp/kubeadm-backup-manifests858209931/etcd.yaml
16,17c16,17
<---listen-client-urls = https://127.0.0.1 : 2379

<---advertise-client-urls = https://127.0.0.1 : 2379

- --listen-client-urls=http://127.0.0.1:2379
- --advertise-client-urls=http://127.0.0.1:2379

19,27c19
<---key-file = / etc / kubernetes / pki / etcd / server.key
<---trusted-ca-file = / etc / kubernetes / pki / etcd / ca.crt
<---peer-cert-file = / etc / kubernetes / pki / etcd / peer.crt
<---peer-key-file = / etc / kubernetes / pki / etcd / peer.key
<---client-cert-auth = true
<---peer-client-cert-auth = true
<---cert-file = / etc / kubernetes / pki / etcd / server.crt
<---peer-trusted-ca-file = / etc / kubernetes / pki / etcd / ca.crt

<이미지 : gcr.io/google_containers/etcd-amd64:3.1.12

image: gcr.io/google_containers/etcd-amd64:3.1.11

29,35d20
<임원 :
<명령 :
<-/ bin / sh
<--ec
<-ETCDCTL_API = 3 etcdctl --endpoints = 127.0.0.1 : 2379 --cacert = / etc / kubernetes / pki / etcd / ca.crt
<--cert = / etc / kubernetes / pki / etcd / healthcheck-client.crt --key = / etc / kubernetes / pki / etcd / healthcheck-client.key
<get foo
36a22,26
httpGet :
호스트 : 127.0.0.1
경로 : / health
포트 : 2379
체계 : HTTP
43,45c33
<이름 : etcd-data
<-mountPath : / etc / kubernetes / pki / etcd

<이름 : etcd-certs

  name: etcd

51,55c39
<이름 : etcd-data
<-호스트 경로 :
<경로 : / etc / kubernetes / pki / etcd
<유형 : DirectoryOrCreate

<이름 : etcd-certs

name: etcd

root @ vagrant : ~ # ls / etc / kubernetes / pki / etcd
ca.crt ca.key healthcheck-client.crt healthcheck-client.key peer.crt peer.key server.crt server.key

1.9.6 Ubuntu 17.10 Vagrant의 클러스터 :

root<strong i="6">@vagrant</strong>:/vagrant# 1.10_kubernetes/server/bin/kubeadm upgrade apply v1.10.0
[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.0"
[upgrade/versions] Cluster version: v1.9.6
[upgrade/versions] kubeadm version: v1.10.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[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.0"...
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests262738652/etcd.yaml"
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [localhost] and IPs [127.0.0.1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [vagrant] and IPs [10.0.2.15]
[certificates] Generated 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-manifests858209931/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[apiclient] Error getting Pods with label selector "component=etcd" [the server was unable to return a response in the time allotted, but may still be processing the request (get pods)]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: http2: server sent GOAWAY and closed the connection; LastStreamID=27, ErrCode=NO_ERROR, debug=""]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: net/http: TLS handshake timeout]
[apiclient] Error getting Pods with label selector "component=etcd" [the server was unable to return a response in the time allotted, but may still be processing the request (get pods)]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: http2: server sent GOAWAY and closed the connection; LastStreamID=3, ErrCode=NO_ERROR, debug=""]
[upgrade/apply] FATAL: fatal error when trying to upgrade the etcd cluster: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition], rolled the state back to pre-upgrade state

이것은 내 재현 환경입니다 : https://github.com/stealthybox/vagrant-kubeadm-testing

부트 스트랩에 대해 다음 줄을 1.9.6-00 로 변경합니다. https://github.com/stealthybox/vagrant-kubeadm-testing/blob/9d4493e990c9bd742107b317641267c3ef3640cd/Vagrantfile#L18 -L20

그런 다음 1.10 서버 바이너리를 저장소로 다운로드하면 게스트에서 /vagrant 에서 사용할 수 있습니다.
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

kubelet etcd 관련 로그 :

root<strong i="6">@vagrant</strong>:~# journalctl -xefu kubelet | grep -i etcd
Mar 28 16:32:07 vagrant kubelet[14676]: W0328 16:32:07.808776   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:32:07 vagrant kubelet[14676]: I0328 16:32:07.880412   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "etcd-vagrant" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 16:34:27 vagrant kubelet[14676]: W0328 16:34:27.472534   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:57:33 vagrant kubelet[14676]: W0328 16:57:33.683648   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:57:33 vagrant kubelet[14676]: I0328 16:57:33.725564   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") pod "etcd-vagrant" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 16:57:33 vagrant kubelet[14676]: I0328 16:57:33.725637   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") pod "etcd-vagrant" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 16:57:35 vagrant kubelet[14676]: E0328 16:57:35.484901   14676 kuberuntime_container.go:66] Can't make a ref to pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)", container etcd: selfLink was empty, can't make reference
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.889458   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "7278f85057e8bf5cb81c9f96d3b25320" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.889595   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd" (OuterVolumeSpecName: "etcd") pod "7278f85057e8bf5cb81c9f96d3b25320" (UID: "7278f85057e8bf5cb81c9f96d3b25320"). InnerVolumeSpecName "etcd". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.989892   14676 reconciler.go:297] Volume detached for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") on node "vagrant" DevicePath ""
Mar 28 16:58:03 vagrant kubelet[14676]: E0328 16:58:03.688878   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Timeout: request did not complete within allowed duration
Mar 28 16:58:03 vagrant kubelet[14676]: E0328 16:58:03.841447   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff626cfbc5", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"37936d2107e31b457cada6c2433469f1", APIVersion:"v1", ResourceVersion:"", FieldPath:""}, Reason:"SuccessfulMountVolume", Message:"MountVolume.SetUp succeeded for volume \"etcd-certs\" ", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e59c5, ext:1534226953099, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e59c5, ext:1534226953099, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:58:33 vagrant kubelet[14676]: E0328 16:58:33.844276   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff626cfb82", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"37936d2107e31b457cada6c2433469f1", APIVersion:"v1", ResourceVersion:"", FieldPath:""}, Reason:"SuccessfulMountVolume", Message:"MountVolume.SetUp succeeded for volume \"etcd-data\" ", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e5982, ext:1534226953033, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e5982, ext:1534226953033, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:59:03 vagrant kubelet[14676]: E0328 16:59:03.692450   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": the server was unable to return a response in the time allotted, but may still be processing the request (post pods)
Mar 28 16:59:03 vagrant kubelet[14676]: E0328 16:59:03.848007   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff641f915f", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"7278f85057e8bf5cb81c9f96d3b25320", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers{etcd}"}, Reason:"Killing", Message:"Killing container with id docker://etcd:Need to kill Pod", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f72f0ef5f, ext:1534255433999, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f72f0ef5f, ext:1534255433999, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:59:14 vagrant kubelet[14676]: W0328 16:59:14.472661   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:59:14 vagrant kubelet[14676]: W0328 16:59:14.473138   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:14 vagrant kubelet[14676]: E0328 16:59:14.473190   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:14 vagrant kubelet[14676]: E0328 16:59:14.473658   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:15 vagrant kubelet[14676]: W0328 16:59:15.481336   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:59:15 vagrant kubelet[14676]: E0328 16:59:15.483705   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:15 vagrant kubelet[14676]: E0328 16:59:15.497391   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:00:34 vagrant kubelet[14676]: W0328 17:00:34.475851   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.720076   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: http2: server sent GOAWAY and closed the connection; LastStreamID=47, ErrCode=NO_ERROR, debug=""
Mar 28 17:01:07 vagrant kubelet[14676]: E0328 17:01:07.720107   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: http2: server sent GOAWAY and closed the connection; LastStreamID=47, ErrCode=NO_ERROR, debug=""; some request body already written
Mar 28 17:01:07 vagrant kubelet[14676]: E0328 17:01:07.725335   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:07 vagrant kubelet[14676]: I0328 17:01:07.728709   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "etcd-vagrant" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.734475   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.740642   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:09 vagrant kubelet[14676]: E0328 17:01:09.484412   14676 kuberuntime_container.go:66] Can't make a ref to pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)", container etcd: selfLink was empty, can't make reference
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.848794   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849282   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849571   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data" (OuterVolumeSpecName: "etcd-data") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1"). InnerVolumeSpecName "etcd-data". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849503   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs" (OuterVolumeSpecName: "etcd-certs") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1"). InnerVolumeSpecName "etcd-certs". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.949925   14676 reconciler.go:297] Volume detached for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") on node "vagrant" DevicePath ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.949975   14676 reconciler.go:297] Volume detached for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") on node "vagrant" DevicePath ""

현재 해결 방법은 업그레이드를 계속 재 시도하는 것이며 어느 시점에서 성공할 것입니다.

@stealthybox etcd 컨테이너의 도커에서 로그를 가져 오셨습니까? 또한 grep -i etcd 은 (는) 일부 kubelet 출력을 마스킹 할 수 있습니다 (예 : 컨테이너 이름이 없지만 관련성이있는 일부 오류 메시지).

이 버그와 관련된 또 다른 이상한 사건이 발생했습니다. kubeadm 업그레이드는 새 etcd 이미지를 가져오고 새 정적 포드를 배포하기 전에 etcd 업그레이드를 완료된 것으로 표시했습니다. 이로 인해 이후 단계에서 업그레이드 시간이 초과되고 업그레이드 롤백이 실패합니다. 이로 인해 클러스터가 중단 된 상태가됩니다. 클러스터를 복구하려면 원래 etcd 정적 포드 매니페스트를 복원해야합니다.

오 그래 나도 거기에 갇혀있어. 내 클러스터가 완전히 다운되었습니다. 누군가가이 주에서 구출하는 방법에 대한 지침을 공유 할 수 있습니까?

@detiber가 설명한 것처럼 두 번째 업그레이드 시도에

/ etc / kubernetes / tmp에서 백업 된 내용을 찾았고, etcd가 범인 일 수 있다고 생각하고, 이전 매니페스트를 매니페스트 폴더의 새 매니페스트 위에 복사했습니다. 그 시점에서 나는 잃을 것이 없었습니다. 왜냐하면 클러스터에 대한 통제력을 완전히 잃었 기 때문입니다. 그런 다음 정확히 기억이 나지 않지만 전체 시스템을 다시 시작하고 나중에 모든 항목을 v1.9.6으로 다운 그레이드 한 것 같습니다. 결국 나는 클러스터에 대한 제어권을 얻었고 v1.10.0을 다시 엉망으로 만들 동기를 잃었습니다. 전혀 재미 없었어요 ...

/etc/kubernetes/tmp 에서 etcd 정적 포드 매니페스트를 롤백하는 경우 1.10의 새로운 TLS 구성으로 인해 apiserver 매니페스트를 1.9 버전으로 롤백하는 것도 중요합니다.

^ etcd 업그레이드가 나머지 컨트롤 플레인 업그레이드를 차단한다고 믿기 때문에 아마도 이것을 할 필요가 없을 것입니다.

etcd 매니페스트 만 업그레이드 실패시 롤백되지 않는 것 같습니다. 다른 모든 것은 괜찮습니다. 백업 매니페스트를 이동하고 kubelet을 다시 시작하면 모든 것이 정상적으로 돌아옵니다.

나는 같은 시간 초과 문제에 직면했고 kubeadm은 kube-apiserv 매니페스트를 1.9.6으로 롤백했지만 etcd 매니페스트를 그대로 두었습니다 (읽기 : TLS 사용). 분명히 apiserv가 비참하게 실패하여 내 마스터 노드를 효과적으로 손상시킵니다. 별도의 문제 보고서를 작성하기에 좋은 후보라고 생각합니다.

@dvdmuckle @codepainters , 안타깝게도 롤백 성공 여부는 경쟁 조건 (etcd 또는 api 서버)에 맞는 구성 요소에 따라 다릅니다. 경쟁 조건에 대한 수정 사항을 찾았지만 kubeadm 업그레이드를 완전히 중단합니다. 저는 @stealthybox 와 협력하여 업그레이드를 적절히 수정하기위한 적절한 경로를 찾으려고 노력하고 있습니다.

@codepainters 같은 문제라고 생각합니다.

이 문제를 일으키는 몇 가지 근본적인 문제가 있습니다.

• 업그레이드는 API에서 미러 포드를 쿼리 한 결과에서 각 구성 요소에 대한 미러 포드의 해시를 생성합니다. 그런 다음 업그레이드는이 해시 값이 변경되는지 테스트하여 포드가 정적 매니페스트 변경에서 업데이트되었는지 확인합니다. 해시 된 값에는 정적 매니페스트 변경 (예 : 포드 상태 업데이트) 이외의 이유로 변경 될 수있는 필드가 포함됩니다. 해시 비교 사이에서 포드 상태가 변경되면 업그레이드가 조기에 다음 구성 요소로 계속됩니다.
• 업그레이드는 etcd 정적 포드 매니페스트 업데이트 (etcd에 tls 보안 추가 포함)를 수행하고 apiserver를 사용하여 포드가 업데이트되었는지 확인하려고 시도합니다. 그러나 apiserver 매니페스트는이 시점에서 etcd와 통신하기 위해 tls를 사용하도록 업데이트되지 않았습니다. .

결과적으로 현재 업그레이드는 kubelet이 etcd에 대한 새 정적 매니페스트를 선택하기 전에 해시를 변경하는 etcd 포드에 대한 포드 상태 업데이트가있는 경우에만 성공합니다. 또한 apiserver 매니페스트를 업데이트하기 전에 업그레이드 도구가 api를 쿼리 할 때 api 서버를 apiserver 업그레이드의 첫 번째 부분에 사용할 수 있어야합니다.

@detiber 와 저는 업그레이드 프로세스에 필요한 변경 사항에 대해 논의하기 위해 전화를 받았습니다.
1.10.x 패치 릴리스에서이 버그에 대한 3 가지 수정 사항을 구현할 계획입니다.

• 업그레이드에서 etcd TLS를 제거하십시오.
  현재 업그레이드 루프는 구성 요소별로 일괄 수정을 직렬 방식으로 수행합니다.
  구성 요소 업그레이드는 종속 구성 요소 구성에 대한 지식이 없습니다.
  업그레이드를 확인하려면 포드 상태를 확인하기 위해 APIServer를 사용할 수 있어야합니다.
  Etcd TLS에는이 계약을 위반하는 결합 된 etcd + apiserver 구성 변경이 필요합니다.
  이것은이 문제를 해결하기위한 최소한의 실행 가능한 변경이며 업그레이드 된 클러스터는 안전하지 않은 etcd로 남겨 둡니다.

• 포드 상태 변경시 미러 포드 해시 경쟁 조건을 수정합니다.
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/staticpods.go#L189.
  이제 etcd와 apiserver 플래그 간의 호환성을 가정하면 업그레이드가 올 바릅니다.

• 특별히 별도의 단계에서 TLS를 업그레이드하십시오.
  Etcd와 APIServer는 함께 업그레이드해야합니다.
  kubeadm alpha phase ensure-etcd-tls ?.
  이 단계는 클러스터 업그레이드와 관계없이 실행할 수 있어야합니다.
  클러스터 업그레이드 중에는 모든 구성 요소를 업데이트하기 전에이 단계를 실행해야합니다.

1.11의 경우 다음 을 원합니다.

• 업그레이드 된 정적 팟 (Pod)의 런타임 검사에 kubelet API를 사용하십시오.
  우리가 현재하고있는 것처럼 로컬 프로세스를 모니터링하기 위해 apiserver 및 etcd에 의존하는 것은 바람직하지 않습니다.
  포드에 대한 로컬 데이터 소스는 고차 분산 kubernetes 구성 요소에 의존하는 것보다 우수합니다.
  이는 업그레이드 루프에서 현재 포드 런타임 검사를 대체합니다.
  이를 통해 ensure-etcd-tls 단계에 검사를 추가 할 수 있습니다.

대안 : CRI를 사용하여 포드 정보를 가져옵니다 ( crictl 사용하여 데모 실행 가능).
주의 사항 : dockershim 및 기타 컨테이너 런타임의 CRI는 현재 CRI 주요 변경 사항에 대한 하위 호환성을 지원하지 않습니다.

할 것:

• []이 4 가지 변경 사항에 대한 공개 및 링크 문제.

정적 포드 업데이트 경쟁 조건을 해결하기위한 PR : https://github.com/kubernetes/kubernetes/pull/61942
릴리스 -1.10 브랜치에 대한 체리 픽 PR : https://github.com/kubernetes/kubernetes/pull/61954

@detiber 우리가 말하는 경쟁 조건을 설명해 주시겠습니까? 나는 kubeadm 내부에 익숙하지 않지만 흥미롭게 들립니다.

@codepainters 참조 https://github.com/kubernetes/kubeadm/issues/740#issuecomment -377263347

참고-1.9.3에서 동일한 문제 / 문제 업그레이드
여러 번 다시 시도하는 해결 방법을 시도했습니다. 마지막으로 API 서버와 경쟁 조건에 도달했고 업그레이드를 롤백 할 수 없습니다.

@stealthybox thx, 처음 읽었을 때 얻지 못했습니다.

동일한 문제가 있습니다 .. [ERROR APIServerHealth] : API 서버가 비정상입니다. / healthz가 "ok"를 반환하지 않았습니다.
[오류 MasterNodesReady] : 클러스터의 마스터를 나열 할 수 없습니다. 업그레이드하는 동안 https를 가져옵니다 ........ 이걸 도와주세요. 1.9.3에서 1.10.0으로 업그레이드하고 있습니다. 처음에는 "[upgrade / staticpods] kubelet이 구성 요소를 다시 시작하기를 기다리는 중"이라는 특정 지점에 도달 할 수있었습니다.

임시 해결 방법은 인증서를 확인하고 검사를 우회하여 etcd 및 apiserver 포드를 업그레이드하는 것입니다.

구성을 확인하고 사용 사례에 대한 플래그를 추가하십시오.

kubectl -n kube-system edit cm kubeadm-config  # change featureFlags
...
  featureGates: {}
...
kubeadm alpha phase certs all
kubeadm alpha phase etcd local
kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

감사합니다 @stealthybox
나를 위해 upgrade apply 프로세스가 [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... 에서 중단되었지만 클러스터가 성공적으로 업그레이드되었습니다.

@stealthybox 확실하지 않지만 kubeadm upgrade plan 이 (가) 그 후에 중단되기 때문에이 단계를 수행 한 후에 뭔가 손상된 것 같습니다.

[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] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.10.1
[upgrade/versions] kubeadm version: v1.10.1
[upgrade/versions] Latest stable version: v1.10.1

업데이트를 적용 할 때 [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... 도 교수형

@kvaps @stealthybox 이것은 etcd 문제 일 가능성이 가장 높습니다 ( kubeadm 는 TLS 지원 etcd 에게 평범한 HTTP/2 을 말합니다). 이 다른 문제를 참조하십시오 : https://github.com/kubernetes/kubeadm/issues/755

솔직히, TLS 및 비 TLS etcd 리스너 모두에 동일한 TCP 포트가 사용되는 이유를 이해할 수 없으며, 이와 같은 문제 만 발생합니다. 분명 해지면 _ 연결이 거부 됨 _은 즉각적인 힌트를 줄 것입니다. 여기서 무슨 일이 일어나고 있는지 이해하기 위해 tcpdump 에 의존해야했습니다.

오!
Etcd 상태 확인을위한 내 로컬 TLS 패치에서만 작동합니다.

업그레이드를 완료하려면 다음을 수행하십시오.

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

위의 해결 방법을 수정했습니다.

@stealthybox 두 번째 kubeadm 명령이 작동하지 않습니다.

# kubeadm alpha phase upload-config
The --config flag is mandatory

@renich 는 구성의 파일 경로를 제공합니다.

사용자 지정 설정을 사용하지 않는 경우 빈 파일로 전달할 수 있습니다.
다음은 bash에서이를 수행하는 간단한 방법입니다.

1.10_kubernetes/server/bin/kubeadm alpha phase upload-config --config <(echo)

이 문제는 이제 https://github.com/kubernetes/kubernetes/pull/62655 의 병합으로 해결되어야하며 v1.10.2 릴리스의 일부가 될 것입니다.

kubeadm 1.10.2로 1.10.0-> 1.10.2 업그레이드가 원활하고 시간 초과가 없음을 확인할 수 있습니다.

1.10.0-> 1.10.2에 여전히 시간 초과가 있지만 다른 시간이 있습니다.
[upgrade/staticpods] Waiting for the kubelet to restart the component Static pod: kube-apiserver-master hash: a273591d3207fcd9e6fd0c308cc68d64 [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]

어떻게해야할지 모르겠습니다 ...

@ denis111 은 docker ps 사용하여 업그레이드를 수행하는 동안 API 서버 로그를 확인합니다. 나는 당신이 나도 직면하고있는 문제에 직면했을 것 같습니다.

@dvdmuckle 글쎄, 그 로그에 오류가 없으며 I와 몇 W로 시작하는 항목 만 표시됩니다.
그리고 kube-apiserver의 해시는 업그레이드 중에 변경되지 않는다고 생각합니다.

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]

v1.10.2-> v1.10.2 업그레이드 (말도 안 될 수도 있습니다. 테스트 중입니다 ...)

Ubuntu 16.04.

그리고 오류와 함께 실패합니다.

kubeadm upgrade apply v1.10.2

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

이 문제가 여전히 추적되는지 궁금합니다 ... 찾을 수 없습니다.

또한 timed out waiting for the condition 오류로 인해 업그레이드가 여전히 실패하는 것으로 나타났습니다.

편집 : 토론을 새 티켓 https://github.com/kubernetes/kubeadm/issues/850으로 이동했습니다. 거기에서 토론하십시오.

다른 사람이 1.9.x에서이 문제가있는 경우 :

사용자 지정 호스트 이름이있는 AWS에있는 경우 kubeadm-config configmap을 편집하고 nodeName에서 aws 내부 이름을 설정해야합니다. ip-xx-xx-xx-xx. $ REGION.compute.internal)

kubectl -n kube-system edit cm kubeadm-config -oyaml

이것은 etc 클라이언트를 http로 설정하는 것 외에도. 나는 그들이 그것을 고쳤는지 확인하기 위해 아직 편지 버전을 사용하지 않았습니다.

이는 kubeadm이 api에서이 경로를 읽으려고하기 때문입니다 : / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

1.10.6에서 시간 제한이 증가했기 때문에 몇 주 전에 1.9.7 배포를 1.10.6으로 성공적으로 업데이트했습니다.

이 버전에 동일한 변경 사항이 적용되므로 .deb 패키지가 준비되는 즉시 1.11.2로 업그레이드 할 계획입니다.

내 클러스터는 ARM64 보드에서 온 프레미스로 실행됩니다.