<p>kubeadm रिसेट सक्सेस लेकिन यह नोड ip अभी भी kubeadm-config configmap में है</p>

को निर्मित 5 दिस॰ 2018 · 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"}

पर्यावरण :

कुबेरनेट्स संस्करण ( 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 कॉन्फिगरेशन देखता हूं, तो पहले से ही क्लस्टर नोड में यह नोड आईपी है।

मेरा अभी भी एक सवाल है, क्यों kubeadm reset इस नोड को सीधे क्लस्टर से नहीं हटाते हैं? इसके बजाय, kubectl delete node <node name> मैन्युअल रूप से चलाएं।

क्या होने की उम्मीद थी?

kubeadm-config विन्यास इस नोड आईपी को हटा दें।

इसे कैसे पुन: पेश करें (जितना संभव हो न्यूनतम और ठीक है)?

पहले नोड पर 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 पहले से ही क्लस्टर क्लस्टर में दूसरा नोड आईपी पाते हैं।

हमें कुछ और जानना चाहिए?

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 (उदाहरण के लिए, मास्टर 01 पर)

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 19 फ़र॰ 2019

👍8 🎉3

सभी 32 टिप्पणियाँ

cc @fabriziopandini

neolit123 5 दिस॰ 2018

आदर्श रूप से क्लस्टरस्टैटस को "ताज़ा" करने का एक तरीका होगा। हम अव्यवस्था परीक्षण के साथ क्लस्टर चलाते हैं, यह एक नियंत्रण विमान नोड के लिए चेतावनी के बिना और kubeadm reset चलाने के अवसर के बिना समाप्त होने के लिए पूरी तरह से संभव है। आदर्श रूप से कंट्रोल प्लेन नोड्स को हटाने के लिए क्लस्टरस्टैटस को स्पष्ट रूप से अपडेट करने का एक साफ तरीका होगा जो हमें पता है कि क्लस्टर में नहीं हैं। यह कुछ ऐसा है जो kubeadm join --control-plane ... चलने से पहले किया जाएगा या संभवतः इसे बनाया गया है?

danbeaulieu 6 दिस॰ 2018

कुछ टिप्पणियाँ यहाँ:

kubeadm-config configMap इस नोड आईपी को हटा दें।

@ पॉइटिमर मुझे पता है कि क्लस्टर स्थिति में एक नोड

मेरा अभी भी एक सवाल है, क्यूबीडम रीसेट ने क्लस्टर से सीधे इस नोड को क्यों नहीं हटाया? इसके बजाय, kubectl हटाएँ नोड चलाएँमैन्युअल रूप से।

@ लक्सा ऐतिहासिक संदर्भ का एक छोटा सा
मेरा अनुमान है कि नोड के पास खुद को हटाने का विशेषाधिकार नहीं था (लेकिन यह कार्यकर्ता नोड्स पर लागू होता है, नियंत्रण-प्लेन के लिए नहीं ...)

आदर्श रूप से ClusterStatus को "रीफ़्रेश" करने का एक तरीका होगा / ClusterStatus को स्पष्ट रूप से अपडेट करने का एक साफ तरीका होगा

@danbeaulieu यह एक अच्छी बात है। क्लस्टर स्थिति को सिंक्रनाइज़ करने के लिए या kubeadm निष्पादित होने पर स्वचालित सिंक को लागू करने के लिए एक स्पष्ट आदेश होना एक अच्छा विचार है।
हालांकि, किसी भी प्रकार के निरंतर चलने वाले नियंत्रण लूप के बिना कुबेदम होने के नाते, मुझे लगता है कि हमेशा सिंक से बाहर क्लस्टरस्टैटस होने की संभावना होगी।
यह एक समस्या नहीं होनी चाहिए, या विशेष रूप से नोड्स के लिए नोड आईपी होने से अधिक नहीं है (सफाई की कमी) अब समस्या नहीं होनी चाहिए।
इसके बजाय यदि कोई नोड मौजूद है और संबंधित नोड IP ClusterStatus (गलत प्रारंभ) से अनुपलब्ध है, तो यह अद्यतन के लिए समस्याएँ बना सकता है।

क्या आप कृपया रिपोर्ट कर सकते हैं कि क्या उपरोक्त धारणा आपके अराजकता परीक्षण की पुष्टि करती है? किसी भी प्रतिक्रिया वास्तव में मूल्यांकन किया जाएगा।

fabriziopandini 6 दिस॰ 2018

@fabriziopandini मैं एक ही कंट्रोल-प्लेन नोड में शामिल

मेरे कदम

दूसरा कंट्रोल-प्लेन नोड आईपी 192.168.46.212 ।

192.168.46.212 नोड आदि को सदस्य समूह से हटा दें।
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 कोड देखता हूं, और मुझे लगता है कि यह समस्या शायद 192.168.46.212 के कारण kubeadm-config configMap में शेष है।

नियंत्रण-प्लेन नोड में शामिल होने पर Kubeadm को kubeadm-config कॉन्फ़िगरेशन से एपीआई समापन बिंदु मिलते हैं, और etcd समापन बिंदु एपीआई समापन बिंदु के समान होते हैं। लेकिन 912.168.46.212 कंट्रोल-प्लेन नोड को हटा दिया गया है और यह अभी तक शामिल नहीं हुआ है, इसलिए चेक क्लस्टर स्वास्थ्य को गलत करें।

जब मैं हटाने 192.168.46.212 से एपीआई endpoint kubeadm-config ConfigMap, और इस पर नियंत्रण विमान नोड फिर से शामिल होने, यह सफलता में शामिल हो।

pytimer 7 दिस॰ 2018

👍5

@pytimer धन्यवाद!
इसकी जांच होनी चाहिए। पहले से ही एक तर्क है जो वास्तविक etcd सूची समापन बिंदु के साथ etcd समापन बिंदुओं की सूची को सिंक करने की कोशिश करता है, लेकिन कुछ उचित नहीं लगता है

fabriziopandini 7 दिस॰ 2018

हाँ यह एक बग की तरह लगता है। हमारे पास 3 नोड कंट्रोल प्लेन ASG है। यदि हम एक उदाहरण को समाप्त करते हैं तो एएसजी नियमों के अनुसार एक नया बनाया जाएगा। इस समय के दौरान समाप्त नोड को etcd की सदस्य सूची में अस्वास्थ्यकर के रूप में सूचीबद्ध किया गया है। जब नया उदाहरण सामने आता है, तो kubeadm join... चलने से पहले, यह अनहेल्दी मेंबर को etcd से हटा देता है। जब तक हम kubeadm join... चलाते हैं तब तक etcd क्लस्टर के अनुसार 2 नोड्स के साथ स्वस्थ है। हालांकि कुबेदम क्लेस्टरस्टैटस को सच्चाई के अपने स्रोत के रूप में उपयोग करता है, जो अभी भी पुराने उदाहरण में सूचीबद्ध है।

Etcd सदस्यता प्रबंधन करने के बाद हमारे लिए वर्कअराउंड सही है, क्लस्टर की सच्चाई के साथ kubeadm-config configMap अद्यतन करना है, और फिर kubeadm join... चल रहा है।

आदर्श रूप से kubeadm join... सत्य के स्रोत के रूप में etcd का उपयोग करेगा और तदनुसार kubeadm-config विन्यास को अद्यतन करेगा।

danbeaulieu 7 दिस॰ 2018

@fabianofranz मैं शायद इस समस्या का कारण पाया।

जब वास्तविक etcd समापन बिंदु सूची के साथ etc अंत बिंदुओं को सिंक करते हैं, तो सिंक सफलता है। लेकिन ग्राहक को Endpoints का वास्तविक etcd एंडपॉइंट असाइन करें, यह क्लाइंट चर सूचक नहीं है, इसलिए जब अन्य कोड क्लाइंट का उपयोग करते हैं, तो यह क्लाइंट एंडपॉइंट अभी भी पुराने समापन बिंदु हैं, न कि सिंक के बाद वास्तविक समापन बिंदु।

मैंने अपने फोर्क रिपॉजिटरी में इस समस्या को ठीक किया, आप इस PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4fa480800033 की जांच कर सकते हैं join the same control-plane node उपयोगकर्ता मामले का परीक्षण कर रहा हूं, यह सफलता में शामिल होता है।

pytimer 11 दिस॰ 2018

@ पायमेटिमर बहुत अच्छा लग रहा है! अच्छी तरह से देखा गया!
क्या आप कृपया एक पीआर भेज सकते हैं? IMO यह चेरी पिकिंग के लिए पात्र होगा।

@ neolit123 @timothysc ^^^

fabriziopandini 11 दिस॰ 2018

@fabianofranz पहला पीआर गलत है, मैं सीएलए की पुष्टि करता हूं।

यह PR https://github.com/kubernetes/kubernetes/pull/71945 आप देख सकते हैं। अगर कुछ भी गलत हो, तो आशा है कि आप इंगित करेंगे।

pytimer 11 दिस॰ 2018

@fabriziopandini मैं एक ही कंट्रोल-प्लेन नोड में शामिल
मेरे कदम
दूसरा कंट्रोल-प्लेन नोड आईपी 192.168.46.212 ।
192.168.46.212 नोड आदि को सदस्य समूह से हटा दें।
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 कोड देखता हूं, और मुझे लगता है कि यह समस्या शायद 192.168.46.212 के कारण kubeadm-config configMap में शेष है।
नियंत्रण-प्लेन नोड में शामिल होने पर Kubeadm को kubeadm-config कॉन्फ़िगरेशन से एपीआई समापन बिंदु मिलते हैं, और etcd समापन बिंदु एपीआई समापन बिंदु के समान होते हैं। लेकिन 912.168.46.212 कंट्रोल-प्लेन नोड को हटा दिया गया है और यह अभी तक शामिल नहीं हुआ है, इसलिए चेक क्लस्टर स्वास्थ्य को गलत करें।
जब मैं हटाने 192.168.46.212 से एपीआई endpoint kubeadm-config ConfigMap, और इस पर नियंत्रण विमान नोड फिर से शामिल होने, यह सफलता में शामिल हो।

Kubeadm संस्करण 1.13.2 में समान त्रुटि मिली, मैंने नोड को मैन्युअल रूप से निकालने और kubeadm-config को अपडेट करने की कोशिश की, यह काम नहीं करता है, बाकी etcd नोड्स अभी भी हटाए गए नोड को जोड़ने का प्रयास करते हैं

zhangyelong 9 फ़र॰ 2019

जब मैं kubeadm-config configMap से 192.168.46.212 api समापन बिंदु निकालता हूं, और इस नियंत्रण-प्लेन नोड को फिर से सम्मिलित करता हूं, तो यह सफलता में शामिल हो जाता है।

@pytimer क्या आप इस बारे में विस्तार से

मैं 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

फिर मैंने एपी पॉड्स और कॉर्ड पॉड्स (प्रत्येक के 2) को मार दिया है।

वे फिर से जुड़ जाते हैं, लेकिन अतिरिक्त नोड को जोड़ने की कोशिश करते समय मेरे पास अभी भी वही त्रुटि है।

lvangool 13 फ़र॰ 2019

क्लस्टर से नोड हटाएं

kubectl delete node master03

डाउनलोड etcdctl (उदाहरण के लिए, मास्टर 01 पर)

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 19 फ़र॰ 2019

👍8 🎉3

@zhangyelong अब kubeadm रीसेट, etcd सदस्य को हटा नहीं सकता है, इसलिए आपने पाया कि etc क्लस्टर अभी भी हटाए गए etc नोड को कनेक्ट करते हैं। अब आपको etcdctl का उपयोग करके मैन्युअल रूप से etcd सदस्य को निकालना चाहिए।

जब रीसेट होता है, तो मैं पीआरआर को लागू करने के लिए पीआर भेजता हूं, आप देख सकते हैं। https://github.com/kubernetes/kubernetes/pull/74112

pytimer 19 फ़र॰ 2019

👍1

@lvangool आप @Halytskyi चरणों का पालन कर सकते हैं। PR: https://github.com/kubernetes/kubernetes/pull/71945 कंट्रोल प्लेन नोड में शामिल होने पर सिंक etcd एंडपॉइंट्स को ठीक करता है, etc सदस्य को हटा नहीं सकता है।

रीसेट करते समय etcd सदस्य को etcd क्लस्टर से निकालें, आप # 74112 kubernetes / kubernetes देख सकते हैं।

pytimer 19 फ़र॰ 2019

यह अभी भी 1.13.4 में एक बग लगता है।

हमें अभी भी मैन्युअल रूप से kubeadm config map ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200 अपडेट करने की आवश्यकता है

क्या यह ठीक नहीं है
kubernetes / kubernetes # 71945 क्लस्टर सदस्यों के लिए सत्य के स्रोत के रूप में आदि क्लस्टर सदस्यता का उपयोग करेगा? यदि नहीं, तो वास्तव में उस पीआर ने क्या तय किया?

दिलचस्प है कि यह छिटपुट रूप से काम करता है क्योंकि क्लस्टरस्टैटस जैसे नक्शे पर गोलंग रेंज में, गैर-नियतात्मक है । इसलिए यदि पहला समापन बिंदु यह पाता है कि पुराने समापन बिंदु से है जो अब मौजूद नहीं है, तो चीजें विफल हो जाती हैं। यदि यह एक स्वस्थ समापन बिंदु पाता है तो यह क्लस्टर सिंक से क्लस्टरस्टैटस को अपडेट करेगा ...

मेरा मानना है कि इसका मूल कारण etcd clientv3 में एक बग है जहां बग क्लाइंट को दूसरे एंडपॉइंट्स को पुनःप्राप्त नहीं करने का कारण बनता है यदि पहले वाला https://github.com/etcd-io/etcd/issues/9949 विफल रहता है

danbeaulieu 1 मार्च 2019

कृपया रीसेट सुधार पर नज़र रखने के लिए निम्नलिखित समस्या का उपयोग करें

https://github.com/kubernetes/kubeadm/issues/1312 ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pub/72886) से कंट्रोल-प्लेन नोड्स निकालें
https:// g लिथ

fabriziopandini 1 मार्च 2019

@fabriziopandini यहाँ कम से कम एक और मुद्दा है जो kubeadm reset से असंबंधित है।

यदि एक नोड kubeadm रीसेट (उदाहरण समाप्ति, हार्डवेयर विफलता आदि) का मौका दिए बिना विफल रहता है
क्लस्टर को उस स्थिति में छोड़ दिया जाता है जहाँ ClusterStatus.apiEndpoint अभी भी एक नोड को सूचीबद्ध करता है जो अब क्लस्टर में नहीं है। इसके लिए kubeadm join प्रदर्शन करने से पहले कॉन्फ़िगरेशन मैप को पढ़ने, संपादन और अपडेट करने की आवश्यकता होती है। कुबेदम में संभवतः 2 विकल्प हैं:

1) डायल विफल होने पर स्वयं ही etcd क्लाइंट को फिर से लागू करें
2) गो-जीपीसी बग को ठीक करने के लिए प्रतीक्षा करें और फिर इसे ठीक करने के लिए etcd क्लाइंट के लिए

