Kubeadm: تغيير عنوان IP الرئيسي

هذا ليس قيدًا بواسطة kubeadm ، ولكنه مجرد ممارسة أمنية عامة.
تم توقيع الشهادة لـ {your-old-IP-here} ولا يمكن أن يحدث الاتصال الآمن بعد ذلك لـ {your-new-ip-here}

يمكنك إضافة المزيد من عناوين IP في الشهادة مسبقًا على الرغم من ...

شكرا لردكم.

نظرًا لأن عناوين IP يتم تعيينها بواسطة موفر السحابة ، فإن إنشاء الشهادة مسبقًا لن يعمل إلا إذا كان بإمكاني تعيينها على حرف بدل. (آسف ، لا أعرف شيئًا عن الشهادات.)

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

في كلتا الحالتين ، شكرًا لك على كل العمل المنجز في kubeadm! إنه لأمر سحري أن ترى الكتلة تظهر في غضون دقائق - لقد كنت أستخدم Kubernetes منذ 0.14 ، في الإنتاج منذ 1.0.

analytik لدي نفس المشكلة تمامًا مثل مشكلتك. تحظر شبكة شركتي gcr.io. لذلك أنا أستخدم دونجل للتثبيت. ومع ذلك ، فإن عنوان IP الخاص بالموفر يتغير ديناميكيًا ولا يخضع لسيطري. لذلك حتى أنا أبحث عن حل. حتى إذا كنت أبقيت الدونجل الخاص بي متصلاً ، في بعض الأحيان بسبب إعادة الشبكة لتعيين تغييرات IP. هل لديك أي حل لهذا؟ كيف تتعامل مع هذا؟
luxas هل يمكنك اقتراح كيف يمكنني المتابعة. أنا مبتدئ في K8S. فقدت تماما مع هذا التكوين. هل يمكنك إعلامي كيف يمكنني إصلاح مشكلة IP الديناميكية هذه؟

كيف تتعاملون مع IP الرئيسي المتغير؟

هل هناك أي تحديث حول هذه المشكلة؟

نفس المشكلة هنا. هل هناك أي وثائق لمتابعة تعديل بروتوكول الإنترنت الرئيسي دون إعادة ضبط المجموعة بأكملها من فضلك؟

تمكنت من تحقيق ذلك من خلال:

• استبدال عنوان IP في جميع ملفات التكوين في / etc / kubernetes
• النسخ الاحتياطي / etc / kubernetes / pki
• تحديد الشهادات في / etc / kubernetes / pki التي لها عنوان IP القديم كاسم بديل [1]
• حذف كل من الشهادة والمفتاح لكل منهما (بالنسبة لي كان مجرد apiserver و etcd / peer)
• إعادة إنشاء الشهادات باستخدام kubeadm alpha phase certs [2]
• تحديد configmap في مساحة الاسم kube-system التي أشارت إلى عنوان IP القديم [3]
• يدوياً تحرير خرائط التكوين تلك
• إعادة تشغيل kubelet و docker (لفرض إعادة إنشاء جميع الحاويات)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

واو ، لم أكن على علم بهذه الأوامر. معلومات رائعة ، هذا هو الحيلة. شكرا لك !

هل هناك طريقة للعثور على configmaps يدويًا وتغييرها؟

آمل أن يتمكن kubeadm من تغطية هذه العملية في إصدار مستقبلي.

patricklucas بجدية ، شكرًا لك على الكتابة. أنقذت حياتي.

لأولئك الذين يبحثون عن المزيد من الوضوح ، كانت هذه تجربتي:

1. استبدل عنوان IP في جميع ملفات التكوين في /etc/kubernetes
bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. نسخ احتياطي /etc/kubernetes/pki
bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. تحديد الشهادات في /etc/kubernetes/pki التي لها عنوان IP القديم كاسم بديل (يمكن مسح هذا)
   bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. حدد configmap في مساحة الاسم kube-system التي أشارت إلى عنوان IP القديم ، وقم بتحريرها:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. تغيير عنوان IP (عبر cli أو gui للتوزيع الخاص بك)

6. احذف كلاً من الشهادة والمفتاح لكلٍّ منهما تم تحديده بواسطة grep في الخطوة السابقة ، وأعد إنشاء تلك الشهادات

   ملاحظة: قبل إعادة إنشاء الشهادات عبر kubeadm admin phase certs ... ، ستحتاج إلى تطبيق عنوان IP الجديد

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. إعادة تشغيل kubelet و docker
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. نسخ عبر التكوين الجديد
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

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

