المحتويات

المقدمة

NDO QuickStart

Kubernetes مع NDO عطل دورة

نظرة عامة على NDO باستخدام أوامر Kubernetes

تسجيل دخول CLI Access

مراجعة أسماء NDO

مراجعة نشر NDO

مراجعة مجموعة النسخ المتماثلة ل NDO (RS)

مراجعة NDO Pod

Use-case Pod ليس سليم

أستكشاف أخطاء CLI وإصلاحها بحثا عن PODS غير السليمة

كيفية تشغيل أوامر تصحيح أخطاء الشبكة من داخل حاوية

فحص معرف Pod Kubernetes (K8s)

كيفية فحص معرف العملية من وقت تشغيل الحاوية

كيفية إستخدام المحدث لتشغيل أوامر تصحيح أخطاء الشبكة داخل حاوية

المقدمة

يوضح هذا المستند كيفية مراجعة NDO واستكشاف أخطائه وإصلاحها باستخدام واجهة سطر الأوامر (CLI) الخاصة بوقت تشغيل الحاوية و Kubectl.

NDO QuickStart

إن Cisco Nexus Dashboard Orchestrator (NDO) عبارة عن أداة إدارية للقنوات الليفية تسمح للمستخدمين بإدارة أنواع مختلفة من البنى التي تتضمن مواقع Cisco® Application Centric Infrastructure (Cisco ACI®)، ومواقع ACI للسحابة من Cisco، ومواقع Cisco Nexus Dashboard Fabric Controller (NDFC)، حيث تتم إدارة كل منها بواسطة وحدة التحكم الخاصة بها (مجموعة APIC، أو مجموعة NDFC، أو مثيلات APIC للسحابة في شبكة عامة).

وتوفر الخدمة المعطلة (NDO) تناسقا في الشبكة وتنسيق السياسات وقابلية التوسع واسترداد البيانات بعد الكوارث عبر مراكز بيانات متعددة من خلال واجهة زجاجية واحدة.

في الأيام السابقة، تم نشر MSC (وحدة التحكم متعددة المواقع) كمجموعة مكونة من ثلاث عقد مع VMWare Open Virtual Appliances (OVAs) التي سمحت للعملاء بتهيئة مجموعة Docker Swarm وخدمات MSC. يدير هذا التجمع من Swarm خدمات MSC الصغيرة كحاويات وخدمات Docker.

تظهر هذه الصورة طريقة عرض مبسطة حول كيفية إدارة سرب Docker للخدمات الدقيقة كنسخ متماثلة لنفس الحاوية لتحقيق توفر عال.

كان Docker Swarm مسؤولا عن الحفاظ على العدد المتوقع من النسخ المتماثلة لكل واحدة من الخدمات الدقيقة في بنية MSC. من وجهة نظر سرب الوثائق، كانت وحدة التحكم متعددة المواقع هي عملية نشر الحاوية الوحيدة التي يمكن تنسيقها.

لوحة معلومات Nexus (ND) هي وحدة تحكم إدارية مركزية لمواقع مراكز بيانات متعددة ونظام أساسي مشترك يستضيف خدمات تشغيل مركز البيانات من Cisco، والتي تتضمن Nexus Insight والإصدار 3.3 من Nexus Dashboard Orchestrator (NDO)، وغير الاسم إلى Nexus Dashboard Orchestrator (NDO).

وفي حين أن معظم الخدمات الصغيرة التي تشكل بنية MSC لا تزال هي نفسها، فإن NDO يتم نشرها في مجموعة Kubernetes (K8s) بدلا من نشرها في مجموعة Docker Swarm. وهذا يسمح ل ND بتنسيق تطبيقات أو عمليات نشر متعددة بدلا من تطبيق واحد فقط.

Kubernetes مع NDO عطل دورة

Kubernetes هو نظام مفتوح المصدر من أجل أتمتة نشر، تطوير، وإدارة التطبيقات التي تم احتواؤها في حاويات. كوبرنيتس كوكر، يعمل مع تقنية الحاوية، ولكنه غير مرتبط مع Docker. هذا يعني أن Kubernetes يدعم منصات الحاويات الأخرى (Rkt، PodMan).

الفرق الرئيسي بين سفريت وكوبرنيتس هو أن الأخيرة لا تعمل مع الحاويات مباشرة، بل تعمل مع مفهوم مجموعات الحاويات في موقع واحد، وتسمى PODS، بدلا من ذلك.

يجب تشغيل الحاويات الموجودة في Pod في نفس العقدة. يطلق على مجموعة PODS اسم "النشر". يمكن أن يصف نشر Kubernetes التطبيق بأكمله.

يسمح Kubernetes أيضا للمستخدمين أن يضمن مقدار معين من الموارد متوفر لأي تطبيق معين. ويتم تنفيذ ذلك باستخدام وحدات التحكم في النسخ المتماثل، لضمان توافق عدد نقاط الوصول مع "بيانات التطبيق".

البيان هو ملف بتنسيق YAML يصف موردا ليتم نشره بواسطة نظام المجموعة. يمكن أن يكون المورد أي من الموارد الموضحة من قبل أو الموارد الأخرى المتوفرة للمستخدمين.

يمكن الوصول إلى التطبيق خارجيا من خلال خدمة واحدة أو أكثر. يتضمن Kubernetes خيار موازن حمل للقيام بذلك.

تقدم Kubernetes أيضا طريقة لعزل موارد مختلفة مع مفهوم مساحات الأسماء. يستخدم ND مساحات أسماء للتعرف بشكل فريد على مختلف التطبيقات وخدمات نظام المجموعة. عند تشغيل أوامر واجهة سطر الأوامر (CLI)، قم دائما بتعيين مساحة الاسم.

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

يتم توضيح أساسيات بنية موارد Kubernetes في هذا المخطط:

ومن المهم تذكر كيفية تفاعل كل نوع من الموارد مع الأنواع الأخرى، كما أنها تؤدي دورا رئيسيا في عملية الاستعراض واستكشاف الأخطاء وإصلاحها.

نظرة عامة على NDO باستخدام أوامر Kubernetes

تسجيل دخول CLI Access

لوصول CLI بواسطة SSH إلى NDO، فإن admin-user كلمة المرور مطلوبة. على أي حال، بدلا من إستخدام rescue-user كلمة المرور. كما في:

ssh rescue-user@ND-mgmt-IP

rescue-user@XX.XX.XX.XX’s password:

[rescue-user@MxNDsh01 ~]$ pwd

/home/rescue-user

[rescue-user@MxNDsh01 ~]$

هذا هو الوضع الافتراضي والمستخدم للوصول إلى واجهة سطر الأوامر ومعظم المعلومات متاحة للرؤية.

مراجعة أسماء NDO

يسمح مفهوم K8هذا بعزل الموارد المختلفة عبر المجموعة. يمكن إستخدام الأمر التالي لمراجعة مساحات الأسماء المختلفة التي تم نشرها:

[rescue-user@MxNDsh01 ~]$ kubectl get namespace

NAME                 STATUS   AGE

authy                Active   177d

authy-oidc           Active   177d

cisco-appcenter      Active   177d

cisco-intersightdc   Active   177d

cisco-mso            Active   176d

cisco-nir            Active   22d

clicks               Active   177d

confd                Active   177d

default              Active   177d

elasticsearch        Active   22d

eventmgr             Active   177d

firmwared            Active   177d

installer            Active   177d

kafka                Active   177d

kube-node-lease      Active   177d

kube-public          Active   177d

kube-system          Active   177d

kubese               Active   177d

maw                  Active   177d

mond                 Active   177d

mongodb              Active   177d

nodemgr              Active   177d

ns                   Active   177d

rescue-user          Active   177d

securitymgr          Active   177d

sm                   Active   177d

statscollect         Active   177d

ts                   Active   177d

zk                   Active   177d

