KAKUTA TECH BLOG

Blog Article

Kubernetesとは

はじめに

Kubernetes は、コンテナ化したアプリケーションを複数のサーバー上で動かし、必要な数を維持したり、障害から自動的に復旧したりするための仕組みです。本記事では、Kubernetes の基本概念から、Pod、Service、Deployment などの役割まで、初学者向けに整理して説明します。

参考リンク

Kubernetesとは

Kubernetes は、コンテナ化したアプリケーションを管理するためのオープンソースのプラットフォームです。

コンテナは、アプリケーションと、そのアプリケーションを動かすために必要なファイルなどをまとめて実行できる仕組みです。Docker などを使ってコンテナを作成できますが、実際のサービスが大規模になると、コンテナを 1 個ずつ手作業で管理するのは大変になります。

例えば、Web アプリケーションを 3 個のコンテナで動かしていたとして、そのうち 1 個が停止したとします。人間が毎回状態を確認して、新しいコンテナを起動するのは手間がかかります。Kubernetes では「3 個の Pod を動かしたい」というように、どういう状態にしたいのかを宣言しておくことで、その状態を維持するための処理を Kubernetes が行います。

🔰一言で言うと「コンテナを自動的に管理する仕組み」です。

コンテナオーケストレーション

Kubernetes は、コンテナを管理する「コンテナオーケストレーション」のために利用されます。

オーケストレーションとは、複数のコンテナをまとめて管理することです。アプリケーションを複数のコンテナで動かしたり、コンテナが停止したときに必要な数へ戻したり、複数のコンテナへ通信を振り分けたりします。

Kubernetes では、単純にコンテナを起動するだけではなく、アプリケーションをどのような状態で動かしたいのかを定義し、その状態を維持することが重要になります。

サービスディスカバリと通信

複数のコンテナを動かす場合、それぞれのコンテナへ直接アクセスするのは扱いにくくなります。

コンテナを再作成すると IP アドレスが変わる場合があるため、「この IP アドレスのコンテナへアクセスする」という方法では安定した通信ができません。

そこで Kubernetes では Service という仕組みを利用します。Service は複数の Pod に対して安定した IP アドレスや DNS 名を提供し、適切な Pod へ通信を転送する役割を持ちます。

スケーリング

Kubernetes では、アプリケーションを動かす Pod の数を増減できます。

アクセスが増えて処理量が多くなった場合、1 個の Pod だけでは処理しきれないことがあります。その場合、同じ役割を持つ Pod を複数起動して処理を分散できます。

逆に、必要以上に Pod が起動している場合は数を減らすこともできます。

このように、アプリケーションを動かす単位を必要な数に調整できることも Kubernetes の重要な特徴です。

自己修復

Kubernetes では、Pod が停止した場合などに、指定された状態へ戻すための処理が行われます。

例えば「3 個の Pod を動かしたい」と設定しているにもかかわらず、何らかの原因で 1 個停止した場合、Kubernetes は現在の状態と設定された望ましい状態の差を認識し、不足している Pod を作成するように動作します。

これは Kubernetes の Controller という仕組みによって実現されています。

設定情報の管理

アプリケーションを動かすには、プログラム本体だけでなく、環境ごとの設定情報なども必要になります。

Kubernetes では、一般的な設定値を ConfigMap、パスワードなどの機密情報を Secret として扱えます。

ただし、Secret だから自動的にすべてが安全になるわけではありません。保存方法やアクセス権限なども含めて、適切なセキュリティ対策が必要です。

Kubernetesの仕組み

Kubernetes の仕組みを理解するには、まず「どこで何が動いているのか」を理解する必要があります。

Kubernetes のクラスタは、大きく Control Plane と Node から構成されます。

Control Plane はクラスタ全体を管理する役割を持ち、Node は実際にアプリケーションを動かす役割を持ちます。

全体像を簡単にすると、次のようになります。

                           Kubernetes Cluster
                                    │
              ┌────────────┴────────────┐
              │                                          │
        Control Plane                                   Node
        ┌────────┐                        ┌──────────┐
        │ API Server  │                         │     kubelet    │
        │ Scheduler   │                         │ kube-proxy     │
        │ Controllers │                         │ Container      │
        │ etcd        │                         │ Runtime        │
        └── ─────┘                         └─────┬────┘
                                                           │
                                                          Pod
                                                    ┌───┴────┐
                                                    │   Container │
                                                    └────────┘

CNI

Kubernetes の Pod 間通信を成立させるためには、CNI プラグインが必要です。

