<p>kubeadmリセットは成功しましたが、このノードのIPはまだkubeadm-configconfigmapにあります</p>

作成日 2018年12月05日 · 32コメント · ソース: kubernetes/kubeadm

これはバグレポートですか、それとも機能リクエストですか？

バグレポート

バージョン

kubeadmバージョン（ kubeadm version ）：

[root@k8s-211 ~]# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T21:02:01Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

環境：

Kubernetesバージョン（ kubectl version ）：

[root@k8s-211 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T21:04:45Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

クラウドプロバイダーまたはハードウェア構成：
OS （例：/ etc / os-releaseから）：

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

カーネル（例： uname -a ）：

Linux k8s-lixin-211 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

その他：

何が起こった？

kubeadm reset -fを使用してこのコントロールプレーンノードをリセットすると、コマンドの実行が成功します。しかし、 kubeadm-config ConfigMapを見ると、ClusterStatusにこのノードIPがすでにあります。

まだ質問があります。なぜkubeadm resetはこのノードをクラスターから直接削除しないのですか？代わりに、 kubectl delete node <node name>手動で実行してください。

あなたは何が起こると思っていましたか？

kubeadm-config ConfigMapはこのノードIPを削除します。

それを（可能な限り最小限かつ正確に）再現する方法は？

最初のノードでkubeadm init --config=kubeadm.yml 。
2番目のノードでkubeadm join --experimental-control-plane --config=kubeadm.yml 。
2番目のノードでkubeadm reset -f 。
kubectl -n kube-system get cm kubeadm-config -oyamlは、すでにClusterStatusにある2番目のノードIPを検索します。

他に知っておくべきことはありますか？

kubeadm-config configMap yaml：

apiVersion: v1
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        authorization-mode: Node,RBAC
      timeoutForControlPlane: 4m0s
    apiVersion: kubeadm.k8s.io/v1beta1
    certificatesDir: /etc/kubernetes/pki
    clusterName: kubernetes
    controlPlaneEndpoint: 192.168.46.117:6443
    controllerManager: {}
    dns:
      type: CoreDNS
    etcd:
      local:
        dataDir: /var/lib/etcd
        extraArgs:
          cipher-suites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        serverCertSANs:
        - 192.168.46.117
    imageRepository: k8s.gcr.io
    kind: ClusterConfiguration
    kubernetesVersion: v1.13.0
    networking:
      dnsDomain: cluster.local
      podSubnet: 10.244.0.0/16
      serviceSubnet: 10.96.0.0/12
    scheduler: {}
  ClusterStatus: |
    apiEndpoints:
      k8s-211:
        advertiseAddress: 192.168.46.211
        bindPort: 6443
      k8s-212:
        advertiseAddress: 192.168.46.212
        bindPort: 6443
    apiVersion: kubeadm.k8s.io/v1beta1
    kind: ClusterStatus
kind: ConfigMap
metadata:
  creationTimestamp: "2018-12-04T14:17:38Z"
  name: kubeadm-config
  namespace: kube-system
  resourceVersion: "103402"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kubeadm-config
  uid: 5a9320c1-f7cf-11e8-868d-0050568863b3

help wanted kinbug prioritimportant-soon

ソース

pytimer

最も参考になるコメント

1.13.3でも同じ問題が発生しました（HAクラスターのセットアップ：3つのマスターノード+ 3つのワーカー）。次の手順の後でのみ、マスターノードを正常に置き換えました。

クラスターからノードを削除します

kubectl delete node master03

etcdctlをダウンロードします（たとえば、master01で）

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

etcdからマスターノードを削除します

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

kubeadm-configから削除します

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

Halytskyi 2019年02月19日

👍8 🎉3

全てのコメント32件

cc @fabriziopandini

neolit123 2018年12月05日

理想的には、ClusterStatusを「更新」する方法があります。カオステストを使用してクラスターを実行します。コントロールプレーンノードが警告なしに、またkubeadm resetを実行する機会なしに終了する可能性は完全にあります。理想的には、ClusterStatusを明示的に更新して、クラスター内に存在しないことがわかっているコントロールプレーンノードを削除するクリーンな方法があります。これはkubeadm join --control-plane ...実行する前に行われることですか、それとも組み込みですか？

danbeaulieu 2018年12月06日

ここにいくつかのコメント：

kubeadm-configConfigMapはこのノードのIPを削除します。

@pytimerノードAPIアドレスをクラスターステータスのままにしておくのは理想的ではないことは知っていますが、この「クリーンアップの欠如」によって問題が発生するかどうかを理解したいと思います。同じコントロールプレーンに再度参加しようとしましたか？別のコントロールプレーンに参加しようとしましたか？問題はないと思いますが、この点を確認していただければ幸いです。

私はまだ質問があります、なぜkubeadm resetはこのノードをクラスターから直接削除しないのですか？代わりに、kubectl deletenodeを実行します手動で。

@luxasは、少し歴史的な文脈がここで役立つかもしれません。
私の推測では、ノードには自分自身を削除する権限がありませんでした（ただし、これはワーカーノードに適用され、コントロールプレーンノードには適用されません...）

理想的には、ClusterStatusを「更新」する方法があります/ ClusterStatusを明示的に更新するクリーンな方法があります

@danbeaulieuそれは良い点です。クラスタステータスを同期したり、kubeadmの実行時に自動同期を強制したりするための明示的なコマンドを用意することをお勧めします。
ただし、制御ループを継続的に実行することなくkubeadmであるため、ClusterStatusが同期していない可能性は常にあると思います。
これは問題ではないはずです。具体的には、存在しないノードのノードIP（クリーンアップの欠如）が問題になることはありません。
代わりに、ノードが存在し、対応するノードIPがClusterStatusにない（初期化が間違っている）場合、更新などの問題が発生する可能性があります。

上記の仮定がカオステストによって確認された場合、親切に報告していただけますか？どんなフィードバックも本当に感謝されます。

fabriziopandini 2018年12月06日

@fabriziopandini同じコントロールプレーンノードに参加しましたが、失敗しました。

私の参加手順：

2番目のコントロールプレーンノードのIPは192.168.46.212です。

etcdクラスターから192.168.46.212ノードetcdメンバーを削除します。
kubectl delete node k8s-212
このコントロールプレーンノードのkubeadm reset -f 。
kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5もう一度実行します。

kubeadm参加ログ：

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

kubeadmコードが表示されますが、この問題はkubeadm-config ConfigMapに残っている192.168.46.212が原因である可能性があります。

Kubeadmは、コントロールプレーンノードに参加するときにkubeadm-config ConfigMapからapiエンドポイントを取得し、etcdエンドポイントはapiエンドポイントと同じです。ただし、 912.168.46.212コントロールプレーンノードは削除されており、まだ参加していないため、etcdクラスターの状態を確認してください。

kubeadm-config ConfigMapから192.168.46.212 apiエンドポイントを削除し、このコントロールプレーンノードに再度参加すると、成功に参加します。

pytimer 2018年12月07日

👍5

@pytimerありがとう！
これは調査する必要があります。 etcdエンドポイントの想定リストを実際のetcdリストエンドポイントと同期しようとするロジックはすでに存在しますが、何かが正しく機能していないようです

fabriziopandini 2018年12月07日

はい、これはバグのようです。 3ノードのコントロールプレーンASGがあります。インスタンスを終了すると、ASGルールに従って新しいインスタンスが作成されます。この間、終了したノードはetcdのメンバーリストに異常としてリストされます。新しいインスタンスが起動すると、 kubeadm join...実行する前に、異常なメンバーがetcdから削除されます。 kubeadm join...を実行するまでに、etcdクラスターはetcdによると2つのノードで正常です。ただし、kubeadmは、信頼できる唯一の情報源としてClusterStatusを使用しますが、これにはまだ古いインスタンスがリストされています。

etcdメンバーシップ管理を実行した直後の回避策は、クラスターの真偽でkubeadm-config ConfigMapを更新してから、 kubeadm join...です。

理想的には、 kubeadm join...はetcdを真実のソースとして使用し、それに応じてkubeadm-configConfigMapを更新します。

danbeaulieu 2018年12月07日

@fabianofranz私はおそらくこの問題の原因を見つけました。

etcdエンドポイントを実際のetcdエンドポイントリストと同期すると、同期は成功します。ただし、実際のetcdエンドポイントをetcdクライアントEndpointsに割り当てます。このクライアント変数はポインターではないため、他のコードがクライアントを使用する場合、このクライアントエンドポイントは、同期後の実際のエンドポイントではなく、古いエンドポイントのままです。

フォークリポジトリでこの問題を修正しました。このPRhttps ます。そして、私はjoin the same control-plane nodeユーザーケースをテストしました、それは成功に加わります。

pytimer 2018年12月11日

@pytimerよさそうだ！よく発見されました！
PRを送っていただけませんか。 IMOこれはチェリーピッキングの対象になります。

@ neolit123 @timothysc ^^^

fabriziopandini 2018年12月11日

@fabianofranz最初のPRが間違っている、CLAの確認を忘れた。

このPRhttps ：//github.com/kubernetes/kubernetes/pull/71945を確認できます。何か問題があれば、指摘してください。

pytimer 2018年12月11日

@fabriziopandini同じコントロールプレーンノードに参加しましたが、失敗しました。
私の参加手順：
2番目のコントロールプレーンノードのIPは192.168.46.212です。
etcdクラスターから192.168.46.212ノードetcdメンバーを削除します。
kubectl delete node k8s-212
このコントロールプレーンノードのkubeadm reset -f 。
kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5もう一度実行します。
kubeadm参加ログ：
...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded
kubeadmコードが表示されますが、この問題はkubeadm-config ConfigMapに残っている192.168.46.212が原因である可能性があります。
Kubeadmは、コントロールプレーンノードに参加するときにkubeadm-config ConfigMapからapiエンドポイントを取得し、etcdエンドポイントはapiエンドポイントと同じです。ただし、 912.168.46.212コントロールプレーンノードは削除されており、まだ参加していないため、etcdクラスターの状態を確認してください。
kubeadm-config ConfigMapから192.168.46.212 apiエンドポイントを削除し、このコントロールプレーンノードに再度参加すると、成功に参加します。

kubeadmバージョン1.13.2で同じエラーが発生しました。ノードを手動で削除して、kubeadm-configを更新しようとしましたが、機能しません。残りのetcdノードは、削除されたノードに接続しようとします。

zhangyelong 2019年02月09日

kubeadm-config ConfigMapから192.168.46.212 apiエンドポイントを削除し、このコントロールプレーンノードに再度参加すると、成功に参加します。

@pytimer古いAPIサーバーを手動で削除した方法について詳しく教えてください。

私は1.13.3を実行しています。次の方法で古いサーバーを手動で削除します。

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml

次のエラーのため、まだクラスターに参加できません。

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

次に、apiポッドとetcdポッド（それぞれ2つ）を強制終了しました。

それらは再作成されますが、追加のノードに接続しようとすると同じエラーが発生します。

lvangool 2019年02月13日

クラスターからノードを削除します

kubectl delete node master03

etcdctlをダウンロードします（たとえば、master01で）

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

etcdからマスターノードを削除します

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

kubeadm-configから削除します

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

Halytskyi 2019年02月19日

👍8 🎉3

@zhangyelong kubeadm resetはetcdメンバーを削除できないため、etcdクラスターは削除されたetcdノードに接続していることがわかりました。ここで、etcdctlを使用してetcdメンバーを手動で削除する必要があります。

リセット時にetcdノードを削除するように実装するPRを送信します。 https://github.com/kubernetes/kubernetes/pull/74112

pytimer 2019年02月19日

👍1

@ lvangool @ Halytskyiの手順に従うことができます。 PR： https ：

リセット時にetcdクラスターからetcdメンバーを削除すると、kubernetes / kubernetes＃74112が表示されます。

pytimer 2019年02月19日

これは1.13.4のバグのようです。

kubeadm config map alahttps ： //github.com/kubernetes/kubeadm/issues/1300#issuecomment-463374200を手動で更新する必要があり

の修正はそうではありませんか
kubernetes / kubernetes＃71945は、etcdクラスターメンバーシップをクラスターメンバーの真実のソースとして使用しますか？そうでない場合、そのPRは正確に何を修正しましたか？

興味深いことに、 ClusterStatusのようなマップ上のgolang範囲では非決定論的であるため、散発的に機能します。したがって、最初に検出されたエンドポイントが、存在しなくなった古いエンドポイントからのものである場合、問題は発生します。正常なエンドポイントが見つかると、etcdSyncからClusterStatusを更新します。

これの根本的な原因は、etcd clientv3のバグであり、最初のエンドポイントが失敗した場合にクライアントが他のエンドポイントを再試行しない原因になると思いますhttps://github.com/etcd-io/etcd/issues/9949。

danbeaulieu 2019年03月01日

リセットの改善を追跡するには、次の問題を使用してください

https://github.com/kubernetes/kubeadm/issues/1312 ClusterStatusからコントロールプレーンノードを削除し@Klaven https://github.com/kubernetes/kubernetes/pull/72886）
https://github.com/kubernetes/kubeadm/issues/1211 etcdクラスターからetcdメンバーを削除します（ @pytimer https://github.com/kubernetes/kubernetes/pull/74112）

fabriziopandini 2019年03月01日

@fabriziopandiniここには、 kubeadm resetとは関係のない問題が少なくとも1つあります。

kubeadmリセットを実行する機会なしにノードに障害が発生した場合（インスタンスの終了、ハードウェア障害など）
クラスターは、ClusterStatus.apiEndpointsに、クラスター内に存在しなくなったノードがまだリストされている状態のままになります。これには、 kubeadm join実行する前に、構成マップの読み取り、編集、および更新の回避策が必要です。 Kubeadmにはおそらく2つのオプションがあります。

1）ダイヤルが失敗した場合、etcdクライアントがそれ自体を再試行するように実装します
2）go-grpcバグが修正されるのを待ってから、修正がetcdクライアントに届くのを待ちます

この問題は、これらのオプションのいずれかを追跡するために使用するのに適した問題である可能性があります。

danbeaulieu 2019年03月01日

👍1

kubeadmリセットを実行する機会なしにノードに障害が発生した場合（インスタンスの終了、ハードウェア障害など）
クラスターは、ClusterStatus.apiEndpointsに、クラスター内に存在しなくなったノードがまだリストされている状態のままになります。これには、 kubeadm join実行する前に、構成マップの読み取り、編集、および更新の回避策が必要です。

つまり、resetを呼び出さずに、ClusterStatusを手動で更新する必要があります。
それを行うコマンドはありません。 kubeadmがサポートすべき機能であると思われる場合は、別のチケットを提出してください。

neolit123 2019年03月01日

今日1.14.1でこれを体験しました

マスターノードの1つを実行しているインスタンスに障害が発生したため、正常に削除できませんでした。新しいノードが入ろうとしたとき、このチケットに記載されているエラーのために参加できませんでした。

etcdctlを使用してetcdメンバーを手動で削除する必要がありました。その後、新しいノードに参加できました。また、kubeadm-config ConfigMapからノードを手動で削除しましたが、それが必要かどうかはわかりません。

falken 2019年05月01日

👍3

@Halytskyiありがとうetcdctlセクションは私を助けてくれました.....

Nurlan199206 2019年07月14日

今日1.15.5でこれを経験しました

私の場合、クラスターに参加しましたが、バージョンは1.16です。次に、このノードkubectl delete nodeを削除し、15.5.5にダウングレードして、再参加（同じIP、同じホスト名、異なるバージョン）を試みたところ、etcdの異常エラーが発生しました。

解決策（ etcdctlが更新されている）：

kubeadm-configconfigmapからノードを削除します

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

問題のあるノードのkubeadmreset -f && iptables -t -f-Xなど。
etcdメンバーを削除します（これがキーです）：

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

`` `シェル
root @ k8s-nebula-m-115-2 ：〜/ etcdctl / etcd-v3.4.3-linux-amd64＃。/ etcdctl --endpoints https://127.0.0.1：2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key / etc / kubernetes / pki / etcd / server.keyメンバーリスト
289ed62da3c6e9e5、開始、k8s-nebula-m-115-1、 https ：//10.205.30.2：2380、 https ：//10.205.30.2：2379、false
917e16b9e790c427、開始、k8s-nebula-m-115-0、 https ：//10.205.30.1：2380、 https ：//10.205.30.1：2379、false
ad6b76d968b18085、開始、k8s-nebula-m-115-2、 https ：//10.205.30.0：2380、 https ：//10.205.30.0：2379、false

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

そして、作品に再び参加します。

zakkg3 2019年10月30日

これは、 kubeadm resetが中断され、kubeadmCMからノードを削除できなかった場合に発生する可能性があります。
このような場合は、kubeadmCMから手動で削除する必要があります。

neolit123 2019年10月30日

したがって、 kubectl delete node foobarでノードを削除しても、削除されません
etcdメンバーから削除しますか？しかし、必要なノードでkubeadm resetすると、
削除するには、それを行いますか？ 🙄

2019年10月30日水曜日、13：27 Lubomir I. Ivanov、 notifications @ github.com
書きました：

これは、kubeadmのリセットが中断され、削除できなかった場合に発生する可能性があります
kubeadmCMからのノード。
このような場合は、kubeadmCMから手動で削除する必要があります。
—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
。

zakkg3 2019年10月31日

「kubeadmreset」はそれをkubeadmCMから削除する必要がありますが、「kubectldeletenode」を呼び出すことも必要です。これによりノードAPIオブジェクトが削除されます。

neolit123 2019年10月31日

私の場合、de configmapからノードを削除しても、ノードは削除されませんでした。
etcdクラスター私は手動でetcdctl delete member必要がありました。

木には、16時28分に2019年10月31日、ルボミールI.イワノフ[email protected]
書きました：

「kubeadmreset」はkubeadmCMから削除する必要がありますが、「kubectl
NodeAPIオブジェクトを削除する「deletenode」も必要です。
—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
。

zakkg3 2019年10月31日

kubeadm resetは、etcdクラスターからetcdメンバーも削除する必要があります。
たとえば--v = 5で実行してみて、何が行われるかを確認してください。

ただし、kubeadm resetはベストエフォートコマンドであるため、何らかの理由で失敗した場合は、警告のみが出力される可能性があることに注意してください。

neolit123 2019年10月31日

したがって、 kubectl delete nodeはetcdから削除しません。代わりに、ノードkubeadm resetで実行すると実行されます。
私には壊れているように聞こえますが、 kubectl delete nodeはetcdからも削除する必要があると思います。または、明らかなユースケースがありませんか？
多分それもそこから削除されるべきかどうか尋ねますか？
とにかく@ neolit123の説明に感謝します。最初にコントロールプレーンから削除してからリセットしました。etcdから自分自身を削除するには遅すぎたと思います。

zakkg3 2019年10月31日

したがって、さまざまな責任があります。
kubectl delete node、Node APIオブジェクトを削除します-ノードが不要であることが本当に確実な場合は、これを行う必要があります。
その前に、そのノードでkubeadmresetを呼び出す必要があります。私がしていることは、ディスク上の状態をクリーンアップし、etcdメンバーも削除することです（これがコントロールプレーンノードであり、etcdインスタンスがコントロールプレーンノードごとに実行されているデフォルトオプションを使用している場合）

kubeadm resetはノードをリセットしますが、いくつかの理由でNodeオブジェクトを削除しません。

resetはノードをリセットするだけで、ノードに再参加できます。ノード名は予約されたままです。
ノード自体には、そのノードオブジェクトを削除するための十分な権限がありません。これは、「admin.conf」の所有者（管理者など）の責任です。

neolit123 2019年10月31日

👍2

kubeadmresetはベストエフォートコマンドです

これに関して： kubeadm resetが何らかの理由で完了しなかった場合（最初からkubeadmリセットが実行されないようにするための基盤となるサーバーのハード障害を含む）、手動編集以外に状態を手動で調整するオプションがありますkubeadm-config configmapオブジェクトとノードの削除？

Mikulas 2019年10月31日

ノードにハード障害が発生し、ノードでkubeadm resetを呼び出すことができない場合は、手動の手順が必要です。あなたがしなければならないだろう：
1）コントロールプレーンIPをkubeadm-config CMClusterStatusから削除します
2）etcdctlを使用してetcdメンバーを削除します
3）kubectlを使用してNodeオブジェクトを削除します（Nodeが不要になった場合）

1と2は、コントロールプレーンノードにのみ適用されます。

neolit123 2019年10月31日

kubeadm resetを実行できない場合、このフェイルオーバーを自動化する方法はありますか？

amadav 2020年05月09日

1.9でも同じ問題。解決策をありがとう。

thyn 2020年05月23日

このページは役に立ちましたか？

0 / 5 - 0 評価

<p>kubeadmリセットは成功しましたが、このノードのIPはまだkubeadm-configconfigmapにあります</p>

これはバグレポートですか、それとも機能リクエストですか？

バージョン

何が起こった？

あなたは何が起こると思っていましたか？

それを（可能な限り最小限かつ正確に）再現する方法は？

他に知っておくべきことはありますか？

最も参考になるコメント

全てのコメント32件

関連する問題