Kubeadm: 1.9.6 से 1.10.0 तक अपग्रेड करना टाइमआउट के साथ विफल हो जाता है

स्थानीय स्तर पर इस बग को पुन: पेश करने पर काम कर रहा है।

इसे 10 बार रिटायर करने के बाद आखिरकार इसने काम किया

यहाँ मेरे etcd भिन्नता है
`` ` जड़ @ योनि : ~ # diff /etc/kubernetes/manifests/etcd.yaml/etc/kubernetes/tmp/kubeadm-backup-manifests858999931/etcd.yaml
16,17c16,17
<- --लिस्टन-क्लाइंट-उरल्स = https://127.0.0.1 : 2379

<- - व्यवसाय-ग्राहक- 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,27 सी 19
<- --key-file = / etc / kubernetes / pki / etcd / server.key
<- - सौंप-सीए-फ़ाइल = / etc / kubernetes / pki / etcd / ca.crt
<- --peer-cert-file = / etc / kubernetes / pki / etcd / peer.crt
<- --peer-key-file = / etc / kubernetes / pki / etcd / peer.key
<- - क्लिंकेंट-सर्टिफिकेट-ओरी = सच
<- - पेपर-क्लाइंट-सर्टिफ़िकेट-ऑर्टिक = सच
<- --ert-file = / etc / kubernetes / pki / etcd / server.crt
<- --peer-भरोसेमंद 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
<निष्पादन:
<आदेश:
<- / बिन / श
<- -क
<- 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
<फर हो जाओ
36 ए 22,26
httpGet:
मेजबान: 127.0.0.1
पथ: / स्वास्थ्य
पोर्ट: 2379
योजना: HTTP
४३,४५ सी ३३
<नाम: आदि-डेटा
<- माउंटपाथ: / etc / kubernetes / pki / etcd

<नाम: आदि-सेरट

  name: etcd

५१,५५ सी ३ ९
<नाम: आदि-डेटा
<- hostPath:
<पथ: / etc / kubernetes / pki / etcd
<प्रकार: DirectoryOrCreate

<नाम: वगैर-सेर्ट्स

name: etcd

रूट @ योनि : ~ # ls / etc / kubernetes / pki / etcd
ca.crt ca.key healthcheck-client.crt स्वास्थ्यवर्धक

उबंटू 17.10 वगरंट पर 1.9.6 क्लस्टर:

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/9d4493e990c9bd742b317641267c3ef3640cd/Vagrantfile#L18 -L2020L

फिर रेपो में 1.10 सर्वर बायनेरी डाउनलोड करें, और वे /vagrant में अतिथि पर उपलब्ध होंगे
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

क्यूबलेट 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 क्या आप वगैरह कंटेनर के लिए लॉग आउट करने के लिए होते हैं? इसके अलावा, grep -i etcd क्यूबलेट आउटपुट में से कुछ को मास्क कर सकते हैं, उदाहरण के लिए कुछ त्रुटि संदेश जिसमें इसमें कंटेनर का नाम नहीं है, लेकिन फिर भी प्रासंगिक है।

मैंने इस बग से संबंधित एक और अजीब बढ़त मामले को मारा। Kubeadm अपग्रेड ने नई etcd इमेज को खींचे जाने और नए स्टैटिक पॉड को परिनियोजित करने से पहले etc को अपग्रेड के रूप में पूरा किया। यह अपग्रेड को बाद के चरण में टाइमआउट करने और अपग्रेड रोलबैक को विफल करने का कारण बनता है। यह भी एक टूटी हुई अवस्था में क्लस्टर छोड़ देता है। क्लस्टर को पुनर्प्राप्त करने के लिए मूल etcd स्थिर फली प्रकट को बहाल करने की आवश्यकता है।

अरे हाँ मैं भी वहाँ फँस गया हूँ। मेरा क्लस्टर पूरी तरह से बंद है। क्या कोई इस राज्य से बचाव के बारे में कुछ निर्देश साझा कर सकता है?

वहाँ मेरे उन्नयन के लिए 2 प्रयास पर, बस @detiber की तरह वर्णित है, काफी दर्दनाक। :रोना:

/ Etc / kubernetes / tmp में कुछ समर्थित सामान मिला, यह महसूस करते हुए कि etcd अपराधी हो सकता है, मैंने अपने पुराने मैनिफ़ेस्ट को मैनिफ़ेस्ट्स फ़ोल्डर में नए पर कॉपी किया। उस समय मेरे पास खोने के लिए कुछ भी नहीं था, क्योंकि मैं पूरी तरह से क्लस्टर का नियंत्रण खो चुका हूं। फिर, मुझे ठीक से याद नहीं है, लेकिन मुझे लगता है कि मैंने पूरी मशीन को फिर से शुरू किया, और बाद में सभी सामानों को v1.9.6 पर डाउनग्रेड कर दिया। आखिरकार, मैंने क्लस्टर पर नियंत्रण प्राप्त किया और फिर v1.10.0 के साथ गड़बड़ करने के लिए किसी भी प्रेरणा को खो दिया। यह बिल्कुल भी मजेदार नहीं था ...

यदि आप /etc/kubernetes/tmp से etcd स्टैटिक पॉड मैनिफ़ेस्ट को वापस रोल करते हैं, तो 1.10 में नए TLS कॉन्फ़िगरेशन के कारण Apiserver मैनिफ़ेस्ट को 1.9 संस्करण में वापस करना भी महत्वपूर्ण है।

^ आपको शायद ऐसा करने की आवश्यकता नहीं होगी, क्योंकि मेरा मानना ​​है कि कंट्रोल अपग्रेड के बाकी कॉर्ड अपग्रेड ब्लॉक को ब्लॉक करते हैं।

ऐसा लगता है कि एक असफल उन्नयन पर केवल etcd प्रकट नहीं हुआ है, बाकी सब ठीक है। बैकअप प्रकट होने पर और क्यूबलेट को फिर से शुरू करने के बाद, सब कुछ ठीक हो जाता है।

मैंने एक ही टाइमआउट समस्या का सामना किया और kubeadm ने 1.9.6 के लिए क्यूब-एपिसिसर्व रोल को वापस ले लिया, लेकिन जैसा कि (टीएलएस सक्षम है) के साथ छोड़ दिया गया है, जाहिर है, स्पष्ट रूप से गलत तरीके से असफल होने के लिए अग्रणी एपिसर्व, प्रभावी रूप से मेरे मास्टर नोड को तोड़ रहा है। एक अलग मुद्दे की रिपोर्ट के लिए अच्छा उम्मीदवार, मुझे लगता है।

@dvdmuckle @codepainters , दुर्भाग्य से यह इस बात पर निर्भर करता है कि कौन सा घटक दौड़ की स्थिति को हिट करता है (etcd या एपीआई सर्वर) कि क्या रोलबैक सफल है। मुझे रेस की स्थिति के लिए एक फिक्स मिला, लेकिन यह कुबेदम अपग्रेड को पूरी तरह से तोड़ देता है। मैं @stealthybox के साथ काम कर रहा हूं और अपग्रेड को ठीक करने के लिए आगे एक उचित रास्ता ढूंढ रहा हूं।

@codepainters मुझे लगता है कि यह एक ही मुद्दा है।

इस समस्या के कारण कुछ अंतर्निहित समस्याएं हैं:

• उन्नयन एपीआई से दर्पण फली क्वेरी के परिणाम से प्रत्येक घटक के लिए मिरर पॉड का हैश उत्पन्न कर रहा है। नवीनीकरण तब यह देखने के लिए परीक्षण करता है कि क्या यह हैशेड मान यह निर्धारित करने के लिए बदलता है कि क्या पॉड को स्थैतिक प्रकट परिवर्तन से अपडेट किया गया है। हैशेड मूल्य में वे फ़ील्ड शामिल हैं जिन्हें स्थैतिक प्रकट परिवर्तन (जैसे फली स्थिति अपडेट) के अलावा अन्य कारणों से उत्परिवर्तित किया जा सकता है। यदि पॉड की स्थिति हैश तुलना के बीच बदल जाती है, तो उन्नयन अगले घटक पर समय से पहले जारी रहेगा।
• अपग्रेड, स्टैड पॉड मेनिफ़ेस्ट अपडेट (कॉन्सर्ड में tls सुरक्षा जोड़ने सहित) करता है और यह पुष्टि करने के लिए कि पॉड अपडेट किया गया है, अप्रीज़र का उपयोग करने का प्रयास करता है, हालांकि एफ़ड्रेस मेनिफ़ेस्ट इस बिंदु पर अपडेट नहीं किया गया है ताकि कॉर्ड्स के साथ संचार करने के लिए टल्स का उपयोग किया जा सके ।

नतीजतन, अपग्रेड केवल वर्तमान में सफल होता है जब वहाँ है कि फली स्टेटस के लिए एक पॉड स्टेटस अपडेट होता है जो हैश को क्यूबलेट से पहले बदलने का कारण बनता है, आदि के लिए नए स्टैटिक मेनिफ़ेस्ट। इसके अलावा, एपि सर्वर अपग्रेड के पहले भाग के लिए उपलब्ध रहने की जरूरत है, जब अपग्रेड टूलिंग एपिवर को प्रकट करने से पहले एपीआई को क्वेरी कर रहा है।

@detiber और मुझे उन बदलावों पर चर्चा करने के लिए कॉल मिला जो हमें अपग्रेड प्रक्रिया में करने की आवश्यकता है।
हम 1.10.x पैच रिलीज़ में इस बग के लिए 3 फ़िक्सेस लागू करने की योजना बनाते हैं:

• अपग्रेड टीएलएस को अपग्रेड से हटा दें।
  वर्तमान अपग्रेड लूप क्रमिक तरीके से प्रति घटक बैच संशोधन करता है।
  किसी घटक को अपग्रेड करने पर निर्भर घटक कॉन्फ़िगरेशन का कोई ज्ञान नहीं है।
  नवीनीकरण की पुष्टि के लिए पॉड स्टेटस की जांच के लिए APIServer उपलब्ध है।
  Etcd TLS को एक युग्मित etcd + apiserver कॉन्फ़िगरेशन परिवर्तन की आवश्यकता होती है जो इस अनुबंध को तोड़ता है।
  यह इस समस्या को ठीक करने के लिए न्यूनतम व्यवहार्य परिवर्तन है, और असुरक्षित क्लस्टर के साथ उन्नत क्लस्टर छोड़ देता है।

• फली स्थिति परिवर्तन पर दर्पण-पॉड हैश रेस की स्थिति को ठीक करें।
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrad/staticpods.go#L189
  अपग्रेड अब वगैरह और एपेस्वर झंडे के बीच अनुकूलता को सही मानेंगे।

• टीएलएस को विशेष रूप से एक अलग चरण में अपग्रेड करें।
  Etcd और APIServer को एक साथ अपग्रेड करने की आवश्यकता है।
  kubeadm alpha phase ensure-etcd-tls ?
  इस चरण को एक क्लस्टर उन्नयन के स्वतंत्र रूप से चलाने योग्य होना चाहिए।
  क्लस्टर नवीनीकरण के दौरान, यह चरण सभी घटकों को अपडेट करने से पहले चलना चाहिए।

1.11 के लिए हम चाहते हैं:

• उन्नत स्थिर पॉड्स के रनटाइम चेक के लिए क्यूबलेट एपीआई का उपयोग करें।
  यह स्थानीय प्रक्रियाओं की निगरानी के लिए माफी और विश्वास पर भरोसा करने के लिए अवांछनीय है जैसे हम वर्तमान में कर रहे हैं।
  फली के बारे में डेटा का एक स्थानीय स्रोत उच्च-क्रम वितरित कुबेरनेट घटकों पर भरोसा करने के लिए बेहतर है।
  यह अपग्रेड लूप में वर्तमान पॉड रनटाइम चेक की जगह लेगा।
  यह हमें सुनिश्चित करने के लिए चेकों को जोड़ने की अनुमति देगा- etc-tls चरण।

वैकल्पिक: फली जानकारी प्राप्त करने के लिए CRI का उपयोग करें ( crictl का उपयोग करके डेमो व्यवहार्य होगा)।
चेतावनी: dockershim पर CRI और संभवतः अन्य कंटेनर रनटाइम में वर्तमान में CRI ब्रेकिंग परिवर्तन के लिए पिछड़े संगतता का समर्थन नहीं करता है।

ऐसा करने के लिए:

• [] इन 4 परिवर्तनों के लिए मुद्दों को खोलें और लिंक करें।

: पीआर स्थिर फली अद्यतन रेस स्थिति पता करने के लिए https://github.com/kubernetes/kubernetes/pull/61942
चेरी-पिक पीआर रिलीज़ -१.१० शाखा के लिए: https://github.com/kubernetes/kubernetes/pull/61954

@detiber क्या आप बताते हैं कि हम किस नस्ल की स्थिति के बारे में बात कर रहे हैं? मैं कुबेदम इंटर्नल से परिचित नहीं हूँ, फिर भी यह दिलचस्प लगता है।

@codepainters https://github.com/kubernetes/kubeadm/issues/740#issuecomment -377263347 देखें

FYI करें - 1.9.3 से एक ही समस्या / समस्या का उन्नयन
कई बार पुन: प्रयास करने की कोशिश की। अंत में रेस स्थिति w / एपीआई सर्वर को हिट करें और अपग्रेड वापस नहीं आ सके।

@stealthybox thx, मुझे यह पहली बार पढ़ने पर नहीं मिला।

मैं एक ही मुद्दा रहा हूँ .. [त्रुटि एपीसर्वरहेल्थ]: एपीआई सर्वर अस्वस्थ है; / healthz "ओके" नहीं लौटा
[ERROR MasterNodesReady]: क्लस्टर में मास्टर्स को सूचीबद्ध नहीं कर सका: उन्नयन करते समय https ....... प्राप्त करें। इसमें मेरी मदद करो। मैं 1.9.3 से 1.10.0 तक अपग्रेड कर रहा हूं। प्रारंभ में, यह "[अपग्रेड / स्टैटिकपोड्स] के कुछ बिंदु तक पहुंचने में सक्षम था, घटक को पुनरारंभ करने के लिए क्यूबलेट की प्रतीक्षा कर रहा है"।

अस्थाई वर्कअराउंड चेकों को दरकिनार करके सीट्स और अपडेवर पॉड्स को अपग्रेड करना सुनिश्चित करना है।

अपने कॉन्फ़िगरेशन की जांच करना और अपने उपयोग के मामले में किसी भी झंडे को जोड़ना सुनिश्चित करें:

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 सादा HTTP/2 TLS- सक्षम etcd ) बोलता है, मैंने इसे भी मारा। इस अन्य मुद्दे को देखें: https://github.com/kubernetes/kubeadm/issues/755

ईमानदारी से, मुझे समझ नहीं आ रहा है कि एक ही टीसीपी पोर्ट का उपयोग टीएलएस और गैर-टीएलएस etcd श्रोताओं दोनों के लिए क्यों किया जाता है, यह केवल इस तरह की परेशानी का कारण बनता है। सादा हो रहा है, पुराने _connection ने इनकार कर दिया_ तत्काल संकेत देगा, यहां मुझे यह समझने के लिए tcpdump का सहारा लेना होगा कि क्या हो रहा है।

ओह!
गोली मारो तुम सही हो, कि केवल मेरे स्थानीय TLS पैच के साथ काम करता है Etcd स्थिति जाँच के लिए।

अपग्रेड खत्म करने के लिए ऐसा करें:

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

उपरोक्त वर्कअराउंड को सही होने के लिए संपादित किया

@stealthybox दूसरा kubeadm कमांड काम नहीं करता है:

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

@renich इसे केवल अपने कॉन्फिग की फाइलपथ दें

यदि आप किसी भी कस्टम सेटिंग्स का उपयोग नहीं करते हैं, तो आप इसे एक खाली फ़ाइल पास कर सकते हैं।
यहाँ एक आसान तरीका यह है कि बाश में:

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

इसे अब https://github.com/kubernetes/kubernetes/pull/62655 के विलय के साथ हल किया जाना चाहिए और v1.10.2 रिलीज का हिस्सा होगा।

मैं इस बात की पुष्टि कर सकता हूं कि 1.10.0 -> 1.10.2 कुबड़ेम 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 से शुरू होने वाली प्रविष्टियाँ हैं।
और मुझे लगता है कि उन्नयन के दौरान क्यूब-एपेसेवर का हैश नहीं बदलता है।

मेरे पास 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 (जो बकवास हो सकता है। बस परीक्षण ...)

उबंटू 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 के साथ यह समस्या है:

यदि आप कस्टम होस्टनाम के साथ हैं, तो आपको kubeadm-config configmap को संपादित करने और नोडनाम aws के आंतरिक नाम पर सेट करने की आवश्यकता है: ip-xx-xx-xx-xx।

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

यह क्लाइंट को http पर सेट करने के अलावा है। मैं पत्र संस्करणों पर अभी तक देखने के लिए नहीं हूं कि क्या उन्होंने तय किया है।

ऐसा इसलिए है क्योंकि kubeadm इस पथ को एपीआई में पढ़ने की कोशिश करता है: / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

चूंकि टाइमआउट 1.10.6 पर बढ़ाया गया है, इसलिए मैंने कुछ हफ़्ते पहले अपनी 1.9.7 तैनाती को 1.10.6 में सफलतापूर्वक अपडेट किया है।

जैसे ही .deb पैकेज तैयार होते हैं, उसी संस्करण में 1.11.2 पर अपग्रेड करने की योजना है।

मेरा क्लस्टर ARM64 बोर्डों पर ऑन-प्रिमाइसेस चलता है।