Kubeadm: الترقية من 1.9.6 إلى 1.10.0 تفشل مع انتهاء المهلة

العمل على إعادة إنتاج هذا الخطأ محليًا.

بعد إعادة محاولة هذا 10 مرات نجحت في النهاية

ها هو بلدي فرق البيان الخ
"" 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 ، 27 ج 19
<- --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
<- - العميل- cert-auth = صحيح
<- --peer-client-cert-auth = صحيح
<- --cert-file = / etc / kubernetes / pki / etcd / server.crt
<- --peer-trust-ca-file = / etc / kubernetes / pki / etcd / ca.crt

<image: gcr.io/google_containers/etcd-amd64:3.1.12

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

29،35 د 20
<إكسيك:
<الأمر:
<- / بن / ش
<- -ج
<- ETCDCTL_API = 3 etcdctl - نقاط النهاية = 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
http الحصول على:
المضيف: 127.0.0.1
المسار: / الصحة
المنفذ: 2379
المخطط: HTTP
43،45 ج 33
<الاسم: etcd-data
<- mountPath: / etc / kubernetes / pki / etcd

<الاسم: etcd-certs

  name: etcd

51،55 ج 39
<الاسم: etcd-data
<- hostPath:
<المسار: / 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

هذه هي بيئة Repro الخاصة بي: 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 هل grep -i etcd بعضًا من مخرجات kubelet ، على سبيل المثال بعض رسائل الخطأ التي لا تحتوي على اسم حاوية فيها ، ولكنها لا تزال ذات صلة.

لقد أصبت للتو بحالة غريبة أخرى تتعلق بهذا الخطأ. حددت ترقية kubeadm ترقية etcd على أنها مكتملة قبل سحب الصورة الجديدة وما إلى ذلك ونشر الكبسولة الثابتة الجديدة. يؤدي هذا إلى انتهاء مهلة الترقية في خطوة لاحقة وفشل التراجع عن الترقية. هذا أيضًا يترك الكتلة في حالة كسر. استعادة بيان جراب ثابت etcd الأصلي مطلوب لاستعادة الكتلة.

أوه نعم أنا أيضًا عالق هناك. مجموعتي معطلة تمامًا. هل يمكن لأحد أن يشارك ببعض التعليمات حول كيفية الإنقاذ من هذه الحالة؟

كنت هناك في محاولتي الثانية للترقية ، تمامًا مثل وصف detiber ،

عثرت على بعض العناصر التي تم نسخها احتياطيًا في / etc / kubernetes / tmp ، وشعرت أن etcd قد يكون الجاني ، قمت بنسخ بيانه القديم على الملف الجديد في مجلد المانيفست. في تلك المرحلة لم يكن لدي ما أخسره ، لأنني فقدت السيطرة على الكتلة تمامًا. بعد ذلك ، لا أتذكر بالضبط ، لكنني أعتقد أنني أعدت تشغيل الجهاز بالكامل ، وبعد ذلك قمت بخفض مستوى جميع الأشياء إلى الإصدار 1.9.6. في النهاية ، اكتسبت السيطرة على الكتلة ثم فقدت أي دافع للعبث بـ v1.10.0 مرة أخرى. لم يكن الأمر ممتعًا على الإطلاق ...

إذا قمت باسترجاع بيان البود الثابت etcd من /etc/kubernetes/tmp فمن المهم أيضًا التراجع عن بيان apiserver إلى الإصدار 1.9 بسبب تكوين TLS الجديد في 1.10.

^ ربما لن تحتاج إلى القيام بذلك لأنني أعتقد أن ترقية etcd تحظر بقية ترقية لوحة التحكم.

يبدو أن ملف etcd فقط لا يتم التراجع عنه في حالة فشل الترقية ، وكل شيء آخر على ما يرام. بعد نقل بيان النسخ الاحتياطي وإعادة تشغيل kubelet ، يعود كل شيء على ما يرام.

