المقدمة
يصف هذا المستند خطوات الاسترداد عندما يدخل Cisco Smart Install (SMI) Pod في حالة عدم الاستعداد بسبب خطأ Kubernetes https://github.com/kubernetes/kubernetes/issues/82346.
المشكلة
بعد عزل الموقع، قامت شبكة إيثرنت المتقاربة (CEE) بالإبلاغ عن تنبيه خطأ المعالجة في شبكة إيثرنت المحسنة المجمعة (CEE). حالة الجهاز الجاهزة أقل من 100٪.
[site1app/pod1] cee# show alerts active
alerts active k8s-deployment-replica-mismatch f89d8d09389c
state active
severity critical
type "Processing Error Alarm"
startsAt 2021-05-27T08:38:58.703Z
source site1app-smi-cluster-policy-oam2
labels [ "component: kube-state-metrics" "deployment: prometheus-scrapeconfigs-synch" "exported_namespace: cee-pod1" "instance: 192.0.2.37:8080" "job: kubernetes-pods" "namespace: cee-pod1" "pod: kube-state-metrics-6c476f7494-tqkrc" "pod_template_hash: 6c476f7494" "release: cee-pod1-cnat-monitoring" ]
annotations [ "summary: Deployment cee-pod1/prometheus-scrapeconfigs-synch has not matched the expected number of replicas for longer than 2 minutes." ]
[site1app/pod1] cee# show system status
system status deployed true
system status percent-ready 92.68
ubuntu@site1app-smi-cluster-policy-mas01:~$ kubectl get rs -n cee-pod1 | grep scrape
NAME DESIRED CURRENT READY AGE
prometheus-scrapeconfigs-synch-ccd454f76 1 1 0 395d
prometheus-scrapeconfigs-synch-f5544b4f8 0 0 0 408d
الحل
تعد عملية عزل الموقع بمثابة مشغل للخطأ https://github.com/kubernetes/kubernetes/issues/82346. الحل البديل أن تكون هذه المسامير في حالة جاهزة هو إعادة تشغيل المسامير المصابة. يتم تضمين الإصلاح في إصدارات تقنية شبكة إيثرنت المحسنة المجمعة (CEE) القادمة.
التحقق الأولي من POD والنظام
قم بتسجيل الدخول إلى واجهة سطر الأوامر (CLI) الخاصة ب CEE وحدد حالة النظام.
ssh -p 2024 admin@`kubectl get svc -A| grep " ops-center-cee" | awk '{print $4}'`
show alerts active
show system status
إعادة تشغيل "مجموعات توصيل الطاقة" المتأثرة
قم بتسجيل الدخول إلى العقدة الأساسية، على الأساسي، قم بتشغيل هذه الأوامر. والتعرف على مجموعات الأجهزة والنسخ المتماثلة التي ليس لها جميع الأعضاء في حالة الاستعداد.
kubectl get daemonsets -A
kubectl get rs -A | grep -v '0 0 0'
انسخ هذه الأوامر ولصقها في المفكرة واستبدل جميع CEE-XYZ، بمساحة اسم CEE على الموقع.
kubectl describe pods core-retriever -n cee-xyz | egrep "^Name:|False" | grep -B1 False
kubectl describe pods calico-node -n kube-system | egrep "^Name:|False" | grep -B1 False
kubectl describe pods csi-cinder-nodeplugin -n kube-system | egrep "^Name:|False" | grep -B1 False
kubectl describe pods maintainer -n kube-system | egrep "^Name:|False" | grep -B1 False
kubectl describe pods kube-proxy -n kube-system | egrep "^Name:|False" | grep -B1 False
kubectl describe pods path-provisioner -n cee-xyz | egrep "^Name:|False" | grep -B1 False
kubectl describe pods logs-retriever -n cee-xyz | egrep "^Name:|False" | grep -B1 False
kubectl describe pods node-exporter -n cee-xyz | egrep "^Name:|False" | grep -B1 False
kubectl describe pods keepalived -n smi-vips| egrep "^Name:|False" | grep -B1 False
kubectl describe pods prometheus-scrapeconfigs-synch -n cee-xyz | egrep "^Name:|False" | grep -B1 False
قم بتنفيذ الأوامر وتجميع الإخراج الناتج. في النتيجة، يقوم الإخراج بتعريف أسماء POD بمساحة الاسم المقابلة التي تتطلب إعادة التشغيل.
قم بإعادة تشغيل كافة ملفات التعريف المتأثرة من القائمة التي تم الحصول عليها مسبقا عند إصدار هذه الأوامر (إستبدال اسم ملف التعريف ومساحة الاسم وفقا لذلك).
kubectl delete pods core-retriever-abcde -n cee-xyz
kubectl delete pods core-retriever-abcde -n cee-xyz
…
تحقق من تشغيل أجهزة PODS وتشغيلها دون أي مشكلة.
kubeclt get pods -A
التحقق من PODS وحالة النظام بعد إعادة التشغيل
تنفيذ الأوامر:
kubectl get daemonsets -A
kubectl get rs -A | grep -v '0 0 0'
تأكد من أن مجموعات الأدوات والنسخ المتماثلة تعرض جميع الأعضاء في حالة الاستعداد.
قم بتسجيل الدخول إلى واجهة سطر الأوامر (CLI) الخاصة ب CEE وتأكد من عدم وجود تنبيهات نشطة وحالة النظام بنسبة 100٪.
ssh -p 2024 admin@`kubectl get svc -A| grep " ops-center-cee" | awk '{print $4}'`
show alerts active
show system status
التعليقات