شيء آخر يجب ملاحظته ، كان تغيير الشهادات ممكنًا في وضع عدم الاتصال عن طريق تحديد إصدار k8s في ملف التكوين: https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

weisjohn هل يمكنك أيضًا تحديث تعليقك بالإشارة إلى ما يلي:

kubectl edit cm -nkube-public cluster-info

هناك حاجة أيضا ل kubeadm؟

خلاف ذلك ، تستمر أوامر الانضمام kubeadm الخاصة بي في الفشل باستخدام عنوان IP للخادم القديم / الخطأ في منتصف العملية.

شكرا!

لقد طبقت جميع الخطوات من weisjohn (https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755) و michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338 # issuecomment-428340099) لاستبدال العنوان في كل مكان.

يستخدم هذا للسماح لـ kubernetes باستخدام عنوان VPC الذي تم إنشاؤه حديثًا على eth1 ، بدلاً من عنوان IP العام في eth0. ومع ذلك ، عندما أقوم بتشغيل kubeadm upgrade diff v1.12.3 ما زلت أرغب في إعادة التغييرات إلى --advertise-address في /etc/kubernetes/manifests/kube-apiserver.yaml .

أي أدلة؟

حتى في kubectl get all --export=true --all-namespaces -o yaml ، لا يوجد عنوان IP القديم في أي مكان

تحديث: اتضح أن هذا kubeadm upgrade diff اقترح تغييرًا ، لكن kubeadm upgrade apply لم يغير العنوان على الإطلاق. (واحد من العديد من الأخطاء kubernetes 1.13 مثل الإصلاحات)

weisjohn شكرا لك

patricklucas بجدية ، شكرًا لك على الكتابة. أنقذت حياتي.

لأولئك الذين يبحثون عن المزيد من الوضوح ، كانت هذه تجربتي:

1. استبدل عنوان IP في جميع ملفات التكوين في /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. نسخ احتياطي /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. تحديد الشهادات في /etc/kubernetes/pki التي لها عنوان IP القديم كاسم بديل (يمكن مسح هذا)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. حدد configmap في مساحة الاسم kube-system التي أشارت إلى عنوان IP القديم ، وقم بتحريرها:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. تغيير عنوان IP (عبر cli أو gui للتوزيع الخاص بك)

6. احذف كلاً من الشهادة والمفتاح لكلٍّ منهما تم تحديده بواسطة grep في الخطوة السابقة ، وأعد إنشاء تلك الشهادات

   ملاحظة: قبل إعادة إنشاء الشهادات عبر kubeadm admin phase certs ... ، ستحتاج إلى تطبيق عنوان IP الجديد

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. إعادة تشغيل kubelet و docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. نسخ عبر التكوين الجديد
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

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

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

شكرا لك مقدما :)

ربما يكون من الجيد أن نذكر ، عند نقل IP الرئيسي إلى شبكة خاصة ، قد يكون من المفيد تحديث شبكة التراكب أيضًا. لم تكن شركة Calico تستخدم واجهة VPC حتى تم ربطها بتلك الواجهة:

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadm مرحلة ألفا سيرفر

weisjohn kubeadm alpha stage certs apiserver لا يعمل في الإصدار 1.13.0 ، ويظهر "هذا الأمر ليس من المفترض أن يتم تشغيله بمفرده. راجع قائمة الأوامر الفرعية المتاحة." أي تعليقات محدثة متاحة؟

في 1.13 يسمى الأمر kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

خطوات مفيدة جدًا للعلاج - شكرًا باتريكلوكاس و weisjohn !

نصيحة إضافية واحدة إذا بدأت ، مثلي ، من الحالة التي تغير فيها عنوان IP بالفعل ، لذلك لا يمكنك الاتصال بخادم api لتغيير خرائط التكوين في الخطوة 4:
تم توقيع شهادة خادم api لاسم المضيف kubernetes ، لذا يمكنك إضافة ذلك كاسم مستعار إلى عنوان IP الجديد في /etc/hosts ثم فعل kubectl --server=https://kubernetes:6443 ... .

bborehamweisjohn @ باتريكلوكاس شكرا جزيلا
حذف / إضافته إلى المجموعة؟ أو قم فقط بتغيير _ / etc / kubernetes / kubelet.conf_ و _ / etc / kubernetes / pki / ca.crt_ يدويًا؟