تنتمي الإدخالات بالخط الأسود إلى التطبيقات الموجودة في NDO، بينما تنتمي الكيانات التي تبدأ بالبادئة إلى مجموعة Kubernetes. كل مساحة اسم لها عمليات نشر مستقلة وبطاقات PODS

تسمح واجهة سطر أوامر Kubectl بتحديد مساحة اسم باستخدام  --namespace إذا تم تشغيل أمر بدونه، فإن CLI يفترض أن مساحة الاسم هي default (مساحة الاسم للk8s):

[rescue-user@MxNDsh01 ~]$ kubectl get pod --namespace cisco-mso

NAME                                   READY   STATUS    RESTARTS   AGE

auditservice-648cd4c6f8-b29hh          2/2     Running   0          44h

…

[rescue-user@MxNDsh01 ~]$ kubectl get pod

No resources found in default namespace.

ال kubectl CLI يسمح نوع مختلف من التنسيقات للمخرجات، مثل Yaml، JSON، أو طاولة مخصصة. ويتحقق ذلك من خلال -o خيار [تنسيق]. على سبيل المثال:

[rescue-user@MxNDsh01 ~]$ kubectl get namespace -o JSON

{

"apiVersion": "v1",

"items": [

{

"apiVersion": "v1",

"kind": "Namespace",

"metadata": {

"annotations": {

"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Namespace\",\"metadata\":{\"annotations\":{},\"labels\":{\"serviceType\":\"infra\"},\"name\":\"authy\"}}\n"

},

"creationTimestamp": "2022-03-28T21:52:07Z",

"labels": {

"serviceType": "infra"

},

"name": "authy",

"resourceVersion": "826",

"selfLink": "/api/v1/namespaces/authy",

"uid": "373e9d43-42b3-40b2-a981-973bdddccd8d"

},

}

],

"kind": "List",

"metadata": {

"resourceVersion": "",

"selfLink": ""

}

}

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

وهذا مهم لأن K8s يوفر للمستخدمين خيار تحديد JSONPATH كإخراج، وهذا يسمح بعمليات معقدة لصفيف بيانات JSON. على سبيل المثال، من المخرج السابق، إذا حصلنا على قيمة name لمسارات الأسماء، نحتاج إلى الوصول إلى قائمة قيمة العناصر، ثم metadata بالقاموس ، وبجيب قيمة المفتاح name. يمكن القيام بذلك باستخدام هذا الأمر:

[rescue-user@MxNDsh01 ~]$ kubectl get namespace -o=jsonpath='{.items[*].metadata.name}'

authy authy-oidc cisco-appcenter cisco-intersightdc cisco-mso cisco-nir clicks confd default elasticsearch eventmgr firmwared installer kafka kube-node-lease kube-public kube-system kubese maw mond mongodb nodemgr ns rescue-user securitymgr sm statscollect ts zk

[rescue-user@MxNDsh01 ~]$

يتم إستخدام التدرج الهرمي الموصوف لجلب المعلومات المحددة المطلوبة. يتم الوصول إلى جميع العناصر بشكل أساسي في items القائمة ذات العناصر[*]، ثم المفتاح metadata و name باستخدام metadata.name، يمكن أن يتضمن الاستعلام قيما أخرى لعرضها.

وينطبق الأمر نفسه على خيار الأعمدة المخصصة، التي تستخدم طريقة مماثلة لجلب المعلومات من صفيف البيانات. على سبيل المثال، إذا قمنا بإنشاء جدول يحتوي على معلومات حول name و UID قيم، يمكن أن نطبق الأمر:

[rescue-user@MxNDsh01 ~]$ kubectl get namespace -o custom-columns=NAME:.metadata.name,UID:.metadata.uid

NAME                 UID

authy                373e9d43-42b3-40b2-a981-973bdddccd8d

authy-oidc           ba54f83d-e4cc-4dc3-9435-a877df02b51e

cisco-appcenter      46c4534e-96bc-4139-8a5d-1d9a3b6aefdc

cisco-intersightdc   bd91588b-2cf8-443d-935e-7bd0f93d7256

cisco-mso            d21d4d24-9cde-4169-91f3-8c303171a5fc

cisco-nir            1c4dba1e-f21b-4ef1-abcf-026dbe418928

clicks               e7f45f6c-965b-4bd0-bf35-cbbb38548362

confd                302aebac-602b-4a89-ac1d-1503464544f7

default              2a3c7efa-bba4-4216-bb1e-9e5b9f231de2

elasticsearch        fa0f18f6-95d9-4cdf-89db-2175a685a761

يتطلب الإخراج اسم كل عمود لعرضه ثم قم بتعيين قيمة الإخراج. في هذا المثال، هناك عمودان: NAME و UID. تنتمي هذه القيم إلى .metada.name و .metadata.uid على التوالي. يتوفر المزيد من المعلومات والأمثلة على:

دعم JSONPath

أعمدة مخصصة

مراجعة نشر NDO

النشر هو كائن K8s يوفر مساحة مرتبطة لإدارة ReplicaSet و Pods. تتعامل عمليات النشر مع نشر جميع بطاقات PODS التي تنتمي إلى أحد التطبيقات والعدد المتوقع لنسخ كل منها.

تتضمن واجهة سطر الأوامر (CLI) من Kubectl أمرا للتحقق من عمليات النشر الخاصة بأي مساحة اسم معينة:

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE

auditservice          1/1     1            1           3d22h

backupservice         1/1     1            1           3d22h

cloudsecservice       1/1     1            1           3d22h

consistencyservice    1/1     1            1           3d22h

dcnmworker            1/1     1            1           3d22h

eeworker              1/1     1            1           3d22h

endpointservice       1/1     1            1           3d22h

executionservice      1/1     1            1           3d22h

fluentd               1/1     1            1           3d22h

importservice         1/1     1            1           3d22h

jobschedulerservice   1/1     1            1           3d22h

notifyservice         1/1     1            1           3d22h

pctagvnidservice      1/1     1            1           3d22h

platformservice       1/1     1            1           3d22h

platformservice2      1/1     1            1           3d22h

policyservice         1/1     1            1           3d22h

schemaservice         1/1     1            1           3d22h

sdaservice            1/1     1            1           3d22h

sdwanservice          1/1     1            1           3d22h

siteservice           1/1     1            1           3d22h

siteupgrade           1/1     1            1           3d22h

syncengine            1/1     1            1           3d22h

templateeng           1/1     1            1           3d22h

ui                    1/1     1            1           3d22h

userservice           1/1     1            1           3d22h

يمكننا إستخدام نفس الجدول المخصص باستخدام deployment بدلا من namespace و -n خيار لعرض نفس المعلومات كما كان من قبل.  وهذا لأن الناتج مهيكل بطريقة مماثلة.

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso -o custom-columns=NAME:.metadata.name,UID:.metadata.uid

NAME                  UID

auditservice          6e38f646-7f62-45bc-add6-6e0f64fb14d4

backupservice         8da3edfc-7411-4599-8746-09feae75afee

cloudsecservice       80c91355-177e-4262-9763-0a881eb79382

consistencyservice    ae3e2d81-6f33-4f93-8ece-7959a3333168

dcnmworker            f56b8252-9153-46bf-af7b-18aa18a0bb97

eeworker              c53b644e-3d8e-4e74-a4f5-945882ed098f

endpointservice       5a7aa5a1-911d-4f31-9d38-e4451937d3b0

executionservice      3565e911-9f49-4c0c-b8b4-7c5a85bb0299

fluentd               c97ea063-f6d2-45d6-99e3-1255a12e7026

importservice         735d1440-11ac-41c2-afeb-9337c9e8e359

jobschedulerservice   e7b80ec5-cc28-40a6-a234-c43b399edbe3

notifyservice         75ddb357-00fb-4cd8-80a8-14931493cfb4

pctagvnidservice      ebf7f9cf-964e-46e5-a90a-6f3e1b762979