CNI は Container Network Interface の略で、コンテナのネットワークを構成するための仕組みです。Kubernetes 自体がすべてのネットワーク処理を直接実装しているわけではなく、CNI に対応したネットワークプラグインを利用して Pod のネットワークを構成します。

複数の Node に Pod が分散している場合でも、Pod 同士が通信できるようにネットワークを構成する必要があります。CNI プラグインは、そのためのネットワーク機能を提供します。

Cluster（クラスター）

Cluster は、Kubernetes によってまとめて管理されるコンピューター群全体のことです。

Cluster の中には、管理を担当する Control Plane と、実際にアプリケーションを動かす Node があります。

例えば、3 台のコンピューターを Kubernetes でまとめて管理している場合、その 3 台を含む Kubernetes 全体が 1 つの Cluster になります。

Kubernetes Cluster
│
├── Control Plane
│
├── Node
│   └── Pod
│
└── Node
    └── Pod

Node

Node は、Pod を実行するコンピューターです。

Node は物理サーバーの場合もあれば、仮想マシンの場合もあります。Node 上では kubelet やコンテナランタイムなどが動作し、Pod に含まれるコンテナを実際に実行します。

つまり、Node は「アプリケーションを実際に動かす場所」と考えると分かりやすいです。

Control Plane（コントロールプレーン）

Control Plane は、Kubernetes Cluster 全体を管理するための部分です。

アプリケーションそのものを直接処理する場所というより、Cluster がどのような状態になっているべきかを管理し、その状態になるように各コンポーネントへ指示する役割を持っています。

Control Plane には、複数のコンポーネントがあります。

kube-apiserver（キューブアピサーバー）

kube-apiserver は、Kubernetes API を提供するコンポーネントです。

Kubernetes API は、Kubernetes のリソースを操作するための窓口です。ユーザーが kubectl を使って Pod を作成したり、状態を確認したりするときも、基本的には API Server を経由して Kubernetes とやり取りします。

つまり、Kubernetes に対して「この Pod を作ってほしい」「現在の状態を教えてほしい」といった操作を行うための中心的な入口です。

kubectl（キューブコントロール）

kubectl は、Kubernetes Cluster を操作するためのコマンドラインツールです。

コマンドラインツールとは、ターミナルからコマンドを入力して操作するためのプログラムです。

次のように実行すると、Cluster 内の Pod を確認できます。

kubectl get pods

kubectl が直接 Node にログインして操作しているわけではありません。Kubernetes API を通じて、Cluster の情報を取得したり、リソースを操作したりします。

etcd（イーティーシーディー）

etcd は、Kubernetes が利用する Key-Value ストアです。

Key-Value ストアとは、「キー」と「値」をセットにしてデータを保存する仕組みです。

キー                    値
pod/example              Podの情報
service/example          Serviceの情報
deployment/example      Deploymentの情報

のように、Kubernetes API Server が扱う Cluster の状態や設定などを保存します。

そのため、etcd は Kubernetes の状態を管理するうえで重要なコンポーネントです。

kube-scheduler（キューブスケジューラー）

kube-scheduler は、まだ Node が決まっていない Pod を、どの Node で実行するか決定するコンポーネントです。複数の Node が存在する Cluster で Pod を作成するとき、Pod をどの Node に配置するかを決める必要があります。

kube-scheduler は、利用可能な Node の状態や Pod の要求などを考慮して、Pod を配置する Node を選択します。

kube-controller-manager（キューブコントローラーマネージャー）

kube-controller-manager は、複数の Controller をまとめて実行するコンポーネントです。

Controller は、Kubernetes に設定された「望ましい状態」と、現在の Cluster の状態を比較し、その差を小さくするために動作します。

例えば、3 個の Pod を維持したいのに現在 2 個しか存在しない場合、不足している Pod を作成するように動作します。

このように、Kubernetes が設定された状態を維持するための重要な仕組みが Controller です。

cloud-controller-manager（クラウドコントローラーマネージャー）

cloud-controller-manager は、クラウドサービスと Kubernetes を連携させるためのコンポーネントです。

例えば、クラウド事業者が提供するロードバランサーやネットワーク、Node などを Kubernetes から扱う場合に利用されます。

ただし、すべての Kubernetes 環境で必要になるわけではありません。

Nodeの仕組み

Node は、実際に Pod を実行するコンピューターです。

Node 上では、Kubernetes から指示を受け取って Pod の状態を管理するコンポーネントや、実際にコンテナを実行するためのソフトウェアが動作します。

