はじめに
業務上Kubernetesを用いたアプリケーションのトラブルシューティングをする機会が多く、その際によく使うkubectlコマンドを本記事にて紹介する。また、併せてよく見かけるエラーおよびコマンドを用いたトラブルシューティングの例も紹介する。
なお、パブリッククラウド上のKubernetes（AWS EKS等）のみ経験しているため、その環境を前提とした内容となっている。
※AWS EKS = Amazon Elastic Kubernetes Service
使用頻度の高いkubectlコマンド
1．kubectl get [リソースの種類] [リソース名] [-o yaml]
主にKubernetesのリソース情報確認で使用するコマンド。
getの後にリソースの種類を入力する。
また、リソースの種類の後に単体のリソース名を入力し、さらに「-o yaml」を追加することで単体リソースの設定情報を取得することもできる。
使用頻度が高いリソースの種類は主に以下の通り。
- namespaces
namespace一覧を表示する。
namespaceが作成できたか確認するときなどに使用することが多い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get namespaces
NAME STATUS AGE
default Active 3h27m
kube-node-lease Active 3h27m
kube-public Active 3h27m
kube-system Active 3h27m
- pods (po)
pod一覧を表示する。
Kubernetesへのアプリケーションインストールが完了した後の正常性確認の一部などで使用することが多い。
特に「STATUS」を参照することが多く、サービス起動中にここがRunningやCompleted以外になっていると、サービスが正常でない可能性が高い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get po -n kube-system
NAME READY STATUS RESTARTS AGE
aws-node-jlhhg 2/2 Running 0 3h22m
coredns-7f6d96c6c9-8hd5f 1/1 Running 0 3h25m
coredns-7f6d96c6c9-bswd2 1/1 Running 0 3h25m
ebs-csi-controller-58c5558cff-tc4zz 6/6 Running 29 (150m ago) 162m
ebs-csi-controller-58c5558cff-xxzkm 6/6 Running 29 (150m ago) 162m
ebs-csi-node-x2ctw 3/3 Running 0 162m
eks-pod-identity-agent-twnmm 1/1 Running 0 149m
kube-proxy-65vsw 1/1 Running 0 3h22m
- deployments (deploy)
デプロイ一覧を表示する。
Kubernetes上のアプリケーションではデプロイを使用する機会が多く、podが多いときはデプロイ単位で一覧を確認する場合もある。
また、デプロイでエラーが発生した場合などにおいて、デプロイの設定を表示するために使用する場合もある。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get deploy -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
coredns 2/2 2 2 3h26m
ebs-csi-controller 2/2 2 2 163m
[ec2-user@ip-10-0-9-131 ~]$ kubectl get deploy coredns -n kube-system -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2026-03-29T11:04:21Z"
generation: 1
labels:
eks.amazonaws.com/component: coredns
k8s-app: kube-dns
kubernetes.io/name: CoreDNS
...
- statefulsets (sts)
statefulset一覧を表示する。
DBなど、永続的なストレージ (PersistentVolume) を持つようなイメージを展開している場合に使用する。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get sts -n kube-system
No resources found in kube-system namespace.
※自前の検証環境にstatefulsetがなかったため出力結果は特になし
- services (svc)
サービス一覧を表示する。
Kubernetes内のネットワーク関連 (IPアドレス、DNS名、ロードバランサー等) のリソースを確認する際に使用する。
ネットワーク関連については設定ミスが発生しがちであるため、設定を表示する機会も多い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
eks-extension-metrics-api ClusterIP 172.20.64.53 <none> 443/TCP 3h31m
kube-dns ClusterIP 172.20.0.10 <none> 53/UDP,53/TCP,9153/TCP 3h26m
[ec2-user@ip-10-0-9-131 ~]$ kubectl get svc kube-dns -n kube-system -o yaml
apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/port: "9153"
prometheus.io/scrape: "true"
creationTimestamp: "2026-03-29T11:04:21Z"
labels:
...
spec:
clusterIP: 172.20.0.10
clusterIPs:
- 172.20.0.10
internalTrafficPolicy: Cluster
ipFamilies:
...
- configmaps (cm)
configmap一覧を表示する。
アプリケーションインストール後のエラーにおいてconfigmapの中身を確認する機会は多い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get cm -n kube-system
NAME DATA AGE
amazon-vpc-cni 7 4h14m
aws-auth 1 4h11m
coredns 1 4h14m
extension-apiserver-authentication 6 4h18m
kube-apiserver-legacy-service-account-token-tracking 1 4h18m
kube-proxy 1 4h14m
kube-proxy-config 1 4h14m
kube-root-ca.crt 1 4h18m
[ec2-user@ip-10-0-9-131 ~]$ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
...
- secrets
認証情報の一覧を表示する。
こちらも「-o yaml」オプションで詳細を確認する機会が多い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get secrets -n kube-system
No resources found in kube-system namespace.
※自前の検証環境にsecretがなかったため出力結果は特になし
- events (ev)
Kubernetes内の全てのイベントを表示する。
エラー解析の際に使用する機会が多い。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get events
LAST SEEN TYPE REASON OBJECT MESSAGE
98s Normal Scheduled pod/nginx-deployment-78c44574cd-58v7n Successfully assigned default/nginx-deployment-78c44574cd-58v7n to ip-10-0-157-19.ap-northeast-1.compute.internal
98s Normal Pulling pod/nginx-deployment-78c44574cd-58v7n Pulling image "nginx"
92s Normal Pulled pod/nginx-deployment-78c44574cd-58v7n Successfully pulled image "nginx" in 5.638s (5.638s including waiting). Image size: 62958873 bytes.
92s Normal Created pod/nginx-deployment-78c44574cd-58v7n Container created
92s Normal Started pod/nginx-deployment-78c44574cd-58v7n Container started
98s Normal Scheduled pod/nginx-deployment-78c44574cd-jh6gr Successfully assigned default/nginx-deployment-78c44574cd-jh6gr to ip-10-0-157-19.ap-northeast-1.compute.internal
98s Normal Pulling pod/nginx-deployment-78c44574cd-jh6gr Pulling image "nginx"
92s Normal Pulled pod/nginx-deployment-78c44574cd-jh6gr Successfully pulled image "nginx" in 5.613s (5.613s including waiting). Image size: 62958873 bytes.
92s Normal Created pod/nginx-deployment-78c44574cd-jh6gr Container created
92s Normal Started pod/nginx-deployment-78c44574cd-jh6gr Container started
99s Normal SuccessfulCreate replicaset/nginx-deployment-78c44574cd Created pod: nginx-deployment-78c44574cd-58v7n
98s Normal SuccessfulCreate replicaset/nginx-deployment-78c44574cd Created pod: nginx-deployment-78c44574cd-jh6gr
99s Normal ScalingReplicaSet deployment/nginx-deployment Scaled up replica set nginx-deployment-78c44574cd from 0 to 2
上記出力におけるnginxは以下のURLから取得したテスト用のデプロイとなる。
https://k8s.io/examples/application/nginx-with-request.yaml
- node
Kubernetes内のデータプレーンノードの状態を確認する。
パブリッククラウド上のKubernetes（AWS EKS等）におけるオートスケーリングの動作確認時等に使用する。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get node
NAME STATUS ROLES AGE VERSION
ip-10-0-157-19.ap-northeast-1.compute.internal Ready <none> 4h11m v1.35.2-eks-f69f56f
2．kubectl describe [リソースの種類] [リソース名]
主にリソース単体の詳細情報を確認するためのコマンドであり、エラー解析の際にはとてもお世話になるコマンドその1。
podの詳細情報を確認するために使用することが多かった。
node (データプレーンノード)のCPU・メモリ情報なども確認できるみたいだが、AWS EKSではオートスケーリングでリソースの調整をすることが多かったため、あまり使ったことがない。
podに対する使用例 ※nginx-deployment-78c44574cd-58v7nはPod名
[ec2-user@ip-10-0-9-131 ~]$ kubectl describe pod nginx-deployment-78c44574cd-58v7n
Name: nginx-deployment-78c44574cd-58v7n
Namespace: default
Priority: 0
Service Account: default
Node: ip-10-0-157-19.ap-northeast-1.compute.internal/10.0.157.19
Start Time: Sun, 29 Mar 2026 18:03:36 +0000
Labels: app=nginx
pod-template-hash=78c44574cd
topology.kubernetes.io/region=ap-northeast-1
topology.kubernetes.io/zone=ap-northeast-1c
Annotations: <none>
Status: Running
IP: 10.0.155.246
IPs:
IP: 10.0.155.246
Controlled By: ReplicaSet/nginx-deployment-78c44574cd
Containers:
nginx:
Container ID: containerd://******
Image: nginx
Image ID: docker.io/library/nginx@sha256:******
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sun, 29 Mar 2026 18:03:42 +0000
Ready: True
Restart Count: 0
Limits:
cpu: 500m
memory: 128Mi
Requests:
cpu: 500m
memory: 128Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-9lpg8 (ro)
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-9lpg8:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: Guaranteed
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 31s default-scheduler Successfully assigned default/nginx-deployment-78c44574cd-58v7n to ip-10-0-157-19.ap-northeast-1.compute.internal
Normal Pulling 31s kubelet Pulling image "nginx"
Normal Pulled 25s kubelet Successfully pulled image "nginx" in 5.638s (5.638s including waiting). Image size: 62958873 bytes.
Normal Created 25s kubelet Container created
Normal Started 25s kubelet Container started
出力内容においてよく見るポイントは以下の通り。
- Image
コマンド対象Podが実行しているコンテナイメージの参照先。
参照先のURLやディレクトリが間違っていて、イメージの取得に失敗することが多かったため、見る機会が多かった。 - Conditions
コマンド対象Podの詳細なステータスを確認できる。
例えば出力内容において、Conditions配下のInitializedがFalseになっている場合、Podの初期化が失敗していることがわかり、どの段階でエラーが発生しているのかが分かる。 - Events
コマンド対象Podのイベント内容を確認できる。
コンテナイメージのpullに成功した・失敗したなど、Podで何が起きているのかが分かりやすく表示されている。
「Message」の部分にエラーの原因が記載されていることが多い。
kubectl get events ではKubernetes上の全てのイベントを表示していたのに対して、こちらでは特定のリソースのイベントのみを表示できる。
3．kubectl logs [リソース名]
主にリソースの内部で出力されているログを確認するためのコマンドであり、エラー解析の際にはとてもお世話になるコマンドその2。
Podに対して実行することが多く、イベントに出てこないコンテナ内部の詳細なログを確認することができる。
Podに対する使用例 ※nginx-deployment-78c44574cd-58v7nはPod名
[ec2-user@ip-10-0-9-131 ~]$ kubectl logs nginx-deployment-78c44574cd-58v7n
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/03/29 18:03:42 [notice] 1#1: using the "epoll" event method
2026/03/29 18:03:42 [notice] 1#1: nginx/1.29.7
2026/03/29 18:03:42 [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19)
2026/03/29 18:03:42 [notice] 1#1: OS: Linux 6.12.73-95.123.amzn2023.x86_64
2026/03/29 18:03:42 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 65536:1048576
2026/03/29 18:03:42 [notice] 1#1: start worker processes
2026/03/29 18:03:42 [notice] 1#1: start worker process 29
2026/03/29 18:03:42 [notice] 1#1: start worker process 30
2026/03/29 18:03:42 [notice] 1#1: start worker process 31
2026/03/29 18:03:42 [notice] 1#1: start worker process 32
4．kubectl edit [リソースの種類] [リソース名]
Kubernetes上のリソースの設定を変更するためのコマンドであり、検証時のちょっとした設定変更で使用することが多い。
設定を直接その場で変更するため、本番環境での設定変更で使用するのは非推奨となる。
本番環境での設定変更は、後述するkubectl applyの使用を推奨する。
5．kubectl apply -f [マニフェストファイルのパス]
マニフェストファイル (Kubernetesにおける設定ファイルのようなもの) をKubernetesに適用するコマンドであり、これにより新しいリソースの作成または設定変更を実行することができる。
設定内容の全てがマニフェストファイルに記載されるため、マニフェストファイルをバージョン管理しておくことで、マニフェストファイルで作成されるKubernetesリソースの設定変更履歴を追うことができる。
そのため、本番環境での設定変更は、可能な限りマニフェストファイルを用いてapplyで適用することが推奨される。
以下はサンプルのマニフェストファイル「nginx-with-request.yaml」を用いたkubectl apply によるDeployment作成の例となる。
[ec2-user@ip-10-0-9-131 ~]$ kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
deployment.apps/nginx-deployment created
[ec2-user@ip-10-0-9-131 ~]$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deployment-78c44574cd-58v7n 1/1 Running 0 11s
nginx-deployment-78c44574cd-jh6gr 1/1 Running 0 10s
よく見かけるエラー
kubectl get podsの出力内容のうちの「STATUS」で確認できるエラーにおいて、よく見かけるエラーは以下の3つ。
1．ImagePullBackOffまたはErrImagePull
これらはイメージのpullに失敗しているときに表示される。
主な原因として、イメージ参照先の設定ミス、ネットワーク経路の疎通問題、イメージ参照のための認証情報の設定ミス等が挙げられる。
このエラーが発生した時は、以下を確認することにしている。
- kubectl describe pod [pod名] でイメージ参照先を確認
- イメージ参照先にイメージが配置されているか確認
- イメージ参照先までのネットワーク経路で疎通が取れるかを確認
- kubectl get secret [対象secret名] -o yaml でイメージ取得に使用している認証情報があれば確認し、設定ミスがないかを確認
2．CrashLoopBackOff
こちらはPodがエラーで落ちて再起動を繰り返しているときに表示される。
イメージはpull出来てPodの起動まではできているが、何らかのエラーにより起動後にPodがクラッシュしているため、そのエラーの原因を取り除く必要がある。
このエラーが発生した時は、以下を確認することにしている。
- kubectl describe pod [pod名] でEventsを確認し、Messageにエラーの原因が表示されていないか確認
- kubectl logs [リソース名] でPod単体のログを表示し、エラーの原因が表示されていないか確認
3．Pending
こちらはPodのコンテナを起動できる場所が見つかっていない状態のときに表示される。
主にPodを起動するためのコンピュータリソースが用意できていないときに表示されることが多く、自身の経験上、以下の2つが要因になるケースが多かった。
- オートスケーリングの最小ノード数・最大ノード数の設定ミス
想定したノード数以上のコンピュータリソースが必要となり、Pod起動のためのスケーリングが実行できなくなったことによりPending状態になる - 永続的ボリューム (PV) の割り当て時のエラー
Podに割り当てるPVが何らかのエラーにより割り当てらず、ストレージ不足となりPending状態になる
Pending状態の場合の確認観点はCrashLoopBackOffの時と同様であり、PodのEventsおよびログを確認することにしている。特にPending状態の場合はEventsに原因が表示されているケースが多かった。
トラブルシューティング例
以下は自前の検証環境で実施したトラブルシューティングの例となる。
1．発生した事象
AWS EKSを構築した後、アドオンをインストールしたところ、「AWS EBS CSIドライバー」のインストールが失敗した。
アドオンはKubernetes上にPodやDeploymentとしてインストールされる仕様となっており、Podのステータスは以下のように「ebs-csi-controller」のPodがCrashLoopBackOffとなっていた。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get po -n kube-system
NAME READY STATUS RESTARTS AGE
aws-node-jlhhg 2/2 Running 0 35m
coredns-7f6d96c6c9-8hd5f 1/1 Running 0 39m
coredns-7f6d96c6c9-bswd2 1/1 Running 0 39m
ebs-csi-controller-5c474c6bb8-2s6p9 1/6 CrashLoopBackOff 55 (37s ago) 34m
ebs-csi-controller-5c474c6bb8-8r68r 1/6 CrashLoopBackOff 55 (57s ago) 34m
ebs-csi-node-5rnpf 3/3 Running 0 34m
kube-proxy-65vsw 1/1 Running 0
2．原因の調査
初めにkubectl describe pod [pod名] でエラーが発生しているPodのEventsを確認した。
[ec2-user@ip-10-0-9-131 ~]$ kubectl describe pod ebs-csi-controller-5c474c6bb8-2
Name: ebs-csi-controller-5c474c6bb8-2s6p9
Namespace: kube-system
Priority: 2000000000
Priority Class Name: system-cluster-critical
Service Account: ebs-csi-controller-sa
Node: ip-10-0-157-19.ap-northeast-1.compute.internal/10.0.157.19
Start Time: Sun, 29 Mar 2026 11:09:14 +0000
Labels: app=ebs-csi-controller
app.kubernetes.io/component=csi-driver
app.kubernetes.io/managed-by=EKS
app.kubernetes.io/name=aws-ebs-csi-driver
app.kubernetes.io/version=1.57.1
pod-template-hash=5c474c6bb8
topology.kubernetes.io/region=ap-northeast-1
topology.kubernetes.io/zone=ap-northeast-1c
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 29m default-scheduler Successfully ass
Normal Pulling 29m kubelet Pulling image "6
Normal Pulled 29m kubelet Successfully pul
Normal Created 29m kubelet Container create
Normal Started 29m kubelet Container starte
Normal Pulling 29m kubelet Pulling image "6
Normal Pulled 29m kubelet Successfully pul
Normal Started 29m kubelet Container starte
Normal Pulling 29m kubelet Pulling image "6
Normal Pulled 29m kubelet Successfully pul
Normal Pulling 29m kubelet Pulling image "6
Normal Created 29m kubelet Container create
Normal Started 29m kubelet Container starte
Normal Started 29m kubelet Container starte
Normal Created 29m kubelet Container create
Normal Pulled 29m kubelet Successfully pul
Normal Pulling 29m kubelet Pulling image "6
Normal Started 29m kubelet Container starte
Normal Pulled 29m kubelet Successfully pul
Normal Created 29m kubelet Container create
Normal Started 29m kubelet Container starte
Normal Pulled 29m kubelet Container image
Normal Created 29m kubelet Container create
Normal Pulled 29m kubelet Container image
Normal Created 29m (x2 over 29m) kubelet Container create
Warning BackOff 29m (x4 over 29m) kubelet Back-off restart
Warning BackOff 29m (x4 over 29m) kubelet Back-off restart
Warning BackOff 29m (x4 over 29m) kubelet Back-off restart
Warning BackOff 29m (x4 over 29m) kubelet Back-off restart
Warning Unhealthy 24m (x30 over 29m) kubelet Liveness probe f
Warning BackOff 8m51s (x12 over 17m) kubelet Back-off restart
Normal Pulled 7m37s (x7 over 25m) kubelet Container image
Warning Unhealthy 4m18s (x124 over 29m) kubelet Readiness probe
Normal Killing 4m11s (x10 over 27m) kubelet Container ebs-pl
※ログ収集が上手くできなかったため、Messageが途中で途切れている
describeの内容だけでは、CrashLoopBackOffの原因が分からなかったため、次にkubectl logs [リソース名] でエラーが発生しているPodのログを確認した。
[ec2-user@ip-10-0-9-131 ~]$ kubectl logs ebs-csi-controller-5c474c6bb8-2s6p9 -n kube-system
Defaulted container "ebs-plugin" out of: ebs-plugin, csi-provisioner, csi-attacher, csi-snapshotter, csi-resizer, liveness-probe
I0329 11:41:25.447765 1 main.go:168] "Region provided via AWS_REGION environment variable" region="ap-northeast-1"
I0329 11:41:25.448647 1 envvar.go:172] "Feature gate default state" feature="WatchListClient" enabled=true
I0329 11:41:25.448787 1 envvar.go:172] "Feature gate default state" feature="ClientsAllowCBOR" enabled=false
I0329 11:41:25.448796 1 envvar.go:172] "Feature gate default state" feature="ClientsPreferCBOR" enabled=false
I0329 11:41:25.448802 1 envvar.go:172] "Feature gate default state" feature="InOrderInformers" enabled=true
I0329 11:41:25.448808 1 envvar.go:172] "Feature gate default state" feature="InOrderInformersBatchProcess" enabled=true
I0329 11:41:25.448813 1 envvar.go:172] "Feature gate default state" feature="InformerResourceVersion" enabled=true
I0329 11:41:25.449481 1 driver.go:92] "Driver Information" Driver="ebs.csi.aws.com" Version="v1.57.1"
...
E0329 11:43:05.176591 1 driver.go:133] "GRPC error" err="rpc error: code = FailedPrecondition desc = Failed health check (verify network connection and IAM credentials): dry-run EC2 API call failed: operation error EC2: DescribeAvailabilityZones, https response error StatusCode: 403, RequestID: 3e934ab0-88e0-419d-9e79-2d509800e66c, api error UnauthorizedOperation: You are not authorized to perform this operation. User: arn:aws:sts::************:assumed-role/eksctl-eks-test-nodegroup-eks-node-NodeInstanceRole-****/i-**** is not authorized to perform: ec2:DescribeAvailabilityZones because no identity-based policy allows the ec2:DescribeAvailabilityZones action"
最後の行を見ると、
「not authorized to perform: ec2:DescribeAvailabilityZones because no identity-based policy allows the ec2:DescribeAvailabilityZones action」
の文言があり、このPodを実行するにあたってAWS上の「ec2:DescribeAvailabilityZones」の権限が足りずにエラーが発生していることが判明した。
そのため、今回のエラーの原因は、アドオンをインストールする際に適切なAWS IAM Roleを付与できていなかったことであると分かった。
3．原因の解消および正常性確認
AWSコンソール上でAWS EBS CSIドライバーに割り当てるIAM Roleを設定できるので、そこで適切なRoleを付与した。
以下はAWS EKSにおけるクラスター上のアドオン設定一覧内のAWS EBS CSIドライバーの設定画面となる。
画面上の「EKS Pod Identity」にて新たにRole「AmazonEKSPodIdentityAmazonEBSCSI_test_Role」を付与している。
このロールには、今回のエラーログで表示されていた「ec2:DescribeAvailabilityZones」の権限を含まれている。
※その他にも色々権限が足りなかったので、併せてこのロールにそれらの権限を追加している
上記の対応後に再度Podのステータスを確認したところ、無事にRunningとなり、事象の解決を確認できた。
[ec2-user@ip-10-0-9-131 ~]$ kubectl get po -n kube-system
NAME READY STATUS RESTARTS AGE
aws-node-jlhhg 2/2 Running 0 71m
coredns-7f6d96c6c9-8hd5f 1/1 Running 0 75m
coredns-7f6d96c6c9-bswd2 1/1 Running 0 75m
ebs-csi-controller-58c5558cff-tc4zz 6/6 Running 29 (19m ago) 32m
ebs-csi-controller-58c5558cff-xxzkm 6/6 Running 29 (19m ago) 32m
ebs-csi-node-x2ctw 3/3 Running 0 32m
eks-pod-identity-agent-twnmm 1/1 Running 0 18m
kube-proxy-65vsw 1/1 Running 0 71m
まとめ
Kubernetes上で使用頻度の高いkubectlコマンド、よく見かけるエラー、およびトラブルシューティング例を紹介した。
特にkubectlコマンドについては、自身がトラブルシューティングで使用する機会が多かったものを挙げており、これらを覚えておくことである程度のトラブルについては原因の特定ができるようになる。
Kubernetesは結構覚えることが多いため、今後も今回のような自身の経験を踏まえた内容を備忘録として残していきたい。
参考文献
[1] テスト用のマニフェストファイル https://k8s.io/examples/application/nginx-with-request.yaml , アクセス: 2026-03-30.