यह समस्या उन विकल्पों में से किसी को ट्रैक करने के लिए उपयोग करने के लिए एक अच्छा मुद्दा हो सकता है।

danbeaulieu 1 मार्च 2019

👍1

यदि एक नोड kubeadm रीसेट (उदाहरण समाप्ति, हार्डवेयर विफलता आदि) का मौका दिए बिना विफल रहता है
क्लस्टर को उस स्थिति में छोड़ दिया जाता है जहाँ ClusterStatus.apiEndpoint अभी भी एक नोड को सूचीबद्ध करता है जो अब क्लस्टर में नहीं है। इसके लिए kubeadm join प्रदर्शन करने से पहले कॉन्फ़िगरेशन मैप को पढ़ने, संपादन और अपडेट करने की आवश्यकता होती है।

यह सच है, बिना कॉल रीसेट के आपको मैन्युअल रूप से ClusterStatus को अपडेट करना होगा।
हमारे पास ऐसा आदेश नहीं है जो ऐसा करता हो। यदि आपको ऐसा लगता है कि कुबेदम का समर्थन करना चाहिए तो कृपया एक अलग टिकट दर्ज करें।

neolit123 1 मार्च 2019

बस आज १.१४.१ पर इसका अनुभव किया

मेरे मास्टर नोड्स में से एक चल रहा उदाहरण विफल हो गया, जिसने इसे इनायत से हटा दिया। जब एक नए नोड ने इसमें आने का प्रयास किया तो इस टिकट में वर्णित त्रुटि के कारण शामिल होने में विफल रहा।

