<p>نجح إعادة تعيين kubeadm ولكن عنوان IP هذا العقدة لا يزال في kubeadm-config configmap</p>

تم إنشاؤها على ٥ ديسمبر ٢٠١٨ · 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"}

مزود السحابة أو تكوين الأجهزة :
نظام التشغيل (على سبيل المثال من / 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"

Kernel (على سبيل المثال 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 ، فإنه يحتوي بالفعل على عنوان IP هذا في ClusterStatus.

لا يزال لدي سؤال ، لماذا لا يحذف 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 ابحث عن عنوان IP الثاني للعقدة بالفعل في ClusterStatus.

أي شيء آخر نحن بحاجة إلى معرفته؟

kubeadm-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 في ١٩ فبراير ٢٠١٩

👍8 🎉3

ال 32 كومينتر

cc fabriziopandini

neolit123 في ٥ ديسمبر ٢٠١٨

من الناحية المثالية ستكون هناك طريقة "لتحديث" ClusterStatus. نقوم بتشغيل مجموعات مع اختبار الفوضى ، فمن الممكن تمامًا إنهاء عقدة مستوى التحكم دون سابق إنذار وبدون فرصة لتشغيل kubeadm reset . من الناحية المثالية ، ستكون هناك طريقة نظيفة لتحديث ClusterStatus صراحة لإزالة عقد مستوى التحكم التي نعلم أنها لم تعد موجودة في المجموعة. هل هذا شيء يجب القيام به قبل تشغيل kubeadm join --control-plane ... أو ربما يكون مدمجًا؟

danbeaulieu في ٦ ديسمبر ٢٠١٨

بعض التعليقات هنا:

kubeadm-config ConfigMap إزالة هذه العقدة ip.

@ pytimer أعلم أن ترك عنوان api للعقدة في حالة الكتلة ليس مثاليًا ، لكنني مهتم بفهم ما إذا كان "نقص التنظيف" هذا يولد مشاكل أم لا. هل حاولت الانضمام إلى نفس طائرة التحكم مرة أخرى؟ هل حاولت الانضمام إلى طائرة تحكم أخرى؟ لا أتوقع مشاكل ، لكن الحصول على تأكيد بشأن هذه النقطة سيكون موضع تقدير حقًا.

لا يزال لدي سؤال ، لماذا لا تحذف kubeadm reset هذه العقدة مباشرة من الكتلة؟ بدلاً من ذلك ، قم بتشغيل kubectl delete nodeيدويا.

luxas قد يكون قليلاً من السياق التاريخي يمكن أن يساعد هنا.
تخميني هو أن العقدة لم يكن لديها امتياز حذف نفسها (ولكن هذا ينطبق على العقد العاملة ، وليس لعقد مستوى التحكم ...)

من الناحية المثالية ، ستكون هناك طريقة "لتحديث" ClusterStatus / ستكون هناك طريقة نظيفة لتحديث ClusterStatus بشكل صريح

danbeaulieu هذه نقطة جيدة. يعد وجود أمر صريح لمزامنة حالة المجموعة و / أو فرض المزامنة التلقائية عند تنفيذ kubeadm فكرة جيدة.
ومع ذلك ، لكونك kubeadm بدون أي نوع من حلقة التحكم التي تعمل بشكل مستمر ، أعتقد أنه سيكون هناك دائمًا احتمال أن يكون ClusterStatus خارج المزامنة.
لا ينبغي أن تكون هذه مشكلة ، أو بشكل خاص في وجود عقدة IP للعقد التي لم تعد موجودة بعد الآن (نقص التنظيف) لا ينبغي أن يكون مشكلة.
بدلاً من ذلك ، إذا كانت العقدة موجودة وكان عنوان IP المقابل مفقودًا من ClusterStatus (تهيئة خاطئة) ، فقد يؤدي ذلك إلى حدوث مشكلات في التحديثات على سبيل المثال.

هل يمكنك التفضل بالإبلاغ عما إذا تم تأكيد الافتراض أعلاه من خلال اختبار الفوضى؟ أي ردود فعل سيكون موضع تقدير حقًا.

fabriziopandini في ٦ ديسمبر ٢٠١٨

fabriziopandini ، انضممت إلى نفس عقدة مستوى التحكم ، لقد فشلت.

خطوات الانضمام الخاصة بي:

عنوان IP الثاني لعقدة مستوى التحكم هو 192.168.46.212 .

قم بإزالة العضو 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 ، وأعتقد أن سبب هذه المشكلة ربما يكون بسبب 192.168.46.212 ترك في kubeadm-config ConfigMap.

تحصل Kubeadm على نقاط نهاية api من kubeadm-config ConfigMap عند الانضمام إلى عقدة مستوى التحكم ، ونقاط النهاية etcd هي نفسها نقاط نهاية api. ولكن تمت إزالة عقدة مستوى التحكم في مستوى 912.168.46.212 ولم يتم ضمها بعد ، لذا تحقق من صحة المجموعة الخاطئة.

عندما أزيل نقطة نهاية واجهة برمجة التطبيقات 192.168.46.212 من kubeadm-config ConfigMap ، وانضممت إلى عقدة مستوى التحكم هذه مرة أخرى ، تنضم بنجاح.

pytimer في ٧ ديسمبر ٢٠١٨

👍5

@ pytimer شكرا!
يجب التحقيق في هذا. يوجد بالفعل منطق يحاول مزامنة القائمة المفترضة لنقاط النهاية etcd مع نقطة نهاية القائمة الحقيقية وما إلى ذلك ، ولكن يبدو أن شيئًا ما لا يعمل بشكل صحيح

fabriziopandini في ٧ ديسمبر ٢٠١٨

نعم هذا يبدو وكأنه خطأ. لدينا طائرة تحكم 3 عقدة ASG. إذا قمنا بإنهاء مثيل ، فسيتم إنشاء مثيل جديد وفقًا لقواعد ASG. خلال هذا الوقت ، يتم إدراج العقدة المنتهية على أنها غير صحية في قائمة الأعضاء وما إلى ذلك. عندما يظهر المثيل الجديد ، قبل تشغيل kubeadm join... ، فإنه يزيل العضو غير الصحي من etcd. بحلول الوقت الذي نشغّل فيه kubeadm join... ، تكون الكتلة etcd سليمة مع عقدتين وفقًا لـ etcd. ومع ذلك ، فإن kubeadm يستخدم ClusterStatus كمصدر للحقيقة ، والذي لا يزال يحتوي على المثيل القديم.

الحل البديل بالنسبة لنا هو مباشرة بعد القيام بإدارة العضوية etcd وهو تحديث kubeadm-config ConfigMap مع حقيقة المجموعة ، ثم تشغيل kubeadm join... .

من الناحية المثالية ، قد يستخدم kubeadm join... etcd كمصدر للحقيقة ويقوم بتحديث ملف ConfigMap kubeadm-config وفقًا لذلك.

danbeaulieu في ٧ ديسمبر ٢٠١٨

fabianofranz ربما وجدت سبب هذه المشكلة.

عند مزامنة نقاط النهاية etcd مع قائمة نقاط النهاية الحقيقية ، تكون المزامنة ناجحة. لكن قم بتعيين نقاط النهاية الحقيقية etcd للعميل etcd Endpoints ، متغير العميل هذا ليس مؤشرًا ، لذلك عندما تستخدم شفرة أخرى العميل ، تظل نقاط نهاية العميل هذه قديمة ، وليس نقاط النهاية الحقيقية بعد المزامنة.

لقد أصلحت هذه المشكلة في مستودع fork الخاص بي ، يمكنك التحقق من هذا PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. وأختبر حالة مستخدم join the same control-plane node ، فقد انضممت إلى النجاح

pytimer في ١١ ديسمبر ٢٠١٨

@ pytimer تبدو رائعة! رصدت جيدا!
هل يمكنك التفضل بإرسال العلاقات العامة؟ IMO سيكون هذا مؤهلا لقطف الكرز.

تضمين التغريدة

fabriziopandini في ١١ ديسمبر ٢٠١٨

fabianofranz العلاقات العامة الأولى خاطئة ، نسيت تأكيد CLA.

يمكنك التحقق من هذا https://github.com/kubernetes/kubernetes/pull/71945 . إذا كان هناك أي شيء خاطئ ، أرجو أن تشير.

pytimer في ١١ ديسمبر ٢٠١٨

fabriziopandini ، انضممت إلى نفس عقدة مستوى التحكم ، لقد فشلت.
خطوات الانضمام الخاصة بي:
عنوان IP الثاني لعقدة مستوى التحكم هو 192.168.46.212 .
قم بإزالة العضو 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 ، وأعتقد أن سبب هذه المشكلة ربما يكون بسبب 192.168.46.212 ترك في kubeadm-config ConfigMap.
تحصل Kubeadm على نقاط نهاية api من kubeadm-config ConfigMap عند الانضمام إلى عقدة مستوى التحكم ، ونقاط النهاية etcd هي نفسها نقاط نهاية api. ولكن تمت إزالة عقدة مستوى التحكم في مستوى 912.168.46.212 ولم يتم ضمها بعد ، لذا تحقق من صحة المجموعة الخاطئة.
عندما أزيل نقطة نهاية واجهة برمجة التطبيقات 192.168.46.212 من kubeadm-config ConfigMap ، وانضممت إلى عقدة مستوى التحكم هذه مرة أخرى ، تنضم بنجاح.

حصلت على نفس الخطأ في الإصدار 1.13.2 من kubeadm ، حاولت إزالة العقدة يدويًا وتحديث kubeadm-config ، وهي لا تعمل ، وما زالت العقد الأخرى الأخرى تحاول توصيل العقدة التي تمت إزالتها

zhangyelong في ٩ فبراير ٢٠١٩

عندما أزيل نقطة نهاية واجهة برمجة التطبيقات 192.168.46.212 من kubeadm-config ConfigMap ، وانضممت إلى عقدة مستوى التحكم هذه مرة أخرى ، تنضم بنجاح.

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 والقرون وغيرها (2 من كل منها).

يتم إعادة إنشائها ، لكن لا يزال لدي نفس الخطأ عند محاولة توصيل العقدة الإضافية.

lvangool في ١٣ فبراير ٢٠١٩

حذف العقدة من الكتلة

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 في ١٩ فبراير ٢٠١٩

👍8 🎉3

zhangyelong الآن لا يمكن إعادة تعيين kubeadm إزالة العضو etcd ، لذلك وجدت أن مجموعة etcd لا تزال تربط العقدة etcd التي تمت إزالتها. يجب عليك إزالة عضو etcd يدويًا باستخدام etcdctl الآن.

أرسل PR لتنفيذ إزالة العقدة etcd عند إعادة التعيين ، يمكنك أن ترى. https://github.com/kubernetes/kubernetes/pull/74112

pytimer في ١٩ فبراير ٢٠١٩

👍1

lvangool يمكنك اتباع خطوات Halytskyi . العلاقات العامة: https://github.com/kubernetes/kubernetes/pull/71945 تعمل على إصلاح مزامنة نقاط النهاية etcd عند الانضمام إلى عقدة مستوى التحكم ، ولا يمكن إزالة العضو etcd.

قم بإزالة عضو etcd من مجموعة etcd عند إعادة التعيين ، يمكنك رؤية kubernetes / kubernetes # 74112.

pytimer في ١٩ فبراير ٢٠١٩

يبدو أن هذا لا يزال يمثل خطأ في 1.13.4.

ما زلنا بحاجة إلى تحديث خريطة تكوين kubeadm يدويًا على https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

أليس هذا هو الحال أن الإصلاح في
kubernetes / kubernetes # 71945 هل ستستخدم عضوية المجموعة etcd كمصدر للحقيقة لأعضاء الكتلة؟ إذا لم يكن الأمر كذلك ، فما الذي تم إصلاحه بالضبط؟

ومن المثير للاهتمام أنه يعمل بشكل متقطع لأنه في نطاق golang فوق الخرائط ، مثل ClusterStatus ، يكون غير حتمي. لذلك إذا كانت نقطة النهاية الأولى التي يعثر عليها من نقطة نهاية قديمة لم تعد موجودة ، فإن الأشياء تفشل. إذا عثرت على نقطة نهاية صحية ، فستقوم بتحديث ClusterStatus من المزامنة وما إلى ذلك ...

أعتقد أن السبب الجذري لهذا هو خطأ في etcd clientv3 حيث يتسبب الخطأ في عدم قيام العميل بإعادة محاولة نقاط النهاية الأخرى إذا فشل الأول https://github.com/etcd-io/etcd/issues/9949.

danbeaulieu في ١ مارس ٢٠١٩

يرجى استخدام المشكلة التالية لتتبع تحسينات إعادة التعيين

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 (

fabriziopandini في ١ مارس ٢٠١٩

fabriziopandini هناك مشكلة أخرى على الأقل هنا لا علاقة لها بـ kubeadm reset .

إذا فشلت عقدة دون فرصة لإجراء إعادة تعيين kubeadm (إنهاء المثيل ، فشل الأجهزة ، إلخ)
يتم ترك الكتلة في حالة حيث لا يزال ClusterStatus.apiEndpoints يسرد عقدة لم تعد موجودة في الكتلة. يتطلب هذا الحل البديل لقراءة خريطة التكوين وتحريرها وتحديثها قبل تنفيذ kubeadm join . ربما يكون لدى Kubeadm خياران:

1) قم بتنفيذ عميل etcd وأعد محاولة نفسه إذا فشل الطلب
2) انتظر حتى يتم إصلاح خطأ go-grpc ثم حتى يصل الإصلاح إلى عميل etcd

قد تكون هذه المشكلة مشكلة جيدة لاستخدامها لتتبع أي من هذين الخيارين.

danbeaulieu في ١ مارس ٢٠١٩

👍1

إذا فشلت عقدة دون فرصة لإجراء إعادة تعيين kubeadm (إنهاء المثيل ، فشل الأجهزة ، إلخ)
يتم ترك الكتلة في حالة حيث لا يزال ClusterStatus.apiEndpoints يسرد عقدة لم تعد موجودة في الكتلة. يتطلب هذا الحل البديل لقراءة خريطة التكوين وتحريرها وتحديثها قبل تنفيذ kubeadm join .

هذا صحيح ، بدون استدعاء إعادة تعيين ، سيتعين عليك تحديث ClusterStatus يدويًا.
ليس لدينا أمر يقوم بذلك. إذا كنت تشعر أن هذه ميزة يجب أن يدعمها kubeadm ، فيرجى تقديم تذكرة منفصلة.

neolit123 في ١ مارس ٢٠١٩

اختبرت هذا اليوم للتو في 1.14.1

فشل المثيل الذي يقوم بتشغيل إحدى عقدتي الرئيسية مما منعه من الإزالة بأمان. عندما حاولت عقدة جديدة الدخول ، فشلت في الانضمام بسبب الخطأ الموضح في هذه البطاقة.

اضطررت إلى إزالة عضو etcd يدويًا عبر etcdctl ، ثم يمكنني الانضمام إلى عقدة جديدة. لقد قمت أيضًا بإزالة العقدة يدويًا من kubeadm-config ConfigMap ، لكنني لست متأكدًا مما إذا كان ذلك مطلوبًا.

falken في ١ مايو ٢٠١٩

👍3

Halytskyi شكرا جزيلا الخدكتل ساعدني .....

Nurlan199206 في ١٤ يوليو ٢٠١٩

جربت هذا اليوم في 1.15.5

في حالتي ، انضممت إلى الكتلة ولكن بإصدار 1.16. ثم حذفت هذه العقدة kubectl delete node ، وقم بالرجوع إلى الإصدار 15.5.5 وحاول إعادة الانضمام (نفس عنوان IP ، ونفس اسم المضيف ، وإصدار مختلف) وحصلت على الخطأ etcd غير الصحي.

تم الحل بواسطة (بناءً على إجابة Halytskyi ولكن مع تحديث etcdctl):

احذف العقدة من kubeadm-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 --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 ، خطأ
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 في ٣٠ أكتوبر ٢٠١٩

يمكن أن يحدث هذا إذا تمت مقاطعة kubeadm reset وتعذر حذف العقدة من kubeadm CM.
في مثل هذه الحالة ، تحتاج إلى حذفه يدويًا من kubeadm CM.

neolit123 في ٣٠ أكتوبر ٢٠١٩

لذلك إذا قمت بحذف العقدة بـ kubectl delete node foobar فإنها لا تفعل ذلك
حذفه من العضو الخ؟ ولكن إذا قمت بعمل kubeadm reset في العقدة التي أريدها
لحذف ، ثم يفعل ذلك؟ 🙄

يوم الأربعاء ، 30 أكتوبر 2019 ، 13:27 Lubomir I. Ivanov ، [email protected]
كتب:

يمكن أن يحدث هذا إذا تمت مقاطعة إعادة تعيين kubeadm ولا يمكن حذف ملف
عقدة من kubeadm CM.
في مثل هذه الحالة ، تحتاج إلى حذفه يدويًا من kubeadm CM.
-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubeadm/issues/1300؟email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREXG43VMV47
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

zakkg3 في ٣١ أكتوبر ٢٠١٩

يجب أن تحذف "kubeadm reset" من kubeadm CM ، ولكن استدعاء "kubectl delete node" مطلوب أيضًا والذي يحذف كائن Node API.

neolit123 في ٣١ أكتوبر ٢٠١٩

في حالتي ، لم يؤدي حذف العقدة من de configmap إلى حذفها من ملف
etcd الكتلة كنت بحاجة إلى etcdctl delete member يدويًا.

يوم الخميس ، 31 أكتوبر 2019 الساعة 16:28 ، Lubomir I. Ivanov [email protected]
كتب:

يجب أن تحذف "kubeadm reset" من kubeadm CM ، لكن تستدعي "kubectl
حذف العقدة "مطلوب أيضًا والذي يحذف كائن Node API.
-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubeadm/issues/1300؟
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

zakkg3 في ٣١ أكتوبر ٢٠١٩

إعادة تعيين kubeadm يجب أيضًا إزالة عضو etcd من مجموعة etcd.
حاول تنفيذه باستخدام مثال --v = 5 وانظر ماذا يفعل.

ومع ذلك ، ضع في اعتبارك أن إعادة تعيين kubeadm هو أفضل جهد ، لذا إذا فشل لسبب ما ، فقد يطبع تحذيرًا فقط.

neolit123 في ٣١ أكتوبر ٢٠١٩

لذلك kubectl delete node لا يحذفه من الخ. بدلاً من ذلك ، فإن التشغيل في العقدة kubeadm reset يفعل ذلك.
يبدو مكسورًا بالنسبة لي ، أعتقد أن kubectl delete node يجب أن يحذفه من النموذج وما إلى ذلك أيضًا. أم أنني أفتقد حالة استخدام واضحة؟
ربما يسأل عما إذا كان ينبغي حذفه أيضًا من هناك؟
على أي حال ، شكرًا للتوضيح @ neolit123 ، قمت أولاً بحذفه من مستوى التحكم ثم قمت بإعادة الضبط ، أعتقد أن الأوان قد فات لحذف نفسه من إلخ.

zakkg3 في ٣١ أكتوبر ٢٠١٩

لذلك هناك مسؤوليات مختلفة.
kubectl delete node ، يحذف كائن Node API - يجب عليك القيام بذلك عندما تكون متأكدًا من أنك لم تعد تريد العقدة حولها ،
قبل ذلك يجب عليك استدعاء kubeadm reset على تلك العقدة. ما أفعله هو أنه ينظف الحالة على القرص ويزيل أيضًا عضو etcd (إذا كانت هذه عقدة مستوى تحكم وإذا كنت تستخدم الخيار الافتراضي حيث تعمل مثيلات etcd لكل عقدة مستوى تحكم)

إعادة تعيين kubeadm يعيد تعيين العقدة ، لكنه لا يحذف كائن العقدة لسببين:

إعادة تعيين فقط إعادة تعيين العقدة ويمكنك إعادة الانضمام إليها. يظل اسم العقدة محجوزًا.
العقدة نفسها ليس لديها امتيازات كافية لحذف كائن Node الخاص بها. هذه مسؤولية مالك "admin.conf" (مثل المسؤول).

neolit123 في ٣١ أكتوبر ٢٠١٩

👍2

إعادة تعيين kubeadm هو أفضل أمر مجهود

بخصوص هذا: عندما يفشل kubeadm reset في الإكمال لأي سبب من الأسباب (بما في ذلك الفشل الشديد للخادم الأساسي بحيث لا يتم تنفيذ إعادة تعيين kubeadm في المقام الأول) ، فهناك أي خيارات لتسوية الحالة يدويًا بجانب التحرير اليدوي الكائن kubeadm-configmap وإزالة العقدة؟

Mikulas في ٣١ أكتوبر ٢٠١٩

إذا فشلت العقدة بشدة ولا يمكنك استدعاء kubeadm reset عليها ، فإنها تتطلب خطوات يدوية. عليك أن:
1) قم بإزالة IP لمستوى التحكم من kubeadm-config CM ClusterStatus
2) إزالة العضو etcd باستخدام etcdctl
3) احذف كائن Node باستخدام kubectl (إذا كنت لا تريد وجود Node حولك بعد الآن)

تنطبق 1 و 2 فقط على عقد مستوى التحكم.

neolit123 في ٣١ أكتوبر ٢٠١٩

هل هناك أي طريقة لأتمتة هذا الفشل إذا تعذر تشغيل إعادة تعيين kubeadm؟