Kubernetes

この用語をシェア

概要・定義

Kubernetes（クーバネティス、略称：k8s）は、コンテナ化されたアプリケーションの自動デプロイ、スケーリング、管理を行うオープンソースのコンテナオーケストレーションプラットフォームです。2014年にGoogleによって開発され、現在はCloud Native Computing Foundation（CNCF）によって維持されています。

Kubernetesは、Googleが社内で15年以上にわたって蓄積したコンテナ管理のノウハウを基にしており、Borgシステムの経験を活かして設計されています。大規模なコンテナ化されたアプリケーションの運用を自動化し、高可用性、自動スケーリング、ローリングアップデート機能により、エンタープライズレベルのコンテナ管理を実現します。

2015年にGoogleがCNCFへKubernetesを寄贈し、2018年にはCNCFのGraduatedプロジェクト（卒業プロジェクト）第1号として認定されました。以降、Helm（パッケージ管理）、Prometheus（監視）、Envoy／Istio（サービスメッシュ）、Argo CD（GitOps）など周辺エコシステムが急速に整備され、コンテナオーケストレーションの事実上の標準（デファクトスタンダード）としての地位を確立しています。リリースサイクルは年3回程度（おおむね4ヶ月ごと）のマイナーバージョン更新が続けられており、各クラウドベンダーのマネージドサービスもこのアップストリームの開発速度に追随する形でバージョンアップを行っています。

なお「Kubernetes」という名称はギリシャ語で「操舵手（かじとり）」を意味し、船の舵を取る人になぞらえて名付けられました。ロゴの舵輪（ステアリングホイール）のモチーフもここに由来します。CLIツールの「kubectl」はしばしば「キューブコントロール」「キューブシーティーエル」などと読まれ、コミュニティ内でも呼称は統一されていません。

主要な特徴・利点

1. 自動スケーリング

リソース使用量やカスタムメトリクスに基づいて、Pod数を自動的に増減させる水平スケーリングと、CPU・メモリリソースを調整する垂直スケーリングを提供します。

2. 自動復旧（Self-healing）

障害が発生したコンテナの自動再起動、ノード障害時の自動再配置、ヘルスチェックに失敗したコンテナの自動置き換えを行います。

3. 宣言的設定

YAMLファイルで理想的な状態を定義し、Kubernetesがその状態を維持するように動作します。Infrastructure as Codeの原則に基づいた管理が可能です。

4. サービスディスカバリとロードバランシング

コンテナ間の通信を自動的に管理し、DNSベースのサービスディスカバリとロードバランシングを提供します。

5. ローリングアップデート

ダウンタイムなしでアプリケーションを更新し、問題が発生した場合は自動的にロールバックします。

主要コンポーネント

コントロールプレーン

• API Server: KubernetesクラスターのAPIエンドポイント
• etcd: クラスター状態を保存する分散キーバリューストア
• Scheduler: PodをどのNodeで実行するかを決定
• Controller Manager: 各種コントローラーの管理

ワーカーノード

• kubelet: ノード上でPodを管理するエージェント
• kube-proxy: ネットワークプロキシとロードバランサー
• Container Runtime: コンテナ実行環境（Docker、containerd等）

基本リソース

• Pod: コンテナの実行単位
• Service: Pod群への安定したアクセスを提供
• Deployment: Pod群のデプロイとアップデート管理
• ConfigMap/Secret: 設定情報と機密情報の管理

仕組み：宣言的な状態管理とコントロールループ

Kubernetesの動作原理の核となるのが「コントロールループ（Reconciliation Loop）」です。ユーザーがYAMLマニフェストで「あるべき状態（Desired State）」を宣言すると、その情報はAPI Serverを経由してetcdに保存されます。各種コントローラーは「現在の状態（Current State）」を常時監視し、Desired Stateとの差分を検知すると、Podの再作成やスケジューリングなど必要な操作を実行して差分を解消します。このループは数秒間隔で継続的に回り続けるため、手動介入なしに「あるべき姿」へ自律的に収束していく点がKubernetesの自己修復性・宣言的管理の本質です。

