Kubeadm: 1.9.6から1.10.0へのアップグレードはタイムアウトで失敗します

このバグのローカルでの再現に取り組んでいます。

これを10回再試行した後、最終的に機能しました

これが私の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

<画像：gcr.io/google_containers/etcd-amd64：3.1.12

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

29,35d20
<exec：
<コマンド：
<-/ 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
<fooを取得
36a22,26
httpGet：
ホスト：127.0.0.1
パス：/ health
ポート：2379
スキーム：HTTP
43,45c33
<名前：etcd-data
<-mountPath：/ etc / kubernetes / pki / etcd

<名前：etcd-certs

  name: etcd

51,55c39
<名前：etcd-data
<-hostPath：
<パス：/ etc / kubernetes / pki / etcd
<タイプ：DirectoryOrCreate

<名前：etcd-certs

name: etcd

root @ vagrant：〜＃ls / etc / kubernetes / pki / etcd
ca.crt ca.key healthcheck-client.crt healthcheck-client.key peer.crt peer.key server.crt server.key```

Ubuntu 17.10 Vagrantの1.9.6クラスター：

root<strong i="6">@vagrant</strong>:/vagrant# 1.10_kubernetes/server/bin/kubeadm upgrade apply v1.10.0
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.0"
[upgrade/versions] Cluster version: v1.9.6
[upgrade/versions] kubeadm version: v1.10.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.0"...
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests262738652/etcd.yaml"
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [localhost] and IPs [127.0.0.1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [vagrant] and IPs [10.0.2.15]
[certificates] Generated etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests858209931/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[apiclient] Error getting Pods with label selector "component=etcd" [the server was unable to return a response in the time allotted, but may still be processing the request (get pods)]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: http2: server sent GOAWAY and closed the connection; LastStreamID=27, ErrCode=NO_ERROR, debug=""]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: net/http: TLS handshake timeout]
[apiclient] Error getting Pods with label selector "component=etcd" [the server was unable to return a response in the time allotted, but may still be processing the request (get pods)]
[apiclient] Error getting Pods with label selector "component=etcd" [Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods?labelSelector=component%3Detcd: http2: server sent GOAWAY and closed the connection; LastStreamID=3, ErrCode=NO_ERROR, debug=""]
[upgrade/apply] FATAL: fatal error when trying to upgrade the etcd cluster: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition], rolled the state back to pre-upgrade state

これは私の再現環境です： https ：

ブートストラップの次の行を1.9.6-00に変更します： //github.com/stealthybox/vagrant-kubeadm-testing/blob/9d4493e990c9bd742107b317641267c3ef3640cd/Vagrantfile#L18 -L20

次に、1.10サーバーバイナリをリポジトリにダウンロードすると、ゲストで/vagrantで利用できるようになります。
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#server -binaries

kubelet etcd関連ログ：

root<strong i="6">@vagrant</strong>:~# journalctl -xefu kubelet | grep -i etcd
Mar 28 16:32:07 vagrant kubelet[14676]: W0328 16:32:07.808776   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:32:07 vagrant kubelet[14676]: I0328 16:32:07.880412   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "etcd-vagrant" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 16:34:27 vagrant kubelet[14676]: W0328 16:34:27.472534   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:57:33 vagrant kubelet[14676]: W0328 16:57:33.683648   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:57:33 vagrant kubelet[14676]: I0328 16:57:33.725564   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") pod "etcd-vagrant" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 16:57:33 vagrant kubelet[14676]: I0328 16:57:33.725637   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") pod "etcd-vagrant" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 16:57:35 vagrant kubelet[14676]: E0328 16:57:35.484901   14676 kuberuntime_container.go:66] Can't make a ref to pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)", container etcd: selfLink was empty, can't make reference
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.889458   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "7278f85057e8bf5cb81c9f96d3b25320" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.889595   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd" (OuterVolumeSpecName: "etcd") pod "7278f85057e8bf5cb81c9f96d3b25320" (UID: "7278f85057e8bf5cb81c9f96d3b25320"). InnerVolumeSpecName "etcd". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 16:57:35 vagrant kubelet[14676]: I0328 16:57:35.989892   14676 reconciler.go:297] Volume detached for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") on node "vagrant" DevicePath ""
Mar 28 16:58:03 vagrant kubelet[14676]: E0328 16:58:03.688878   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Timeout: request did not complete within allowed duration
Mar 28 16:58:03 vagrant kubelet[14676]: E0328 16:58:03.841447   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff626cfbc5", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"37936d2107e31b457cada6c2433469f1", APIVersion:"v1", ResourceVersion:"", FieldPath:""}, Reason:"SuccessfulMountVolume", Message:"MountVolume.SetUp succeeded for volume \"etcd-certs\" ", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e59c5, ext:1534226953099, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e59c5, ext:1534226953099, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:58:33 vagrant kubelet[14676]: E0328 16:58:33.844276   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff626cfb82", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"37936d2107e31b457cada6c2433469f1", APIVersion:"v1", ResourceVersion:"", FieldPath:""}, Reason:"SuccessfulMountVolume", Message:"MountVolume.SetUp succeeded for volume \"etcd-data\" ", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e5982, ext:1534226953033, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f713e5982, ext:1534226953033, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:59:03 vagrant kubelet[14676]: E0328 16:59:03.692450   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": the server was unable to return a response in the time allotted, but may still be processing the request (post pods)
Mar 28 16:59:03 vagrant kubelet[14676]: E0328 16:59:03.848007   14676 event.go:200] Server rejected event '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"etcd-vagrant.152023ff641f915f", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, InvolvedObject:v1.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"etcd-vagrant", UID:"7278f85057e8bf5cb81c9f96d3b25320", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers{etcd}"}, Reason:"Killing", Message:"Killing container with id docker://etcd:Need to kill Pod", Source:v1.EventSource{Component:"kubelet", Host:"vagrant"}, FirstTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f72f0ef5f, ext:1534255433999, loc:(*time.Location)(0x5859e60)}}, LastTimestamp:v1.Time{Time:time.Time{wall:0xbea7103f72f0ef5f, ext:1534255433999, loc:(*time.Location)(0x5859e60)}}, Count:1, Type:"Normal", EventTime:v1.MicroTime{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, Series:(*v1.EventSeries)(nil), Action:"", Related:(*v1.ObjectReference)(nil), ReportingController:"", ReportingInstance:""}': 'Timeout: request did not complete within allowed duration' (will not retry!)
Mar 28 16:59:14 vagrant kubelet[14676]: W0328 16:59:14.472661   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:59:14 vagrant kubelet[14676]: W0328 16:59:14.473138   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:14 vagrant kubelet[14676]: E0328 16:59:14.473190   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:14 vagrant kubelet[14676]: E0328 16:59:14.473658   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:15 vagrant kubelet[14676]: W0328 16:59:15.481336   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 16:59:15 vagrant kubelet[14676]: E0328 16:59:15.483705   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 16:59:15 vagrant kubelet[14676]: E0328 16:59:15.497391   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:00:34 vagrant kubelet[14676]: W0328 17:00:34.475851   14676 kubelet.go:1597] Deleting mirror pod "etcd-vagrant_kube-system(122348c3-32a6-11e8-8dc5-080027d6be16)" because it is outdated
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.720076   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: http2: server sent GOAWAY and closed the connection; LastStreamID=47, ErrCode=NO_ERROR, debug=""
Mar 28 17:01:07 vagrant kubelet[14676]: E0328 17:01:07.720107   14676 mirror_client.go:88] Failed deleting a mirror pod "etcd-vagrant_kube-system": Delete https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: http2: server sent GOAWAY and closed the connection; LastStreamID=47, ErrCode=NO_ERROR, debug=""; some request body already written
Mar 28 17:01:07 vagrant kubelet[14676]: E0328 17:01:07.725335   14676 kubelet.go:1612] Failed creating a mirror pod for "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Post https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:07 vagrant kubelet[14676]: I0328 17:01:07.728709   14676 reconciler.go:217] operationExecutor.VerifyControllerAttachedVolume started for volume "etcd" (UniqueName: "kubernetes.io/host-path/7278f85057e8bf5cb81c9f96d3b25320-etcd") pod "etcd-vagrant" (UID: "7278f85057e8bf5cb81c9f96d3b25320")
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.734475   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:07 vagrant kubelet[14676]: W0328 17:01:07.740642   14676 status_manager.go:459] Failed to get status for pod "etcd-vagrant_kube-system(7278f85057e8bf5cb81c9f96d3b25320)": Get https://10.0.2.15:6443/api/v1/namespaces/kube-system/pods/etcd-vagrant: dial tcp 10.0.2.15:6443: getsockopt: connection refused
Mar 28 17:01:09 vagrant kubelet[14676]: E0328 17:01:09.484412   14676 kuberuntime_container.go:66] Can't make a ref to pod "etcd-vagrant_kube-system(37936d2107e31b457cada6c2433469f1)", container etcd: selfLink was empty, can't make reference
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.848794   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849282   14676 reconciler.go:191] operationExecutor.UnmountVolume started for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1")
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849571   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data" (OuterVolumeSpecName: "etcd-data") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1"). InnerVolumeSpecName "etcd-data". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.849503   14676 operation_generator.go:643] UnmountVolume.TearDown succeeded for volume "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs" (OuterVolumeSpecName: "etcd-certs") pod "37936d2107e31b457cada6c2433469f1" (UID: "37936d2107e31b457cada6c2433469f1"). InnerVolumeSpecName "etcd-certs". PluginName "kubernetes.io/host-path", VolumeGidValue ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.949925   14676 reconciler.go:297] Volume detached for volume "etcd-certs" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-certs") on node "vagrant" DevicePath ""
Mar 28 17:01:09 vagrant kubelet[14676]: I0328 17:01:09.949975   14676 reconciler.go:297] Volume detached for volume "etcd-data" (UniqueName: "kubernetes.io/host-path/37936d2107e31b457cada6c2433469f1-etcd-data") on node "vagrant" DevicePath ""

現在の回避策は、アップグレードを再試行し続けることであり、ある時点で成功します。

@stealthybox etcdコンテナのDockerからログを取得しますか？ また、 grep -i etcdは、kubelet出力の一部をマスクしている可能性があります。たとえば、コンテナ名が含まれていないが関連性のあるエラーメッセージなどです。

このバグに関連する別の奇妙なエッジケースに遭遇しました。 kubeadmアップグレードは、新しいetcdイメージがプルされ、新しい静的ポッドがデプロイされる前に、etcdアップグレードが完了したことを示しました。 これにより、後のステップでアップグレードがタイムアウトし、アップグレードのロールバックが失敗します。 これにより、クラスターは壊れた状態のままになります。 クラスタを回復するには、元のetcd静的ポッドマニフェストを復元する必要があります。

そうそう、私もそこに閉じ込められています。 クラスタが完全にダウンしています。 誰かがこの状態から救助する方法についていくつかの指示を共有できますか？

@detiberが説明したように、2回目のアップグレードの試みでそこにいましたが、非常に苦痛でした。 ：泣く：

/ etc / kubernetes / tmpでバックアップされたものを見つけ、etcdが原因である可能性があると感じたので、マニフェストフォルダーの新しいマニフェストに古いマニフェストをコピーしました。 その時点で、私は失うものは何もありませんでした。なぜなら、私はクラスターの制御を完全に失ったからです。 その後、正確には覚えていませんが、マシン全体を再起動し、後ですべてのものをv1.9.6にダウングレードしたと思います。 最終的に、私はクラスターの制御を取得し、v1.10.0を再び混乱させる動機を失いました。 まったく面白くなかった...

etcd静的ポッドマニフェストを/etc/kubernetes/tmpからロールバックする場合、1.10の新しいTLS構成のため、apiserverマニフェストを1.9バージョンにロールバックすることも重要です。

^ etcdアップグレードは残りのコントロールプレーンのアップグレードをブロックすると私は信じているので、おそらくこれを行う必要はないでしょう。

アップグレードが失敗した場合、etcdマニフェストのみがロールバックされないようです。それ以外はすべて問題ありません。 バックアップマニフェストを移動してkubeletを再起動すると、すべてが正常に戻ります。

同じタイムアウトの問題に直面し、kubeadmはkube-apiservマニフェストを1.9.6にロールバックしましたが、etcdマニフェストをそのままにし（読み取り：TLSを有効にした場合）、明らかにapiservが惨めに失敗し、マスターノードが事実上壊れました。 別の問題レポートの良い候補だと思います。

@dvdmuckle @codepainters 、残念ながら、ロールバックが成功するかどうかは、どのコンポーネントが競合状態（etcdまたはapiサーバー）にヒットするかによって異なります。 競合状態の修正を見つけましたが、kubeadmのアップグレードが完全に壊れています。 私は@stealthyboxと

@codepainters同じ問題だと思います。

この問題の原因となる根本的な問題がいくつかあります。

• アップグレードでは、APIからミラーポッドをクエリした結果から、各コンポーネントのミラーポッドのハッシュが生成されます。 次に、アップグレードは、このハッシュ値が変更されるかどうかをテストして、ポッドが静的マニフェストの変更から更新されるかどうかを判断します。 ハッシュ値には、静的マニフェストの変更以外の理由（ポッドステータスの更新など）で変更できるフィールドが含まれます。 ハッシュ比較の間にポッドのステータスが変化した場合、アップグレードは時期尚早に次のコンポーネントに続行されます。
• アップグレードは、etcd静的ポッドマニフェストの更新（etcdへのtlsセキュリティの追加を含む）を実行し、ポッドが更新されたことを確認するためにapiserverを使用しようとしますが、この時点では、etcdとの通信にtlsを使用するようにapiserverマニフェストは更新されていません。 。

その結果、アップグレードは現在、etcdポッドのポッドステータスの更新が発生した場合にのみ成功します。これにより、kubeletがetcdの新しい静的マニフェストを取得する前にハッシュが変更されます。 さらに、アップグレードツールがapiserverマニフェストを更新する前にapiにクエリを実行している場合、apiサーバーはapiserverアップグレードの最初の部分で使用可能なままである必要があります。

@detiberと私は、アップグレードプロセスに加える必要のある変更について話し合うために電話に出ました。
1.10.xパッチリリースでは、このバグに対して3つの修正を実装する予定です。

• etcdTLSをアップグレードから削除します。
  現在のアップグレードループは、コンポーネントごとにシリアル方式でバッチ変更を行います。
  コンポーネントのアップグレードには、依存するコンポーネント構成に関する知識がありません。
  アップグレードを確認するには、ポッドのステータスを確認するためにAPIServerが使用可能である必要があります。
  Etcd TLSでは、etcd + apiserverの構成を組み合わせて変更する必要があり、この契約が破られます。
  これは、この問題を修正するための最小限の実行可能な変更であり、アップグレードされたクラスターには安全でないetcdが残ります。

• ポッドステータス変更時のミラーポッドハッシュ競合状態を修正しました。
  https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/staticpods.go#L189。
  etcdフラグとapiserverフラグの互換性を前提として、アップグレードが正しく行われるようになりました。

• 特に別のフェーズでTLSをアップグレードします。
  EtcdとAPIServerは一緒にアップグレードする必要があります。
  kubeadm alpha phase ensure-etcd-tls ?。
  このフェーズは、クラスターのアップグレードとは関係なく実行可能である必要があります。
  クラスターのアップグレード中は、すべてのコンポーネントを更新する前にこのフェーズを実行する必要があります。

1.11の場合、次のことを行います。

• アップグレードされた静的ポッドのランタイムチェックには、kubeletAPIを使用します。
  現在行っているように、ローカルプロセスを監視するためにapiserverなどに依存することは望ましくありません。
  ポッドに関するローカルデータソースは、高次の分散型kubernetesコンポーネントに依存するよりも優れています。
  これにより、アップグレードループ内の現在のポッドランタイムチェックが置き換えられます。
  これにより、ensure-etcd-tlsフェーズにチェックを追加できるようになります。

別の方法：CRIを使用してポッド情報を取得します（ crictlを使用してデモを実行できます）。
警告：dockershimおよび場合によっては他のコンテナーランタイムのCRIは、現在、CRIの重大な変更に対する下位互換性をサポートしていません。

TODO：

• []これら4つの変更の問題を開いてリンクします。

静的ポッド更新の競合状態に対処するためのPR： https ：
リリース-1.10ブランチのチェリーピックPR： https ：

@detiber私たちが話している競合状態を説明してもよろしいですか？ 私はkubeadmの内部にあまり詳しくありませんが、それでも面白そうです。

@codepaintersはhttps://github.com/kubernetes/kubeadm/issues/740#issuecomment-377263347を参照して

参考までに-1.9.3からのアップグレードと同じ問題/問題
何度も再試行するという回避策を試しました。 最後に、APIサーバーで競合状態になり、アップグレードをロールバックできませんでした。

@stealthybox thx、最初に読んだときに

同じ問題が発生しています。[エラーAPIServerHealth]：APIサーバーが正常ではありません。 / healthzは「ok」を返しませんでした
[エラーMasterNodesReady]：クラスター内のマスターを一覧表示できませんでした：アップグレード中にhttps .......を取得してください。 これを手伝ってください。 1.9.3から1.10.0にアップグレードしています。 最初は、「[upgrade / staticpods]クベレットがコンポーネントを再起動するのを待っています」という特定のポイントに到達することができました。

一時的な回避策は、証明書を確認し、チェックをバイパスしてetcdポッドとapiserverポッドをアップグレードすることです。

必ず構成を確認し、ユースケースのフラグを追加してください。

kubectl -n kube-system edit cm kubeadm-config  # change featureFlags
...
  featureGates: {}
...
kubeadm alpha phase certs all
kubeadm alpha phase etcd local
kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

ありがとう@stealthybox
私の場合、 upgrade applyプロセスは[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"...停止しましたが、クラスターは正常にアップグレードされました。

@stealthyboxよくわかりませんが、 kubeadm upgrade planがその後ハングするため、これらの手順の後で何かが壊れているようです。

[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.10.1
[upgrade/versions] kubeadm version: v1.10.1
[upgrade/versions] Latest stable version: v1.10.1

アップデートを適用すると、 [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.1"...もハングしました

@kvaps @stealthyboxこれはおそらくetcd問題です（ kubeadmはTLS対応のetcdに対して明白なHTTP/2を話します）、私もそれをヒットしました。 この他の問題を参照してください： https ：

正直なところ、TLSリスナーと非TLS etcdリスナーの両方に同じTCPポートが使用されている理由がわかりません。このような問題が発生するだけです。 わかりやすく、古い_connection refused_を取得すると、すぐにヒントが得られます。ここでは、何が起こっているのかを理解するためにtcpdumpに頼らなければなりませんでした。

ああ！
正解です。これは、Etcdステータスチェック用のローカルTLSパッチでのみ機能します。

これを実行して、アップグレードを完了します。

kubeadm alpha phase controlplane all
kubeadm alpha phase upload-config

上記の回避策を正しく編集しました

@ stealthybox2番目のkubeadmコマンドが機能しません：

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

@renichは、設定のファイルパスを

カスタム設定を使用しない場合は、空のファイルを渡すことができます。
これをbashで行う簡単な方法は次のとおりです。

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

これはhttps://github.com/kubernetes/kubernetes/pull/62655のマージで解決されるはずであり、v1.10.2リリースの一部になります。

kubeadm1.10.2を使用した1.10.0-> 1.10.2のアップグレードがスムーズで、タイムアウトがないことを確認できます。

私はまだ1.10.0-> 1.10.2でタイムアウトがありますが、別のタイムアウトがあります：
[upgrade/staticpods] Waiting for the kubelet to restart the component Static pod: kube-apiserver-master hash: a273591d3207fcd9e6fd0c308cc68d64 [upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

どうしたらいいのかわからない...

@ denis111は、 docker psを使用してアップグレードを実行しているときに、APIサーバーのログを確認します。 私も直面している問題に直面しているように感じます。

@dvdmuckleええと、そのログにはエラーは表示されません
そして、kube-apiserverのハッシュはアップグレード中に変更されないと思います。

1.9.3にARM64クラスターがあり、1.9.7に正常に更新されましたが、1.9.7から1.10.2にアップグレードするときに同じタイムアウトの問題が発生しました。

kubeadmを編集して再コンパイルし、タイムアウトを増やしてみました（これらの最後のコミットhttps://github.com/anguslees/kubernetes/commits/kubeadm-gusforkのように）。同じ結果が得られました。

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

v1.10.2-> v1.10.2をアップグレードします（これは意味がないかもしれません。テストするだけです...）

Ubuntu16.04。

そして、それはエラーで失敗します。

kubeadm upgrade apply v1.10.2

[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

これはまだいくつかの問題で追跡されているのだろうか...見つかりませんでした。

timed out waiting for the conditionエラーでアップグレードがまだ失敗しているのも見られます。

編集：ディスカッションを新しいチケットhttps://github.com/kubernetes/kubeadm/issues/850に移動しました。そこでディスカッションしてください。

他の誰かが1.9.xでこの問題を抱えている場合：

カスタムホスト名を持つawsを使用している場合は、kubeadm-config configmapを編集し、nodeNameでaws内部名を設定する必要があります：ip-xx-xx-xx-xx。$ REGION.compute.internal）

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

これは、etcクライアントをhttpに設定する以外に。 彼らがそれを修正したかどうかを確認するために、私はまだレターバージョンを使用していません。

これは、kubeadmがAPIでこのパスを読み取ろうとするためです：/ api / v1 / namespaces / kube-system / pods / kube-apiserver- $ NodeName

1.10.6でタイムアウトが増加したため、数週間前に1.9.7デプロイメントを1.10.6に正常に更新しました。

このバージョンでも同じ変更が加えられているため、.debパッケージの準備ができ次第1.11.2にアップグレードすることを計画しています。

私のクラスターは、ARM64ボード上でオンプレミスで実行されます。