<p>kubeadm 재설정이 성공했지만이 노드 IP는 여전히 kubeadm-config configmap에 있습니다.</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 .
두 번째 노드에서 kubeadm join --experimental-control-plane --config=kubeadm.yml .
두 번째 노드에서 kubeadm reset -f .
kubectl -n kube-system get cm kubeadm-config -oyaml 이미 ClusterStatus에있는 두 번째 노드 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-config ConfigMap은이 노드 ip를 제거합니다.

@pytimer 클러스터 상태에 노드 API 주소를 남겨 두는 것이 이상적이지

여전히 질문이 있습니다. 왜 kubeadm reset이이 노드를 클러스터에서 직접 삭제하지 않습니까? 대신 kubectl delete node를 실행하십시오.수동으로.

@luxas 는 약간의 역사적 맥락이 도움이 될 수 있습니다.
내 생각 엔 노드가 스스로 삭제할 권한이 없다는 것입니다 (그러나 이것은 제어 플레인 노드가 아닌 작업자 노드에 적용됩니다 ...)

이상적으로는 ClusterStatus를 "새로 고침"하는 방법이있을 것입니다. / ClusterStatus를 명시 적으로 업데이트하는 깨끗한 방법이있을 것입니다.

@danbeaulieu 좋은 지적입니다. 클러스터 상태를 동기화하기위한 명시 적 명령이 있거나 kubeadm이 실행될 때 자동 동기화를 시행하는 것이 좋습니다.
그러나 제어 루프를 지속적으로 실행하지 않는 kubeadm이므로 ClusterStatus가 동기화되지 않을 가능성이 항상 있다고 생각합니다.
이것은 문제가되지 않아야합니다. 또는 더 이상 존재하지 않는 노드에 대해 특히 노드 IP를 갖는 경우 (정리 부족) 문제가되지 않아야합니다.
대신 노드가 있고 해당 노드 IP가 ClusterStatus에서 누락 된 경우 (잘못된 초기화) 업데이트와 같은 문제가 발생할 수 있습니다.

위의 가정이 혼돈 테스트를 통해 확인되면 친절하게보고 해 주시겠습니까? 어떤 피드백이라도 정말 감사 할 것입니다.

fabriziopandini 에 2018년 12월 06일

@fabriziopandini 동일한 컨트롤 플레인 노드에 가입

내 가입 단계 :

두 번째 제어 평면 노드 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에 따라 2 개의 노드가있는 etcd 클러스터는 정상입니다. 그러나 kubeadm은 ClusterStatus를 진실의 소스로 사용하며 여전히 이전 인스턴스가 나열되어 있습니다.

해결 방법은 etcd 멤버십 관리를 수행 한 직후에 클러스터의 진실로 kubeadm-config ConfigMap을 업데이트 한 다음 kubeadm join... 를 실행하는 것입니다.

이상적으로 kubeadm join... 는 etcd를 진실의 소스로 사용하고 그에 따라 kubeadm-config ConfigMap을 업데이트합니다.

danbeaulieu 에 2018년 12월 07일

@fabianofranz 아마도이 문제의 원인을 찾았을 것입니다.

etcd 엔드 포인트를 실제 etcd 엔드 포인트 목록과 동기화하면 동기화가 성공합니다. 그러나 실제 etcd 엔드 포인트를 etcd 클라이언트 Endpoints 할당하면이 클라이언트 변수는 포인터가 아니므로 다른 코드에서 클라이언트를 사용할 때이 클라이언트 엔드 포인트는 동기화 후 실제 엔드 포인트가 아니라 여전히 오래된 엔드 포인트입니다.

내 포크 리포지토리 에서이 문제를 해결했습니다 . 이 PR . 그리고 저는 join the same control-plane node 사용자 사례를 테스트하고 성공했습니다.

pytimer 에 2018년 12월 11일

@pytimer 멋지네요 ! 잘 발견되었습니다!
PR을 보내 주시겠습니까? IMO 이것은 체리 따기에 적합합니다.

@ neolit123 @timothysc ^^^

fabriziopandini 에 2018년 12월 11일

@fabianofranz 첫 번째 PR이 잘못되었습니다. CLA 확인을 잊어 버렸습니다.

이 PR https://github.com/kubernetes/kubernetes/pull/71945 확인하실 수 있습니다. 잘못된 점이 있으면 지적하십시오.

pytimer 에 2018년 12월 11일

@fabriziopandini 동일한 컨트롤 플레인 노드에 가입
내 가입 단계 :
두 번째 제어 평면 노드 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-server를 수동으로 제거하는 방법에 대해 자세히 설명해 주시겠습니까?

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 pod와 etcd pod (각각 2 개)를 죽였습니다.

그들은 다시 생성되지만 추가 노드를 연결하려고 할 때 여전히 동일한 오류가 발생합니다.

lvangool 에 2019년 02월 13일

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

@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://github.com/kubernetes/kubernetes/pull/71945 수정은 컨트롤 플레인 노드에 가입 할 때 etcd 끝점을 동기화하고 etcd 구성원을 제거 할 수 없습니다.

재설정시 etcd 클러스터에서 etcd 구성원을 제거하십시오. kubernetes / kubernetes # 74112를 볼 수 있습니다.

pytimer 에 2019년 02월 19일

이것은 여전히 1.13.4의 버그 인 것 같습니다.

여전히 kubeadm 구성 맵 ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment-463374200을 수동으로 업데이트해야합니다.

