Kubeadm: Das Upgrade von 1.9.6 auf 1.10.0 schlägt mit Zeitüberschreitung fehl

Arbeiten an der lokalen Reproduktion dieses Fehlers.

Nachdem ich dies 10 Mal wiederholt hatte, funktionierte es schließlich

Hier ist mein etcd manifest 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

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

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

29,35d20
<exec:
<Befehl:
<- / 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:
Host: 127.0.0.1
Pfad: / Gesundheit
Hafen: 2379
Schema: HTTP
43,45c33
<name: etcd-data
<- mountPath: / etc / kubernetes / pki / etcd

<name: etcd-certs

  name: etcd

51,55c39
<name: etcd-data
<- hostPath:
<Pfad: / etc / kubernetes / pki / etcd
<Typ: DirectoryOrCreate

<name: 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 Cluster unter 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

Dies ist meine Repro-Umgebung: https://github.com/stealthybox/vagrant-kubeadm-testing

Ändern Sie diese Zeilen für den Bootstrap in 1.9.6-00 : https://github.com/stealthybox/vagrant-kubeadm-testing/blob/9d4493e990c9bd742107b317641267c3ef3640cd/Vagrantfile#L18 -L20

Laden Sie dann die 1.10-Server-Binärdateien in das Repo herunter, und sie sind für den Gast in /vagrant verfügbar
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

kubelet etcd verwandte Protokolle:

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 ""

Die aktuelle Problemumgehung besteht darin, das Upgrade erneut zu versuchen, und irgendwann wird es erfolgreich sein.

@stealthybox Bekommst du zufällig Protokolle aus dem Docker für den etcd-Container? Außerdem maskiert grep -i etcd möglicherweise einen Teil der Kubelet-Ausgabe, z. B. einige Fehlermeldungen, die keinen Containernamen enthalten, aber dennoch relevant sind.

Ich habe gerade einen anderen seltsamen Randfall getroffen, der mit diesem Fehler zusammenhängt. Das kubeadm-Upgrade hat das etcd-Upgrade als abgeschlossen markiert, bevor das neue etcd-Image abgerufen und der neue statische Pod bereitgestellt wurde. Dies führt dazu, dass das Upgrade zu einem späteren Zeitpunkt abläuft und das Upgrade-Rollback fehlschlägt. Dadurch bleibt der Cluster auch in einem fehlerhaften Zustand. Das Wiederherstellen des ursprünglichen statischen Pod-Manifests etcd ist erforderlich, um den Cluster wiederherzustellen.

Oh ja, ich stecke auch da drin fest. Mein Cluster ist komplett ausgefallen. Kann jemand Anweisungen zur Rettung aus diesem Zustand geben?

Ich war bei meinem zweiten Upgrade-Versuch dabei, genau wie @detiber beschrieben, ziemlich schmerzhaft. :Schrei:

Ich habe einige gesicherte Inhalte in / etc / kubernetes / tmp gefunden und das Gefühl, dass etcd der Schuldige sein könnte. Ich habe das alte Manifest über das neue im Ordner "Manifeste" kopiert. Zu diesem Zeitpunkt hatte ich nichts zu verlieren, da ich die Kontrolle über den Cluster völlig verloren hatte. Dann erinnere ich mich nicht genau, aber ich glaube, ich habe den gesamten Computer neu gestartet und später alle Inhalte wieder auf Version 1.9.6 heruntergestuft. Schließlich erlangte ich die Kontrolle über den Cluster und verlor dann jegliche Motivation, mich erneut mit v1.10.0 zu beschäftigen. Es hat überhaupt keinen Spaß gemacht ...

Wenn Sie das statische Pod-Manifest etcd von /etc/kubernetes/tmp zurücksetzen, ist es wichtig, das Apiserver-Manifest aufgrund der neuen TLS-Konfiguration in 1.10 auch auf die Version 1.9 zurückzusetzen.

^ Sie müssen dies wahrscheinlich nicht tun, da ich glaube, dass das etcd-Upgrade den Rest des Controlplane-Upgrades blockiert.