platformservice       579eaae0-792f-49a0-accc-d01cab8b2891

platformservice2      4af222c9-7267-423d-8f2d-a02e8a7a3c04

policyservice         d1e2fff0-251a-447f-bd0b-9e5752e9ff3e

schemaservice         a3fca8a3-842b-4c02-a7de-612f87102f5c

sdaservice            d895ae97-2324-400b-bf05-b3c5291f5d14

sdwanservice          a39b5c56-8650-4a4b-be28-5e2d67cae1a9

siteservice           dff5aae3-d78b-4467-9ee8-a6272ee9ca62

siteupgrade           70a206cc-4305-4dfe-b572-f55e0ef606cb

syncengine            e0f590bf-4265-4c33-b414-7710fe2f776b

templateeng           9719434c-2b46-41dd-b567-bdf14f048720

ui                    4f0b3e32-3e82-469b-9469-27e259c64970

userservice           73760e68-4be6-4201-959e-07e92cf9fbb3

تذكر دائما أن عدد النسخ المعروضة خاص بالنشر، وليس عدد بطاقات Pods لكل خدمة مصغرة.

يمكننا إستخدام الكلمة المفتاحية describe بدلا من get لعرض معلومات أكثر تفصيلا حول مورد، في هذه الحالة نشر المخطط:

[rescue-user@MxNDsh01 ~]$ kubectl describe deployment -n cisco-mso schemaservice

Name:               schemaservice

Namespace:          cisco-mso

CreationTimestamp:  Tue, 20 Sep 2022 02:04:58 +0000

Labels:             k8s-app=schemaservice

scaling.case.cncf.io=scale-service

Annotations:        deployment.kubernetes.io/revision: 1

kubectl.kubernetes.io/last-applied-configuration:

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"creationTimestamp":null,"labels":{"k8s-app":"schemaservice","sca...

Selector:           k8s-app=schemaservice

Replicas:           1 desired | 1 updated | 1 total | 1 available | 0 unavailable

StrategyType:       Recreate

MinReadySeconds:    0

Pod Template:

Labels:           cpu.resource.case.cncf.io/schemaservice=cpu-lg-service

k8s-app=schemaservice

memory.resource.case.cncf.io/schemaservice=mem-xlg-service

Service Account:  cisco-mso-sa

Init Containers:

init-msc:

Image:      cisco-mso/tools:3.7.1j

Port:       <none>

Host Port:  <none>

Command:

/check_mongo.sh

Environment:  <none>

Mounts:

/secrets from infracerts (rw)

Containers:

schemaservice:

Image:       cisco-mso/schemaservice:3.7.1j

Ports:       8080/TCP, 8080/UDP

Host Ports:  0/TCP, 0/UDP

Command:

/launchscala.sh

schemaservice

Liveness:  http-get http://:8080/api/v1/schemas/health delay=300s timeout=20s period=30s #success=1 #failure=3

Environment:

JAVA_OPTS:  -XX:+IdleTuningGcOnIdle

Mounts:

/jwtsecrets from jwtsecrets (rw)

/logs from logs (rw)

/secrets from infracerts (rw)

msc-schemaservice-ssl:

Image:       cisco-mso/sslcontainer:3.7.1j

Ports:       443/UDP, 443/TCP

Host Ports:  0/UDP, 0/TCP

Command:

/wrapper.sh

Environment:

SERVICE_PORT:  8080

Mounts:

/logs from logs (rw)

/secrets from infracerts (rw)

schemaservice-leader-election:

Image:      cisco-mso/tools:3.7.1j

Port:       <none>

Host Port:  <none>

Command:

/start_election.sh

Environment:

SERVICENAME:  schemaservice

Mounts:

/logs from logs (rw)

Volumes:

logs:

Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)

ClaimName:  mso-logging

ReadOnly:   false

infracerts:

Type:        Secret (a volume populated by a Secret)

SecretName:  cisco-mso-secret-infra

Optional:    false

jwtsecrets:

Type:        Secret (a volume populated by a Secret)

SecretName:  cisco-mso-secret-jwt

Optional:    false

Conditions:

Type          Status  Reason

----          ------  ------

Available     True    MinimumReplicasAvailable

Progressing   True    NewReplicaSetAvailable

Events:         <none>

[rescue-user@MxNDsh01 ~]$

يعرض الأمر describe تسمح القيادة أيضا بتضمين --show-events=true إظهار أي حدث ذي صلة لعملية النشر.

مفسد (إبراز إلى القراءة)

مراجعة مجموعة النسخ المتماثلة ل NDO (RS)

مفسد (إبراز إلى القراءة)

#### هذا متوفر فقط للمستخدم الجذري #####

مجموعة النسخ المتماثلة (RS) هي كائن K8S يهدف إلى الاحتفاظ بعدد ثابت من نقاط الوصول المتماثلة. يكتشف هذا الكائن أيضا عندما يرى عدد غير صحيح من النسخ المتماثلة مع تحقيق دوري إلى PODS.

كما يتم تنظيم RS في مساحات الأسماء.

[root@MxNDsh01 ~]#  kubectl get rs  -n cisco-mso

NAME                             DESIRED   CURRENT   READY   AGE

auditservice-648cd4c6f8          1         1         1       3d22h

backupservice-64b755b44c         1         1         1       3d22h

cloudsecservice-7df465576        1         1         1       3d22h

consistencyservice-c98955599     1         1         1       3d22h

dcnmworker-5d4d5cbb64            1         1         1       3d22h

eeworker-56f9fb9ddb              1         1         1       3d22h

endpointservice-7df9d5599c       1         1         1       3d22h

executionservice-58ff89595f      1         1         1       3d22h

fluentd-86785f89bd               1         1         1       3d22h

importservice-88bcc8547          1         1         1       3d22h

jobschedulerservice-5d4fdfd696   1         1         1       3d22h

notifyservice-75c988cfd4         1         1         1       3d22h

pctagvnidservice-644b755596      1         1         1       3d22h

platformservice-65cddb946f       1         1         1       3d22h

platformservice2-6796576659      1         1         1       3d22h

policyservice-545b9c7d9c         1         1         1       3d22h

schemaservice-7597ff4c5          1         1         1       3d22h

sdaservice-5f477dd8c7            1         1         1       3d22h

sdwanservice-6f87cd999d          1         1         1       3d22h

siteservice-86bb756585           1         1         1       3d22h

siteupgrade-7d578f9b6d           1         1         1       3d22h

syncengine-5b8bdd6b45            1         1         1       3d22h

templateeng-5cbf9fdc48           1         1         1       3d22h

ui-84588b7c96                    1         1         1       3d22h

userservice-87846f7c6            1         1         1       3d22h

يعرض الأمر describe يتضمن الخيار معلومات حول عنوان URL، والمنفذ الذي يستخدمه التحقيق، ودورية الاختبارات وعتبة الفشل.

[root@MxNDsh01 ~]#  kubectl describe rs  -n cisco-mso schemaservice-7597ff4c5

Name:           schemaservice-7597ff4c5

Namespace:      cisco-mso

Selector:       k8s-app=schemaservice,pod-template-hash=7597ff4c5

Labels:         cpu.resource.case.cncf.io/schemaservice=cpu-lg-service

k8s-app=schemaservice

memory.resource.case.cncf.io/schemaservice=mem-xlg-service

pod-template-hash=7597ff4c5

Annotations:    deployment.kubernetes.io/desired-replicas: 1

deployment.kubernetes.io/max-replicas: 1

deployment.kubernetes.io/revision: 1

Controlled By:  Deployment/schemaservice

Replicas:       1 current / 1 desired

Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed

Pod Template:

Labels:           cpu.resource.case.cncf.io/schemaservice=cpu-lg-service

k8s-app=schemaservice

memory.resource.case.cncf.io/schemaservice=mem-xlg-service

pod-template-hash=7597ff4c5

Service Account:  cisco-mso-sa

Init Containers:

init-msc:

Image:      cisco-mso/tools:3.7.1j

Port:       <none>

Host Port:  <none>

Command:

/check_mongo.sh

Environment:  <none>

Mounts:

/secrets from infracerts (rw)

Containers:

schemaservice:

Image:       cisco-mso/schemaservice:3.7.1j

Ports:       8080/TCP, 8080/UDP

Host Ports:  0/TCP, 0/UDP

Command:

/launchscala.sh

schemaservice

Liveness:  http-get http://:8080/api/v1/schemas/health delay=300s timeout=20s period=30s #success=1 #failure=3

Environment:

JAVA_OPTS:  -XX:+IdleTuningGcOnIdle

Mounts:

/jwtsecrets from jwtsecrets (rw)

/logs from logs (rw)

/secrets from infracerts (rw)

msc-schemaservice-ssl:

Image:       cisco-mso/sslcontainer:3.7.1j

Ports:       443/UDP, 443/TCP

Host Ports:  0/UDP, 0/TCP

Command:

/wrapper.sh

مراجعة مجموعة النسخ المتماثلة ل NDO (RS) #### هذه متوفرة فقط للمستخدم الجذري ##### مجموعة النسخ المتماثلة (RS) عبارة عن كائن K8s بهدف الاحتفاظ بعدد ثابت من مجموعات النسخ المتماثلة. يكتشف هذا الكائن أيضا عندما يرى عدد غير صحيح من النسخ المتماثلة مع تحقيق دوري إلى PODS.   كما يتم تنظيم RS في مساحات الأسماء. [root@MxNDsh01 ~]# kubectl get rs -n cisco-msoNAME Desired Current Ready AgeAuditService-648cd4c6f8 1 1 3d22hbackupservice-64b755b44c 1 3d22hcloudsecservice-7df465576 1 1 3d22hconsistencyservice-c9895599 1 1 3d22hdcnmworker-5d4d5cb61 3d22heeworker-56f9fb9ddb 1 1 3d22hendpointService-7df9d5599c 1 3d22hexecutionService-58ff8955f 1 3d22hfluentd-86785f89bd 1 3d22himportService-88bcc8547 1 1 3d22hjobschedulerservice-5d4fdfd69613d2 hnotifyservice-75c988cfd4 1 3d22hpctagvnidservice-644b75596 1 3d22hplatformService-65cddb946f 1 3d22hplatformservice2-679657659 1 3d22hpolicy service-545b9c7d9c1 1d252hschema1d2hschemaService-757ff414c 1 3d22hsdaservice-5f477dd8c7 1 3d22hsdwanservice-6f87cd999d 1 3d22hsiteservice-86bb756585 1 3d22hsiteupgrade-7d578f9b6d 1 1 3d22hsyncengine-5b8bdd6b451 1 3d22htemplate-5cbb9fdc41 d22hui-84588b7c96 1 3d22huserservice-87846f7c6 1 1 3d22h يتضمن خيار الوصف المعلومات حول URL، المنفذ الذي يستخدمه المسبار، ودورية الاختبارات وعتبة الفشل. [root@MxNDsh01 ~]# kubectl يصف rs -n cisco-mso diagramService-7597ff4c5Name: diagramService-7597ff4c5Namespace: cisco-msoSelector: k8s-app=diagramService، pod-template-hash=7597ff4c5Labels: cpu.resource.case.cncf.io/schemaservice=cpu-lg-service                k8s-app=diagramVice memory.resource.case.cncf.io/schemaservice=mem-xlg-service         pod-template-hash=7597ff4c5Annotations: deployment.kubernetes.io/desired-replicas: 1 deployment.kubernetes.io/max-replicas: 1Control by: Deployment/schemaServiceReplicas: 1 / ds مرغوب الحالة: 1 قيد التشغيل / 0 انتظار / 0 فشل / 0 فشل قالب Pod: الملصقات: deployment.kubernetes.io/revision k8s-app=diagramVice cpu.resource.case.cncf.io/schemaservice=cpu-lg-service                    pod-template-hash=7597ff4c5 حساب الخدمة: cisco-mso-sa Init Containers: init-msc: الصورة: cisco-mso/tools:3.7.1j ميناء: <none> المضيف: <none> الأمر: memory.resource.case.cncf.io/schemaservice=mem-xlg-service                    البيئة: <none> حمولات: /secrets من Infracerts (rw) الحاويات: المخطط: الصورة: cisco-mso/diagramVice:3.7.1j: 8080/TCP، 8080/UDP مضيف ميناء: 0/TCP، 0/UDP أمر: /check_mongo.sh diagramService: http-get /launchscala.sh delay=300s timeout=20s period=30s #success=1 #failure=3 بيئة: JAVA_OPTS: -XX:+IdleTuningGcOnIdle Mount: /jwtsecret من jwtsecret (rw) /log من أسرار Infracerts (rw) msc-schemaService-Ssl: الصورة: cisco-mso/sslcontainer:3.7.1j ميناء: 443/UDP، 443/TCP مضيف ميناء: 0/UDP، 0/TCP أمر: http://:8080/api/v1/schemas/health /wrapper.sh

مراجعة NDO Pod

Pod هي مجموعة من الحاويات ذات الصلة الوثيقة التي تعمل في نفس مساحة اسم Linux (مختلفة عن مساحة اسم K8s) وفي نفس عقدة K8s. هذا هو أكثر العناصر الذرية التي يمكن معالجتها في K8s، حيث أنها لا تتفاعل مع الحاويات. يمكن أن يتكون التطبيق من حاوية واحدة أو أن يكون أكثر تعقيدا مع العديد من الحاويات. باستخدام الأمر التالي، يمكننا التحقق من Pods لأي مساحة اسم محددة:

[rescue-user@MxNDsh01 ~]$ kubectl get pod --namespace cisco-mso

NAME                                   READY   STATUS    RESTARTS   AGE

auditservice-648cd4c6f8-b29hh          2/2     Running   0          2d1h

backupservice-64b755b44c-vcpf9         2/2     Running   0          2d1h

cloudsecservice-7df465576-pwbh4        3/3     Running   0          2d1h

consistencyservice-c98955599-qlsx5     3/3     Running   0          2d1h

dcnmworker-5d4d5cbb64-qxbt8            2/2     Running   0          2d1h

eeworker-56f9fb9ddb-tjggb              2/2     Running   0          2d1h

endpointservice-7df9d5599c-rf9bw       2/2     Running   0          2d1h

executionservice-58ff89595f-xf8vz      2/2     Running   0          2d1h

fluentd-86785f89bd-q5wdp               1/1     Running   0          2d1h

importservice-88bcc8547-q4kr5          2/2     Running   0          2d1h

jobschedulerservice-5d4fdfd696-tbvqj   2/2     Running   0          2d1h

mongodb-0                              2/2     Running   0          2d1h

notifyservice-75c988cfd4-pkkfw         2/2     Running   0          2d1h

pctagvnidservice-644b755596-s4zjh      2/2     Running   0          2d1h

platformservice-65cddb946f-7mkzm       3/3     Running   0          2d1h

platformservice2-6796576659-x2t8f      4/4     Running   0          2d1h

policyservice-545b9c7d9c-m5pbf         2/2     Running   0          2d1h

schemaservice-7597ff4c5-w4x5d          3/3     Running   0          2d1h

sdaservice-5f477dd8c7-l5jn7            2/2     Running   0          2d1h

sdwanservice-6f87cd999d-6fjb8          3/3     Running   0          2d1h

siteservice-86bb756585-5n5vb           3/3     Running   0          2d1h

siteupgrade-7d578f9b6d-7kqkf           2/2     Running   0          2d1h

syncengine-5b8bdd6b45-2sr9w            2/2     Running   0          2d1h

templateeng-5cbf9fdc48-fqwd7           2/2     Running   0          2d1h

ui-84588b7c96-7rfvf                    1/1     Running   0          2d1h