문제가 해결되지 않은 경우
kubernetes / kubernetes # 71945는 etcd 클러스터 멤버십을 클러스터 멤버의 진실 소스로 사용합니까? 그렇지 않다면 그 PR이 정확히 무엇을 수정 했습니까?

지도를 통해 범위를 golang에 있기 때문에 흥미롭게도이 산발적으로 작동 ClusterStatus처럼 , 비 결정적이다 . 따라서 발견 된 첫 번째 엔드 포인트가 더 이상 존재하지 않는 이전 엔드 포인트에서 온 것이면 실패합니다. 정상 엔드 포인트를 찾으면 etcd 동기화에서 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 와 관련이없는 다른 문제가 하나 이상 있습니다.

kubeadm 재설정을 수행 할 기회없이 노드가 실패하는 경우 (인스턴스 종료, 하드웨어 실패 등)
클러스터는 ClusterStatus.apiEndpoints가 더 이상 클러스터에없는 노드를 계속 나열하는 상태로 남아 있습니다. 이를 위해서는 kubeadm join 를 수행하기 전에 구성 맵을 읽고 편집하고 업데이트하는 해결 방법이 필요합니다. Kubeadm에는 아마도 두 가지 옵션이 있습니다.

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에서 이것을 경험했습니다.

내 마스터 노드 중 하나를 실행하는 인스턴스가 실패하여 정상적으로 제거되지 않았습니다. 새 노드가 들어 오려고 할 때이 티켓에 설명 된 오류로 인해 참여하지 못했습니다.

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 비정상 오류가 발생했습니다.

해결 방법 ( @Halytskyi 답변을 기반으로하지만 업데이트 된 etcdctl 포함) :

kubeadm-config configmap에서 노드를 삭제하십시오.

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

kubeadm reset -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 이 중단되고 kubeadm CM에서 노드를 삭제할 수없는 경우 이러한 상황이 발생할 수 있습니다.
이러한 경우 kubeadm CM에서 수동으로 삭제해야합니다.

neolit123 에 2019년 10월 30일

따라서 kubectl delete node foobar 노드를 삭제하면
etcd 회원에서 삭제 하시겠습니까? 하지만 내가 원하는 노드에서 kubeadm reset 하면
삭제하려면 어떻게합니까? 🙄

수요일, 30 Oct 2019, 13:27 Lubomir I. Ivanov, [email protected]
썼다 :

이것은 kubeadm reset이 중단되고 삭제할 수없는 경우에 발생할 수 있습니다.
kubeadm CM의 노드.
이러한 경우 kubeadm CM에서 수동으로 삭제해야합니다.
—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMVQJKTDN547877054 BPW63LNMVXHJKW63LNMVXH
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

zakkg3 에 2019년 10월 31일

"kubeadm reset"은 kubeadm CM에서 삭제해야하지만 노드 API 객체를 삭제하는 "kubectl delete node"도 호출해야합니다.

neolit123 에 2019년 10월 31일

제 경우에는 de configmap에서 노드를 삭제해도 삭제되지 않았습니다.
etcd 클러스터는 수동으로 etcdctl delete member .

2019 년 10 월 31 일 목요일 16:28, Lubomir I. Ivanov [email protected]
썼다 :

"kubeadm reset"은 kubeadm CM에서 삭제해야하지만 "kubectl
노드 API 객체를 삭제하는 노드 삭제 "도 필요합니다.
—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFWSVREXG43GIVMVORP963,issueLNMVXHJK963
또는 구독 취소
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 객체를 삭제합니다. 노드가 더 이상 필요하지 않다고 확신 할 때이 작업을 수행해야합니다.
그 전에 해당 노드에서 kubeadm reset을 호출해야합니다. 내가하는 일은 디스크의 상태를 정리하고 etcd 멤버도 제거하는 것입니다 (제어 플레인 노드이고 etcd 인스턴스가 제어 플레인 노드별로 실행되는 기본 옵션을 사용하는 경우)

kubeadm reset은 노드를 재설정하지만 다음과 같은 몇 가지 이유로 Node 객체를 삭제하지 않습니다.

재설정은 노드를 재설정하고 다시 가입 할 수 있습니다. 노드 이름은 예약 된 상태로 유지됩니다.
노드 자체에는 노드 개체를 삭제할 수있는 충분한 권한이 없습니다. 이것은 "admin.conf"소유자 (예 : 관리자)의 책임입니다.

neolit123 에 2019년 10월 31일

👍2

kubeadm reset은 최선의 명령입니다.

이와 관련하여 : kubeadm reset 가 어떤 이유로 든 완료되지 않는 경우 (kubeadm 재설정이 처음에 실행되지 않도록 기본 서버의 하드 실패 포함) 수동 편집 외에 상태를 수동으로 조정하는 옵션이 있습니다. kubeadm-config configmap 객체를 제거하고 노드를 제거 하시겠습니까?

Mikulas 에 2019년 10월 31일

노드가 하드 실패하여 kubeadm reset을 호출 할 수없는 경우 수동 단계가 필요합니다. 다음을 수행해야합니다.
1) kubeadm-config CM ClusterStatus에서 제어 플레인 IP 제거
2) etcdctl을 사용하여 etcd 멤버 제거
3) kubectl을 사용하여 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-config configmap에 있습니다.</p>

버그 보고서 또는 기능 요청입니까?

버전

어떻게 된 거예요?

무슨 일이 일어나기를 기대 했습니까?

그것을 재현하는 방법 (가능한 한 최소한으로 정확하게)?

우리가 알아야 할 다른 것이 있습니까?

가장 유용한 댓글

모든 32 댓글

관련 문제