Kubernetesエコシステムの各ツールが解決する問題を理解する

概要¶

Kubernetesエコシステムの各ツールは、Kubernetes単体では解決できなかった具体的な課題を解決するために存在する。「問題 → ツール」の形式で整理した解説。

1日に5つのネームスペースをまたいで kubectl get/describe/logs/exec/delete/apply を50回繰り返すのは遅く、ミスが起きやすい。

K9s または Lens を使うと、ターミナルUIでクラスタ全体を一画面に表示でき、キー1つでネームスペース切り替え、コマンド入力なしでログ追跡が可能になる。

kubectl apply でローカルからデプロイしていると、誰かがクラスタを直接変更したとき、Gitとの差分（ドリフト）がサイレントに発生する。本番障害まで気づかない。

ArgoCD を使うと、GitをSingle Source of Truthとして扱い、すべての変更を自動同期。手動変更があればArgoCDが上書き修正する。

Kafkaコンシューマのバックログが20万件に積み上がっていても、CPUが5%なら HPAはスケールしない。ユーザーは待ち続ける。

KEDA を使うと、キューの深さ・SQSメッセージ数・Prometheusメトリクスに基づいてPodをスケールできる。CPUだけに依存しない。

HPAはPodを増やすが、ノードが満杯なら新しいPodはPending状態のまま。HPAの仕事は終わっているが、クラスタに置き場がない。

Karpenter を使うと、PendingのPodが出た瞬間に新しいノードを数秒で起動し、負荷が下がれば自動削除。使った分だけ課金される。

決済サービスがDBに、内部ツールがログサービスに到達できる状態はデフォルト。侵害されたPodの爆発半径が大きい。

Network Policies を使うと、DBへのアクセスをアプリからのトラフィックのみに限定し、それ以外は拒否できる。

1つのサービスが遅くなるとリトライが積み上がり、他の4サービスにカスケード障害が広がる。どこから始まったかがわからない。

Istio または Linkerd（Service Mesh）を使うと、各Podにサイドカープロキシを配置し、mTLS・リトライ・サーキットブレーカー・トラフィックメトリクスをアプリのコード変更なしに提供する。

kubectl アクセス権があれば誰でもSecretsを読める。VaultやAWS Secrets Managerに移したいが、アプリを書き直したくない。

Secrets Store CSI Driver を使うと、VaultやAWS Secrets ManagerのシークレットをファイルとしてPodに直接マウントできる。KubernetesのSecretとしては保存されない。

開発者がrootで動くコンテナやリソース制限なしのマニフェストをshipしても、インシデントが起きるまで気づかない。

Kyverno を使うと、Admissionの段階でポリシーを強制適用できる。rootコンテナ禁止、ダイジェストなしイメージ禁止、limitsなしDeployment禁止を、クラスタに入る前に弾く。

Podの再起動・レイテンシ急増・メモリ増加が起きていても、数値も履歴もなければ「いつから始まったか」がわからない。

Prometheus + Grafana を使うと、Prometheusが全Pod・ノード・コンポーネントからメトリクスを収集し、Grafanaがダッシュボードで可視化。スパイクが始まった正確な時刻と原因サービスがわかる。

ログはフラグメント、メトリクスは集計値。どのリクエストが最初にどのサービスを叩き、どこで遅くなったかは見えない。

Jaeger を使うと、1つのリクエストが触れたすべてのサービスを追跡し、ホップごとのレイテンシと正確な障害点を表示できる。

このエコシステムは「ツールの一覧」ではなく、Kubernetesが解けなかった問題への回答集として理解するべき。