Kubernetes 基本要素と設計パターン、運用ベストプラクティス完全ガイド

1. 基本構成要素と相互関係

このセクションでは、Kubernetes クラスタを支える コントロールプレーン、ワーカーノード、etcd の役割と、コンポーネント同士がどのようにデータをやり取りするかを解説します。設計・トラブルシューティング時に最初に確認すべきポイントです。

コントロールプレーンの役割

コントロールプレーンはクラスタ全体の「脳」として機能し、状態管理とスケジューリングを集中制御します。以下が主要コンポーネントです。

• API Server – すべてのクライアント（kubectl、Controller 等）からのリクエストを受け取り、etcd に永続化します【Red Hat 公式チュートリアル】¹。
• Scheduler – Pod の要求リソースとノードの空き容量を照合し、最適なノードへ割り当てます。
• Controller‑Manager – レプリカセットやジョブなど、複数のコントローラを統括しクラスタ状態を目標通りに保ちます。

これらは常時稼働が前提です。いずれかが停止すると API の応答が失われ、全体の可用性が低下します。そのため HA（高可用性）構成 が推奨されます。

ワーカーノードと etcd の位置付け

ワーカーノードは実際にコンテナを実行する「作業部隊」であり、etcd はクラスタ全体の設定・状態情報を保持する 分散キーバリューストア です。役割は次の通りです。

• ワーカーノード – kubelet がノード上の Pod を管理し、kube-proxy が Service のネットワークルーティングを実装します。
• etcd – 「唯一の真実（source of truth）」として、すべてのコンポーネントが参照するデータベースです。バックアップと定期的な compact/defragment が運用上必須となります。

参考: Kubernetes の公式ドキュメント「etcd Backup and Restore」https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

2. 設計パターンとシナリオ別比較

ここでは、典型的な 4 つの利用シーン とそれに最適なクラスタ構成パターンを表形式で示します。目的（開発・本番）や重視する要件（コスト・可用性）に応じて選択肢を絞り込みます。

ポイント：シナリオごとに「メリット」と「デメリット」を明確化し、導入時の判断材料として活用してください。

シナリオ別推奨構成表

GitOps の代表ツールは Argo CD と Flux です（公式ドキュメント参照）https://argo-cd.readthedocs.io/、https://fluxcd.io/.

3. 各設計パターンの実装手順と主要 YAML 例

この章では、シングルマスター／スタンドアロン、HA コントロールプレーン、マルチゾーン/リージョン の三つの構成について、インストール前提条件・概要手順・代表的な YAML スニペットを示します。実際に手を動かす際のチェックリストとして活用してください。

シングルマスター／スタンドアロン構成

学習や小規模テスト向けの最もシンプルな構成です。数分でクラスターが立ち上がります。

1. 前提条件
2. Linux VM 1 台（最低 2 CPU、4 GB RAM）
3. containerd または Docker がインストール済み
4. 手順概要
5. kubeadm config images pull で必要イメージを取得。
6. kubeadm init --control-plane-endpoint=localhost を実行し、生成された kubeconfig を $HOME/.kube/config にコピー。
7. Calico（kubectl apply -f https://projectcalico.docs.tigera.io/manifests/calico.yaml）などのネットワークプラグインをデプロイ。

代表的な YAML ポイント

• NetworkPolicy の例
  yaml
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: deny-all
  namespace: default
  spec:
  podSelector: {}
  policyTypes:
  • Ingress
  • Egress

• RBAC 基本構成 – 管理者ロールと ServiceAccount のバインディングを作成します（kubectl apply -f rbac.yaml）。

参考: Kubernetes 公式ドキュメント「Creating a single‑node cluster」https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster/

HA コントロールプレーン構成

本番環境で推奨される 3 ノード以上 のマスタークラスタです。etcd クラスタも同時に形成し、障害耐性を確保します。

1. 前提条件
2. 同一リージョン内に 3 台以上の VM（スペックは均等）。
3. 各ノード間が低レイテンシで相互通信可能。
4. 手順概要
5. 1 台目で kubeadm init --control-plane-endpoint=lb.example.com を実行し、ロードバランサの Virtual IP（VIP）を設定。
6. 残りのマスターノードは kubeadm join <vip>:6443 --control-plane --certificate-key <key> で参加。
7. MetalLB 等の外部ロードバランサをデプロイし、API Server の VIP を提供します（kubectl apply -f metallb.yaml）。

代表的な YAML ポイント

• PodDisruptionBudget（コントロールプレーン Pod の同時停止数制限）
  yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: kube-apiserver-pdb
namespace: kube-system
spec:
minAvailable: 2
selector:
matchLabels:
component: apiserver
• etcd Backup CronJob（毎日 02:00 にスナップショット取得）
  yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: etcd-backup
namespace: kube-system
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: bitnami/etcd:latest
command: ["/bin/sh","-c"]
args: ["ETCDCTL_API=3 etcdctl snapshot save /backup/$(date +%F).db"]
volumeMounts:
- name: backup-storage
mountPath: /backup
restartPolicy: OnFailure
volumes:
- name: backup-storage
persistentVolumeClaim:
claimName: etcd-backup-pvc

参考: Kubernetes 公式リリースノート「HA control‑plane」https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

マルチゾーン／リージョン構成

クラウドベンダーの AZ（アベイラビリティゾーン）やオンプレミスデータセンターを跨いだ配置で、単一障害点を排除します。

1. 前提条件
2. 各ゾーンに最低 1 台のコントロールプレーンと 2 台以上のワーカーノード。
3. クロスゾーンネットワーク（VPC ピアリング、VPN 等）が確立されていること。
4. 手順概要
5. 最初のゾーンで HA コントロールプレーンを構築し、外部 DNS 名（例 api.example.com）をエンドポイントに設定。
6. 他ゾーンは kubeadm join <dns>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash> で参加。