أعلم أنها مشكلة قديمة ولكن ربما يكون تعليقي مفيدًا لشخص ما.
لسوء الحظ ، الحل الذي اقترحه patricklucas و weisjohn لم يعمل معي ، لذلك قمت بإنشاء حل خاص بي:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@ valerius257 شكرا لك يا رجل ، حفظت عطلة نهاية الأسبوع لدينا)

شكرا @ valerius257 👍
لقد جربت جميع عمليات الكتابة / التعليمات الواردة من patricklucas و weisjohn . لم يعملوا من أجل مجموعتي. الجزء الجيد هو أن هذه التعليمات تسلط الضوء على بعض الجوانب الرئيسية للشهادات والمفاتيح والجدول الزمني الذي يحتاجون إلى العناية به.

عملت التعليمات التي ذكرها @ valerius257 بسلاسة ، حتى

استمرار متابعة الخطوات المذكورة بواسطة @ valerius257
كنت أستخدم المكون الإضافي flannel n / w في عقدة رئيسية واحدة.
مشكلة الفانيلا: kube-flannel-ds-xxxx back-off إعادة تشغيل الحاوية الفاشلة
حالة الجراب: CrashLoopBackOff. بسبب هذا فشل البودات الأخرى مثل core-dns-xxx أيضًا في الظهور.

الحل: نظرًا لأنني بدأت المجموعة باستخدام kubeadm init مع cidr n / w (عندما كان IP قديمًا أو أثناء تشغيل العقدة الرئيسية) ، فإن الخطوة التالية تمسح إعدادات cidr من "/ etc / kubernetes / manifests / kube-controller-manager .yaml ".
kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd.

ومن ثم ، إذا بدأت العقدة الرئيسية kubeadm (مع عنوان IP للمرة الأولى) باستخدام الأمر "kubeadm init --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16" "، فقم بنشر تخصيص IP الجديد يجب عليك تنفيذ الأمر التالي مع --pod-network-cidr = 10.244.0.0 / 16.
"kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16"

أو قم بتعديل الملف "/etc/kubernetes/manifests/kube-controller-manager.yaml مع تضمين المعلمات التالية ، إذا كانت مفقودة ضمن المواصفات: الحاويات : الأمر:

• --allocate-node-cidrs = صحيح
• - العنقود- cidr = 10.244.0.0 / 16
  
  
  
  • - عقدة-سيدر-قناع-الحجم = 24
    
    المرجع: https://github.com/coreos/flannel/issues/728 ، اقرأ الحل منwkjun
    
    بمجرد إدخال التغييرات المذكورة أعلاه ،
    
    توقف systemctl عامل ميناء kubelet
    
    النوم 20
    
    systemctl بدء docker kubelet
    
    تحقق من أن جميع الكبسولات جاهزة للعمل بما في ذلك الفانيلا.
    
    kubect الحصول على القرون -n kube-system
  
  

العدد 2
تبدأ جميع البودات الموجودة في مساحة اسم التطبيق أو في نظام kube بإظهار أخطاء في وصف أوامر البود مثل:
"تحذير FailedScheduling Default-Scheduler 0/1 متوفرة: عقدة واحدة بها عيوب لم يتسامح معها الكبسولة."
نفّذ الأمر: kubectl taint nodes --all node-role.kubernetes.io/master-
وصف جميع البودات التي تعمل في مساحة عمل التطبيقات أو في مساحة اسم نظام kube ، ولن يتم ملاحظة الأخطاء المذكورة. في مجموعة العقدة المتعددة ، قد يتعين عليك توخي الحذر الشديد.

patricklucas بجدية ، شكرًا لك على الكتابة. أنقذت حياتي.

لأولئك الذين يبحثون عن المزيد من الوضوح ، كانت هذه تجربتي:

1. استبدل عنوان IP في جميع ملفات التكوين في /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. نسخ احتياطي /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. تحديد الشهادات في /etc/kubernetes/pki التي لها عنوان IP القديم كاسم بديل (يمكن مسح هذا)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. حدد configmap في مساحة الاسم kube-system التي أشارت إلى عنوان IP القديم ، وقم بتحريرها:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. تغيير عنوان IP (عبر cli أو gui للتوزيع الخاص بك)

