Kubernetes とは何か

この記事ではコンテナで動くアプリケーションを管理するための基盤である Kubernetes の仕組みを、図で説明します。Docker でコンテナを直接動かす場合と比べて何が変わるのか、コンテナのプロセスが止まったときに誰が何をするのかがわかります。

この記事はシリーズの第1回で、前提となる回はありません。Docker でコンテナを動かしたことがあれば読み進められます。

以下の図は Kubernetes の全体像を表しています。

タップで拡大クリックで拡大 （図を拡大表示する）

利用者は「nginx の Pod を 3 つ動かしてほしい」という望ましい状態を書いて渡すだけです。どのノードで動かすか、止まったときにどうするかは、Kubernetes が引き受けます。図では、右上にアイコンが付いた破線の枠がノードです。

Kubernetes とは

Kubernetes はコンテナで動くワークロード（アプリケーションなど、クラスタで動かす処理）とサービス（ここでは、アプリケーションが提供する機能のこと。後の回で扱う Service というリソースとは別の意味）を管理するための、オープンソースのプラットフォームです。公式ドキュメントは Kubernetes を 宣言的な設定と自動化の両方を進めやすくするもの と説明しています。

名前はギリシャ語で「操舵手」や「水先案内人」を意味する言葉に由来します。K と s の間の 8 文字を数えて、K8s とも略されます。Google が 2014 年にオープンソースとして公開しました。

参考：Overview | Kubernetes

Kubernetes は複数のマシンをまとめた クラスタ の上で動きます。クラスタは全体を管理するコントロールプレーンと、1 台以上のノードでできています。Kubernetes に作って管理させるもの（Pod や Deployment など）を、このシリーズではリソースと呼びます。公式ドキュメントではオブジェクト（object）とも呼ばれます。この回で使う用語を、次の表にまとめます。

参考：Kubernetes Components | Kubernetes、Controllers | Kubernetes、Nodes | Kubernetes、Pods | Kubernetes、Deployments | Kubernetes、Objects In Kubernetes | Kubernetes

それぞれの詳しい仕組みは後の回で 1 つずつ扱います。この回では、表の意味がつかめていれば十分です。

なぜ Kubernetes が必要なのか

コンテナはアプリケーションをまとめて動かすのに便利な方法です。ただし本番の環境では、アプリケーションを動かすコンテナを管理し、サービスが止まらないようにする必要があります。公式ドキュメントは「コンテナが止まったら、別のコンテナを起動する必要がある。この振る舞いをシステムが引き受けてくれたら楽ではないか」という例で、Kubernetes が必要な理由を説明しています。

参考：Overview | Kubernetes

Docker の docker run でコンテナを動かす場合、再起動ポリシー（--restart）の既定値は no です。既定のままでは、止まったコンテナは自動では再起動されません。--restart を指定すれば Docker も再起動できますが、それだけでは足りない場面があります（後の「コンテナのプロセスが止まったときの違い」で説明します）。

参考：Start containers automatically | Docker Docs

一般的に、マシンが複数台になると、どのマシンでどのコンテナを動かすか、マシンが壊れたらどこで動かし直すかも考える必要が出てきます。Kubernetes は分散したシステムを止まりにくく動かすための枠組みを提供し、アプリケーションのスケーリングや障害時の切り替えを引き受けます。公式ドキュメントが挙げる機能のうち、主なものを次の表にまとめます。

参考：Overview | Kubernetes

表の機能の多くは後の回で 1 つずつ扱うので、ここでは名前と大まかな内容だけで構いません。この回では、このうち 自己修復 と、その土台にある 宣言的な管理 を扱います。

Kubernetes の仕組み

望ましい状態を宣言して任せる

Kubernetes には「何をするか」の手順ではなく「どういう状態であってほしいか」を伝えます。これを 望ましい状態（desired state） と呼びます。

Kubernetes に作ったリソースは、公式ドキュメントの言葉では「意図の記録（record of intent）」です。リソースを作ると、Kubernetes はそのリソースが存在し続けるよう、絶えず働きます。ほとんどのリソースには spec と status という 2 つのフィールドがあります。spec には利用者が望ましい状態を書き、status には Kubernetes が実際の状態（current state）を書き込みます。コントロールプレーンはすべてのリソースの実際の状態が望ましい状態に一致するよう、継続して管理します。

