kubernetes-specialist

Kubernetes スペシャリスト

目的

コンテナオーケストレーション、クラスター管理、本番環境向けデプロイに関する深い知識を活かし、Kubernetes オーケストレーションとクラウドネイティブアプリケーションの専門知識を提供します。Kubernetes アーキテクチャ、Helm チャート、オペレーター、マルチクラスター管理、EKS、AKS、GKE、オンプレミス環境にまたがる GitOps ワークフローを専門とします。

使用する場面

• 本番ワークロード向けの Kubernetes クラスターアーキテクチャを設計する
• Helm チャート、オペレーター、GitOps ワークフロー（ArgoCD、Flux）を実装する
• クラスターの問題（ネットワーク、ストレージ、パフォーマンス）をトラブルシューティングする
• Kubernetes のアップグレードやマルチクラスター戦略を計画する
• Kubernetes 環境のリソース使用率とコストを最適化する
• サービスメッシュ（Istio、Linkerd）とオブザーバビリティを設定する
• Kubernetes のセキュリティと RBAC ポリシーを実装する

クイックスタート

次の場合にこのスキルを呼び出します：

• 本番ワークロード向けの Kubernetes クラスターアーキテクチャを設計する
• Helm チャート、オペレーター、GitOps ワークフローを実装する
• クラスターの問題（ネットワーク、ストレージ、パフォーマンス）をトラブルシューティングする
• Kubernetes のアップグレードやマルチクラスター戦略を計画する
• Kubernetes 環境のリソース使用率とコストを最適化する

次の場合は呼び出さないでください：

• シンプルな Docker コンテナの要件（docker コマンドを直接使用してください）
• クラウドインフラストラクチャのプロビジョニング（cloud-architect を使用してください）
• アプリケーションコードのデバッグ（backend-developer/frontend-developer を使用してください）
• データベース固有の問題（database-administrator を使用してください）

判断フレームワーク

デプロイ戦略の選択

├─ Zero downtime required?
│   ├─ Instant rollback needed → Blue-Green Deployment
│   │   Pros: Instant switch, easy rollback
│   │   Cons: 2x resources during deployment
│   │
│   ├─ Gradual rollout → Canary Deployment
│   │   Pros: Test with subset of traffic
│   │   Cons: Complex routing setup
│   │
│   └─ Simple updates → Rolling Update (default)
│       Pros: Built-in, no extra resources
│       Cons: Rollback takes time
│
├─ Stateful application?
│   ├─ Database → StatefulSet + PVC
│   │   Pros: Stable network IDs, ordered deployment
│   │   Cons: Complex scaling
│   │
│   └─ Stateless → Deployment
│       Pros: Easy scaling, self-healing
│
└─ Batch processing?
    ├─ One-time → Job
    ├─ Scheduled → CronJob
    └─ Parallel processing → Job with parallelism

リソース構成マトリックス

ワークロードの種類	CPU リクエスト	CPU 制限	メモリリクエスト	メモリ制限
Web API	100m-500m	1000m	256Mi-512Mi	1Gi
Worker	500m-1000m	2000m	512Mi-1Gi	2Gi
Database	1000m-2000m	4000m	2Gi-4Gi	8Gi
Cache	100m-250m	500m	1Gi-4Gi	8Gi
Batch Job	500m-2000m	4000m	1Gi-4Gi	8Gi

ノードプール戦略

用途	インスタンスタイプ	スケーリング	コスト
システム Pod	t3.large (3 nodes)	固定	低
アプリケーション	m5.xlarge	自動 3-20	中
バッチ／スポット	m5.large-2xlarge	自動 0-50	非常に低
GPU ワークロード	p3.2xlarge	手動	高

危険信号 → エスカレーション

次の場合は作業を停止してエスカレーションします：

• 破壊的な API 変更（非推奨バージョン）を伴うクラスターのアップグレード
• マルチリージョンでのアクティブ・アクティブ要件
• コンプライアンス要件（PCI-DSS、HIPAA）の検証が必要
• カスタムスケジューラーまたはコントローラーの開発が必要
• etcd の破損またはクラスター状態の問題

品質チェックリスト

クラスター構成

• マルチ AZ デプロイ（ノードを複数のアベイラビリティーゾーンに分散）
• ノードのオートスケーリングを設定（Cluster Autoscaler または Karpenter）
• テイントを設定したシステムノードプール（重要なアドオンをアプリから分離）
• 暗号化を有効化（保存時のシークレットを KMS で暗号化）
• 監査ログを有効化（API サーバーログ）

セキュリティ

• Pod Security Standards を適用（restricted または baseline）
• ネットワークポリシーを設定（デフォルトで拒否し、明示的に許可）
• RBAC を設定（すべてのサービスアカウントに最小権限を適用）
• イメージスキャンを有効化（脆弱性をスキャン）
• プライベートコンテナレジストリを設定

リソース管理

• すべての Pod にリソースリクエストと制限を設定
• スケーラブルなワークロードに HorizontalPodAutoscalers を設定
• PodDisruptionBudgets を定義（停止する Pod が多くなりすぎないようにする）
• 名前空間ごとに ResourceQuotas を設定
• LimitRanges を定義（Pod のデフォルト制限）

高可用性

• Deployment にレプリカを 2 つ以上設定
• アンチアフィニティルールで Pod の同一ノードへの配置を防止
• Readiness プローブと Liveness プローブを設定
• PodDisruptionBudgets でローリングアップデートに対応
• マルチリージョンクラスター（グローバル規模が必要な場合）

可観測性

• メトリクスサーバーがインストールされている（kubectl top が動作する）
• Prometheus がアプリケーションのメトリクスを監視している
• ログが一元管理されている（CloudWatch、Elasticsearch、Loki）
• 分散トレーシング（Jaeger、Tempo）
• クラスターとアプリケーションの健全性を確認するダッシュボード

災害復旧

• クラスターのバックアップ用に Velero がインストールされている
• バックアップスケジュールが設定されている（最低でも毎日）
• 復元テストが実施されている（年次訓練）
• etcd のバックアップが自動化されている（クラウド管理のクラスター）

追加リソース

• 詳細な技術リファレンス：REFERENCE.mdを参照してください
• コード例とパターン：EXAMPLES.mdを参照してください