لقد واجهت مشكلة المهلة نفسها وأعاد kubeadm بيان kube-apiserv للخلف إلى 1.9.6 ، ولكن تم تركه كما هو (اقرأ: مع تمكين TLS) ، مما أدى بوضوح إلى فشل apiserv بشكل بائس ، وكسر عقدي الرئيسية بشكل فعال. مرشح جيد لتقرير مشكلة منفصل ، على ما أعتقد.

codepaintersdvdmuckle، للأسف فإنه يعتمد على الذي يضرب المكونة حالة السباق (etcd أو خادم API) ما إذا كان التراجع ناجحة. لقد وجدت إصلاحًا لحالة السباق ، لكنه يكسر تمامًا ترقية kubeadm. أنا أعمل مع stealthybox لمحاولة العثور على مسار مناسب للأمام لإصلاح الترقية بشكل صحيح.

codepainters أعتقد أنها نفس المشكلة.

هناك بعض المشاكل الأساسية التي تسبب هذه المشكلة:

• تقوم الترقية بإنشاء تجزئة لحجرة النسخ المتطابقة لكل مكون من نتيجة الاستعلام عن جراب المرآة من واجهة برمجة التطبيقات. ثم تختبر الترقية بعد ذلك لمعرفة ما إذا كانت هذه القيمة المجزأة قد تغيرت لتحديد ما إذا تم تحديث الكبسولة من تغيير البيان الثابت. تتضمن القيمة المجزأة الحقول التي يمكن تغييرها لأسباب أخرى غير تغيير البيان الثابت (مثل تحديثات حالة الحجرة). إذا تغيرت حالة البود بين مقارنات التجزئة ، فستستمر الترقية إلى المكون التالي قبل الأوان.
• تقوم الترقية بتحديث بيان pod الثابت etcd (بما في ذلك إضافة أمان tls إلى etcd) وتحاول استخدام apiserver للتحقق من تحديث البود ، ومع ذلك لم يتم تحديث بيان apiserver في هذه المرحلة لاستخدام tls للتواصل مع etcd .

نتيجة لذلك ، لا تنجح الترقية حاليًا إلا عندما يحدث تحديث لحالة pod لحجرة etcd التي تتسبب في تغيير التجزئة قبل أن يلتقط kubelet البيان الثابت الجديد لـ etcd. بالإضافة إلى ذلك ، يجب أن يظل خادم api متاحًا للجزء الأول من ترقية الخادم عندما تقوم أدوات الترقية بالاستعلام عن واجهة برمجة التطبيقات قبل تحديث بيان الخادم.

تلقيتُ مكالمةdetiber لمناقشة التغييرات التي نحتاج إلى
نخطط لتنفيذ 3 إصلاحات لهذا الخطأ في إصدارات التصحيح 1.10.x :

• إزالة etcd TLS من الترقية.
  تقوم حلقة الترقية الحالية بإجراء تعديلات على الدُفعات لكل مكون بطريقة تسلسلية.
  ترقية أحد المكونات ليس لديه معرفة بتكوينات المكونات التابعة.
  يتطلب التحقق من الترقية أن يكون خادم APIServer متاحًا للتحقق من حالة البود.
  يتطلب Etcd TLS تغيير تكوين الخادوم + الخادوم المقترن الذي يكسر هذا العقد.
  هذا هو الحد الأدنى من التغيير القابل للتطبيق لإصلاح هذه المشكلة ، ويترك المجموعات التي تمت ترقيتها مع إلخ غير الآمنة.

• إصلاح حالة سباق تجزئة المرآة عند تغيير حالة الجراب.
  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 نريد:

• استخدم kubelet API لفحص وقت التشغيل للقرون الثابتة التي تمت ترقيتها.
  من غير المرغوب فيه الاعتماد على apiserver و etcd لمراقبة العمليات المحلية كما نفعل حاليًا.
  يتفوق المصدر المحلي للبيانات حول القرون على الاعتماد على مكونات kubernetes الموزعة ذات الترتيب الأعلى.
  سيحل هذا محل عمليات التحقق من وقت تشغيل البود الحالي في حلقة الترقية.
  سيسمح لنا هذا بإضافة الشيكات إلى مرحلة الضمان etcd-tls.

