Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Kubernetesの基礎.pdf
yosshi_
March 25, 2019
Technology
22
13k
Kubernetesの基礎.pdf
yosshi_
March 25, 2019
Tweet
Share
More Decks by yosshi_
See All by yosshi_
Getting Started with Kubernetes Observability
yosshi_
6
1k
PromQL_Compatibility_Testing_Recap
yosshi_
0
520
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
6
2.1k
これから学ぶKubernetesのReconciliation Loop
yosshi_
8
1.7k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
12
4.6k
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
0
94
“Running Apache Samza on Kubernetes” Recap : KubeCon2019@NA
yosshi_
3
920
Kuberntes_Monitoring_入門.pdf
yosshi_
17
2.5k
Kubernetes_Logging入門.pdf
yosshi_
14
6.1k
Other Decks in Technology
See All in Technology
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
0
540
Who owns the Service Level?
chaspy
5
660
A Conditional Point Diffusion-Refinement Paradigm for 3D Point Cloud Completion
takmin
0
170
5分で完全理解するGoのiota
uji
3
1.7k
Power BI ”を” 可視化しよう!
hanaseleb
0
140
THETA Xの登場はジオ業界を変えるか?
furuhashilab
0
150
Nutanix_Meetup_20220511
keigotomomatsu
0
140
[SRE NEXT 2022]ヤプリのSREにおけるセキュリティ強化の取り組みを公開する
mmochi23
1
240
GitHub 엔터프라이즈 어카운트 소개 및 엔터프라이즈 서버 구축 경험
posquit0
1
130
株式会社オプティム_採用会社紹介資料 / optim-recruit
optim
0
5.2k
如何使用 Argo Event& Workflow 快速建置自定義的工作流程 @ #CNTUG #47
line_developers_tw
PRO
0
370
インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」
cyberblack28
9
6.2k
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
229
9.3k
YesSQL, Process and Tooling at Scale
rocio
157
12k
Making the Leap to Tech Lead
cromwellryan
113
6.9k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.2k
Music & Morning Musume
bryan
35
4.1k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
125
8.5k
KATA
mclloyd
7
8.6k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
Design by the Numbers
sachag
271
17k
Building Flexible Design Systems
yeseniaperezcruz
310
33k
Product Roadmaps are Hard
iamctodd
34
6.1k
How STYLIGHT went responsive
nonsquared
85
3.9k
Transcript
ç Kubernetes基礎 NTT Tech Conference#4 @yosshi_
• 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •
Kubernetes 、Prometheus etc • 登壇 CNDT “Kubernetes Logging入門” etc • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
今日話す内容 • Kubernetesの全体像 – Cluster – kubectl • 基本的な構成要素 –
Workload – Configuration – Discovery & LB – Metadata • kubectlによるオペレーション – Manifestを中心にしたオペレーション – よく使うkubectl
Kubernetesの全体像
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl これを 今から説明します API Server経由でetcdの操作を行い、etcdの状態に応じてアクションする
Infrastructure components • Master – k8sを管理するコンポーネントが配置されるサーバ群 • Node – コンテナが配置されるサーバ群
• etcd cluster – コンテナが配置されるサーバ群高信頼性KVS、k8sのデータが保存される
Master components • API Server – etcdへのwrite、readを行うAPIサーバ – 複数台配置して冗長化構成をとることができる •
Controller Manager – デプロイするコンテナの個数等を管理する – 複数台配置できるがリーダは1つだけ • Scheduler – コンテナをどのNodeにデプロイするか決める – 複数台配置できるがリーダは1つだけ
Node components • Container runtime – 文字通りコンテナのランタイム – Docker以外を使用することもできる •
Kubelet – Node上に配置されるエージェント – コンテナの起動停止等を行う • Kube-proxy – コンテナとの接続を保証するためにNodeのNWを管理する
kubectl • kubectl – ユーザがk8sを操作する際に使う – 詳細は後述
参考:MasterとControl Plane componentsの違い API Server Scheduler Controller Manager Kubelet Kube-proxy
API Server Scheduler Controller Manager 参照 < https://kubernetes.io/docs/concepts/architecture/master-node-communication/ > こんなニュアンスが多そうだか その限りでもなさそうで困る Master to Clusterの通信とかなんだよ・・ • Control Plane components – k8sを管理するコンポーネントが配置されるサーバ群 • Master – k8sを管理するコンポーネントが配置されるサーバ群
参考:Master Nodeの中身 Controller Manager Kubelet Container runtime API Server Scheduler
Master Control Planeもコンテナだったりする
Kubeadmで構築時のMaster $ systemctl status docker • docker.service - Docker Application
Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-03-24 01:04:19 UTC; 23h ago Docs: https://docs.docker.com Main PID: 1229 (dockerd) Tasks: 211 Memory: 874.2M CPU: 39min 29.172s CGroup: /system.slice/docker.service ├─1229 /usr/bin/dockerd -H fd:// ├─1254 docker-containerd --config /var/run/docker/containerd/containerd.toml ├─2820 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/808fb・・・ ├─2822 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/2f33b・・・ $ systemctl status kubelet • kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-03-24 01:05:58 UTC; 23h ago Docs: https://kubernetes.io/docs/home/ Main PID: 2691 (kubelet) Tasks: 17 Memory: 75.0M CPU: 48min 37.605s CGroup: /system.slice/kubelet.service └─2691 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubel・・・ API Server Controller Manager Scheduler ①Dockerの起動 ②Kubeletの起動 ③ Control Plane componentsが コンテナとして起動
参考:systemctlで“kubelet”を確認する (1/4) $ systemctl status kubelet • kubelet.service - kubelet:
The Kubernetes Node Agent Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) since Sun 2019-07-21 03:13:41 UTC; 2 days ago Docs: https://kubernetes.io/docs/home/ Main PID: 17633 (kubelet) Tasks: 18 (limit: 4915) CGroup: /system.slice/kubelet.service └─17633 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driv 起動時にこのconfigを読んでる
参考:systemctlで“kubelet”を確認する (2/4) $ cat /var/lib/kubelet/config.yaml address: 0.0.0.0 apiVersion: kubelet.config.k8s.io/v1beta1 authentication:
anonymous: enabled: false : : serializeImagePulls: true staticPodPath: /etc/kubernetes/manifests streamingConnectionIdleTimeout: 4h0m0s syncFrequency: 1m0s volumeStatsAggPeriod: 1m0s 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ > Static Pods機能を使うと 起動時に指定したmanifestに書かれたPodを 起動することができる
参考:systemctlで“kubelet”を確認する (3/4) $ ls /etc/kubernetes/manifests etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml kubelet起動時にStaticPodsで指定した
Control Plane ComponentsのPodが立つことでKubernetesとして機能している 参考< https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ >
参考systemctlで“kubelet”を確認する (4/4) $ cat /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1 kind: Pod metadata:
creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: : : 中身は普通のyaml
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl API Server経由でetcdの操作を行い、etcdの状態に一致するようにk8sが変更される
参考:API Serverからetcdにいかない例外の4パターン • “/proxy” – API Serverとの間にproxyをはる • “/exec” –
コンテナでコマンドで実行 • “/attach” – コンテナにattach • “/logs” – コンテナのログを取得 “logs”の場合の通信 Mnaging Kubernetes
Kuberntes(k8s)の全体像 k8s Cluster node master API Server etcd cluster Controller
Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ node Kubelet Kube-proxy Container runtime コンテナ Kubectl マネージドサービスを使うと だけ考えれば良いことが多い オンプレミスだとこれら全てを理解して保証する必要がある
基本的な構成要素
構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod
generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > :今日話す範囲
構成要素の全体像 Resources mgt Network / exposition Configuration Storage IAM Pod
generator Creates References Kubernetes Ressources Map 参考< https://github.com/kubernetes/community/tree/master/icons > :今日話す範囲 ① コンテナの制御 ② コンテナのConfig ③ NW ④ 仮想ク ラスタ 権限制御 ストレージ リソース制限
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Workload
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース
Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース :今日話す範囲
Pod(po) • コンテナのデプロイの最小単位 – 1個のPodに複数のコンテナを定義できる(Sidecar) – 定義された複数のコンテナは必ず同一のNodeにデプロイされる – 複数のコンテナは同一のIPアドレスを共有 node
Kubelet Kube-proxy node Kubelet Kube-proxy コンテナB コンテナA Pod 必ずPod単位でNodeにデプロイされる
Pod(po) コンテナB コンテナA Pod $ kubectl get po –o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-deployment-756bf884bf-gr6qt 2/2 Running 0 10s 10.244.1.2 worker01 <none> <none> spec: containers: - name: nginx1 image: nginx:1.7.9 - name: nginx2 image: nginx:1.7.9 Podの定義 k8s Clusterの状態 NIC Podの中にコンテナが 2個あることが分かる Pod単位にNICが1個ある Podをデプロイすると
ReplicaSet(rs) コンテナA Pod app: nginx 1個のPodにLabelを複数付与できるので、目的の違う PodのLabelの組み合わせが被らないように設計しよう コンテナA Pod app:
nginx コンテナA Pod app: nginx ReplicaSet “replicas: 3” Label Selector ”app: nginx” Podが死んだ場合でも 個数が3になるように管理する • デプロイしたPod数を維持するリソース – Podに付与されているlabelを意識してReplicaSetが制御する
ReplicaSet(rs) kubectl get rs,po -o wide NAME DESIRED CURRENT READY
AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-76fbb7bd7b 3 3 3 6s nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 6s 10.244.2.9 worker02 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 6s 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Running 0 6s 10.244.1.9 worker01 <none> <none> spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx1 image: nginx:1.7.9 ReplicaSetの定義 k8s Clusterの状態 同一のreplicasetの管理下で あることが分かる ReplicaSetをデプロイすると ReplicaSetで管理するPodのLabel Podに付与するLabel ReplicaSetのLabel Selector
Deployment(deploy) コンテナA Pod ReplicaSet 旧 コンテナA Pod コンテナA’ Pod ReplicaSet
新 コンテナA’ Pod Deployment 新しいReplicaSetが作られて Podも順次作られる 旧のReplicaSetのreplicas の数が減って Podも順次削除される • RollingUpdateするためにReplicaSetを管理するリソース
Deployment(deploy) kubectl get deploy,rs,po -o wide NAME READY UP-TO-DATE AVAILABLE
AGE CONTAINERS IMAGES SELECTOR deployment.extensions/nginx-deployment 3/3 3 3 118m nginx1 nginx:1.12 app=nginx NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR replicaset.extensions/nginx-deployment-5fbf59df75 2 2 1 3s nginx1 nginx:1.12 app=nginx,pod-template-hash=5fbf59df75 replicaset.extensions/nginx-deployment-76fbb7bd7b 2 2 2 114m nginx1 nginx:1.7.9 app=nginx,pod-template-hash=76fbb7bd7b NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 0/1 ContainerCreating 0 1s <none> worker03 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 3s 10.244.1.10 worker01 <none> <none> pod/nginx-deployment-76fbb7bd7b-9rhdr 1/1 Running 0 114m 10.244.2.9 worker02 <none> <none> pod/nginx-deployment-76fbb7bd7b-kdsfl 1/1 Running 0 114m 10.244.3.9 worker03 <none> <none> pod/nginx-deployment-76fbb7bd7b-x566n 1/1 Terminating 0 114m 10.244.1.9 worker01 <none> <none> k8s Clusterの状態 Podの削除と新規作成が 順次行われる imageを変更してデプロイ “1.7.9” -> “1.12” spec: containers: - name: nginx1 image: nginx:1.12 新しいReplicaSetが作られる Deploymentの定義
Workloadの一覧 名前 略称 説明 Pod - コンテナのデプロイの最小単位 ReplicaSet rs デプロイしたPod数を維持するリソース
Deployment deploy RollingUpdateするためにReplicaSetを管理するリソース DaemonSet ds 各Nodeに1個ずつPodをデプロイするリソース StatefulSet sts Statefulなコンテナのデプロイに対応したリソース Job - Job用のコンテナをデプロイするリソース CronJob - Jobをcron実行するリソース :今日話す範囲
参考:WorkLoadのリソースの関係 Deployment CronJob ReplicaSet StatefulSet Pod DaemonSet Job Pod Pod
Pod StatefulSetがReplicaSetを操作してたりするわけじゃない Kuberntes完全ガイド
Configuration
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Configurationの一覧 名前 説明 Configmap 設定情報をkey-valueの形式で保持するリソース Sercret 機密情報を保持するリソース
ConfigMap • 設定情報をkey-valueの形式で保持するリソース • 作り方 – Manifestを書く – ファイルから作る (–frome-file,kustomize:configMapGenerator)
• 使い方 – 環境変数とする – Volumeとしてマウントする apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very ConfigMapの定義 Podの定義
Sercretの一覧 種類 説明 opaque Key-valueで機密情報を保持する kubernetes.io/service-account-token サービスアカウント用の機密情報を保持する kubernetes.io/dockerconfigjson Dockerレジストリ用の機密情報を保持する kubernetes.io/basic-auth
Basic認証用の機密情報を保持する kubernetes.io/ssh-auth SSH用の機密情報を保持する kubernetes.io/tls TLS用の機密情報を保持する 参考< https://docs.koki.io/short/resources/secret/ > :今日話す範囲
Sercret”Type:Opaque”について • Key-valueの形式で機密情報を保持する – 扱い方はConfigmap • Configmapと違い – 値がBASE64エンコードされる –
ディスクではなく、tmpfsに配置される – リソースタイプがConfigmapではなくSecret
Sercret”Type:Opaque”について • 使う目的 – ID,Password等を格納する (例えばDBのアクセス用のとか) • 使い方 – secretに対して特定のユーザを除き”Get”、”List”の権限を与えない
– Gitで管理するときにConfigmapとは管理方法を分ける Configmapとは別のリソースタイプなのでそれぞれ別の権限管理を 行えることに意味がある。 名前から受ける印象じゃなくて 仕様を理解して使うことが大事
Discovery & LB
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
ClusterIP コンテナ B Pod ClusterIP コンテナA Pod コンテナ B Pod
コンテナ B Pod LBされる 10.244.1.10 10.244.1.10 Service名で アクセスする 10.244.2.10 10.244.3.10 アプリがDBにアクセスするときもよく使う • クラスタ内のアクセスを保証する – クラスタ内のPodへアクセスをLBする – Service名で名前解決してクラスタ内のPodへアクセスする LabelとSelectorの仕組みにより IPアドレスの管理から解放される
NodePort • クラスタ外からクラスタのPortを指定してアクセスする – クラスタの全てのNodeの特定のPortへのアクセスをPodへ保証する
Serviceのデプロイ kubectl get svc,po -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP
PORT(S) AGE SELECTOR service/svc-sample NodePort 10.110.100.22 <none> 8080:31706/TCP 17s app=nginx NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> NodePortをデプロイする apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx NodePortが確認できる NodePortでも ClusterIPが付与される
Describeで、より詳細を見てみる kubectl describe svc svc-sample Name: svc-sample Namespace: default Labels:
<none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"svc-sample","namespace":"defaultSelector: app=nginxType: NodePortIP: 10.110.100.22 Port: http-port 8080/TCP TargetPort: 80/TCP NodePort: http-port 31706/TCP Endpoints: 10.244.1.10:80,10.244.2.10:80,10.244.3.10:80 Session Affinity: None External Traffic Policy: Cluster Events: <none> k8s Clusterの状態 ServiceとPodが対応してることがわかる kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-deployment-5fbf59df75-55j5b 1/1 Running 0 83m 10.244.3.10 worker03 <none> <none> pod/nginx-deployment-5fbf59df75-6hnbq 1/1 Running 0 83m 10.244.2.10 worker02 <none> <none> pod/nginx-deployment-5fbf59df75-fwqpn 1/1 Running 0 83m 10.244.1.10 worker01 <none> <none> NodePortが確認できる
kubeadm config view kubeadm config view apiServer: extraArgs: authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s apiVersion: kubeadm.k8s.io/v1beta1 certificatesDir: /etc/kubernetes/pki clusterName: kubernetescontrolPlane Endpoint: "“ controllerManager: {} dns: type: CoreDNSetcd: local: dataDir: /var/lib/etcdimageRepository: k8s.gcr.io kind: ClusterConfiguration kubernetesVersion: v1.13.4 networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 scheduler: {} k8s Clusterの状態 PodとServiceはNWが別
Metadata
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図
Namespace • 1つのクラスタの中を仮想のクラスタで分けることができる • 使い方 – 商用、検証、開発環境で1つのクラスタの中で分ける – 開発チーム単位で分ける –
あるプロダクト単位で分ける – etc Namespace単位で分けてもクラスタ全体に対する障害については影響を受ける 爆発半径はクラスタ単位で分けた方が小さいが、クラスタ管理コストが増える傾向にある
Workload Configuration Discovery & LB Deployment ReplicaSet Pod Service Secret
ConfigMap k8s Cluster Namespace 今日話す基本的な構成要素の全体図(復習)
kubectl
Manifestを中心にしたオペレーション apiVersion: v1 kind: Servicemetadata: name: svc-sample spec: type: NodePort
ports: - name: "http-port“ protocol: "TCP“ port: 8080 targetPort: 80 selector: app: nginx Kubectl API Server k8s Cluster • 基本的にManifestを作成してk8sを操作する – 他のやり方も可能だが状態が観測できなくなる – git等でManifestを管理することでk8sの状態を把握しやすくなる
よく使うkubectlコマンド 種類 説明 kubectl apply リソースを作成する kubectl delete リソースを削除する kubectl
get Node pod などのリソースの情報を取得 kubectl describe リソースの詳細情報を取得 kubectl logs コンテナのログを確認する kubectl exec コンテナでコマンドを実行する
参考:書籍 しくみがわかるKuberntes Kubernetes実践入門 Mnaging Kubernetes Kuberntes完全ガイド