userservice-87846f7c6-lzctd            2/2     Running   0          2d1h

[rescue-user@MxNDsh01 ~]$

يشير الرقم الذي يظهر في العمود الثاني إلى عدد الحاويات لكل Pod.

يعرض الأمر describe كما يتوفر خيار يتضمن معلومات تفصيلية حول الحاويات الموجودة على كل POD.

[rescue-user@MxNDsh01 ~]$ kubectl describe pod  -n cisco-mso schemaservice-7597ff4c5-w4x5d

Name:         schemaservice-7597ff4c5-w4x5d

Namespace:    cisco-mso

Priority:     0

Node:         mxndsh01/172.31.0.0

Start Time:   Tue, 20 Sep 2022 02:04:59 +0000

Labels:       cpu.resource.case.cncf.io/schemaservice=cpu-lg-service

k8s-app=schemaservice

memory.resource.case.cncf.io/schemaservice=mem-xlg-service

pod-template-hash=7597ff4c5

Annotations:  k8s.v1.cni.cncf.io/networks-status:

[{

"name": "default",

"interface": "eth0",

"ips": [

"172.17.248.16"

],

"mac": "3e:a2:bd:ba:1c:38",

"dns": {}

}]

kubernetes.io/psp: infra-privilege

Status:       Running

IP:           172.17.248.16

IPs:

IP:           172.17.248.16

Controlled By:  ReplicaSet/schemaservice-7597ff4c5

Init Containers:

init-msc:

Container ID:  cri-o://0c700f4e56a6c414510edcb62b779c7118fab9c1406fdac49e742136db4efbb8

Image:         cisco-mso/tools:3.7.1j

Image ID:      172.31.0.0:30012/cisco-mso/tools@sha256:3ee91e069b9bda027d53425e0f1261a5b992dbe2e85290dfca67b6f366410425

Port:          <none>

Host Port:     <none>

Command:

/check_mongo.sh

State:          Terminated

Reason:       Completed

Exit Code:    0

Started:      Tue, 20 Sep 2022 02:05:39 +0000

Finished:     Tue, 20 Sep 2022 02:06:24 +0000

Ready:          True

Restart Count:  0

Environment:    <none>

Mounts:

/secrets from infracerts (rw)

/var/run/secrets/kubernetes.io/serviceaccount from cisco-mso-sa-token-tn45l (ro)

Containers:

schemaservice:

Container ID:  cri-o://d2287f8659dec6848c0100b7d24aeebd506f3f77af660238ca0c9c7e8946f4ac

Image:         cisco-mso/schemaservice:3.7.1j

Image ID:      172.31.0.0:30012/cisco-mso/schemaservice@sha256:6d9fae07731cd2dcaf17c04742d2d4a7f9c82f1fc743fd836fe59801a21d985c

Ports:         8080/TCP, 8080/UDP

Host Ports:    0/TCP, 0/UDP

Command:

/launchscala.sh

schemaservice

State:          Running

Started:      Tue, 20 Sep 2022 02:06:27 +0000

Ready:          True

Restart Count:  0

Limits:

cpu:     8

memory:  30Gi

Requests:

cpu:     500m

memory:  2Gi

تتضمن المعلومات المعروضة صورة الحاوية لكل حاوية وتظهر وقت تشغيل الحاوية المستخدم. في هذه الحالة، CRI-O (cri-o)، وهي الإصدارات السابقة من ND المستخدمة للعمل مع Docker، يؤثر ذلك على كيفية الإرتباط بالحاوية.

مفسد (إبراز إلى القراءة)

على سبيل المثال، عندما cri-o المستخدم، ونريد الاتصال بجلسة تفاعلية بحاوية (عبر exec -it ) للحاوية من المخرج السابق، ولكن بدلا من docker أمر، نحن نستخدم أمر الجرس:

schemaservice:

Container ID:  cri-o://d2287f8659dec6848c0100b7d24aeebd506f3f77af660238ca0c9c7e8946f4ac

Image:         cisco-mso/schemaservice:3.7.1j

نستخدم هذا الأمر:

[root@MxNDsh01 ~]# crictl exec -it d2287f8659dec6848c0100b7d24aeebd506f3f77af660238ca0c9c7e8946f4ac bash

root@schemaservice-7597ff4c5-w4x5d:/#

root@schemaservice-7597ff4c5-w4x5d:/# whoami

root

بالنسبة لإصدارات ND اللاحقة، يكون معرف الحاوية الذي سيتم إستخدامه مختلفا. أولا، نحتاج إلى إستخدام الأمر crictl ps لسرد كافة الحاويات التي يتم تشغيلها على كل عقدة. يمكننا تصفية النتيجة كما هو مطلوب.

[root@singleNode ~]# crictl ps| grep backup

a9bb161d67295 10.31.125.241:30012/cisco-mso/sslcontainer@sha256:26581eebd0bd6f4378a5fe4a98973dbda417c1905689f71f229765621f0cee75 2 days ago that run msc-backupservice-ssl 0 84b3c691cfc2b

4b26f67fc10cf 10.31.125.241:30012/cisco-mso/backupservice@sha256:c21f4cdde696a5f2dfa7bb910b7278fc3fb4d46b02f42c3554f872ca8c87c061 2 days ago Running backupservice 0 84b3c691cfc2b

[root@singleNode ~]#

باستخدام القيمة من العمود الأول، يمكننا بعد ذلك الوصول إلى وقت تشغيل الحاوية باستخدام الأمر نفسه كما كان من قبل:

[root@singleNode ~]# crictl exec -it 4b26f67fc10cf bash

root@backupservice-8c699779f-j9jtr:/# pwd

/

على سبيل المثال، عند إستخدام CRI-o، ونريد الاتصال بجلسة تفاعلية بحاوية (عبر exec -it option) من الإخراج السابق إلى الحاوية؛ ولكن بدلا من أمر docker، نستخدم الأمر cri-o://d2287f8659dec6848c0100b7d24aeebd506f3f77af660238ca0c9c7e8946f4ac    image: cisco-mso/schemaService:3.7.1j نستخدم هذا الأمر: [root@MxNDsh01 ~]# cricketEXEC -it2287f8659dec6848c0100b7d24aeebd506f3f77af 660238ca0c9c7e8946f4ac bashroot@schemaservice-7597ff4c5-w4x5d:/#root@schemaservice-7597ff4c5-w4x5d:/# whoamiroot للإصدارات اللاحقة ND، معرف الحاوية الذي سيتم إستخدامه مختلف. أولا، نحتاج إلى إستخدام قوائم التحكم في الأوامر لسرد جميع الحاويات التي يتم تشغيلها على كل عقدة. يمكننا تصفية النتيجة كما هو مطلوب. [root@singleNode ~]# من الحارات التي يتم تشغيلها منذ يومين MSC-backupservice-ssl 0 84b3c691cfc2b4b26f10cf 10.31.125.241:30012/cisco-mso/backupservice@sha256:c21f4cdde696a5f2dfa7bb910b7278fc3fb4d46b02f42c3554f872ca8c87c061 منذ يومين يتم تشغيل خدمة الدعم 0 84b3c691cfc2b[31.125.241:30012/cisco-mso/sslcontainer@sha256:26581eebd0bd6f4378a5fe4a98973dbda417c1905689f71f229765621f0cee75 ~]# باستخدام القيمة من العمود الأول، يمكننا بعد ذلك الوصول إلى وقت تشغيل الحاوية بنفس الأمر قبل: [root@singleNode]# من EXEC -4b26f6 7fc10cf root@singleNode bashroot@backupservice-8c699779f-j9jtr:/# pwd/

Use-case Pod ليس سليم

يمكننا إستخدام هذه المعلومات لاستكشاف أخطاء Pods من النشر وإصلاحها. على سبيل المثال، إصدار لوحة معلومات Nexus هو 2.2-1D والتطبيق المتأثر هو Nexus Dashboard Orchestrator (NDO).