参考：Objects In Kubernetes | Kubernetes

以下は nginx の Pod を 3 つ動かす Deployment のマニフェストです。公式ドキュメントの例をそのまま引用しています。

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

参考：Deployments | Kubernetes

spec の下にある replicas: 3 は「Pod を 3 つ動かしてほしい」、image: nginx:1.14.2 は「このコンテナイメージでコンテナを動かしてほしい」という望ましい状態です。どのノードで起動するか、どの順番で起動するかは書いていません。ほかのフィールドの読み方は第5回で扱います。

ほかに、この回で知っておくとよい点は次の 3 つです。

• kind: Deployment は作るリソースの種類を表すフィールド（次の回で使うツールの kind とは別物）
• spec は 2 か所にある。外側は Deployment の spec、template の下は Deployment の仕組みで作られる Pod のひな形で、その中の spec が Pod の spec
• イメージのバージョン nginx:1.14.2 は公式ドキュメントの例の値

参考：Deployments | Kubernetes、Objects In Kubernetes | Kubernetes

このマニフェストを Kubernetes に渡すと、Kubernetes は Deployment の spec を読んで nginx の Pod を 3 つ起動し、実際に動いている数などの実際の状態を status に書き込みます。マニフェストを渡すときに使うコマンドの kubectl は第3回で扱います。Pod が 1 つなくなると、status が変わります。Kubernetes は spec と status の差に反応して、代わりを起動します。何が起きたか（コンテナが止まったのか、Pod がなくなったのか）によって、誰がどう対応するかが変わります。これは後の「コンテナのプロセスが止まったときの違い」で説明します。

参考：Objects In Kubernetes | Kubernetes

この差を埋める働きを、公式ドキュメントは部屋のサーモスタット（温度調節器）にたとえています。設定温度が望ましい状態、今の室温が実際の状態で、サーモスタットは機器をつけたり止めたりして、室温を設定温度に近づけます。Kubernetes では、この役目をコントローラーが受け持ちます。公式ドキュメントはコントローラーを、クラスタの状態を見て必要な変更を行う（または求める）制御ループ（control loop）だと説明しています。このシリーズでは、コントローラーが実際の状態を望ましい状態に近づけるこの繰り返しを、調整ループ（Reconciliation Loop）と呼びます。

参考：Controllers | Kubernetes

公式ドキュメントは Kubernetes を「A をして、次に B、次に C」と決めた手順を実行するだけの仕組みではないと説明しています。Kubernetes は、独立した複数の制御の仕組みが、現在の状態を望ましい状態へ絶えず近づけるシステムです。2 つの考え方の違いを、次の表にまとめます。

参考：Overview | Kubernetes

コンテナのプロセスが止まったときの違い

ここでは、同じ nginx のコンテナを 2 通りの方法で動かし、コンテナのプロセスが止まったときに何が起きるかを比べます。1 つは docker run で直接動かす方法（再起動ポリシーは既定値の no）、もう 1 つは Deployment で Pod を 1 つ動かす方法（上のマニフェストの replicas を 1 にしたもの）です。

以下の図は、2 つの方法で動かしたコンテナがプロセスの停止と Pod の削除のあとにどうなるかを、コマ送りで表しています。

タップで拡大クリックで拡大 （図を拡大表示する）

タップで拡大クリックで拡大 （図を拡大表示する）

タップで拡大クリックで拡大 （図を拡大表示する）

タップで拡大クリックで拡大 （図を拡大表示する）

上段の docker run のコンテナは一度止まると止まったままです。下段の Pod では、コンテナの再起動と Pod の作り直しを、それぞれ別のコンポーネントが受け持っています。

コンテナを再起動するのは kubelet

コンテナのプロセスが止まったとき、コンテナを再起動するのは、Pod が動いているノードの kubelet です。Pod の spec には restartPolicy というフィールドがあり、値は Always、OnFailure、Never のどれかで、既定値は Always です。Always のとき、kubelet はコンテナがどんな理由で終了しても再起動します。この再起動は 同じノードの同じ Pod の中で、コンテナを動かし直すもの です。

参考：Pod Lifecycle | Kubernetes

