NDOリソースのトラブルシューティングとレビュー
概要
このドキュメントでは、kubectlおよびコンテナランタイムCLIを使用してNDOを確認し、トラブルシューティングする方法について説明します。
NDO QuickStart
Cisco Nexus Dashboard Orchestrator(NDO)は、ファブリック管理ツールです。このツールを使用すると、Cisco® Application Centric Infrastructure(Cisco ACI®)サイト、Cisco Cloud ACIサイト、Cisco Nexus Dashboard Fabric Controller(NDFC)サイトなどのさまざまな種類のファブリックを管理できます。各ファブリックは、独自のコントローラ（パブリッククラウド内のAPICクラスタ、NDFCクラスタ、またはCloud APICインスタンス）で管理されます。
NDOは、1つの画面で複数のデータセンター間で一貫したネットワークとポリシーのオーケストレーション、拡張性、およびディザスタリカバリを提供します。
初期には、VMWare Open Virtual Appliances(OVA)を使用した3ノードクラスタとしてMSC(Multi-Site Controller)が導入され、Docker SwarmクラスタとMSCサービスを初期化できました。このSwarmクラスタは、MSCマイクロサービスをDockerコンテナおよびサービスとして管理します。
この図は、Docker Swarmがハイアベイラビリティを実現するためにマイクロサービスを同じコンテナのレプリカとして管理する方法を簡単に示しています。
Docker Swarmは、MSCアーキテクチャ内の各マイクロサービスに対して予想される数のレプリカを維持する役割を担っていました。Docker Swarmの観点からは、マルチサイトコントローラがオーケストレーションを行う唯一のコンテナ展開でした。
Nexus Dashboard(ND)は、複数のデータセンターサイトに対応する中央管理コンソールであり、Nexus InsightやMSCバージョン3.3以降を含むシスコのデータセンター運用サービスをホストし、Nexus Dashboard Orchestrator(NDO)に名前を変更した共通のプラットフォームです。
MSCアーキテクチャを構成するマイクロサービスの大部分は同じままですが、NDOはDocker SwarmクラスタではなくKubernetes(K8s)クラスタに導入されます。これにより、NDは1つのアプリケーションまたは導入ではなく、複数のアプリケーションまたは導入を調整できます。
Kubernetes with NDO Crash-Course
Kubernetesは、コンテナ化されたアプリケーションの導入、スケーラビリティ、および管理を自動化するオープンソースシステムです。Dockerとして、Kubernetesはコンテナテクノロジーで動作しますが、Dockerとは関係ありません。これは、Kubernetesが他のコンテナプラットフォーム(Rkt、PodMan)をサポートすることを意味します。
SwarmとKubernetesの主な違いは、後者はコンテナを直接操作するのではなく、代わりにポッドと呼ばれるコンテナのグループを同じ場所に配置するという概念で動作することです。
ポッド内のコンテナは同じノードで実行する必要があります。ポッドのグループは導入と呼ばれます。Kubernetesの導入では、アプリケーション全体を記述できます。
また、Kubernetesは、ユーザが特定のアプリケーションに対して一定量のリソースを確実に使用できるようにしています。これは、Replication Controllerを使用して行われ、Podの数がアプリケーションマニフェストと一致していることを確認します。
マニフェストは、クラスターによって展開されるリソースを記述するYAML形式のファイルです。リソースは、前に説明したリソースまたはユーザが使用できるその他のリソースです。
アプリケーションには、1つ以上のサービスを使用して外部からアクセスできます。Kubernetesには、これを実現するためのロードバランサオプションが含まれています。
Kubernetesは、名前空間の概念を使用して異なるリソースを分離する方法も提供します。NDは名前空間を使用して、さまざまなアプリケーションとクラスターサービスを一意に識別します。CLIコマンドを実行するときは、常にネームスペースを指定します。
NDまたはNDOのトラブルシューティングにはKubernetesに関する深い知識は必要ありませんが、問題のあるリソースや注意が必要なリソースを適切に特定するには、Kubernetesアーキテクチャに関する基本的な知識が必要です。
Kubernetesリソースアーキテクチャの基本を次の図に示します。
各リソースが他のリソースとどのように相互作用するかを覚えておくことが重要であり、レビューおよびトラブルシューティングプロセスで重要な役割を果たします。
KubernetesコマンドによるNDOの概要
CLIアクセスログイン
NDOへのSSHによるCLIアクセスの場合は、 admin-user パスワードが必要です。ただし、代わりに rescue-user password が base64 でエンコードされたものです。次のような場合：
ssh rescue-user@ND-mgmt-IP
rescue-user@XX.XX.XX.XX’s password:
[rescue-user@MxNDsh01 ~]$ pwd
/home/rescue-user
[rescue-user@MxNDsh01 ~]$
これはCLIアクセスのデフォルトモードとユーザであり、ほとんどの情報を表示できます。
NDO名前空間の確認
このK8sの概念により、クラスタ全体で異なるリソースを分離できます。次のコマンドを使用して、導入されたさまざまなネームスペースを確認できます。
[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のアプリケーションに属し、プレフィックスkubeで始まるエンティティはKubernetesクラスタに属しています。各名前空間には独自の展開とポッドがあります
kubectl CLIでは、 --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 [format]オプションを使用します。以下に、いくつかの例を示します。
[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": ""
}
}
前のテキストからの出力はディクショナリで、そのキーの1つがitemsと呼ばれ、値はディクショナリのリストで、各ディクショナリがNamespaceエントリを占め、その属性がディクショナリ内のキーと値のペア値またはネストされたディクショナリです。
これは、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 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
出力では、表示する各列に名前を付け、出力に値を割り当てる必要があります。この例では、次の2つの列があります。 NAME と UID.これらの値は、 .metada.name と .metadata.uid それぞれに対応.詳細と例については、次のURLを参照してください。
NDO導入のレビュー
Deploymentは、ReplicaSetとPodを管理するための結合スペースを提供するK8sオブジェクトです。導入では、アプリケーションに属するすべてのポッドのロールアウトと、各ポッドの予想コピー数が処理されます。
kubectl CLIには、任意の名前空間の展開を確認するコマンドが含まれています。
[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
表示されるコピーの数は、各マイクロサービスのポッドの数ではなく、導入用であることに注意してください。
キーワードは describe 代わりに get リソースに関するより詳細な情報を表示するには、次の手順に従います。この場合、schemaservice配置は次のとおりです。
[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オブジェクトです。また、このオブジェクトは、ポッドへの定期的なプローブで異常な数のレプリカが検出されたときも検出します。
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ポッドレビュー
Podは、同じLinux名前空間（K8s名前空間とは異なる）および同じK8sノードで実行される、密接に関連したコンテナのグループです。これはコンテナと相互作用しないので、K8sが処理する最もアトミックオブジェクトです。アプリケーションは、単一のコンテナで構成することも、複数のコンテナを使用してより複雑にすることもできます。次のコマンドを使用して、任意のネームスペースのポッドを確認できます。
[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 ~]$
2列目の数値は、各ポッドのコンテナの数を示しています。
「 describe オプションも利用できます。これには、各ポッドのコンテナに関する詳細情報が含まれます。
[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 cricltコマンドを使用します。
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リリースでは、使用するコンテナIDが異なります。最初に、コマンドを使用する必要があります 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
/
ユースケースPodが正常でない
この情報を使用して、導入のポッドが正常でない理由をトラブルシューティングできます。この例では、Nexus Dashboardのバージョンは2.2-1dで、影響を受けるアプリケーションはNexus Dashboard Orchestrator(NDO)です。
NDO GUIの[Service]ビューに、不完全なポッドのセットが表示されます。この例では、26個のポッドのうち24個です。
別のビューは、 System Resources -> Pods ポッドが示すステータスが異なる場所の表示 Ready.
異常なポッドのCLIトラブルシューティング
既知の事実では、名前空間は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
この例では、一貫したサービスポッドに焦点を当てます。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 ~]$
statusディクショナリが表示されます。このリストの中のconditionsというディクショナリには、messageキーとvalueキーを持つ項目が含まれています。このリストの{"\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
Cisco Unified Computing System get pods コマンドを使用して、前の出力の問題と一致する必要がある問題を含むポッド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]
ここでは、値の計算方法について説明することが重要です。この例では、cpu 500mは500ミリコアを指し、メモリ内の1GはGBを表します。
「 Describe ノードのオプションには、クラスタ（ホストまたはVM）内の各K8sワーカーに使用可能なリソースが表示されます。
[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 ~]$
[Allocatable] セクションには、各ノードで使用可能なCPU、メモリ、およびストレージ内のリソースの合計が表示されます。[Allocated] セクションには、すでに使用されているリソースが表示されます。CPUの値13は、13コアまたは13,000(13K)ミリコアを示します。
この例では、ノードがoversubscribedであり、これがポッドが開始できない理由を説明しています。NDをクリアした後、ND APPを削除するか、VMリソースを追加します。
クラスタは常に保留中のポリシーの展開を試みるため、リソースが空いている場合はポッドを展開できます。
[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
リソースチェックに使用するコマンドを使用して、クラスタにCPU用の使用可能なリソースがあることを確認します。
[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 ~]$
導入の詳細には、ポッドの現在の状態に関する情報を含むメッセージが含まれます。
[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 ~]$
コンテナ内からnetwork debugコマンドを実行する方法
コンテナにはPodに固有の最小限のライブラリと依存関係しか含まれていないため、ほとんどのネットワークデバッグツール(ping、ip route、ip addr)はコンテナ自体の内部では使用できません。
これらのコマンドは、サービス（NDノード間）またはApicへの接続に関するネットワーク問題をトラブルシューティングする必要がある場合に非常に便利です。複数のマイクロサービスがデータインターフェイス(bond0またはbond0br)を使用してコントローラと通信する必要があるためです。
「 nsenter ユーティリティ（rootユーザのみ）を使用すると、コンテナ内にあるNDノードからネットワークコマンドを実行できます。このために、デバッグするコンテナからプロセスID(PID)を見つけます。これは、旧バージョンのDockerなど、コンテナランタイムからのローカル情報に対するPod K8s IDによって実現されます。 cri-o 新しいバージョンの場合はデフォルトです。
Pod Kubernetes(K8s)IDの検査
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
ポッドは同じK8sノードで実行する必要があります。実稼働環境には、 -o wide 各ポッドが実行するノードを確認するオプションを最後に追加します。Pod K8s ID（前の出力例で太字で示されています）を使用して、コンテナランタイムによって割り当てられたプロセス(PID)を確認できます。
コンテナランタイムからPIDを検査する方法
新しいデフォルトのコンテナランタイムは、KubernetesのCRI-Oです。したがって、このドキュメントはコマンドに関するルールの後に続きます。CRI-Oによって割り当てられるプロセスID(PID)は、K8sノード内で一意にすることができます。これは、 crictl 使用できます。
「 ps このオプションは、CRI-Oによってポッドを構築する各コンテナに付与されたIDを表示します。サイトサービスの例では、2つのIDが表示されます。
[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 コマンドにより、WLC CLI で明確に示されます。
[root@MxNDsh01 ~]# crictl inspect fb560763b06f2| grep -i pid
"pid": 239563,
"pids": {
"type": "pid"
コンテナ内でnetwork debugコマンドを実行するためのセンサーの使用方法
上記の出力の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
pingも使用でき、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]
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
27-Feb-2023 |
初版 |
フィードバック