تعرض واجهة المستخدم الرسومية (GUI) ل NDO مجموعة غير كاملة من PODS من طريقة عرض الخدمة. في هذه الحالة 24 من 26 محركا من الأقراص الصلبة.

طريقة عرض أخرى متوفرة ضمن System Resources -> Pods طريقة عرض حيث تظهر ال Pods حالة مختلفة عن Ready.

أستكشاف أخطاء CLI وإصلاحها بحثا عن PODS غير السليمة

مع الحقيقة المعروفة أن مساحة الاسم هي Cisco-mso (على الرغم من أنها تكون مماثلة للتطبيقات/مساحات الأسماء الأخرى عندما تكون مثيرة للمشاكل)، تظهر طريقة عرض Pod إذا كان هناك أي منها غير سليمة:

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso

NAME READY UP-TO-DATE AVAILABLE AGE

auditservice 1/1 1 1 6d18h

backupservice 1/1 1 1 6d18h

cloudsecservice 1/1 1 1 6d18h

consistencyservice 0/1 1 0 6d18h <---

fluentd 0/1 1 0 6d18h <---

syncengine 1/1 1 1 6d18h

templateeng 1/1 1 1 6d18h

ui 1/1 1 1 6d18h

userservice 1/1 1 1 6d18h

على سبيل المثال، نركز على مجموعات توصيل ConsistentService. من مخرجات JSON، يمكننا الحصول على المعلومات المحددة من حقول الحالة، باستخدام jsonpath:

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso consistencyservice -o json

{

<--- OUTPUT OMITTED ---->

"status": {

"conditions": [

{

"message": "Deployment does not have minimum availability.",

"reason": "MinimumReplicasUnavailable",

},

{

"message": "ReplicaSet \"consistencyservice-c98955599\" has timed out progressing.",

"reason": "ProgressDeadlineExceeded",

}

],

}

}

[rescue-user@MxNDsh01 ~]$

نرى قاموس الحالة وداخل قائمة تسمى شروط مع قواميس كعناصر مع مفاتيح رسالة وقيمة، {"\n"} جزء هو إنشاء سطر جديد في النهاية:

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso consistencyservice -o=jsonpath='{.status.conditions[*].message}{"\n"}'

Deployment does not have minimum availability. ReplicaSet "consistencyservice-c98955599" has timed out progressing.

[rescue-user@MxNDsh01 ~]$

يوضح هذا الأمر كيفية التحقق من get Pod لمساحة الاسم:

[rescue-user@MxNDsh01 ~]$ kubectl get pods -n cisco-mso

NAME READY STATUS RESTARTS AGE

consistencyservice-c98955599-qlsx5 0/3 Pending 0 6d19h

executionservice-58ff89595f-xf8vz 2/2 Running 0 6d19h

fluentd-86785f89bd-q5wdp 0/1 Pending 0 6d19h

importservice-88bcc8547-q4kr5 2/2 Running 0 6d19h

jobschedulerservice-5d4fdfd696-tbvqj 2/2 Running 0 6d19h

mongodb-0 2/2 Running 0 6d19h

مع get pods أمر، نحن يمكن أن تحصل على Pod id مع مشاكل أن تتطابق مع واحد من المخرج السابق. في هذا المثال consistencyservice-c98955599-qlsx5.

يوفر تنسيق مخرجات JSON أيضا كيفية التحقق من معلومات معينة، من المخرجات المحددة.

[rescue-user@MxNDsh01 ~]$ kubectl get pods -n cisco-mso consistencyservice-c98955599-qlsx5 -o json