restartPolicy はマニフェストでは template の下の spec（Pod の spec）に書くフィールドです。Deployment で作る Pod では、restartPolicy に Always しか指定できません（上の例のように書かなければ Always になります）。そのため、Deployment で動かしたコンテナは、止まるたびに kubelet が再起動します。

参考：Deployments | Kubernetes

Pod を作り直すのは Deployment の仕組み

Pod そのものが削除されたとき（たとえば、操作を誤って Pod を消してしまったとき）や、ノードが故障したときは、kubelet による再起動では戻せません。kubelet の再起動は同じ Pod の中でコンテナを動かし直すものだからです。ここで働くのが Deployment です。

正確には、Deployment は ReplicaSet というリソースを作ります。ReplicaSet は同じ Pod を指定した数だけ動かし続けるためのリソースです。Deployment も ReplicaSet も望ましい状態の記録で、それ自体が Pod を作るわけではありません。記録を読んで動くのは、コントロールプレーンの kube-controller-manager の中で動くコントローラーです。ReplicaSet を担当するコントローラーは、指定された数になるよう、必要に応じて Pod を作ったり削除したりします。

ノードが故障した場合は、そのノードの Pod が動かなくなったことにコントローラーが気づき、代わりの Pod を作ります。代わりの Pod を正常なノードに配置するのは kube-scheduler です。

参考：Deployments | Kubernetes、ReplicaSet | Kubernetes、Controllers | Kubernetes、kube-controller-manager | Kubernetes、Pods | Kubernetes、Kubernetes Components | Kubernetes

起きたことごとに、誰が何をするかを次の表にまとめます。

コンテナの再起動は kubelet が restartPolicy に従って行うので、Deployment を使わずに作った Pod でも起きます。Deployment が加えるのは、Pod そのものを作り直して数を保つ仕組みです。公式ドキュメントは Pod を 1 つだけ動かす場合でも Pod を直接作らず、Deployment などを使う よう勧めています。

参考：Pod Lifecycle | Kubernetes、Pods | Kubernetes

この回はまだクラスタが手元にない前提なので、手元で試す手順は載せていません。次の回で検証用クラスタを作ります。Deployment の Pod を削除したあとに作り直される様子は第6回で、コンテナの再起動の様子は第9回で試します。

注意点

Kubernetes を学び始めるときに誤解しやすい点を、次の表にまとめます。

参考：Overview | Kubernetes、Pods | Kubernetes、Pod Lifecycle | Kubernetes、Object Names and IDs | Kubernetes、Nodes | Kubernetes、Cluster Architecture | Kubernetes

再起動しても直らない障害では、コンテナが止まる原因（アプリケーションの不具合や設定の誤りなど）を取り除く必要があります。自己修復は原因まで直してくれるわけではありません。

参考：Pod Lifecycle | Kubernetes

関連記事

次の回で使う kind は Docker のコンテナをノードとして使い、手元のマシンにクラスタを作るツールです。手元に検証用クラスタを作る手順は、次の回で解説しています。

参考：kind

基本仕様 第2回 kind で検証用のクラスタを作るDocker のコンテナをノードにして、手元のマシンに Kubernetes のクラスタを作るツール kind の仕組みを図で説明します。kind create cluster で何が起きるかを押さえ、シングルノードとマルチノードのクラスタを作って、ノードの正体が Docker のコンテナであることを確かめる手順を紹介します。

コントロールプレーンとノードの中で動くコンポーネントについては、以下の記事で解説しています。

基本仕様 第4回 コントロールプレーンとノードの構成クラスタを形づくるコントロールプレーンとノードの構成を図で説明します。kube-apiserver・etcd・kube-scheduler・kube-controller-manager と、kubelet・コンテナランタイム・kube-proxy の役割を押さえ、kind のクラスタで kube-system の Pod を一覧して各コンポーネントと対応づける手順を紹介します。

実際の状態を望ましい状態に近づける調整ループについては、以下の記事で解説しています。

基本仕様 第6回 消した Pod が戻ってくる仕組み（調整ループ）コントローラーが実際の状態を望ましい状態に近づけ続ける調整ループの仕組みを図で説明します。Deployment・ReplicaSet・Pod の関係と、Pod を消したときに誰が気づいて代わりを作るのかを押さえ、kind のクラスタで Deployment の Pod を手で削除し、作り直される様子を観察する手順を紹介します。