Kubeadm: La actualización de 1.9.6 a 1.10.0 falla con el tiempo de espera

Trabajando en la reproducción de este error localmente.

Después de volver a intentarlo 10 veces finalmente funcionó

Aquí está mi diferencia de manifiesto de 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
<- - archivo-clave = / 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-trust-ca-file = / etc / kubernetes / pki / etcd / ca.crt

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

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

29,35d20
<ejecutivo:
<comando:
<- / 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
<conseguir foo
36a22,26
httpGet:
anfitrión: 127.0.0.1
camino: / salud
puerto: 2379
esquema: HTTP
43,45c33
<nombre: etcd-data
<- ruta de montaje: / etc / kubernetes / pki / etcd

<nombre: etcd-certs

  name: etcd

51,55c39
<nombre: etcd-data
<- ruta de host:
<ruta: / etc / kubernetes / pki / etcd
<tipo: DirectoryOrCreate

<nombre: etcd-certs

name: etcd

root @ vagabundo : ~ # 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 clúster en 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

Este es mi entorno de reproducción: https://github.com/stealthybox/vagrant-kubeadm-testing

Cambie estas líneas a 1.9.6-00 para el bootstrap: https://github.com/stealthybox/vagrant-kubeadm-testing/blob/9d4493e990c9bd742107b317641267c3ef3640cd/Vagrantfile#L18 -L20

Luego descargue los binarios del servidor 1.10 en el repositorio, y estarán disponibles para el invitado en /vagrant
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

Registros relacionados con 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 solución alternativa actual es seguir reintentando la actualización y, en algún momento, se realizará correctamente.

@stealthybox ¿Obtiene registros de la ventana acoplable para el contenedor etcd? Además, grep -i etcd podría estar enmascarando parte de la salida de kubelet, por ejemplo, algunos mensajes de error que no tienen el nombre del contenedor, pero siguen siendo relevantes.

Acabo de encontrar otro caso de borde extraño relacionado con este error. La actualización de kubeadm marcó la actualización de etcd como completa antes de que se extrajera la nueva imagen de etcd y se implementara el nuevo pod estático. Esto hace que se agote el tiempo de espera de la actualización en un paso posterior y que falle la reversión de la actualización. Esto también deja el clúster en un estado roto. Es necesario restaurar el manifiesto del pod estático original de etcd para recuperar el clúster.

Oh, sí, también estoy atrapado allí. mi clúster está completamente caído. ¿Alguien puede compartir algunas instrucciones sobre cómo rescatar de este estado?

Estuve allí en mi segundo intento de actualización, como lo describió

Encontré algunas copias de seguridad en / etc / kubernetes / tmp, sintiendo que etcd podría ser el culpable, copié su antiguo manifiesto sobre el nuevo en la carpeta de manifiestos. En ese momento no tenía nada que perder, porque perdí por completo el control del grupo. Entonces, no recuerdo exactamente, pero creo que reinicié toda la máquina y luego bajé todas las cosas a la v1.9.6. Finalmente, obtuve el control del clúster y luego perdí la motivación para volver a meterme con la v1.10.0. No fue nada divertido ...

Si revierte el manifiesto de pod estático etcd de /etc/kubernetes/tmp , es importante revertir también el manifiesto de apiserver a la versión 1.9 debido a la nueva configuración de TLS en 1.10.

^ Sin embargo, probablemente no necesite hacer esto porque creo que la actualización de etcd bloquea el resto de la actualización del plano de control.

Parece que solo el manifiesto etcd no se revierte en una actualización fallida, todo lo demás está bien. Después de mover el manifiesto de respaldo y reiniciar el kubelet, todo vuelve bien.

Me enfrenté al mismo problema de tiempo de espera y kubeadm revertió el manifiesto de kube-apiserv a 1.9.6, pero dejé el manifiesto de etcd como está (léase: con TLS habilitado), obviamente, lo que llevó a apiserv a fallar miserablemente, rompiendo efectivamente mi nodo maestro. Buen candidato para un informe de problemas por separado, supongo.

@dvdmuckle @codepainters , desafortunadamente depende de qué componente alcance la condición de carrera (etcd o servidor api) si la reversión es exitosa. Encontré una solución para la condición de carrera, pero rompe por completo la actualización de kubeadm. Estoy trabajando con @stealthybox para intentar encontrar un camino adecuado a seguir para solucionar correctamente la actualización.