Es scheint, dass bei einem fehlgeschlagenen Upgrade nicht nur das etcd-Manifest zurückgesetzt wird, alles andere ist in Ordnung. Nachdem Sie das Sicherungsmanifest verschoben und das Kubelet neu gestartet haben, ist alles wieder in Ordnung.

Ich hatte das gleiche Timeout-Problem und kubeadm hat das kube-apiserv-Manifest auf 1.9.6 zurückgesetzt, aber das etcd-Manifest wie es ist (lesen: mit aktiviertem TLS) belassen, was offensichtlich dazu führte, dass apiserv kläglich versagte und meinen Masterknoten effektiv brach. Ich nehme an, ein guter Kandidat für einen separaten Themenbericht.

@dvdmuckle @codepainters , leider hängt es davon ab, welche Komponente die Race-Bedingung erfüllt (etcd oder API-Server), ob das Rollback erfolgreich ist. Ich habe eine Lösung für die Rennbedingung gefunden, aber sie bricht das Kubeadm-Upgrade vollständig ab. Ich arbeite mit @stealthybox zusammen , um einen geeigneten Weg für die ordnungsgemäße Behebung des Upgrades zu finden.

@codepainters Ich denke, es ist das gleiche Problem.

Es gibt einige zugrunde liegende Probleme, die dieses Problem verursachen:

• Das Upgrade generiert einen Hash des Spiegel-Pods für jede Komponente aus dem Ergebnis der Abfrage des Spiegel-Pods über die API. Das Upgrade testet dann, ob sich dieser Hash-Wert ändert, um festzustellen, ob der Pod aufgrund der statischen Manifeständerung aktualisiert wurde. Der Hash-Wert enthält Felder, die aus anderen Gründen als der statischen Manifeständerung (z. B. Aktualisierungen des Pod-Status) mutiert werden können. Wenn sich der Pod-Status zwischen den Hash-Vergleichen ändert, wird das Upgrade vorzeitig zur nächsten Komponente fortgesetzt.
• Das Upgrade führt die Aktualisierung des statischen Pod-Manifests etcd durch (einschließlich des Hinzufügens von tls-Sicherheit zu etcd) und versucht, mithilfe des Apiservers zu überprüfen, ob der Pod aktualisiert wurde. Das Apiserver-Manifest wurde jedoch zu diesem Zeitpunkt noch nicht aktualisiert, um tls für die Kommunikation mit etcd zu verwenden .

Infolgedessen ist das Upgrade derzeit nur dann erfolgreich, wenn zufällig eine Pod-Statusaktualisierung für den etcd-Pod erfolgt, bei der sich der Hash ändert, bevor das Kubelet das neue statische Manifest für etcd aufnimmt. Darüber hinaus muss der API-Server für den ersten Teil des Apiserver-Upgrades verfügbar bleiben, wenn das Upgrade-Tool die API abfragt, bevor das Apiserver-Manifest aktualisiert wird.

@detiber und ich haben einen Anruf erhalten, um die Änderungen zu besprechen, die wir am Upgrade-Prozess vornehmen müssen.
Wir planen, 3 Fixes für diesen Fehler in den Patch-Versionen 1.10.x zu implementieren:

• Entfernen Sie etcd TLS aus dem Upgrade.
  Die aktuelle Upgrade-Schleife führt Batch-Änderungen pro Komponente seriell durch.
  Das Aktualisieren einer Komponente kennt keine abhängigen Komponentenkonfigurationen.
  Um ein Upgrade zu überprüfen, muss der APIServer verfügbar sein, um den Pod-Status zu überprüfen.
  Etcd TLS erfordert eine gekoppelte Konfigurationsänderung von etcd + apiserver, die diesen Vertrag bricht.
  Dies ist die minimal durchführbare Änderung, um dieses Problem zu beheben, und führt dazu, dass aktualisierte Cluster mit unsicherem usw.

• Korrigieren Sie die Spiegel-Pod-Hash-Race-Bedingung bei Änderung des Pod-Status.
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/staticpods.go#L189.
  Upgrades sind jetzt korrekt, sofern die Kompatibilität zwischen etcd- und Apiserver-Flags gegeben ist.

