K8S — Interview Questions I¶

チェック¶

[ ] 本文を確認した
[ ] 概要を確認した
[ ] タグを確認した
[ ] inbox/ 直下へ移行した

概要¶

Kubernetes の面接質問と回答をまとめた記事。 Pod scheduling、OOM、ConfigMap/Secret 更新、Pod の安定性、ClusterIP の負荷分散、ログ収集、livenessProbe、スケーリング、kubectl exec、再起動トラブルシュートなどが扱われる。面接対策だけでなく、Kubernetes 運用の基本確認リストとして使える。

本文¶

記事は Kubernetes の基本動作を問う Q&A 形式。単なる用語暗記ではなく、Pod がどこに置かれるか、コンテナが落ちたときに何が起きるか、設定変更がどう反映されるか、といった実運用寄りの理解を確認している。

Pod はどの Node にスケジュールされるか¶

2 台の Node があり、どちらも空いている場合、Pod はどちらに置かれるか。 Kubernetes scheduler は、単純にランダムに置くのではなく、複数の条件で Node を filter し、score を付けて選ぶ。

考慮される要素には次のようなものがある。

Node の CPU/Memory などの空き resource。
Pod の requests。
nodeSelector / nodeAffinity。
podAffinity / podAntiAffinity。
taints / tolerations。
hostPort の衝突。
volume や zone の制約。
resource quota や policy。

空の Node が複数ある場合、scheduler は負荷分散されるように選ぶことが多いが、実際の配置は scheduler plugin と制約次第。

コンテナが OOM になったら Pod はどうなるか¶

コンテナが memory limit を超えると、そのコンテナは OOMKilled される。 Pod 全体が必ず再作成されるわけではない。 restartPolicy が Always や OnFailure なら、同じ Pod の中でコンテナが再起動される。

複数コンテナ Pod の場合、OOM になったコンテナだけが再起動され、他のコンテナは影響を受けないことがある。ただし、共有 volume や readiness、sidecar 依存があれば、Pod 全体の動作に影響する。

確認するには次を見る。

kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous

exit code 137、Reason OOMKilled、Restart Count を確認する。

ConfigMap / Secret の変更は自動反映されるか¶

ConfigMap や Secret を Pod の環境変数として使っている場合、ConfigMap/Secret を更新しても既存 Pod の環境変数は変わらない。 Pod を再作成する必要がある。

envFrom:
  - configMapRef:
      name: app-config

この場合、Deployment を rollout restart する。

kubectl rollout restart deployment <deployment-name>

一方、ConfigMap/Secret を volume として mount している場合、Kubernetes は一定時間後にファイルを更新する。ただし、アプリケーションがそのファイルを再読み込みするとは限らない。アプリ側に reload 機構が必要。

Reloader のような controller を使い、ConfigMap/Secret の変更を検知して Deployment を再起動する方法もある。

Pod は安定した存在か¶

Pod は Kubernetes で最小の実行単位だが、安定した永続的な存在ではない。 Node 障害、eviction、Deployment の rollout、HPA、手動削除、Cluster Autoscaler による Node 終了などで消える。

Pod IP も固定ではない。安定したアクセス先が必要なら Service を使う。永続データが必要なら PVC を使う。同じ名前や順序が必要なら StatefulSet を使う。

ClusterIP はどう負荷分散するか¶

ClusterIP Service は、クラスタ内の仮想 IP として提供される。 Pod は Service の DNS 名や ClusterIP にアクセスし、kube-proxy が backend Pod へ転送する。

kube-proxy の実装モードには iptables や IPVS がある。 iptables では確率的なルールで backend へ振り分ける。 IPVS では Linux IPVS の load balancing 機能を使う。

Service は TCP/UDP レベルで分散するが、HTTP path や header を見た L7 routing は Ingress や Gateway API、Service Mesh の領域になる。

Kubernetes のログ収集¶

コンテナの stdout/stderr は、Node 上の container runtime によってログファイルとして扱われる。本番では、Fluent Bit、Fluentd、Filebeat などを DaemonSet として動かし、各 Node のログを集めて Elasticsearch、Loki、CloudWatch Logs などへ送る。

ログ損失のリスクもある。 Pod がすぐ落ちる、Node が壊れる、ログ agent が詰まる、出力先が落ちる、ローテーションが早すぎるとログが消える。

重要なログは stdout/stderr に出すだけでなく、集約先の可用性、backpressure、buffer、retention を設計する。

livenessProbe が healthy なら問題ないか¶

livenessProbe が成功していても、アプリケーションに問題がないとは限らない。 liveness は、主に「プロセスを再起動すべきほど壊れているか」を見る。 DB への遅延、外部 API 障害、業務ロジックのバグ、性能劣化、エラー率上昇までは見ないことが多い。

readinessProbe は Service の endpoint に入れるかどうか。 startupProbe は起動が遅いアプリの初期起動を守る。

本当に運用品質を見るには、metrics、logs、traces、SLO、synthetic monitoring が必要。

トラフィック増加時のスケーリング¶

トラフィックが増えた場合のスケーリングには複数の仕組みがある。

HPA は Pod 数を増減する。 CPU/Memory または custom/external metrics を使える。

VPA は Pod の requests/limits を推奨または変更する。ただし、Pod restart が必要になる場合がある。

Cluster Autoscaler は Node 数を増減する。 Pod が Pending になったときに Node Group を増やし、空いている Node を減らす。

KEDA は queue length、Prometheus metrics、cron、外部イベントなどを使って event-driven に Pod をスケールできる。

Service や LoadBalancer は、増えた Pod へ traffic を分散する。

kubectl exec は Pod に入るのか¶

kubectl exec -it <pod> -- bash は Pod に入るというより、Pod 内の特定コンテナでコマンドを実行する。 Pod にコンテナが一つだけなら意識しなくてもよいが、複数コンテナ Pod では -c で対象コンテナを指定する。

kubectl exec -it <pod-name> -c <container-name> -- bash

distroless image などでは shell が入っていないため、bash や sh が使えないこともある。その場合は debug container や kubectl debug を検討する。

Pod の再起動を調査する¶

Pod が何度も再起動している場合、まず状態とイベントを見る。

kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous

見るポイントは、Exit Code、Reason、Restart Count、Events、Probe failure、OOMKilled。

Exit Code 137 なら OOM の可能性が高い。 Exit Code 1 ならアプリケーションエラーや設定ミスを疑う。 ImagePullBackOff ならイメージ名や認証。 CrashLoopBackOff ならログと起動コマンド。

環境変数、ConfigMap、Secret、Command/Args、entrypoint、resource limits、probe 設定、依存サービス、DB 接続、権限を確認する。 Prometheus や Grafana があれば、再起動前後の CPU/Memory、レイテンシ、エラー率も見る。

要点¶

scheduler は resource、affinity、taints、selector、volume、policy を見て Node を選ぶ。
OOMKilled は基本的にコンテナ単位で起き、restartPolicy に応じて再起動される。
環境変数として読んだ ConfigMap/Secret は Pod 再作成まで変わらない。
volume mount の ConfigMap/Secret は更新されるが、アプリの reload が必要。
Pod は ephemeral。安定したアクセスには Service、永続データには PVC を使う。
ClusterIP は kube-proxy の iptables/IPVS で backend Pod へ分散する。
livenessProbe 成功はアプリ全体の健全性を保証しない。
スケーリングは HPA、VPA、Cluster Autoscaler、KEDA を使い分ける。
kubectl exec は Pod 内のコンテナでコマンドを実行する。

タグ¶

kubernetes #interview #troubleshooting #operations #learning¶