Podのスケジューリングでは、Schedulerがノードのリソース空き状況（CPU/メモリ）、Node Affinity/Anti-Affinity、Taint/Toleration、Topology Spread Constraintsなどの条件を評価し、フィルタリング（要件を満たさないノードの除外）とスコアリング（最適ノードの優先順位付け）の2段階で配置先ノードを決定します。この仕組みにより、可用性ゾーンをまたいだ分散配置や、特定ワークロード専用ノードへの意図的な配置制御が可能になります。

使用例・実装方法

基本的なDeploymentの作成

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Serviceによる公開とHorizontal Pod Autoscalerの設定

上記Deploymentに対してクラスター外部からのアクセスを可能にするには、Serviceリソースを組み合わせます。さらに負荷に応じたPod数の自動調整にはHorizontal Pod Autoscaler（HPA）を利用します。

# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

---
# nginx-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

代表的なkubectlコマンドの流れは次のとおりです。kubectl apply -f nginx-deployment.yamlでマニフェストを適用し、kubectl get pods -wでPodの起動状況をリアルタイムに監視、kubectl rollout status deployment/nginx-deploymentでロールアウトの完了を確認、問題発生時はkubectl rollout undo deployment/nginx-deploymentで直前のリビジョンへ即座にロールバックできます。kubectl describe pod <Pod名>やkubectl logs <Pod名>は障害切り分けの基本コマンドとして頻繁に使用します。

実運用では、生のマニフェストを直接管理するのではなく、Helm（テンプレート化されたパッケージ管理）やKustomize（環境差分のオーバーレイ管理）を用いて構成を管理し、Argo CDやFlux CDによるGitOps運用（Gitリポジトリの内容をクラスターへ自動同期する方式）を組み合わせるのが一般的です。

混同されやすい用語・類似技術との違い

Kubernetesは「コンテナ関連技術」としてDockerや他のオーケストレーションツールと混同されがちですが、担っている役割の階層が異なります。以下に代表的な類似・関連技術との違いを整理します。

Kubernetes vs Docker / Docker Compose

Dockerはコンテナイメージのビルド・実行を担う「コンテナランタイム／エンジン」であり、Kubernetesはそのコンテナを複数のホスト（ノード）にまたがって配置・監視・自動復旧させる「オーケストレーター」です。両者は競合関係ではなく、Kubernetesは内部でcontainerdなどのコンテナランタイムを利用してコンテナを起動します。Docker Composeは単一ホスト上で複数コンテナの起動順序や依存関係を定義する軽量ツールであり、開発環境やごく小規模な検証用途には適していますが、複数ノードにまたがる自動スケーリングや自己修復、ローリングアップデートといった本番運用機能は持ちません。

Kubernetes vs Docker Swarm

Docker Swarmは、Docker社自身が提供していた純正のオーケストレーション機能で、Kubernetesと比べてセットアップが簡単で学習コストが低いことが利点でした。しかしCRD（カスタムリソース定義）によるエコシステム拡張性、対応するマネージドサービスの充実度、コミュニティの活発さの面でKubernetesが大きく上回った結果、現在では新規構築でSwarmが選ばれる場面は限定的です。

Kubernetes vs Amazon ECS

Amazon ECS（Elastic Container Service）はAWS独自のコンテナオーケストレーションサービスで、IAMやALB、CloudWatchなど他のAWSサービスとのネイティブな統合が強みです。Kubernetesの概念（Pod、Service、CRDなど）を学ぶ必要がなく、AWSに閉じた構成であればECSの方が学習コストが低く運用もシンプルになりやすい一方、マルチクラウド前提の設計やKubernetesエコシステム（Helm chart、Operatorなど）を活用したい場合はEKSを含むKubernetesが選択肢になります。

Kubernetes vs HashiCorp Nomad

NomadはHashiCorpが開発するオーケストレーターで、コンテナだけでなくVMやバッチジョブ、Javaアプリケーションなど多様なワークロードを単一のスケジューラーで扱える点が特徴です。単一バイナリで動作しシンプルな構成にできる反面、KubernetesほどのCRDエコシステムや大規模コミュニティのサポートはなく、既にHashiCorp製品（Vault、Consul）を中核に据えたインフラで採用される傾向があります。