代表的なものが kubelet、kube-proxy、Container Runtime です。

kubelet（キューブレット）

kubelet は、Node 上で動作する Kubernetes のエージェントです。

エージェントとは、管理システムから指示を受け取り、対象のコンピューター上で処理を実行するプログラムのことです。

kubelet は、Node 上で動作する Pod に含まれるコンテナが、指定された状態になるように管理します。

Pod に含まれるコンテナを起動したり、状態を確認したりします。

kube-proxy（キューブプロキシ）

kube-proxy は、Kubernetes の Service に関係するネットワーク機能を Node 上で提供するコンポーネントです。

Service は、複数の Pod に対して安定したアクセス先を提供します。しかし、実際に Service 宛ての通信を適切な Pod へ転送するためには、Node 側でネットワーク処理が必要です。

kube-proxy はそのための仕組みに関わります。ただし、利用するネットワークプラグインによっては、Service のネットワーク処理を独自に実装している場合もあります。

Container Runtime（コンテナランタイム）

Container Runtime は、コンテナを実際に実行するためのソフトウェアです。

Kubernetes が直接コンテナそのものを実行しているわけではありません。Kubernetes は Container Runtime と連携して、Pod に含まれるコンテナを起動・停止します。

Kubernetes では Docker Engine だけを利用する必要があるわけではなく、Kubernetes が対応する Container Runtime を利用します。

Pod（ポッド）

Pod は、Kubernetes における最小のデプロイ単位です。

デプロイとは、アプリケーションを実際の実行環境へ配置して動かすことです。

Pod は 1 個以上のコンテナをまとめた単位で、一般的には 1 Pod に 1 コンテナを配置する構成が多く使われます。ただし、必要に応じて複数のコンテナを 1 つの Pod に配置することもできます。

Pod に含まれるコンテナは、ネットワークなどの一部のリソースを共有します。そのため、同じ Pod 内のコンテナ同士は localhost を使って通信できます。

Pod
│
├── Container
│
└── Container

なお、Volume は Pod に必ず存在するものではありません。データを保持したい場合など、必要に応じて Pod に Volume を設定します。

Service（サービス）

Service は、Pod に対して安定したアクセス先を提供する仕組みです。

Pod は削除されたり作り直されたりすることがあり、そのたびに Pod の IP アドレスが変わる可能性があります。

そのため、利用者や別のアプリケーションが Pod の IP アドレスを直接指定して通信する方法では管理しにくくなります。

そこで Service を利用します。

             Service
                │
       ┌────────┼────────┐
       ↓       　　　　 ↓     　　　   ↓
     Pod A  　　　　  Pod B  　　　  Pod C

Service は、バックエンドとして登録された Pod へ通信を転送します。

そのため、Pod が入れ替わっても、利用する側は基本的に Service をアクセス先として利用できます。

ClusterIP（クラスターアイピー）

ClusterIP は、Cluster 内部から Service にアクセスするための仮想 IP アドレスです。

仮想 IP アドレスとは、特定の物理コンピューターそのものに直接割り当てられた IP アドレスではなく、Service へのアクセス先として利用される IP アドレスです。

例えば、Web アプリケーションの Pod が複数存在していても、別のアプリケーションからは Service の ClusterIP を利用してアクセスできます。

LoadBalancer（ロードバランサー）

LoadBalancer は、Service を外部からアクセスできるようにするために利用される Service タイプです。

クラウド環境などでは、Kubernetes とクラウド事業者の仕組みが連携して、外部ロードバランサーが作成される場合があります。

ここで注意したいのは、Kubernetes の Service 自体が必ず外部ロードバランサーそのものを提供するわけではないという点です。

利用する環境やクラウドサービスによって、実際の外部ロードバランサーの構成は異なります。

Ingress（イングレス）

Ingress は、主に HTTP / HTTPS の通信を Cluster 内の Service へルーティングするための仕組みです。

ルーティングとは、受け取った通信を「どこへ送るか」を決めることです。

https://example.com/app
        │
        ↓
     Ingress
        │
        ↓
   Service A
        │
   ┌────┴────┐
   ↓         ↓
 Pod A      Pod B

のように、リクエストの URL などに応じて適切な Service へ通信を送る構成ができます。

ReplicaSet（レプリカセット）

ReplicaSet は、指定した数の Pod を維持するための Kubernetes リソースです。

3 個の Pod を動かしたい場合、ReplicaSet に「3 個」という状態を設定します。何らかの理由で Pod が 1 個削除されて 2 個になった場合、ReplicaSet は現在の状態と望ましい状態の差を検出し、不足した Pod を作成して 3 個に戻そうとします。