{

<--- OUTPUT OMITTED ---->

"spec": {

<--- OUTPUT OMITTED ---->

"containers": [

{

<--- OUTPUT OMITTED ---->

"resources": {

"limits": {

"cpu": "8",

"memory": "8Gi"

},

"requests": {

"cpu": "500m",

"memory": "1Gi"

}

},

<--- OUTPUT OMITTED ---->

"status": {

"conditions": [

{

"lastProbeTime": null,

"lastTransitionTime": "2022-09-20T02:05:01Z",

"message": "0/1 nodes are available: 1 Insufficient cpu.",

"reason": "Unschedulable",

"status": "False",

"type": "PodScheduled"

}

],

"phase": "Pending",

"qosClass": "Burstable"

}

}

[rescue-user@MxNDsh01 ~]$

يجب أن يتضمن إخراج JSON معلومات حول الحالة في السمة التي لها نفس الاسم. تتضمن الرسالة معلومات عن السبب.

[rescue-user@MxNDsh01 ~]$ kubectl get pods -n cisco-mso consistencyservice-c98955599-qlsx5 -o=jsonpath='{.status}{"\n"}'

map[conditions:[map[lastProbeTime:<nil> lastTransitionTime:2022-09-20T02:05:01Z message:0/1 nodes are available: 1 Insufficient cpu. reason:Unschedulable status:False type:PodScheduled]] phase:Pending qosClass:Burstable]

[rescue-user@MxNDsh01 ~]$

يمكننا الوصول إلى معلومات حول الحالة والمتطلبات الخاصة بالأدوات:

[rescue-user@MxNDsh01 ~]$ kubectl get pods -n cisco-mso consistencyservice-c98955599-qlsx5 -o=jsonpath='{.spec.containers[*].resources.requests}{"\n"}'

map[cpu:500m memory:1Gi]

وهنا من الأهمية بمكان أن نذكر كيف يتم حساب القيمة. في هذا المثال، تشير وحدة المعالجة المركزية (CPU500m) إلى 500 مللي كورة، بينما الجيل الأول في الذاكرة هي ل GB.

يعرض الأمر Describe يظهر خيار العقدة المورد المتوفر لكل عامل K8s في نظام المجموعة (المضيف أو VM):

[rescue-user@MxNDsh01 ~]$ kubectl describe nodes | egrep -A 6 "Allocat"

Allocatable:

cpu: 13

ephemeral-storage: 4060864Ki

hugepages-1Gi: 0

hugepages-2Mi: 0

memory: 57315716Ki

pods: 110

--

Allocated resources:

(Total limits may be over 100 percent, i.e., overcommitted.)

Resource Requests Limits

-------- -------- ------

cpu 13 (100%) 174950m (1345%)

memory 28518Mi (50%) 354404Mi (633%)

ephemeral-storage 0 (0%) 0 (0%)

>[rescue-user@MxNDsh01 ~]$

يوضح القسم القابل للتخصيص إجمالي الموارد في وحدة المعالجة المركزية (CPU) والذاكرة والتخزين المتوفرة لكل عقدة. يظهر القسم المخصص الموارد المستخدمة بالفعل. تشير القيمة 13 لوحدة المعالجة المركزية إلى 13 مركزا أو 13000 (13k) مللي كور.

على سبيل المثال، تم زيادة الاشتراك في العقدة، مما يفسر سبب عدم قدرة Pod على بدء التشغيل. بعد مسح ND بحذف تطبيقات ND أو إضافة موارد VM.

يحاول نظام المجموعة باستمرار نشر أي نهج معلقة، لذا إذا كانت الموارد مجانية، يمكن نشر PODS.

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso

NAME READY UP-TO-DATE AVAILABLE AGE

auditservice 1/1 1 1 8d

backupservice 1/1 1 1 8d

cloudsecservice 1/1 1 1 8d

consistencyservice 1/1 1 1 8d

dcnmworker 1/1 1 1 8d

eeworker 1/1 1 1 8d

endpointservice 1/1 1 1 8d

executionservice 1/1 1 1 8d

fluentd 1/1 1 1 8d

importservice 1/1 1 1 8d

jobschedulerservice 1/1 1 1 8d

notifyservice 1/1 1 1 8d

pctagvnidservice 1/1 1 1 8d

platformservice 1/1 1 1 8d

platformservice2 1/1 1 1 8d

policyservice 1/1 1 1 8d

schemaservice 1/1 1 1 8d

sdaservice 1/1 1 1 8d

sdwanservice 1/1 1 1 8d

siteservice 1/1 1 1 8d

siteupgrade 1/1 1 1 8d

syncengine 1/1 1 1 8d

templateeng 1/1 1 1 8d

ui 1/1 1 1 8d

userservice 1/1 1 1 8d

باستخدام الأمر المستخدم للتحقق من الموارد، نؤكد أن نظام المجموعة لديه مورد متوفر لوحدة المعالجة المركزية:

[rescue-user@MxNDsh01 ~]$ kubectl describe nodes | egrep -A 6 "Allocat"

Allocatable:

cpu: 13

ephemeral-storage: 4060864Ki

hugepages-1Gi: 0

hugepages-2Mi: 0

memory: 57315716Ki

pods: 110

--

Allocated resources:

(Total limits may be over 100 percent, i.e., overcommitted.)

Resource Requests Limits

-------- -------- ------

cpu 12500m (96%) 182950m (1407%)

memory 29386Mi (52%) 365668Mi (653%)

ephemeral-storage 0 (0%) 0 (0%)

[rescue-user@MxNDsh01 ~]$

تتضمن تفاصيل النشر رسالة تتضمن معلومات حول الظروف الحالية ل Pods:

[rescue-user@MxNDsh01 ~]$ kubectl get deployment -n cisco-mso consistencyservice -o=jsonpath='{.status.conditions[*]}{"\n"}'

map[lastTransitionTime:2022-09-27T19:07:13Z lastUpdateTime:2022-09-27T19:07:13Z message:Deployment has minimum availability. reason:MinimumReplicasAvailable status:True type:Available] map[lastTransitionTime:2022-09-27T19:07:13Z lastUpdateTime:2022-09-27T19:07:13Z message:ReplicaSet "consistencyservice-c98955599" has successfully progressed. reason:NewReplicaSetAvailable status:True type:Progressing]

[rescue-user@MxNDsh01 ~]$

مفسد (إبراز إلى القراءة)

كيفية تشغيل أوامر تصحيح أخطاء الشبكة من داخل حاوية

نظرا لأن الحاويات تحتوي فقط على الحد الأدنى من المكتبات والتبعيات الخاصة ب Pod، فإن معظم أدوات تصحيح أخطاء الشبكة (ping و ip route و ip addr) غير متوفرة داخل الحاوية نفسها.

تكون هذه الأوامر مفيدة جدا عندما تكون هناك حاجة لاستكشاف أخطاء الشبكة وإصلاحها لخدمة (بين عقد ND) أو اتصال ب Apics نظرا لأن العديد من الخدمات الدقيقة تحتاج إلى الاتصال بوحدات التحكم بواجهة البيانات (Bond0 أو Bond0br).

يعرض الأمر nsenter تسمح لنا الأداة المساعدة (للمستخدم الجذري فقط) بتشغيل أوامر الشبكة من عقدة ND كما هي داخل الحاوية. لهذا، ابحث عن معرف العملية (PID) من الحاوية التي نريد تصحيح أخطائها. يتم تحقيق ذلك باستخدام معرف Pod K8s مقابل المعلومات المحلية من وقت تشغيل الحاوية، مثل Docker للإصدارات القديمة، و cri-o بالنسبة للأحدث كافتراضي.

فحص معرف Pod Kubernetes (K8s)

من قائمة Pods داخل مساحة اسم Cisco-mso، يمكننا تحديد الحاوية لاستكشاف الأخطاء وإصلاحها:

[root@MxNDsh01 ~]# kubectl get pod -n cisco-mso

NAME READY STATUS RESTARTS AGE

consistencyservice-569bdf5969-xkwpg 3/3 Running 0 9h

eeworker-65dc5dd849-485tq 2/2 Running 0 163m

endpointservice-5db6f57884-hkf5g 2/2 Running 0 9h

executionservice-6c4894d4f7-p8fzk 2/2 Running 0 9h

siteservice-64dfcdf658-lvbr4 3/3 Running 0 9h

siteupgrade-68bcf987cc-ttn7h 2/2 Running 0 9h

يجب تشغيل Pods في نفس عقدة K8s. لبيئات الإنتاج، يمكننا إضافة -o wide خيار في النهاية لاكتشاف العقدة التي يشغلها كل Pod. باستخدام معرف Pod K8s (المزود في مثال الإخراج السابق) يمكننا التحقق من العملية (PID) المعينة بواسطة وقت تشغيل الحاوية.

كيفية فحص معرف العملية من وقت تشغيل الحاوية

وقت تشغيل الحاوية الافتراضي الجديد هو CRI-O ل Kubernetes. إذا تأتي الوثيقة بعد تلك القاعدة للأوامر. يمكن أن يكون معرف العملية (PID) المعين من قبل CRI-O فريدا في عقدة K8s، والتي يمكن اكتشافها مع crictl الأداة.

يعرض الأمر ps يكشف الخيار عن الهوية المعطاة من قبل CRI-O لكل حاوية تبني Pod، إثنان للمثال الموقعي:

[root@MxNDsh01 ~]# crictl ps |grep siteservice

fb560763b06f2 172.31.0.0:30012/cisco-mso/sslcontainer@sha256:2d788fa493c885ba8c9e5944596b864d090d9051b0eab82123ee4d19596279c9 10 hours ago Running msc-siteservice2-ssl 0 074727b4e9f51

ad2d42aae1ad9 1d0195292f7fcc62f38529e135a1315c358067004a086cfed7e059986ce615b0 10 hours ago Running siteservice-leader-election 0 074727b4e9f51

29b0b6d41d1e3 172.31.0.0:30012/cisco-mso/siteservice@sha256:80a2335bcd5366952b4d60a275b20c70de0bb65a47bf8ae6d988f07b1e0bf494 10 hours ago Running siteservice 0 074727b4e9f51

[root@MxNDsh01 ~]#

بهذه المعلومات، يمكننا إستخدام inspect CRIO-ID خيار أن ترى PID الفعلي معطى لكل حاوية. هذه المعلومات مطلوبة من أجل nsenter :

[root@MxNDsh01 ~]# crictl inspect fb560763b06f2| grep -i pid

"pid": 239563,

"pids": {

"type": "pid"

كيفية إستخدام المحدث لتشغيل أوامر تصحيح أخطاء الشبكة داخل حاوية

مع معرف العملية من الإخراج أعلاه، يمكننا إستخدامه كهدف في صياغة الأمر التالية:

nsenter --target <PID> --net <NETWORK COMMAND>

يعرض الأمر --net يتيح لنا الخيار تشغيل الأوامر في مساحات أسماء الشبكة، لذلك فإن عدد الأوامر المتاحة محدود.

على سبيل المثال:

[root@MxNDsh01 ~]# nsenter --target 239563 --net ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450

inet 172.17.248.146 netmask 255.255.0.0 broadcast 0.0.0.0

inet6 fe80::984f:32ff:fe72:7bfb prefixlen 64 scopeid 0x20<link>

ether 9a:4f:32:72:7b:fb txqueuelen 0 (Ethernet)

RX packets 916346 bytes 271080553 (258.5 MiB)

RX errors 0 dropped 183 overruns 0 frame 0

TX packets 828016 bytes 307255950 (293.0 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

inet 127.0.0.1 netmask 255.0.0.0

inet6 ::1 prefixlen 128 scopeid 0x10<host>

loop txqueuelen 1000 (Local Loopback)

RX packets 42289 bytes 14186082 (13.5 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 42289 bytes 14186082 (13.5 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

يتوفر إختبار الاتصال أيضا، وهو يختبر الاتصال من الحاوية إلى الخارج، بدلا من عقدة K8S فقط.

[root@MxNDsh01 ~]# nsenter --target 239563 --net wget --no-check-certificate https://1xx.2xx.3xx.4xx

--2023-01-24 23:46:04-- https://1xx.2xx.3xx.4xx/

Connecting to 1xx.2xx.3xx.4xx:443... connected.

WARNING: cannot verify 1xx.2xx.3xx.4xx's certificate, issued by ‘/C=US/ST=CA/O=Cisco System/CN=APIC’:

Unable to locally verify the issuer's authority.

WARNING: certificate common name ‘APIC’ doesn't match requested host name ‘1xx.2xx.3xx.4xx’.

HTTP request sent, awaiting response... 200 OK

Length: 3251 (3.2K) [text/html]

Saving to: ‘index.html’

100%[===================================================================================================================================================>] 3,251 --.-K/s in 0s

2023-01-24 23:46:04 (548 MB/s) - ‘index.html’ saved [3251/3251]

كيفية تشغيل أوامر تصحيح أخطاء الشبكة من داخل حاوية لأن الحاويات تتضمن فقط الحد الأدنى من المكتبات والتبعيات الخاصة ب Pod، ولا تتوفر معظم أدوات تصحيح أخطاء الشبكة (ping، ip route، ip addr) داخل الحاوية نفسها.   تكون هذه الأوامر مفيدة للغاية عندما تكون هناك حاجة لاستكشاف أخطاء الشبكة وإصلاحها لخدمة (بين عقد ND) أو اتصال ب Apics نظرا لأن العديد من الخدمات الدقيقة تحتاج إلى الاتصال بوحدات التحكم بواجهة البيانات (bond0 أو bond0br).   تتيح لنا الأداة المساعدة للمصدر (المستخدم الجذري فقط) تشغيل أوامر الشبكة من عقدة ND كما هي داخل الحاوية. لهذا، ابحث عن معرف العملية (PID) من الحاوية التي نريد تصحيح أخطائها. ويتم تحقيق ذلك باستخدام معرف Pod K8s مقابل المعلومات المحلية من وقت تشغيل الحاوية، مثل Docker للإصدارات القديمة و cri-o للإصدارات الأحدث كافتراضي.   فحص معرف Pod Kubernetes (K8s) من قائمة Pods داخل مساحة الاسم Cisco-mso، يمكننا تحديد الحاوية لاستكشاف الأخطاء وإصلاحها: [root@MxNDsh01 ~]# kubectl get pod -n cisco-msoNAME ready الحالة RESTART AGEconsistentService-569bdf5969-xkwpg 3/3 Running 0 9heeworker-65dc5dd849-485tq 2/2 Running 0163endpointService-5db6f57 84-hkf5g 2/2 يركض 0 9hexecutionservice-6c4894d4f7-p8fzk 2/2 يركض 0 9hsiteservice-64dfcdf658-lvbr4 3/3 يركض 0 9hsiteupgrade-68bcf987cc-ttn7h 2/2 يركض 0 9h يجب أن تعمل Pods في نفس عقدة K8s. وبالنسبة لبيئات الإنتاج، يمكننا إضافة خيار -o الواسع في النهاية لمعرفة العقدة التي يعمل عليها كل Pod. باستخدام معرف Pod K8s (المزود في مثال الإخراج السابق) يمكننا التحقق من العملية (PID) المعينة بواسطة وقت تشغيل الحاوية.   كيفية فحص معرف العملية من وقت تشغيل الحاوية يكون وقت تشغيل الحاوية الافتراضي الجديد هو CRI-O ل Kubernetes. إذا تأتي الوثيقة بعد تلك القاعدة للأوامر. يمكن أن يكون معرف العملية (PID) الذي تم تعيينه من قبل CRI-O فريدا في عقدة K8s، والتي يمكن اكتشافها باستخدام الأداة المساعدة للحدث.   يكشف خيار PS عن المعرف المعطى من قبل CRI-O لكل حاوية تبني POD، إثنان للمثال التالي: [root@MxNDsh01 ~]# وحدات التخزين الصغيرة |grep siteservicefb560763b06f2 172.31.0.0:30012/cisco-mso/sslcontainer@sha256:2d788fa493c885ba8c9e5944596b864d090d9051b0eab82123ee4d19596279c9 منذ 10 ساعات تشغيل msc-siteservice2-ssl 074727b4e9f51ad2d42aae1ad9 1d0195292f7fcc62f38529e135a1358067004a086cfed7e0e0e 59986ce615b0 قبل 10 ساعات تشغيل الموقع -Control 074727b4e9f5129b0b6d41d1e3 172.31.0.0:30012/cisco-mso/siteservice@sha256:80a2335bcd5366952b4d60a275b20c70de0bb65a47bf8ae6d988f07b1e0bf494 قبل 10 ساعات تشغيل الموقع 074727b4e9f51[root@MxNDsh01 ~]# مع هذه المعلومات، يمكننا بعد ذلك إستخدام خيار فحص CRIO-ID لرؤية PID الفعلي المقدم إلى كل حاوية. هذه المعلومات مطلوبة للأمر: [root@MxNDsh01 ~]# فحص FB560763b06f2| GREP -i pid: 239563،"pids": {"type": "pid" كيفية إستخدام جهاز العرض لتشغيل أوامر تصحيح أخطاء الشبكة داخل الحاوية مع معرف العملية من الإخراج أعلاه، يمكن أن نستخدم كهدف في صياغة الأمر التالي: nsenter —target <PID> —net <NETWORK Command> يسمح خيار —net بتشغيل الأوامر في مساحات الشبكة، رقم الشبكة الأوامر المتوفرة محدودة. على سبيل المثال: [root@MxNDsh01 ~]# nsenter — target 239563 — net ifconfig0: flags=4163<up، broadcast، running، multicast> mtu 1450inet 172.17.248.146 netmask 255.255.0.0 بث 0.0.0inet6 fe80::984f:32ff:fe72:7bfb prefix 64 scopeid 0x20>link:4a f:32:72:7b:fb txqueuelen 0 (Ethernet)RX Packet 916346 بايت 271080553 (258.5 MiB)RX Errors 0 سقطت 183 تجاوز 0 إطار 0TX Packet 828016 بايت 307255950 (293.0 MiB)أخطاء TX 0 تجاوزت 0 تصادمات الناقل 0 علامات=73<LOUP،0 opback،running> MTU 65536inet 127.0.0.1 netmask 255.0.0.0inet6 ::1 بادئة 128 نطاق 0x10<host>تكرار txqueuelen 1000 (الاسترجاع المحلي)حزم RX 42289 بايت 14186082 (13.5 MiB)أخطاء RX 0 تم إسقاط 0 تجاوز 0 إطار 0TX حزم 42289 بايت 14882 082 (13.5 MiB)TX إخفاق 0 تجاوز 0 حامل 0 إصطدام 0 إختبار الاتصال متوفر أيضا، وهو يختبر الاتصال من الحاوية إلى الخارج، بدلا من فقط العقدة K8s. [root@MxNDsh01 ~]# رمز— الهدف 239563 — الشبكة:No-Check-Certificate https://1xx.2xx.3xx.4xx--2023-01-24 23:46:04— https://1xx.2xx.3xx.4xx/Connecting إلى 1xx.2xx.3xx.4xx:443.. متصل.تحذير: لا يمكن التحقق من شهادة 1xx.2xx.3xx.4xx.4xx، التي تم إصدارها ‘/c=US/ST=CA/O=Cisco System/CN=apic':يتعذر التحقق محليا من مرجع المصدر.تحذير: الاسم الشائع للشهادة 'APIC' لا يطابق الاسم المطلوب 'المضيف' xx.2xx.3xx.4xx'.http طلب مرسل، في انتظار الاستجابة... 200 OKLength: 3251 (3.2K) [text/html]الحفظ إلى: 'index.html’100٪[=========================================================================================================================================>] 3،251 — k/s في 0s2023-01-24 23:46:04 (548 ميجابايت/s) - 'index.html' محفوظ [3251/3251]