मुझे etcdctl के माध्यम से etc सदस्य को मैन्युअल रूप से निकालना था, फिर मैं एक नए नोड में शामिल हो सकता था। मैंने स्वयं भी kubeadm-config configMap से नोड को हटा दिया था, लेकिन मुझे यकीन नहीं है कि अगर यह आवश्यक था।

falken 1 मई 2019

👍3

@Halytskyi धन्यवाद मेरे लिए मदद आदि अनुभाग मैं .....

Nurlan199206 14 जुल॰ 2019

1.15.5 में आज इसका अनुभव किया

मेरे मामले में, मैं क्लस्टर में शामिल हो गया लेकिन 1.16 संस्करण के साथ। फिर इस नोड को kubectl delete node 15.5.5 पर डाउनग्रेड किया गया और पुनः कनेक्ट करने का प्रयास करें (वही आईपी, समान होस्टनाम, अलग-अलग संस्करण) और आदि को अस्वस्थ त्रुटि मिली।

द्वारा हल किया गया ( @Halytskyi उत्तर पर लेकिन अद्यतन किए गए अपडेट के साथ):

नोड को हटाएं kubeadm-config configmap का निर्माण करें

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

kubeadm रीसेट -f प्रॉब्लम नोड और& iptables -t -f -X इत्यादि में।
हटाना आदि सदस्य (यह कुंजी है):

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-acacert / 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 30 अक्तू॰ 2019