Kubernetes vs Red Hat OpenShift

OpenShiftはRed Hatが提供するKubernetesディストリビューション（Kubernetes本体に追加機能を統合した製品）で、開発者向けのビルド機能（Source-to-Image）、統合された認証基盤、より厳格なデフォルトのセキュリティポリシーなどを標準搭載しています。素のKubernetesより制約が多い分、エンタープライズ環境での運用ガバナンスを組み込みやすいという特徴があります。

Kubernetes vs サーバーレス（AWS Lambda / Cloud Run等）

サーバーレス（FaaS、CaaS）はインフラのプロビジョニングやスケーリングを完全にクラウド側へ委ね、コード実行に集中できる点が魅力です。反面、実行時間やメモリ量に制限があり、常時稼働するステートフルなワークロードや細かなネットワーク制御には不向きな場合があります。Kubernetesはインフラ管理の負荷は残るものの、実行時間無制限のワークロード、複雑なサービス間通信、GPUなど特殊なハードウェアの利用まで柔軟に対応できる点で使い分けがなされます。

AWS・Azure・GCPにおけるマネージドKubernetesサービス比較

主要クラウド3社はいずれもKubernetesのコントロールプレーンを代行運用するマネージドサービスを提供しています。自前でコントロールプレーンを構築・維持するコスト（etcdのバックアップ、API Serverの冗長化、マイナーバージョンアップグレードの検証など）を大幅に削減できるため、実務では自己構築（kubeadm等）よりもマネージドサービスの採用が主流です。

選定にあたっては、既存システムがどのクラウドに集中しているか（AWS中心ならEKS、Microsoft 365やAzure ADなどMicrosoft系資産が多いならAKS、BigQueryなどGCPのデータ分析基盤と連携したいならGKE）を軸に検討するのが実務上の定石です。マルチクラウド／ハイブリッドクラウド戦略を取る場合は、Anthos（GCP）やAzure Arcのように、クラウドをまたいでKubernetesクラスターを一元管理する仕組みも提供されています。

料金の考え方とコスト最適化

Kubernetesの利用コストは大きく「コントロールプレーン費用」「ワーカーノードのコンピュート費用」「関連サービス費用（ロードバランサー、永続ボリューム、外向き通信量等）」の3つで構成されます。ノードのコンピュート費用が総コストの大半を占めるケースが多く、いかにノードのリソース使用率を高め、無駄な過剰プロビジョニングを減らすかがコスト最適化の中心的な論点になります。

• オートスケーリングの多層活用: Horizontal Pod Autoscaler（Pod数調整）、Vertical Pod Autoscaler（Pod毎のリソース割当調整）、Cluster Autoscaler／Karpenter（ノード数調整）を組み合わせ、必要な分だけリソースを確保する
• スポット・プリエンプティブインスタンスの活用: 中断耐性のあるバッチ処理やステートレスワークロードにAWSのスポットインスタンスやGCPのプリエンプティブVM（Spot VM）を充てることで、オンデマンド料金比で大幅なコスト削減が期待できる
• Bin Packingの意識: 小さすぎるノードサイズを多数並べるとオーバーヘッド（各ノードのOS・kubelet分のリソース消費）が積み重なるため、適切なノードサイズ選定とPodの詰め込み効率を意識する
• コスト可視化ツールの導入: OpenCost（CNCF Sandboxプロジェクト）やKubecostなどを用いて、Namespace・ラベル単位でのコスト配賦を可視化し、部門やプロジェクトごとの使用状況を把握する
• フルマネージド実行環境とのトレードオフ: Fargate for EKSやGKE Autopilotはノード管理の運用負荷を大幅に下げられる一方、vCPU・メモリ単位の課金がEC2やCompute Engineの直接利用よりも割高になる傾向があるため、運用工数とインフラ費用のバランスで選定する

設計パターンとベストプラクティス

実務でKubernetesクラスターを安定運用するうえで、繰り返し登場する設計パターンと注意点を整理します。

