KubernetesのWorkloadsリソース（その1）

Workloadsリソース

連載の第3回目で、Kubernetes のリソースには、大きく分けて5つの種類があることをお話しました。今回と次回の2回に渡って、そのうちの1つであるWorkloadsリソースについて解説します。

Workloadsリソースは、クラスタ上にコンテナを起動させるのに利用するリソースです。内部的に利用されているものを除いて利用者が直接利用するものとしては、全部で8種類のWorkloadsリソースが存在します。

• Pod
• ReplicationController
• ReplicaSet
• Deployment（今回はここまで解説します）
• DaemonSet
• StatefulSet
• Job
• CronJob

Pod

Kubernetes では Workloads リソースの最小単位として、「Pod」とよばれるリソースが存在します。Pod は1つ以上のコンテナから構成されており、ネットワークは隔離されておらず、IP Addressなどは共有しています。言い換えると、2つのコンテナが入ったPodを作成した場合、2つのコンテナが同一のIP Addressを持つこととなります。そのため、Pod内のコンテナはお互いにlocalhost宛で通信することが可能です。

Pod内のNetwork Namespaceの共有

多くの場合は1つのPodに1つのコンテナを含んでいますが、Proxyの役割をするコンテナ、設定値の動的な書き換えを行うコンテナ、ローカルキャッシュ用のコンテナ、SSL終端用のコンテナなどをPod内に入れておくことで2コンテナ以上を内包したPodが利用されることもあります。このようにメインのコンテナに加えて、補助的な役割を担うコンテナを内包した形から、補助するサブコンテナのことを「サイドカー」と呼ぶこともあります。

コンテナのサイドカーパターン

Podの作成

簡単なPodのサンプルを動作させてみます。まず設定ファイルですが、下記のようなファイルからsample-podを作成します。sample-pod内にnginx:1.12イメージを使ったコンテナが1つ入っている形になっており、80番ポートを開放するだけのシンプルなPodです。

設定ファイルを元にPodを作成します。

それでは、起動したPodを確認してみましょう。

正しくコンテナが動作していることがわかります。また、リソースのもう少し詳細な情報を取得するには「--output wide（-o wide）」オプションを追加します。

2つのコンテナを内包したPodの作成

下記は2つのコンテナを内包したPodの例です。

正常に起動すると、下記のように2/2でRunning状態になっていることが確認できます。

では、下記のようにcontainerPortを両方とも80番ポートに設定して、わざと衝突させた場合はどうなるでしょうか。

実際に作成後に起動してみると、2つ目のコンテナは起動していないことがわかります。PodはNetwork名前空間を共有しているため、通常のVM上で80ポートをbindするサービスを2つ起動できないのと同じ状態になります。Pod内ではcontainerPortが衝突しないようにしましょう。

コンテナへのログイン

実際にコンテナに入って確認するには「kubectl exec」でbashを実行します。

疑似端末を生成し（-t）、標準入力をパススルー（-i）しながら/bin/bashを起動することで、あたかもコンテナにsshログインしているような状態となります。

コンテナ内を確認してみても、正しくプロセスが動作しているようです。

この他にも「kubectl exec -it sample-pod some-command」のように、色々なコマンドを実行することが可能です。

ReplicaSet/ReplicationController

ReplicaSet/ReplicationControllerはPodのレプリカを生成し、指定した数のPodを維持し続けるリソースです。

ReplicaSetリソース

当初Podのレプリカを生成するリソースはReplicationControllerという名前でしたが、Kubernetesのコンポーネントを彷彿とさせるように紛らわしかった過去の経緯から、ReplicaSetと名前を変え、合わせて一部機能の追加が行われました。細かいですが、ReplicationControllerではequality-based selectorでしたが、ReplicaSetではより強化されたset-based selectorを利用することで、柔軟なレプリケーションの設定が可能となりました。

ReplicationControllerは今後廃止の流れになっているため、基本的にはReplicaSetを利用するようにして下さい。

ReplicaSet の作成

簡単なReplicaSetのサンプルを動作させてみます。まず設定ファイルですが、下記のようなファイルから、sample-rsを作成します。spec.templateの部分には複製するPodの定義を書いておく形になります。今回の例では先ほどの単体で作成したPodを、「replicas=3」でスケールさせたReplicaSetを作成します。

設定ファイルを元にReplicaSetを作成します。

ReplicaSetを確認してみると、Podが3つ起動していることを確認できます。

実際にラベルを指定してPodを確認してみても、3つ起動していることが確認できます。

また、ReplicaSetが生成するPodは、［ReplicaSet名］−［乱数］で命名されています。

ReplicaSetの命名規則

Podの停止とオートヒーリング

ReplicaSetでは、ノードやPodに障害が発生した場合でも、Pod数を指定された数になるように別のノードでコンテナを起動してくれるため、障害時の影響を低減できます。これがKubernetesの大事なコンセプトの1つである「オートヒーリング」と呼ばれるものです。

ReplicaSet のオートヒーリング

オートヒーリングを確認するため、試しにPodを1つ削除してみましょう。

再度Podを確認すると、ReplicaSetによってすぐにPodが新規に作成されていることがわかります。

ReplicaSetのPodの増減は「kubectl describe rs」とすることで履歴を確認できます。

LabelとRepicaSet

ReplicaSetは、KubernetesがPodの監視を行うことで数を調整しています。監視は、特定のラベルがつけられたPodの数をカウントする形で実現しています。レプリカ数が不足している場合はtemplateからPodを生成し、レプリカ数が過剰な場合はラベルにマッチするPodのうち1つを削除します。

ラベルによるReplicaSetのレプリカ数維持

カウントされるPodのラベルは、下記のspec.selectorの部分で指定しています。

また、上記のReplicaSetのtemplateの例では、spec.template.metadata.labelsの部分に「app:sample-app」の設定が入っており、app:sample-appラベルが付与された状態で Pod が生成されるため、レプリカ数としてカウントされることになります。

もしわざとspec.selectorとspec.template.metadata.labelsを一致させないようにするとどうなるでしょう？　下記のリストのように不一致にすると、レプリカ数を増やそうとPodが永遠に作り続けられてしまうため、エラーが出て作成できないようになっています。

また、同じラベルを持つPodをReplicaSets外で立てた場合は、どうなるでしょう？　下記のようなlabelを持つsample-podを作成して、試してみます。

作成後にPodの状態を見てみます。「kubectl get pods -L ...」のオプションを利用することで、各Podの指定したlabelも表示することが可能です。ラベルが重複している場合、ReplicaSetはPodを増やしすぎたと誤認し、4つのPodのうち1つの停止を試みます。今回の例では最後に作成したPodが削除されているだけですが、場合によっては既存のPodが削除されることもあるため、注意が必要です。

Kubernetesの動作に熟知するまでは、Labelはユニークにつけるようにするのが適切でしょう。1つのコンテナに複数のLabelを付与することも可能なため、下記のようにルールを決めてラベリングするようにしましょう。

Podのスケーリング

ReplicaSetの設定を変更し、Podの数を変更してみましょう。方法は下記の2つがあります。

• yaml configを書き換えて「kubectl apply -f FILENAME」を実行する
• kubectl scaleコマンドを利用してスケール処理を行う

今回は「kubectl scale」を使ってスケーリングを行ってみます。scaleコマンドでスケール処理を行えるWorkloadsリソースは、Deployment、Job、ReplicaSet、ReplicationControllerの4種類のみです。

ReplicaSetの状態を確認すると、Podが増えているのがわかります。