@codepainters Creo que es el mismo problema.

Hay algunos problemas subyacentes que causan este problema:

• La actualización genera un hash del módulo de espejo para cada componente a partir del resultado de consultar el módulo de espejo desde la API. Luego, la actualización prueba para ver si este valor hash cambia para determinar si el pod se actualiza a partir del cambio del manifiesto estático. El valor hash incluye campos que se pueden modificar por motivos distintos al cambio del manifiesto estático (como actualizaciones de estado del pod). Si el estado del pod cambia entre las comparaciones de hash, la actualización continuará al siguiente componente antes de tiempo.
• La actualización realiza la actualización del manifiesto de pod estático de etcd (incluida la adición de seguridad de tls a etcd) e intenta usar el apiserver para verificar que el pod se haya actualizado; sin embargo, el manifiesto de apiserver no se ha actualizado en este punto para usar tls para comunicarse con etcd .

Como resultado, la actualización solo tiene éxito actualmente cuando hay una actualización de estado del pod para el pod etcd que hace que el hash cambie antes de que kubelet recoja el nuevo manifiesto estático para etcd. Además, el servidor api debe permanecer disponible durante la primera parte de la actualización de apiserver cuando las herramientas de actualización consultan la api antes de actualizar el manifiesto de apiserver.

@detiber y yo recibimos una llamada para discutir los cambios que debemos realizar en el proceso de actualización.
Planeamos implementar 3 correcciones para este error en las versiones del parche

• Elimine etcd TLS de la actualización.
  El ciclo de actualización actual realiza modificaciones por lotes por componente de una manera en serie.
  La actualización de un componente no tiene conocimiento de las configuraciones de los componentes dependientes.
  La verificación de una actualización requiere que APIServer esté disponible para verificar el estado del módulo.
  Etcd TLS requiere un cambio de configuración de etcd + apiserver acoplado que rompe este contrato.
  Este es el cambio mínimo viable para solucionar este problema y deja los clústeres actualizados con etcd inseguros.

• Corrija la condición de carrera de hash de la cápsula espejo en el cambio de estado de la cápsula.
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/staticpods.go#L189.
  Las actualizaciones ahora serán correctas asumiendo la compatibilidad entre los indicadores etcd y apiserver.

• Actualice TLS específicamente en una fase separada.
  Etcd y APIServer deben actualizarse juntos.
  kubeadm alpha phase ensure-etcd-tls ?.
  Esta fase debe poder ejecutarse independientemente de una actualización de clúster.
  Durante una actualización de clúster, esta fase debe ejecutarse antes de actualizar todos los componentes.

Para 1.11 queremos:

• Utilice la API de kubelet para realizar comprobaciones en tiempo de ejecución de pods estáticos actualizados.
  No es deseable depender de apiserver y etcd para monitorear los procesos locales como lo estamos haciendo actualmente.
  Una fuente local de datos sobre pods es superior a depender de componentes de Kubernetes distribuidos de orden superior.
  Esto reemplazará las comprobaciones actuales del tiempo de ejecución del pod en el ciclo de actualización.
  Esto nos permitirá agregar comprobaciones a la fase asegurar-etcd-tls.

alternativa: use el CRI para obtener información sobre el pod (la demostración es viable usando crictl ).
advertencia: CRI en dockershim y posiblemente otros tiempos de ejecución de contenedores no admite actualmente la compatibilidad con versiones anteriores para los cambios importantes de CRI.

QUE HACER:

• [] problemas de apertura y enlace para estos 4 cambios.

PR para abordar la condición de carrera de actualización de la vaina estática: https://github.com/kubernetes/kubernetes/pull/61942
Cherry-pick PR para la rama release-1.10: https://github.com/kubernetes/kubernetes/pull/61954

@detiber ¿te importaría explicar de qué condición de carrera estamos hablando? No estoy tan familiarizado con los componentes internos de kubeadm, pero suena interesante.

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

Para su información: el mismo problema / problema al actualizar desde 1.9.3
Probé la solución alternativa de volver a intentarlo varias veces. Finalmente alcanzó la condición de carrera con el servidor API y la actualización no pudo revertirse.

@stealthybox thx, no lo entendí en la primera lectura.