• Aktualisieren Sie TLS speziell in einer separaten Phase.
  Etcd und der APIServer müssen zusammen aktualisiert werden.
  kubeadm alpha phase ensure-etcd-tls ?.
  Diese Phase sollte unabhängig von einem Cluster-Upgrade ausgeführt werden können.
  Während eines Cluster-Upgrades sollte diese Phase ausgeführt werden, bevor alle Komponenten aktualisiert werden.

Für 1.11 wollen wir:

• Verwenden Sie die Kubelet-API zur Laufzeitprüfung aktualisierter statischer Pods.
  Es ist unerwünscht, sich auf den Apiserver und etcd zu verlassen, um lokale Prozesse zu überwachen, wie wir es derzeit tun.
  Eine lokale Datenquelle über Pods ist der Verwendung verteilter Kubernetes-Komponenten höherer Ordnung überlegen.
  Dies ersetzt die aktuellen Pod-Laufzeitprüfungen in der Upgrade-Schleife.
  Auf diese Weise können wir der Phase "verify-etcd-tls" Überprüfungen hinzufügen.

Alternative: Verwenden Sie den CRI, um Pod-Informationen abzurufen (Demo mit crictl ).
Einschränkung: CRI auf Dockershim und möglicherweise anderen Containerlaufzeiten unterstützt derzeit keine Abwärtskompatibilität für CRI-Änderungen.

MACHEN:

• [] Probleme für diese 4 Änderungen öffnen und verknüpfen.

PR zur Behebung der statischen Pod-Update-Race-Bedingung: https://github.com/kubernetes/kubernetes/pull/61942
Cherry-Pick-PR für Release-1.10-Zweig: https://github.com/kubernetes/kubernetes/pull/61954

@detiber Hast du etwas dagegen zu erklären, über welche Rennbedingungen wir sprechen? Ich bin nicht so vertraut mit Kubeadm-Interna, aber es klingt interessant.

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

Zu Ihrer Information - das gleiche Problem / Problem-Upgrade von 1.9.3
Versuchte die Problemumgehung, es mehrmals zu versuchen. Treffen Sie schließlich die Race-Bedingung mit dem API-Server und das Upgrade konnte nicht zurückgesetzt werden.

@stealthybox thx, ich habe es beim ersten Lesen nicht bekommen.

Ich habe das gleiche Problem. [ERROR APIServerHealth]: Der API-Server ist fehlerhaft. / healthz hat nicht "ok" zurückgegeben
[ERROR MasterNodesReady]: Master im Cluster konnten nicht aufgelistet werden: Beim Upgrade https ....... abrufen. Bitte helfen Sie mir dabei. Ich aktualisiere von 1.9.3 auf 1.10.0. Anfänglich war es möglich, einen bestimmten Punkt von "[upgrade / staticpods] Warten auf den Neustart der Komponente durch das Kubelet" zu erreichen.

Temporäre Problemumgehung besteht darin, Zertifikate sicherzustellen und die etcd- und apiserver-Pods zu aktualisieren, indem die Überprüfungen umgangen werden.

Überprüfen Sie unbedingt Ihre Konfiguration und fügen Sie Flags für Ihren Anwendungsfall hinzu:

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