6. احذف كلاً من الشهادة والمفتاح لكلٍّ منهما تم تحديده بواسطة grep في الخطوة السابقة ، وأعد إنشاء تلك الشهادات

   ملاحظة: قبل إعادة إنشاء الشهادات عبر kubeadm admin phase certs ... ، ستحتاج إلى تطبيق عنوان IP الجديد

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. إعادة تشغيل kubelet و docker
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. نسخ عبر التكوين الجديد
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

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

في مكان newip أي IP يجب أن نعطي؟
هل يمكننا إنشاء عنوان IP خاص بنا؟

VipinKrizz سياق هذه المشكلة هو أن IP قد تغير بالفعل بسبب عوامل داخل البنية التحتية. لا يمكن لأحد أن يجيب على عنوان IP الذي يجب أن تستخدمه باستثناء شخص على دراية بالإعداد الخاص بك.

ربما يمكنك العثور على شخص للدردشة معه حول هذا الموضوع على Slack؟ قضايا Kubeadm ليست المكان المناسب.

@ valerius257 شكرًا جزيلاً على هذا النص ، أرى الآن عددًا من الجوانب السلبية في

لكن نعم ، نصك أنقذ لحم الخنزير المقدد لي اليوم.

@ valerius257 لقد اتبعت خطوتك ولكني أحصل على المشكلة أدناه

root @ ubuntu : / etc / kubernetes / pki # kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd
W0122 10: 15: 34.819150 102032 version.go: 101] تعذر جلب إصدار Kubernetes من الإنترنت: تعذر الحصول على عنوان URL " https://dl.k8s.io/release/stable-1.txt ": احصل على https: //dl.k8s.io/release/stable-1.txt : اطلب tcp: lookup dl.k8s.io على 127.0.0.53:53: سوء تصرف الخادم
W0122 10: 15: 34.819340 102032 version.go: 102] الرجوع إلى إصدار العميل المحلي: v1.16.3
[init] استخدام إصدار Kubernetes: v1.16.3
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
[تحذير IsDockerSystemdCheck]: تم اكتشاف "cgroupfs" على أنه برنامج تشغيل Docker cgroup. برنامج التشغيل الموصى به هو "systemd". يرجى اتباع الدليل على https://kubernetes.io/docs/setup/cri/
[تحذير DirAvailable - var-lib-etcd]: / var / lib / etcd ليس فارغًا
[الاختبار المبدئي] مطلوب سحب الصور لإعداد مجموعة Kubernetes
[الاختبار المبدئي] قد يستغرق هذا دقيقة أو دقيقتين ، حسب سرعة اتصالك بالإنترنت
[الاختبار المبدئي] يمكنك أيضًا تنفيذ هذا الإجراء مسبقًا باستخدام "kubeadm config images pull"
[kubelet-start] كتابة ملف بيئة kubelet مع إشارات إلى الملف "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] كتابة تكوين kubelet في ملف "/var/lib/kubelet/config.yaml"
[kubelet-start] تفعيل خدمة kubelet
[الشهادات] استخدام مجلد CertificateDir "/ etc / kubernetes / pki"
[شهادات] استخدام المرجع المصدق الحالي ca
[شهادات] إنشاء مفتاح وشهادة "apiserver"
[شهادات] تم توقيع شهادة تقديم خادم apiserver لأسماء DNS [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] وعناوين IP [10.96.0.1 192.168.120.137]
[شهادات] استخدام شهادة ومفتاح apiserver-kubelet-client موجودان على القرص
[الشهادات] استخدام المرجع المصدق الحالي لـ front-proxy-ca
[الشهادات] استخدام شهادة العميل الأمامي الوكيل والمفتاح الموجود على القرص
[شهادات] استخدام المرجع المصدق etcd / ca الحالي
[الشهادات] استخدام شهادة etcd / server ومفتاح موجود على القرص
[شهادات] إنشاء مفتاح وشهادة "etcd / peer"
[شهادات] etcd / peer service cert مُوقعة لأسماء DNS [ubuntu localhost] وعناوين IP [192.168.120.137 127.0.0.1 :: 1]
[الشهادات] استخدام شهادة ومفتاح etcd / healthcheck-client موجود على القرص
[الشهادات] استخدام الشهادة والمفتاح الموجود على القرص apiserver-etcd-client
[شهادات] استخدام مفتاح "sa" الموجود
[kubeconfig] استخدام مجلد kubeconfig "/ etc / kubernetes"
[kubeconfig] كتابة ملف "admin.conf" kubeconfig
[kubeconfig] كتابة ملف "kubelet.conf" kubeconfig
[kubeconfig] كتابة ملف kubeconfig "controller-manager.conf"
[kubeconfig] كتابة ملف "Scheduler.conf" kubeconfig
[control-plane] استخدام مجلد البيان "/ etc / kubernetes / manifests"
[مستوى التحكم] إنشاء بيان جراب ثابت لـ "kube-apiserver"
[طائرة التحكم] إنشاء بيان جراب ثابت لـ "kube-controller-manager"
[مستوى التحكم] إنشاء بيان لوحة ثابتة لـ "kube-Scheduler"
[etcd] إنشاء بيان Pod ثابت لـ etcd المحلي في "/ etc / kubernetes / manifests"
[wait-control-plane] انتظار kubelet لتمهيد مستوى التحكم كسنفات ثابتة من الدليل "/ etc / kubernetes / manifests". يمكن أن يستغرق هذا ما يصل إلى 4m0s
[kubelet-check] مرت المهلة الأولية البالغة 40 ثانية.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connect رفض.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connect رفض.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connect رفض.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connect رفض.
[kubelet-check] يبدو أن الكوبيليت لا يعمل أو لا يتمتع بصحة جيدة.
[kubelet-check] فشل استدعاء HTTP الذي يساوي "curl -sSL http: // localhost : 10248 / healthz" بسبب الخطأ: احصل على http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connect رفض.