بديل: استخدم CRI للحصول على معلومات pod (عرض قابل للتطبيق باستخدام crictl ).
تحذير: لا يدعم CRI في dockershim وربما أوقات تشغيل الحاوية الأخرى حاليًا التوافق مع الإصدارات السابقة لتغييرات كسر CRI.

لكى يفعل:

• [] فتح وربط القضايا لهذه التغييرات الأربعة.

PR لمعالجة حالة سباق تحديث البود الثابت: https://github.com/kubernetes/kubernetes/pull/61942
cherry-pick PR for release-1.10 الفرع: 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 لم يُرجع "موافق"
[خطأ MasterNodesReady]: تعذر سرد العناصر الرئيسية في المجموعة: احصل على https ....... أثناء الترقية. من فضلك ساعدني في هذا الشئ. أقوم بالترقية من 1.9.3 إلى 1.10.0. في البداية ، كان قادرًا على الوصول إلى نقطة معينة من "[الترقية / staticpods] في انتظار kubelet لإعادة تشغيل المكون".

الحل المؤقت هو ضمان الشهادات وترقية حافظة الخادوم والخادم عن طريق تجاوز عمليات التحقق.

تأكد من التحقق من التكوين الخاص بك وإضافة أي علامات لحالة الاستخدام الخاصة بك:

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"... أيضًا

kvapsstealthybox وهذا هو الأرجح etcd المسألة ( kubeadm يتحدث سهل HTTP/2 لTLS تمكين etcd )، أنا ضربت أيضا. راجع هذه المشكلة الأخرى: https://github.com/kubernetes/kubeadm/issues/755

بصراحة ، لا أستطيع أن أفهم لماذا يتم استخدام نفس منفذ TCP لكل من مستمعي TLS وغير TLS etcd ، فهو يسبب مشاكل مثل هذه فقط. إن رفض الاتصال القديم البسيط من شأنه أن يعطي تلميحًا فوريًا ، وهنا اضطررت إلى اللجوء إلى 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 فقط أعطه مسار ملف التكوين الخاص بك

إذا كنت لا تستخدم أي إعدادات مخصصة ، فيمكنك تمرير ملف فارغ.
إليك طريقة بسيطة للقيام بذلك في bash:

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 مع kubeadm 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 تحقق من سجلات خادم API أثناء إجراء الترقية باستخدام docker ps . أشعر أنك قد تواجه مشكلة أنا أيضًا أواجهها.

dvdmuckle حسنًا ، لا أرى أي خطأ في تلك السجلات ، فقط الإدخالات التي تبدأ بـ I وعدد قليل من W.
وأعتقد أن تجزئة kube-apiserver لا تتغير أثناء الترقية.

لدي مجموعة ARM64 على 1.9.3 وتم تحديثها بنجاح إلى 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.0

وفشل مع وجود خطأ.

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 وتعيين الاسم الداخلي aws في nodeName: ip-xx-xx-xx-xx. $ REGION.compute.internal)

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

هذا إلى جانب تعيين عميل إلخ إلى http. لم أستخدم إصدارات الرسائل حتى الآن لمعرفة ما إذا كانوا قد أصلحوا ذلك.

هذا لأن kubeadm يحاول قراءة هذا المسار في api: / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

منذ زيادة المهلة على 1.10.6 ، لقد نجحت في تحديث نشر 1.9.7 الخاص بي إلى 1.10.6 قبل أسبوعين.

التخطيط للترقية إلى 1.11.2 بمجرد أن تصبح حزم .deb جاهزة لأن نفس التغييرات في هذا الإصدار.

تعمل مجموعتي محليًا على لوحات ARM64.