यह तब हो सकता है यदि kubeadm reset बाधित हो और नोड को kubeadm CM से हटा नहीं सके।
ऐसे मामले में आपको इसे मैन्युअल रूप से kubeadm CM से हटाने की आवश्यकता है।

neolit123 30 अक्तू॰ 2019

तो अगर मैं kubectl delete node foobar साथ नोड को हटाता हूं तो यह नहीं होता है
आदि सदस्य से इसे हटाएं? लेकिन अगर मैं नोड में kubeadm reset करना चाहता हूं
हटाना है, तो यह करता है? 🙄

बुध पर, 30 अक्टूबर 2019, 13:27 लुबोमिर आई। इवानोव, सूचनाएं @github.com
लिखा था:

यह तब हो सकता है जब kubeadm रीसेट बाधित हो और हटा न सके
कुबेदम मुख्यमंत्री से नोड।
ऐसे मामले में आपको इसे मैन्युअल रूप से kubeadm CM से हटाने की आवश्यकता है।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
।

zakkg3 31 अक्तू॰ 2019

"kubeadm reset" को इसे kubeadm CM से हटाना चाहिए, लेकिन "kubectl delete नोड" को कॉल करना भी आवश्यक है जो Node API ऑब्जेक्ट को हटा देता है।

neolit123 31 अक्तू॰ 2019