للأسف ، حدث خطأ:
انتهت مهلة انتظار الشرط

من المحتمل أن يكون سبب هذا الخطأ:
- الكوبيليت لا يعمل
- kubelet غير صحي بسبب خطأ في تكوين العقدة بطريقة ما (cgroups المطلوبة معطلة)

إذا كنت تستخدم نظامًا يعمل بنظام systemd ، فيمكنك محاولة استكشاف الخطأ وإصلاحه باستخدام الأوامر التالية:
- "kubelet حالة systemctl"
- "Journalctl -xeu kubelet"

بالإضافة إلى ذلك ، قد يكون مكون مستوى التحكم قد تعطل أو تم الخروج منه عند بدء تشغيل الحاوية.
لاستكشاف الأخطاء وإصلاحها ، قم بإدراج جميع الحاويات باستخدام أوقات تشغيل الحاوية المفضلة لديك CLI ، مثل عامل الإرساء.
فيما يلي مثال واحد لكيفية سرد جميع حاويات Kubernetes التي تعمل في عامل الإرساء:
- 'docker ps -a | grep kube | grep -v وقفة "
بمجرد العثور على الحاوية الفاشلة ، يمكنك فحص سجلاتها باستخدام:
- "سجلات عامل الإرساء CONTAINERID"
مستوى التحكم في الانتظار في مرحلة تنفيذ الخطأ: تعذر تهيئة مجموعة Kubernetes
لمشاهدة تتبع المكدس لهذا الخطأ ، نفذ مع --v = 5 أو أعلى

رجاء، المساعده

تمكنت من تحقيق ذلك من خلال:

• استبدال عنوان IP في جميع ملفات التكوين في / etc / kubernetes
• النسخ الاحتياطي / etc / kubernetes / pki
• تحديد الشهادات في / etc / kubernetes / pki التي لها عنوان IP القديم كاسم بديل [1]
• حذف كل من الشهادة والمفتاح لكل منهما (بالنسبة لي كان مجرد apiserver و etcd / peer)
• إعادة إنشاء الشهادات باستخدام kubeadm alpha phase certs [2]
• تحديد configmap في مساحة الاسم kube-system التي أشارت إلى عنوان IP القديم [3]
• يدوياً تحرير خرائط التكوين تلك
• إعادة تشغيل kubelet و docker (لفرض إعادة إنشاء جميع الحاويات)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

عملت من أجلي شكرا

الشيء الوحيد الذي تحتاج إلى استخدامه

 kubeadm init phase ..

لأحدث إصدارات kubectl

تضمين التغريدة
لقد اتبعت الخطوات التي ذكرهاpatricklucas
كما ذكرت في الخطوة 4 ، تحتاج إلى إجراء بعض التكوين في / etc / hosts لأن IP قد تغير بالفعل ولا يمكنه الاتصال بخادم api.

توليد الشهادة باستخدام
kubeadm init --kubernetes-version = v1.16.3 stage certs apiserver

لقد تغيرت في / etc / hosts

وجربنا kubectl --server = https: //: 6443 لا يزال لا يعمل :(

أي تكوين محدد يجب القيام به في / etc / hosts ؟؟