Estoy teniendo el mismo problema ... [ERROR APIServerHealth]: el servidor API no está en buen estado; / healthz no devolvió "ok"
[ERROR MasterNodesReady]: no se pudieron enumerar los maestros en el clúster: obtenga https ....... durante la actualización. Por favor, ayúdame con esto. Estoy actualizando de 1.9.3 a 1.10.0. Inicialmente, pudo llegar a cierto punto de "[actualización / staticpods] Esperando que el kubelet reiniciara el componente".

La solución temporal es garantizar los certificados y actualizar los pods etcd y apiserver omitiendo las comprobaciones.

Asegúrese de verificar su configuración y agregar cualquier indicador para su caso de uso:

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

Gracias @stealthybox
Para mí, el proceso upgrade apply se detuvo en [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... sin embargo, el clúster se actualizó correctamente.

@stealthybox no estoy seguro, pero parece que algo se rompe después de estos pasos, porque kubeadm upgrade plan se cuelga después de eso:

[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

Cuando apliqué la actualización, colgué [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"... también

@kvaps @stealthybox esto es probablemente etcd problema ( kubeadm habla claramente HTTP/2 para TLS habilitado etcd ), también lo golpeé. Vea este otro problema: https://github.com/kubernetes/kubeadm/issues/755

Honestamente, no puedo entender por qué se usa el mismo puerto TCP para oyentes TLS y no TLS etcd , solo causa problemas como este. Obtener una vieja _conexión rechazada_ daría una pista inmediata, aquí tuve que recurrir a tcpdump para entender qué está pasando.

¡OH!
Dispara, tienes razón, eso solo funciona con mi parche TLS local para la verificación del estado de Etcd.

Haga esto para finalizar la actualización:

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

editó la solución anterior para que sea correcta

@stealthybox el segundo comando kubeadm no funciona:

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

@renich solo dale la ruta de archivo de tu configuración

Si no utiliza ninguna configuración personalizada, puede pasarle un archivo vacío.
Aquí hay una forma sencilla de hacerlo en bash:

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

Esto ahora debería resolverse con la fusión de https://github.com/kubernetes/kubernetes/pull/62655 y será parte de la versión v1.10.2.

Puedo confirmar que la actualización 1.10.0 -> 1.10.2 con kubeadm 1.10.2 fue fluida, sin tiempos de espera

Todavía tengo tiempo de espera en 1.10.0 -> 1.10.2 pero otro:
[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]

No estoy seguro de que hacer ...

@ denis111 verifica los registros del servidor API mientras realiza la actualización usando docker ps . Siento que es posible que se esté encontrando con un problema con el que también me estoy encontrando.

@dvdmuckle Bueno, no veo ningún error en esos registros, solo las entradas que comienzan con I y unas pocas W.
Y creo que el hash de kube-apiserver no cambia durante la actualización.

Tengo un clúster ARM64 en 1.9.3 y actualicé exitosamente a 1.9.7 pero obtuve el mismo problema de tiempo de espera para actualizar de 1.9.7 a 1.10.2.

Incluso intenté editar y recompilar kubeadm aumentando los tiempos de espera (como estas últimas confirmaciones https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) con los mismos resultados.

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

Actualice v1.10.2 -> v1.10.2 (que puede ser una tontería. Solo prueba ...)

Ubuntu 16.04.

Y falla con un error.

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]

Me pregunto si esto todavía se rastrea en algún problema ... no se pudo encontrar.

También veo que las actualizaciones siguen fallando con el error timed out waiting for the condition .

Editar: se movió la discusión a un nuevo ticket https://github.com/kubernetes/kubeadm/issues/850 , por favor discuta allí.

Si alguien más tiene este problema con 1.9.x:

Si está en aws con nombres de host personalizados, debe editar el mapa de configuración kubeadm-config y establecer en nodeName el nombre interno de aws: ip-xx-xx-xx-xx. $ REGION.compute.internal)

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

Esto además de configurar el cliente etc a http. Todavía no estoy en versiones de cartas para ver si arreglaron eso.

Esto se debe a que kubeadm intenta leer esta ruta en api: / api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

Dado que el tiempo de espera se incrementó en 1.10.6, actualicé con éxito mi implementación 1.9.7 a 1.10.6 hace un par de semanas.

Planea actualizar a 1.11.2 tan pronto como los paquetes .deb estén listos, ya que los mismos cambios están en esta versión.

Mi clúster se ejecuta localmente en placas ARM64.