• Namespaceによるマルチテナンシー分離: 環境（dev/staging/prod）やチーム単位でNamespaceを分け、ResourceQuotaとLimitRangeでリソース使用量の上限を設定し、特定のチームやジョブがクラスター全体のリソースを圧迫しないようにする
• Probe設定の適切化: readinessProbe（トラフィックを受け付けてよいか）、livenessProbe（再起動が必要か）、startupProbe（起動完了判定）を用途に応じて分離設定し、誤ったliveness設定による無限再起動ループを避ける
• PodDisruptionBudget（PDB）の設定: ノードのメンテナンスやオートスケーリングによる意図的なPod削除の際も、最低限のPod数を維持し可用性を担保する
• Pod Anti-Affinity・Topology Spread Constraintsによる分散配置: 同一Deploymentのレプリカを複数のアベイラビリティゾーン・ノードに分散させ、単一障害点（ノード障害・ゾーン障害）でサービス全体が停止しないようにする
• ネットワークポリシーによるゼロトラスト設計: デフォルトで全通信を許可するのではなく、NetworkPolicyで明示的に許可された通信のみを通す「ホワイトリスト型」の設計を基本とする
• Secretの外部管理: Kubernetes Secretは既定でBase64エンコードのみ（暗号化ではない）である点に留意し、HashiCorp VaultやAWS Secrets Manager、External Secrets Operatorと組み合わせて機密情報を管理する
• GitOpsによる変更管理: kubectl applyの手動実行に頼るのではなく、Argo CDやFlux CDでGitリポジトリの内容をクラスター状態の唯一の正（Single Source of Truth）として同期し、変更履歴の追跡とロールバックを容易にする
• Service Meshの適用判断: Istio・Linkerdなどのサービスメッシュはトラフィック制御や可観測性を強化できる反面、サイドカーProxy追加によるレイテンシ増加や運用複雑性の増大も伴うため、マイクロサービス数やチーム体制を踏まえて導入要否を判断する

2025〜2026年の最新動向

Kubernetesは成熟したプロジェクトになった現在も、周辺エコシステムを中心に活発な進化が続いています。特に2025年から2026年にかけては、次のようなテーマが注目されています。

• AI／MLワークロード対応の強化: GPUやTPUなどアクセラレータを柔軟にスケジューリングするDynamic Resource Allocation（DRA）、バッチジョブ・ジョブキューイングを扱うKueue、モデル推論基盤を構築するKServeなど、機械学習基盤としてのKubernetes活用が拡大しています。学習・推論ワークロードのためにKubernetesクラスターを基盤とするAIプラットフォームの構築事例が増えている点が近年の大きな潮流です
• プラットフォームエンジニアリングの浸透: 開発者が複雑なKubernetesの知識を意識せずにアプリケーションをデプロイできるようにする「内部開発者プラットフォーム（IDP）」の構築が広がっており、BackstageやCrossplaneなどのツールと組み合わせたセルフサービス型基盤の整備がトレンドになっています
• ネットワーキングの刷新: 従来のIngressに代わる標準としてGateway APIの採用が進み、より柔軟なルーティング設定が可能になっています。またkube-proxyのiptablesモードに代えて、CiliumなどeBPFベースのCNIを採用しパフォーマンスと可観測性を高める構成も一般化しつつあります
• FinOps・コスト管理の重視: クラウドコストの高騰を背景に、OpenCostやKubecostなどコスト可視化ツールを標準的に導入し、Namespace・ラベル単位でコストを部門配賦する運用が定着してきています
• サプライチェーンセキュリティへの対応: SBOM（Software Bill of Materials）の生成、cosignによるコンテナイメージの署名検証、Pod Security Admissionによる実行時ポリシー統制など、ソフトウェアサプライチェーン全体を対象としたセキュリティ対策が標準的な取り組みとして定着しています
• マルチクラスタ・フリート管理の成熟: 複数クラスターを横断的に管理するCluster APIやKarmadaといったツール、各クラウドベンダーのフリート管理機能（GKE Fleet、Azure Arc等）の活用が進み、単一クラスターに閉じない運用スタイルが広がっています