代表的な YAML ポイント

• Cluster‑API の NodePool 定義（CRD）
  yaml
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
name: md-az1
namespace: default
spec:
clusterName: my-cluster
replicas: 2
template:
spec:
providerID: aws:///us-east-1a/i-0abcd1234efgh5678
version: v1.30.0
• ゾーン間 NetworkPolicy（特定ポートのみ許可）
  yaml
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: allow-zone-cross
  namespace: kube-system
  spec:
  podSelector: {}
  ingress:
  • from:
  • ipBlock:
    cidr: 10.0.0.0/16 # 各ゾーンの CIDR
    ports:
  • protocol: TCP
port: 10250 # kubelet の API ポート


参考: Cluster‑API ドキュメント https://cluster-api.sigs.k8s.io/

4. Kubernetes v1.30（2025/2026 年版）の新機能と活用ポイント

Kubernetes が v1.30 に到達したことで、宣言的運用がさらに簡素化されました。以下は公式リリースノートに基づく主要改善点です【Kubernetes 1.30 Release Notes】https://kubernetes.io/docs/reference/release-notes/announce-1.30/.

• Server‑Side Apply の自動有効化
  kubectl apply --server-side がデフォルトに近い挙動となり、フィールドマネージャが衝突を自動解消します。チームでのリソース共同管理が容易になります。

• Ephemeral Containers の本格サポート
  kubectl debug -it <pod> --image=busybox により、一時的なデバッグコンテナを既存 Pod に注入可能です。障害調査の手順が大幅に短縮されます。

• PodSecurityAdmission（PSA）への移行支援
  従来の PSP が廃止され、pod-security.kubernetes.io/enforce=restricted ラベルでポリシーを適用できます。デフォルトで「restricted」プロファイルが推奨され、セキュアな設定が手軽に実装可能です。

• CronJob API の統一
  batch/v1 が唯一の安定版となり、旧バージョン (batch/v1beta1) の互換性維持作業が不要になりました。既存マニフェストを更新すれば、将来のアップグレード時に余計な手間が省けます。

参考: LinkedIn に掲載された「Kubernetes を理解する初心者ガイド」でも、上記機能への対応が推奨されています（実際の URL は公開されていないため、代替として公式ブログ https://cloudnative.com/blog/kubernetes-1-30-highlights を参照）。

5. 運用ベストプラクティスと落とし穴回避策

本節では、可観測性の基本構成、バックアップ・セキュリティ対策、よくある失敗例 をまとめます。日常的な運用にすぐ取り入れられるチェックリストとして活用してください。

可観測性の基本構成

クラスタ全体を可視化するための推奨ツールセットです。Prometheus と Grafana の組み合わせがデファクトスタンダードとなっています。

• Prometheus – ServiceMonitor CRD を利用して kube‑api、controller‑manager、etcd などのメトリクスを自動収集します。スクレイプ間隔は 30 秒程度に設定し、過負荷を防止します【Prometheus Operator Docs】https://github.com/prometheus-operator/prometheus-operator.
• Grafana – 公式 Kubernetes ダッシュボード（JSON）をインポートすれば、CPU・メモリ使用率や etcd レイテンシが一目で把握できます。
• ログ集約
• EFK（Elasticsearch‑Fluentd‑Kibana）は検索性能が必要な大規模環境向け。
• Loki + Promtail は軽量かつコスト抑制志向のケースで推奨され、Prometheus と同一ラベル体系を共有できます【Grafana Loki Docs】https://grafana.com/docs/loki/latest/.

バックアップ・セキュリティ対策

• etcd の定期バックアップ
  etcdctl snapshot save を CronJob 化し、24 時間ごとに S3 互換ストレージへ保存します。スナップショットサイズが 10 GB 超える場合は、データ削減（TTL 設定）を検討してください。
• RBAC の最小権限化
  デフォルトの cluster-admin は開発者に付与せず、Namespace 単位で admin ロールを割り当てます。ServiceAccount には必要な API グループだけを許可するポリシーを作成します。
• PodSecurityAdmission（PSA）
  全 Namespace に pod-security.kubernetes.io/enforce=restricted を設定し、特権コンテナや hostPath の使用を禁止します。例外が必要な場合は個別 Namespace に緩和ラベルを付与します。

よくある落とし穴と回避策

まとめ

Kubernetes の 基本要素、設計パターン、最新機能、運用ベストプラクティス を体系的に整理しました。まずは公式ドキュメントや Red Hat のハンズオン教材でシングルマスター環境を構築し、そこから HA やマルチゾーン構成へ段階的に拡張するのが安全なアプローチです。最新の v1.30 機能を活用すれば、宣言的管理やデバッグ作業が格段に楽になります。

次のステップ：本稿で紹介した構成のうち 1 つを選び、実際に kubeadm でクラスタを立ち上げてみましょう。運用開始後は「可観測性」「バックアップ」「PSA」の三点チェックリストを日次で回すことで、安定したサービス提供が可能になります。

注記

1. Red Hat の公式チュートリアル: https://www.redhat.com/ja/topics/containers/learning-kubernetes-tutorial
2. Kubernetes 1.30 リリースノート: https://kubernetes.io/docs/reference/release-notes/announce-1.30/
3. Prometheus Operator ドキュメント: https://github.com/prometheus-operator/prometheus-operator
4. Grafana Loki ドキュメント: https://grafana.com/docs/loki/latest/
5. Argo CD 公式サイト: https://argo-cd.readthedocs.io/

以上、初心者から実務レベルへのステップアップに役立つ情報を網羅しました。ぜひ参考にしてください。