望ましい状態
Pod × 3

     ↓

現在の状態
Pod × 2

     ↓ Controller

Pod を 1 個作成

     ↓

Pod × 3

このように、ReplicaSet は Pod の数を維持する役割を持っています。

Deployment

Deployment は、アプリケーションの Deployment を管理するための Kubernetes リソースです。

Deployment は ReplicaSet を管理し、Pod の数を維持するだけではなく、アプリケーションの更新やロールバックなども扱います。

例えば、現在 v1 のアプリケーションを動かしていて、新しい v2 をデプロイしたい場合、Deployment を使って更新を管理できます。

    Deployment
        │
        ↓
    ReplicaSet
        │
 ┌───┼───┐
 ↓      ↓      ↓
Pod    Pod    Pod

Deployment と ReplicaSet の関係を整理すると、Deployment が ReplicaSet を管理し、その ReplicaSet が指定された数の Pod を維持する、という構造になります。

そのため、ReplicaSet は Pod 数の維持、Deployment はアプリケーションの更新を含めた管理と考えると理解しやすいです。

Kubernetesで状態を維持する仕組み

ここまでの内容をつなげると、Kubernetes が単にコンテナを起動するだけの仕組みではないことが分かります。

Kubernetes では「どのような状態にしたいのか」をリソースとして定義し、Controller などが現在の状態を確認します。そして、設定された状態と実際の状態に差があれば、その差をなくすための処理を行います。

この考え方を 望ましい状態と現在の状態を一致させる仕組みとして理解すると、Kubernetes の多くの機能がつながって見えてきます。

Deployment で Pod を 3 個動かすように設定した場合、次のような関係になります。

「Pod を 3 個動かしたい」
          │
          ↓
     Deployment
          │
          ↓
      ReplicaSet
          │
          ↓
      Pod × 3
          │
          ↓
   Node 上でコンテナ実行

もし Pod が 1 個停止すれば、ReplicaSet などの Controller が現在の状態を確認し、不足している Pod を作成することで、望ましい状態へ戻そうとします。

これが Kubernetes における 宣言的な管理の基本的な考え方です。

「このコンテナを今すぐ起動してください」と毎回手動で指示するのではなく、「この状態にしてください」と定義し、その状態を維持するために Kubernetes が動作します。

Kubernetesの全体像

ユーザーが kubectl を使って Kubernetes API を操作すると、API Server がその要求を受け取ります。Cluster の情報は etcd に保存され、Scheduler や Controller などのコンポーネントが、それぞれの役割に応じて Cluster を管理します。

Node では kubelet が Pod の状態を管理し、Container Runtime が実際のコンテナを実行します。

さらに、Service によって Pod への安定したアクセス先を提供し、Ingress などを利用することで HTTP / HTTPS の外部通信を Service へルーティングできます。

このように、Kubernetes は「コンテナを起動するだけのツール」ではなく、複数のコンポーネントが連携して、アプリケーションを望ましい状態に維持するための仕組みです。

まとめ

Kubernetes は、コンテナ化されたアプリケーションを大規模に管理するためのプラットフォームです。

特に重要なのは、Kubernetes が「現在の状態を確認し、設定された望ましい状態へ近づける」という考え方で動作していることです。

今回登場した主要な要素を整理すると、次のようになります。

要素

主な役割

Cluster

Kubernetes 全体の管理単位

Control Plane

Cluster 全体を管理する

Node

Pod を実行するコンピューター

Pod

コンテナを実行する最小のデプロイ単位

Service

Pod への安定したアクセス先を提供する

Ingress

HTTP / HTTPS の通信を Service へルーティングする

ReplicaSet

指定した数の Pod を維持する

Deployment

ReplicaSet を管理し、更新やロールバックなどを行う

Controller

望ましい状態と現在の状態の差をなくすように動作する

kubelet

Node 上の Pod を管理する

kube-apiserver

Kubernetes API を提供する

kube-scheduler

Pod を実行する Node を決定する

etcd

Kubernetes の状態などを保存する Key-Value ストア

Kubernetes は「コンテナをどのような状態で動かしたいか」を定義し、その状態を維持するための仕組みです。

まずは「Control Plane が Cluster を管理し、Node が Pod を実行する」という全体像を押さえ、その後に Pod、Service、ReplicaSet、Deployment の関係を理解すると、Kubernetes の仕組みを整理しやすくなります。