मेरे मामले में de configmap से नोड को हटाने से इसे हटाने के रूप में नहीं हुआ
आदि क्लस्टर मैं etcdctl delete member मैन्युअल रूप से आवश्यक है।

थु पर, 31 अक्टूबर 2019 को 16:28 पर, लुबोमिर आई। इवानोव सूचनाएं @github.com
लिखा था:

"kubeadm रीसेट" को kubeadm CM से हटाना चाहिए, लेकिन "kubectl" को कॉल करना चाहिए
"नोड हटाएं" भी आवश्यक है जो नोड एपीआई ऑब्जेक्ट को हटा देता है।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZWQQQ2TLA5CNFSM4GIIZZKYH3H3H6H3H3H3H3H3H3H3H3&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&hl=hi&bh=hbhbh3h इस शो
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
।

zakkg3 31 अक्तू॰ 2019

kubeadm reset को etcd सदस्य को etcd क्लस्टर से हटा देना चाहिए।
इसे जैसे --v = 5 के साथ निष्पादित करने का प्रयास करें और देखें कि यह क्या करता है।

हालाँकि यह ध्यान रखें कि kubeadm रीसेट एक सर्वश्रेष्ठ प्रयास कमांड है इसलिए यदि यह किसी कारण से विफल हो जाता है तो यह केवल एक चेतावनी प्रिंट कर सकता है।

neolit123 31 अक्तू॰ 2019

