Contents
1. Kubernetes クラスタ全体像と主要コンポーネント
Kubernetes の構成要素は大きく Control Plane と Data Plane（Node） に分かれます。これらの責務と相互依存を正しく把握すれば、障害発生時の切り分けやスケールアウト計画がシンプルになります。
1.1 Control Plane の構成要素
Control Plane はクラスタ全体の状態管理・スケジューリングを担うコンポーネント群です。冗長化と API アクセスの可用性確保が最優先事項となります。
| コンポーネント | 主な役割 | 推奨冗長化 |
|---|---|---|
| kube‑apiserver | すべてのリクエスト入口（REST API） | 3 以上のインスタンスをロードバランサ配下に配置 |
| controller‑manager | 各種コントローラ（ReplicaSet、Job 等） | ステートレスなので水平スケール可 |
| scheduler | Pod のノード割り当てロジック | 同上 |
| etcd | 分散キーバリューストア。クラスタ設定・状態の永続化 | 奇数ノード（3,5）で quorum を確保し、毎日スナップショットを取得 |
要点：Control Plane と etcd の冗長化は「単一障害点排除」の基本です。ロードバランサはクラウドベンダー提供のもの（例: AWS ELB、Azure Load Balancer、GCP Cloud Load Balancing）を使用し、ヘルスチェックで API Server の可用性を監視します。
1.2 Node（Data Plane）の構成要素
Node は実際に Pod を稼働させる作業単位です。kubelet と kube‑proxy が主要コンポーネントとなり、CNI・CSI がネットワークと永続ストレージを提供します。
| コンポーネント | 主な役割 |
|---|---|
| kubelet | Pod のライフサイクル管理、Node 状態の報告 |
| kube‑proxy | Service IP へのトラフィック転送（iptables / ipvs） |
| CNI プラグイン | Pod ネットワーク構築（Calico, Cilium, Flannel 等） |
| CSI ドライバ | 永続ボリュームのプロビジョニング（AWS EBS CSI、Azure Disk CSI など） |
要点：Node は AZ/リージョンを跨いで配置し、Pod Disruption Budget (PDB) と組み合わせることで障害時のサービス継続性を確保します。
2. 高可用性設計とスケーリング戦略
ミッション・クリティカルなワークロードでは HA と 自動スケール が不可欠です。ここではマスターノードの冗長化、etcd クラスタリング、およびリソース管理のベストプラクティスを紹介します。
2.1 マスターノードと etcd の HA 構成
導入文：複数 AZ に跨るマスターノード配置は、データセンター障害時でも API が利用可能であることを保証します。
- 冗長化パターン
- クラウド横断例：AWS EKS（
eksctl create cluster --zones us-east-1a,us-east-1b,us-east-1c）・Azure AKS（az aks create --node-count 3 --zones 1 2 3）・GKE（gcloud container clusters create ... --location=us-central1-a,us-central1-b,us-central1-c）。 -
オンプレ：MetalLB + Keepalived による仮想 IP を API Server 前に配置し、3 台以上のコントロールプレーンを構築。
-
etcd の運用ポイント
etcdctl snapshot save /backup/etcd‑$(date +%F).db（毎日 02:00 UTC）でスナップショット取得。- バックアップは別ストレージ（例：S3、Azure Blob、GCS）へ複製し、リテンションポリシーを設定。
要点：マスターノードは最低 3 AZ に跨げるように配置し、etcd は奇数ノードで quorum を保つと同時にスナップショットでデータ復旧を保証します。
2.2 リソースリクエスト／リミットと自動スケーラ
導入文：Pod の CPU/Memory 要求を明示し、Horizontal Pod Autoscaler (HPA) と Cluster Autoscaler を組み合わせることで、過剰プロビジョニングを抑制しつつ負荷変動に対応します。
2.2.1 リクエスト／リミットのベストプラクティス
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
apiVersion: v1 kind: LimitRange metadata: name: default-limits namespace: production spec: limits: - defaultRequest: cpu: "250m" memory: "256Mi" default: cpu: "500m" memory: "512Mi" type: Container |
- 効果：未指定リソースによる OOM キルを防止し、Scheduler が適切にノードへ割り当てられる。
2.2.2 HPA と Cluster Autoscaler の組み合わせ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 3 maxReplicas: 15 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 |
- Cluster Autoscaler 起動オプション例（kube‑adm の
--extra-configに追加）
|
1 2 3 4 |
--scale-down-delay-after-add=10m \ --balance-similar-node-groups=true \ --expander=least-waste |
要点：リクエスト/リミットで基礎的なリソース制御を行い、HPA と Cluster Autoscaler が連携すれば、スパイク時の自動拡張と閑散期の縮小がシームレスに実現します。
3. ネットワーク・認証・認可のベストプラクティス
ネットワーク設計とアクセス制御は セキュリティ と 運用効率 の根幹です。本章では CNI 選定基準、CIDR 設計、RBAC と Pod Security Standards（PSS）への移行手順を解説します。
3.1 CNI 選定と CIDR 設計
導入文：CNI の選択はレイテンシやポリシー実装に直結し、CIDR は将来的なスケールの上限を決めます。
| 評価項目 | 推奨基準 |
|---|---|
| パフォーマンス | eBPF ベース（Cilium） → 低レイテンシ・高スループット |
| IPAM | 内蔵 IPAM があり、外部 DHCP/Cloud‑Native と統合可能か |
| セキュリティ | NetworkPolicy のフルサポート＋マイクロセグメンテーション機能 |
CIDR 設計例
- Pod CIDR：
10.0.0.0/16（最大 65,536 IP） - Service CIDR：
172.20.0.0/12（約 1M IP）
要点：CNI はパフォーマンスとポリシー機能で比較し、CIDR は
/16以上を確保しておくことで再設計コストを回避できます。
3.2 RBAC と最小権限化、Pod Security Standards（PSS）への移行
導入文：Kubernetes の認可は RBAC が中心です。加えて、1.25 以降は PodSecurityAdmission による PSS が推奨されます（旧 PSP は廃止）。
3.2.1 RBAC 最小権限の実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: production rules: - apiGroups: [""] resources: ["pods"] verbs: ["get","list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: production subjects: - kind: ServiceAccount name: app-sa namespace: production roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io |
3.2.2 Pod Security Standards（PSS）適用例
方法 1：Namespace にラベル付与（Kubernetes v1.25+）
|
1 2 3 4 5 |
kubectl label namespace production \ pod-security.kubernetes.io/enforce=restricted \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/warn=restricted |
方法 2：Admission Policy の YAML（policy/v1）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
apiVersion: policy/v1 kind: PodSecurityPolicy # 注意: v1 は PSP の非推奨名だが、PSS と同等に機能させる例示 metadata: name: restricted-pss spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - configMap - secret - persistentVolumeClaim seLinux: rule: RunAsAny |
要点：RBAC のロールは「最小権限」原則で設計し、Namespace ラベル方式で PSS を有効化すれば、Pod が危険な設定（privileged, hostPath 等）を使用できなくなります。
4. ログ・メトリクス・監視、アップグレードとバックアップ戦略
運用フェーズでは 可観測性 と 安全なバージョン管理 が鍵です。本章は Prometheus/Grafana の標準構成例、ELK/EFK スタックの概要、そしてローリングアップグレード手順と etcd バックアップをまとめます。
4.1 Observability（Prometheus + Grafana + kube‑state‑metrics）
導入文：Prometheus に
kube-state-metricsとnode-exporterを加えるだけで、クラスタ全体のリソース使用率とオブジェクト状態を網羅的に取得できます。
4.1.1 Helm インストール例（公式チャート）
|
1 2 3 4 5 6 |
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set prometheus.prometheusSpec.retention=30d \ --set grafana.adminPassword=StrongPass123! |
kube-state-metricsとnode-exporterはデフォルトで有効化されます。- Grafana の公式ダッシュボード ID 315（Kubernetes cluster monitoring）をインポートしてください。
4.1.2 Alertmanager 基本設定
|
1 2 3 4 5 6 7 8 9 10 11 |
receivers: - name: slack slack_configs: - channel: '#alerts' send_resolved: true route: receiver: slack group_wait: 30s group_interval: 5m repeat_interval: 1h |
要点：Prometheus の保持期間は 30 日程度に設定し、Alertmanager と Slack/Teams 等の通知先を接続すれば、障害検知から対応までのリードタイムが大幅に短縮します。
4.2 安全なローリングアップグレードと etcd スナップショット
導入文：Kubernetes のバージョンアップは
kubectl drain→kubeadm upgrade→kubectl uncordonのフローで実施し、事前に etcd スナップショットを取得しておくと万が一のロールバックが容易です。
4.2.1 ノード退避手順
|
1 2 3 |
# Pod が DaemonSet に属さないことを確認した上で実行 kubectl drain <node-name> --ignore-daemonsets --delete-local-data |
4.2.2 kubeadm によるマスターノードアップグレード例
|
1 2 3 4 5 6 7 |
# 現在のバージョン確認 kubeadm version # アップグレード計画（v1.28.0 → v1.29.0） kubeadm upgrade plan kubeadm upgrade apply v1.29.0 |
4.2.3 etcd スナップショット取得コマンド（etcdctl v3）
|
1 2 3 4 5 6 |
ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd-$(date +%F).db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key |
- 復元例は公式ドキュメント（etcdctl snapshot restore）を参照。
要点：アップグレード前に必ず etcd スナップショットを取得し、
kubectl drainでノードを安全に退避させることで、サービス停止時間を数分以内に抑えることが可能です。
5. コスト最適化・セキュリティ強化と実践チェックリスト
コスト削減は スポット／プリエンプティブインスタンス の活用、セキュリティは イメージスキャン と シークレット管理 が中心です。ここではマルチクラウドでの具体例と、実務ですぐに使えるチェック項目をまとめます。
5.1 インスタンスタイプ選定とスポット活用（マルチクラウド対応）
導入文：汎用インスタンス（vCPU とメモリがバランス良好）を基準に、バッチや開発環境は各ベンダーのスポット／プリエンプティブオプションで置き換えると、料金表上 最大約 70 % の削減が報告されています（※Azure AKS スポットインスタンスガイド・AWS Spot Instances Best Practices）。
5.1.1 PodDisruptionBudget の設定例（共通）
|
1 2 3 4 5 6 7 8 9 10 |
apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: web-pdb spec: minAvailable: 2 # 必要な最低レプリカ数 selector: matchLabels: app: web |
5.1.2 各クラウドでのスポットノードプール構成
| クラウド | スポット設定例 |
|---|---|
| Azure AKS | az aks nodepool add --name spotpool --mode User --node-vm-size Standard_D4s_v3 --priority Spot --eviction-policy Delete |
| AWS EKS | eksctl create nodegroup --cluster my-cluster --name spot-ng --instance-types t3.large,m5.large --managed --spot |
| GCP GKE | gcloud container clusters create ... --node-pool=spot-pool --machine-type=e2-standard-4 --spot |
要点：スポットインスタンスは PDB と組み合わせて最低稼働数を保証すれば、コスト削減と可用性の両立が可能です。
5.2 コンテナイメージスキャンとシークレット管理
導入文：CI パイプラインで脆弱性検出を行い、シークレットは外部 KMS に委譲することで、ランタイムリスクを最小化します。
5.2.1 Trivy を用いた GitHub Actions のスキャン例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
name: Image Scan on: push: paths: - '**/Dockerfile' jobs: trivy-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run Trivy uses: aquasecurity/trivy-action@master with: image-ref: myrepo/app:${{ github.sha }} exit-code: '1' # 脆弱性があればジョブ失敗 |
5.2.2 SealedSecrets による暗号化シークレット例
|
1 2 3 4 |
kubectl create secret generic db-pass \ --from-literal=password=SuperSecret123 \ --dry-run=client -o yaml | kubeseal > sealed-db-pass.yaml |
sealed-db-pass.yamlは暗号化された状態で Git に保存可能です。復号はクラスター内部の controller が自動で行います。
要点：イメージスキャンを CI に組み込み、シークレットは SealedSecrets もしくはクラウド KMS（AWS KMS、Azure Key Vault、GCP Secret Manager）に委譲すれば、供給チェーンとランタイムの両側面でセキュリティが向上します。
5.3 実践チェックリスト（抜粋）
| 項目 | 確認ポイント | 推奨設定 |
|---|---|---|
| Control Plane 冗長化 | API Server が 3 以上のインスタンスで LB 配下か | replicas: 3 + ヘルスチェック |
| etcd バックアップ | 毎日スナップショット取得・別ストレージ保存 | ETCDCTL_API=3 etcdctl snapshot save … |
| ネットワーク CIDR | Pod CIDR /16 以上、Service CIDR 重複なし |
10.0.0.0/16, 172.20.0.0/12 |
| RBAC 最小権限 | ServiceAccount に必要ロールのみ付与 | RoleBinding の subjects を限定 |
| Pod Security Standards | Namespace に enforce=restricted ラベル設定 |
kubectl label ns prod … |
| HPA / Cluster Autoscaler | CPU 利用率しきい値と min/max 設定 | averageUtilization: 60%, minReplicas:3 |
| ログ集約 | EFK/EFK スタックで stdout を取得 | Fluent Bit + Elasticsearch |
| アップグレード手順 | kubectl drain → kubeadm upgrade → kubectl uncordon がドキュメント化済みか |
手順書作成・リハーサル実施 |
| コストモニタリング | インスタンス別利用率とスポット比率を可視化 | CloudWatch / Prometheus Cost Exporter |
| イメージスキャン | CI に Trivy 連携、失敗時ブロック設定 | exit-code: 1 |
要点：上記チェックリストは 設計レビュー と 定期的な運用監査 の両方で活用でき、抜け漏れを防止します。
終わりに（まとめ）
- 可用性：Control Plane・etcd を奇数ノードで冗長化し、マスターノードは複数 AZ に跨げば単一障害点が排除されます。
- スケーラビリティ：リクエスト/リミットと HPA＋Cluster Autoscaler の組み合わせで負荷変動に自動対応します。
- セキュリティ：RBAC と PSS（Namespace ラベル）を徹底し、イメージスキャン・シークレット暗号化で供給チェーン全体を保護します。
- 観測性：Prometheus/Grafana + Alertmanager が標準スタックとなり、障害検知と復旧時間の短縮に寄与します。
- コスト最適化：スポット／プリエンプティブインスタンスを活用しつつ PDB で可用性確保、マルチクラウド対応でベンダーロックイン回避が可能です。
次のステップ：本稿のベストプラクティスとチェックリストを自社環境に落とし込み、まずは小規模クラスター（例：3 ノード）で検証してください。検証結果を踏まえて段階的に本番規模へ拡張すれば、安定・安全・コスト最適化 が実現できるはずです。
参考情報（抜粋）
| 項目 | URL |
|---|---|
| Kubernetes ベストプラクティス（公式） | https://kubernetes.io/ja/docs/setup/best-practices/ |
| Azure AKS スポットノードプールガイド | https://learn.microsoft.com/ja-jp/azure/aks/spot-node-pool |
| AWS Spot Instances Best Practices | https://aws.amazon.com/jp/ec2/spot/best-practices/ |
| GKE プリエンプティブ VM の利用 | https://cloud.google.com/kubernetes-engine/docs/how-to/preemptible-vms |
| Pod Security Standards（公式） | https://kubernetes.io/docs/concepts/security/pod-security-standards/ |
| etcd バックアップ・復元ガイド | https://etcd.io/docs/v3.5/dev-guide/recovery/ |
| Trivy GitHub Action | https://github.com/aquasecurity/trivy-action |
| SealedSecrets プロジェクト | https://github.com/bitnami-labs/sealed-secrets |
（上記は執筆時点の最新リンクです。閲覧日時を明記しておくと、将来の検証が容易になります。）