Danke @stealthybox
Für mich ist der upgrade apply -Prozess auf [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... ins Stocken geraten, der Cluster wurde jedoch erfolgreich aktualisiert.

@stealthybox Ich bin mir nicht sicher, aber es scheint, dass nach diesen Schritten etwas kaputt ist, weil kubeadm upgrade plan hängt:

[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

Beim Anwenden des Updates hatte ich auch [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... gehängt

@kvaps @stealthybox Dies ist höchstwahrscheinlich ein etcd Problem ( kubeadm spricht einfach HTTP/2 für TLS-fähige etcd ), ich habe es auch getroffen. Siehe dieses andere Problem: https://github.com/kubernetes/kubeadm/issues/755

Ehrlich gesagt, kann ich nicht verstehen , warum die gleiche TCP - Port ist für sowohl TLS verwendet und nicht-TLS etcd Zuhörer, es verursacht nur Probleme wie diese. Klar zu werden, alte Verbindung abgelehnt würde sofort einen Hinweis geben, hier musste ich auf tcpdump zurückgreifen, um zu verstehen, was los ist.

OH!
Schießen Sie, Sie haben Recht, das funktioniert nur mit meinem lokalen TLS-Patch für die Etcd-Statusprüfung.

Führen Sie dies aus, um das Upgrade abzuschließen:

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

Die obige Problemumgehung wurde bearbeitet, um korrekt zu sein

@stealthybox Der zweite kubeadm-Befehl funktioniert nicht:

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

@renich gib ihm einfach den Dateipfad deiner Konfiguration

Wenn Sie keine benutzerdefinierten Einstellungen verwenden, können Sie eine leere Datei übergeben.
Hier ist eine einfache Möglichkeit, dies in Bash zu tun:

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

Dies sollte nun durch das Zusammenführen von https://github.com/kubernetes/kubernetes/pull/62655 behoben werden und wird Teil der Version 1.10.2 sein.

Ich kann bestätigen, dass das Upgrade von 1.10.0 -> 1.10.2 mit kubeadm 1.10.2 reibungslos verlief und keine Zeitüberschreitungen auftraten

Ich habe noch eine Zeitüberschreitung bei 1.10.0 -> 1.10.2, aber eine andere:
[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]

Ich bin mir nicht sicher, was ich tun soll ...

@ denis111 Überprüfen Sie die API-Serverprotokolle während des Upgrades mit docker ps . Ich habe das Gefühl, dass Sie auf ein Problem stoßen, auf das ich auch stoße.

@dvdmuckle Nun, ich sehe keinen Fehler in diesen Protokollen, nur Einträge, die mit I und ein paar W beginnen.
Und ich denke, der Hash von kube-apiserver ändert sich während des Upgrades nicht.

Ich habe einen ARM64-Cluster auf 1.9.3 und erfolgreich auf 1.9.7 aktualisiert, habe aber das gleiche Timeout-Problem beim Upgrade von 1.9.7 auf 1.10.2.

Ich habe sogar versucht, kubeadm zu bearbeiten und neu zu kompilieren, um die Zeitüberschreitungen zu erhöhen (wie diese letzten Commits https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork), mit denselben Ergebnissen.

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

Upgrade v1.10.2 -> v1.10.2 (was Unsinn sein kann. Nur testen ...)

Ubuntu 16.04.

Und es schlägt mit einem Fehler fehl.

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]

Ich frage mich, ob dies zu einem bestimmten Thema noch verfolgt wird ... nicht gefunden werden konnte.

Ich sehe auch, dass Upgrades immer noch mit dem Fehler timed out waiting for the condition fehlschlagen.

Bearbeiten: Diskussion auf ein neues Ticket verschoben https://github.com/kubernetes/kubeadm/issues/850 , bitte dort diskutieren.

Wenn jemand anderes dieses Problem mit 1.9.x hat:

Wenn Sie mit benutzerdefinierten Hostnamen in aws arbeiten, müssen Sie die kubeadm-config-Konfigurationskarte bearbeiten und unter nodeName den internen aws-Namen festlegen: ip-xx-xx-xx-xx. $ REGION.compute.internal)

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

Dies neben der Einstellung etc Client auf http. Ich bin noch nicht in Briefversionen, um zu sehen, ob sie das behoben haben.

Dies liegt daran, dass kubeadm versucht, diesen Pfad in api zu lesen: / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

Da das Timeout auf 1.10.6 erhöht wurde, habe ich meine 1.9.7-Bereitstellung vor einigen Wochen erfolgreich auf 1.10.6 aktualisiert.

Planen Sie ein Upgrade auf 1.11.2, sobald die .deb-Pakete bereit sind, da dieselben Änderungen in dieser Version vorgenommen wurden.

Mein Cluster wird lokal auf ARM64-Karten ausgeführt.