इसलिए kubectl delete node इसे etcd से नहीं हटाता है। इसके बजाय, नोड kubeadm reset में चल रहा है।
मेरे लिए टूट गया लगता है, मुझे लगता है कि kubectl delete node को फॉर्म आदि को भी हटाना चाहिए। या मैं एक स्पष्ट उपयोग के मामले को याद कर रहा हूं?
शायद पूछ रहा है कि क्या इसे भी वहां से हटा दिया जाना चाहिए?
वैसे भी स्पष्टीकरण के लिए धन्यवाद @ neolit123 , मैंने पहले इसे नियंत्रण विमान से हटा दिया और फिर एक रीसेट किया, अनुमान है कि खुद को कॉर्ड से हटाने के लिए बहुत देर हो चुकी थी।

zakkg3 31 अक्तू॰ 2019

इसलिए अलग-अलग जिम्मेदारियां हैं।
kubectl नोड हटाएं, नोड API ऑब्जेक्ट को हटाता है - आपको ऐसा तब करना चाहिए जब आप वास्तव में निश्चित हों कि आप अब नोड नोड नहीं चाहते हैं,
इससे पहले कि आप उस नोड पर kubeadm रीसेट कॉल करना चाहिए। मैं क्या करता हूं यह डिस्क पर स्थिति को साफ करता है और आदि सदस्य को भी हटा देता है (यदि यह एक नियंत्रण-विमान नोड है और यदि आप डिफ़ॉल्ट विकल्प का उपयोग कर रहे हैं जहां प्रति नियंत्रण-विमान नोड प्रति चल रहे हैं)

kubeadm रीसेट नोड को रीसेट करता है, लेकिन यह कुछ कारणों से नोड ऑब्जेक्ट को नहीं हटाता है:

रीसेट बस नोड को रीसेट करता है और आप इसे फिर से जोड़ सकते हैं। नोड नाम आरक्षित रहता है।
नोड के पास यह नोड ऑब्जेक्ट को हटाने के लिए पर्याप्त विशेषाधिकार नहीं है। यह "admin.conf" (जैसे प्रशासक) के मालिक की जिम्मेदारी है।

neolit123 31 अक्तू॰ 2019

👍2

kubeadm reset एक बेहतरीन प्रयास कमांड है

इस बारे में: जब kubeadm reset जो भी कारण से पूरा करने में विफल रहता है (अंतर्निहित सर्वर की एक कठिन विफलता सहित, ताकि कुबेदम रीसेट को कभी भी पहले स्थान पर निष्पादित न किया जाए) मैन्युअल रूप से संपादन के साथ राज्य को मैन्युअल रूप से समेटने का कोई विकल्प नहीं है kubeadm-config configmap ऑब्जेक्ट और नोड को हटा रहा है?

Mikulas 31 अक्तू॰ 2019

यदि नोड कठिन है और आप उस पर kubeadm रीसेट नहीं कर सकते हैं, तो इसके लिए मैन्युअल चरणों की आवश्यकता होती है। आपको निम्न करना होगा:
1) kubeadm-config CM ClusterStatus से कंट्रोल-प्लेन IP निकालें
2) etcdctl का उपयोग करके etc सदस्य को हटा दें
3) kubectl का उपयोग करके नोड ऑब्जेक्ट को हटा दें (यदि आप अब और नोड नहीं चाहते हैं)

1 और 2 केवल कंट्रोल-प्लेन नोड्स पर लागू होते हैं।

neolit123 31 अक्तू॰ 2019

क्या इस विफल-स्वचालित को स्वचालित करने का कोई तरीका है यदि कुबेदम रीसेट नहीं चलाया जा सकता है?

amadav 9 मई 2020

1.9 पर समान समस्याएं। समाधान के लिए धन्यवाद।

thyn 23 मई 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

<p>kubeadm रिसेट सक्सेस लेकिन यह नोड ip अभी भी kubeadm-config configmap में है</p>

क्या यह बग रिपोर्ट या प्रतिक्रिया की आवश्यकता है?

संस्करणों

क्या हुआ?

क्या होने की उम्मीद थी?

इसे कैसे पुन: पेश करें (जितना संभव हो न्यूनतम और ठीक है)?

हमें कुछ और जानना चाहिए?

सबसे उपयोगी टिप्पणी

सभी 32 टिप्पणियाँ

संबंधित मुद्दों