Kubeadm: La mise à niveau de 1.9.6 vers 1.10.0 échoue avec le délai d'expiration

Travailler sur la reproduction de ce bogue localement.

Après avoir réessayé cela 10 fois, cela a finalement fonctionné

Voici mon diff manifeste etcd
`` 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:
<commande:
<- / 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
<obtenir foo
36a22,26
httpGet:
hôte: 127.0.0.1
chemin: / santé
port: 2379
schéma: HTTP
43,45c33
<nom: etcd-data
<- mountPath: / etc / kubernetes / pki / etcd

<nom: etcd-certs

  name: etcd

51,55c39
<nom: etcd-data
<- hostPath:
<chemin: / etc / kubernetes / pki / etcd
<type: DirectoryOrCreate

<nom: 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

Cluster 1.9.6 sur 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

Ceci est mon environnement de repro: https://github.com/stealthybox/vagrant-kubeadm-testing

Changez ces lignes en 1.9.6-00 pour le bootstrap: https://github.com/stealthybox/vagrant-kubeadm-testing/blob/9d4493e990c9bd742107b317641267c3ef3640cd/Vagrantfile#L18 -L20

Ensuite, téléchargez les binaires du serveur 1.10 dans le référentiel, et ils seront disponibles sur l'invité dans /vagrant
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

Journaux liés à 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 ""

La solution de contournement actuelle consiste à continuer à réessayer la mise à niveau et à un moment donné, elle réussira.

@stealthybox Est-ce que vous obtenez des journaux de docker pour le conteneur etcd? aussi, grep -i etcd peut masquer une partie de la sortie de kubelet, par exemple certains messages d'erreur qui n'ont pas de nom de conteneur, mais qui restent pertinents.

Je viens de frapper un autre cas étrange lié à ce bogue. La mise à niveau de kubeadm a marqué la mise à niveau etcd comme terminée avant que la nouvelle image etcd ne soit extraite et que le nouveau pod statique soit déployé. Cela entraîne l'expiration de la mise à niveau à une étape ultérieure et l'échec de la restauration de la mise à niveau. Cela laisse également le cluster dans un état cassé. La restauration du manifeste de pod statique etcd d'origine est nécessaire pour récupérer le cluster.

Oh oui, je suis aussi coincé là-dedans. mon cluster est complètement en panne. Quelqu'un peut-il partager des instructions sur la façon de sauver de cet état?

J'y suis allé lors de ma deuxième tentative de mise à niveau, tout comme

J'ai trouvé des éléments sauvegardés dans / etc / kubernetes / tmp, estimant que etcd pourrait être le coupable, j'ai copié son ancien manifeste sur le nouveau dans le dossier manifestes. À ce stade, je n'avais rien à perdre, car j'ai complètement perdu le contrôle du cluster. Ensuite, je ne me souviens pas exactement, mais je pense que j'ai redémarré toute la machine, et plus tard rétrogradé tous les éléments vers la v1.9.6. Finalement, j'ai pris le contrôle du cluster, puis j'ai perdu toute motivation à jouer à nouveau avec la v1.10.0. Ce n'était pas du tout amusant ...

Si vous restaurez le manifeste du pod statique etcd à partir de /etc/kubernetes/tmp il est important de restaurer également le manifeste apiserver vers la version 1.9 en raison de la nouvelle configuration TLS de la 1.10.

^ vous n'aurez probablement pas besoin de le faire car je pense que la mise à niveau etcd bloque le reste de la mise à niveau du plan de contrôle.

Il semble que seul le manifeste etcd ne soit pas restauré en cas d'échec de la mise à niveau, tout le reste va bien. Après avoir déplacé le manifeste de sauvegarde et redémarré le kubelet, tout se passe bien.

J'ai rencontré le même problème de délai d'expiration et kubeadm a restauré le manifeste de kube-apiserv vers la version 1.9.6, mais a laissé le manifeste d'etcd tel quel (lire: avec TLS activé), conduisant évidemment apiserv à échouer lamentablement, brisant efficacement mon nœud maître. Bon candidat pour un rapport de problème séparé, je suppose.

@dvdmuckle @codepainters , malheureusement, cela dépend du composant qui rencontre la condition de concurrence (etcd ou serveur api) si la restauration est réussie. J'ai trouvé un correctif pour la condition de concurrence, mais cela rompt complètement la mise à niveau de kubeadm. Je travaille avec @stealthybox pour essayer de trouver un chemin approprié pour corriger correctement la mise à niveau.

@codepainters Je pense que c'est le même problème.

Il existe quelques problèmes sous-jacents à l'origine de ce problème:

• La mise à niveau génère un hachage du pod miroir pour chaque composant à partir du résultat de l'interrogation du pod miroir à partir de l'API. La mise à niveau teste ensuite si cette valeur hachée change pour déterminer si le pod est mis à jour à partir du changement de manifeste statique. La valeur hachée inclut des champs qui peuvent être mutés pour des raisons autres que la modification du manifeste statique (telles que les mises à jour de l'état du pod). Si l'état du pod change entre les comparaisons de hachage, la mise à niveau se poursuivra prématurément vers le composant suivant.
• La mise à niveau effectue la mise à jour du manifeste du pod statique etcd (y compris l'ajout de la sécurité tls à etcd) et tente d'utiliser l'apiserver pour vérifier que le pod a été mis à jour, mais le manifeste apiserver n'a pas été mis à jour à ce stade pour utiliser tls pour communiquer avec etcd .

En conséquence, la mise à niveau ne réussit actuellement que lorsqu'il y a une mise à jour de l'état du pod pour le pod etcd qui entraîne la modification du hachage avant que le kubelet ne récupère le nouveau manifeste statique pour etcd. De plus, le serveur api doit rester disponible pour la première partie de la mise à niveau d'apiserver lorsque l'outillage de mise à niveau interroge l'API avant de mettre à jour le manifeste apiserver.

@detiber et moi avons reçu un appel pour discuter des changements que nous devons apporter au processus de mise à niveau.
Nous prévoyons d'implémenter 3 correctifs pour ce bogue dans les versions de patch

• Supprimez etcd TLS de la mise à niveau.
  La boucle de mise à niveau actuelle effectue des modifications par lots par composant de manière série.
  La mise à niveau d'un composant n'a aucune connaissance des configurations de composants dépendants.
  La vérification d'une mise à niveau nécessite que l'APIServer soit disponible pour vérifier l'état du pod.
  Etcd TLS nécessite un changement de configuration couplé etcd + apiserver qui rompt ce contrat.
  Il s'agit de la modification minimale viable pour résoudre ce problème et laisse les clusters mis à niveau avec etcd non sécurisés.

• Correction de la condition de concurrence de hachage du miroir-pod lors du changement d'état du pod.
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/staticpods.go#L189.
  Les mises à niveau seront désormais correctes en supposant la compatibilité entre les indicateurs etcd et apiserver.

• Mettez à niveau TLS spécifiquement dans une phase distincte.
  Etcd et APIServer doivent être mis à niveau ensemble.
  kubeadm alpha phase ensure-etcd-tls ?.
  Cette phase doit être exécutable indépendamment d'une mise à niveau du cluster.
  Lors d'une mise à niveau de cluster, cette phase doit s'exécuter avant la mise à jour de tous les composants.

Pour 1.11, nous voulons:

• Utilisez l'API kubelet pour les vérifications d'exécution des pods statiques mis à niveau.
  Il n'est pas souhaitable de s'appuyer sur apiserver et etcd pour surveiller les processus locaux comme nous le faisons actuellement.
  Une source locale de données sur les pods est supérieure à s'appuyer sur des composants Kubernetes distribués d'ordre supérieur.
  Cela remplacera les vérifications d'exécution actuelles du pod dans la boucle de mise à niveau.
  Cela nous permettra d'ajouter des vérifications à la phase ensure-etcd-tls.

alternative: utilisez le CRI pour obtenir des informations sur le pod (démo viable en utilisant crictl ).
mise en garde: le CRI sur dockershim et éventuellement d'autres environnements d'exécution de conteneur ne prend actuellement pas en charge la rétrocompatibilité pour les modifications de rupture CRI.

FAIRE:

• [] ouvrir et lier les problèmes pour ces 4 changements.

PR pour résoudre la condition de concurrence de la mise à jour du pod statique: https://github.com/kubernetes/kubernetes/pull/61942
PR cherry-pick pour la branche release-1.10: https://github.com/kubernetes/kubernetes/pull/61954

@detiber, cela vous dérange-

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

FYI - même problème / problème de mise à niveau à partir de la version 1.9.3
J'ai essayé la solution de contournement de réessayer un certain nombre de fois. Enfin atteint la condition de concurrence avec le serveur API et la mise à niveau n'a pas pu revenir en arrière.

@stealthybox thx, je ne l'ai pas compris en première lecture.

J'ai le même problème. [ERREUR APIServerHealth]: le serveur API est défectueux; / healthz n'a pas retourné "ok"
[ERREUR MasterNodesReady]: impossible de répertorier les maîtres dans le cluster: obtenez https ....... lors de la mise à niveau. S'il vous plait, j'ai besoin de votre aide avec ceci. Je passe de 1.9.3 à 1.10.0. Initialement, il était capable d'atteindre un certain point de "[upgrade / staticpods] En attendant que le kubelet redémarre le composant".

La solution temporaire consiste à garantir les certificats et à mettre à niveau les pods etcd et apiserver en contournant les vérifications.

Assurez-vous de vérifier votre configuration et d'ajouter des indicateurs pour votre cas d'utilisation:

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

Merci @stealthybox
Pour moi, le processus upgrade apply s'est bloqué sur [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... mais le cluster a été mis à niveau avec succès.

@stealthybox Je ne suis pas sûr, mais il semble que quelque chose soit cassé après ces étapes, car kubeadm upgrade plan se bloque après cela:

[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

Lors de l'application de la mise à jour, j'avais également pendu [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"...

@kvaps @stealthybox c'est très probablement etcd problème kubeadm parle clairement HTTP/2 à etcd ), je l'ai frappé aussi. Voir cet autre numéro: https://github.com/kubernetes/kubeadm/issues/755

Honnêtement, je ne peux pas comprendre pourquoi le même port TCP est utilisé pour les écouteurs TLS et non-TLS etcd , cela ne cause que des problèmes comme celui-ci. Être clair, l'ancienne _connexion refusée_ donnerait un indice immédiat, ici j'ai dû recourir à tcpdump pour comprendre ce qui se passait.

OH!
Shoot, vous avez raison, cela ne fonctionne qu'avec mon patch TLS local pour la vérification de l'état Etcd.

Faites ceci pour terminer la mise à niveau:

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

a modifié la solution de contournement ci-dessus pour qu'elle soit correcte

@stealthybox la deuxième commande kubeadm ne fonctionne pas:

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

@renich donnez-lui simplement le chemin du fichier de votre configuration

Si vous n'utilisez aucun paramètre personnalisé, vous pouvez lui transmettre un fichier vide.
Voici un moyen simple de le faire dans bash:

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

Cela devrait maintenant être résolu avec la fusion de https://github.com/kubernetes/kubernetes/pull/62655 et fera partie de la version v1.10.2.

Je peux confirmer que la mise à jour 1.10.0 -> 1.10.2 avec kubeadm 1.10.2 était fluide, sans délai

J'ai encore du timeout sur 1.10.0 -> 1.10.2 mais un autre:
[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]

Je ne sais pas trop quoi faire ...

@ denis111 vérifie les journaux du serveur API lors de la mise à niveau en utilisant docker ps . J'ai l'impression que vous rencontrez peut-être un problème que je rencontre également.

@dvdmuckle Eh bien, je ne vois aucune erreur dans ces journaux, seules les entrées commençant par I et quelques W.
Et je pense que le hachage de kube-apiserver ne change pas pendant la mise à niveau.

J'ai un cluster ARM64 sur 1.9.3 et mis à jour avec succès vers 1.9.7 mais j'ai le même problème de délai d'expiration pour passer de 1.9.7 à 1.10.2.

J'ai même essayé d'éditer et de recompiler kubeadm en augmentant les délais (comme ces derniers commits https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) avec les mêmes résultats.

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

Mettre à niveau v1.10.2 -> v1.10.2 (ce qui peut être absurde. Juste des tests ...)

Ubuntu 16.04.

Et cela échoue avec une erreur.

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]

Je me demande si cela est toujours suivi sur un problème ... impossible de trouver.

Je constate également que les mises à niveau échouent toujours avec l'erreur timed out waiting for the condition .

Edit: discussion déplacée vers un nouveau ticket https://github.com/kubernetes/kubeadm/issues/850 , veuillez en discuter.

Si quelqu'un d'autre a ce problème avec 1.9.x:

Si vous êtes dans aws avec des noms d'hôte personnalisés, vous devez modifier la configuration de kubeadm-config et définir à nodeName le nom interne aws: ip-xx-xx-xx-xx. $ REGION.compute.internal)

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

Ceci en plus de définir le client etc sur http. Je ne suis pas encore sur les versions de lettre pour voir si elles ont corrigé cela.

C'est parce que kubeadm essaie de lire ce chemin dans api: / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

Depuis que le délai d'expiration a été augmenté sur 1.10.6, j'ai mis à jour avec succès mon déploiement 1.9.7 vers 1.10.6 il y a quelques semaines.

Planification de la mise à niveau vers la 1.11.2 dès que les packages .deb seront prêts car les mêmes modifications sont présentes dans cette version.

Mon cluster fonctionne sur site sur des cartes ARM64.