はじめに
Kubernetes Operatorの作成の第一回として、Operatorの仕組みを説明する前に、コンテナを動かす一般名詞となったDockerとKubernetesの動作の仕組みをコンテナを立ち上げることやプロセスの状態確認の流れを説明し、違いについて理解することでKubernetesがどのように動いているのか説明します。
Dockerの動作について
まず、Dockerでコンテナを立ち上げることやプロセスの状態確認についての動作について説明します。
コンテナの起動
DockerでNginxコンテナを立ち上げる時の流れについて説明します。
まず、ユーザが「docker run -d docker.io/library/nginx:latest」をDockerクライアントで実行すると、Dockerデーモンに対してAPI命令に変換して渡します。その結果、Dockerデーモンが命令を解釈して、nginxコンテナのpullを行い、OCIランタイム上でそのコンテナを立ち上げます。その流れを図に示すと以下図1のようになります。
図1 Dockerでのnginx起動について
動作状態の確認
Dockerで、ユーザがコンテナの状態を確認する場合は、以下図2のようにDockerクラインとを使用することで、直接コンテナ状態を確認することができます。
図2 Dockerコマンドによるプロセス監視
以上のように、Dockerは、Dockerデーモンに対して様々なAPI指示を行うことで、コンテナイメージのpullや実行、状態確認をすることができます。そのことより、Dockerの動作は直接的に動作しているとも言えます。
Kubernetesの動作について
次に、Kuberentesでコンテナを立ち上げることやコンテナプロセスの状態確認についてどのように実行されているか説明します。
コンテナの起動
Kubernetesでdockerのときと同じnginxコンテナを立ち上げる場合は複雑です。その流れは図3のようになります。
図3 kubernetes上でのnginxコンテナ実行
上記図3の流れを時系列順に書くと以下の通りになります。
- ユーザがKubernetesクライアントのkubectlを使用して、コマンド「kubectl create depolyment nginx –image=nginx」を実行
- kubectlがコマンド解釈して、kube-apiserverコントローラにDeploymentリソース情報を登録
- kube-apiserverがDeploymentリソース情報をetcdに登録
- kube-controller-managerコントローラがDeploymentリソース情報の登録を検出
- kube-controller-managerがDeploymentリソース情報より、Podリソース情報を作成して登録
- kube-schedulerコントローラがPodリソース情報の登録を検出
- kube-schedulerが各Nodeの負荷状態を確認して、起動場所を指定してPodリソース情報に書き込む
- kubeletコントローラがPodリソース情報の登録を検出
- kubeletがPodリソース情報をもとに、CRIランタイム(dockerデーモンやCRI-Oなど)にコンテナ起動のAPI指示
- CRIランタイムがnginxコンテナをレジストリサーバからpull
- pullしたnginxコンテナを使用してOCIランタイムで実行
- nginxコンテナのプロセス起動
上記流れのように、Kubernetesでは、いろいろなコントローラが動作することでNginxコンテナが起動することになります。
動作状態の確認
Kubernetesでコンテナのプロセス状態を確認する方法は以下の2種類あります。
- kubeletが定期的に収集するコンテナの状態の値を確認
- CRIランタイムの制御ツールでコンテナの状態を確認
kubeletによる監視
KuberentesでPodの状態を確認する際に、kubectlクライアントでPodリソース状態を読むことで確認できます。なぜ、kubectlクライアントを使用することで確認できるのか説明します。
まず、Kubernetesでは、Kubeletが定期的にコンテナの状態を収集してkube-apiserverに送信することで、動作状態を収集しています。
nginxコンテナを立ち上げた後の状態を例にあげますと、以下図4のような動作を行っています。
図4 kubeletによるPodのヘルスチェック
上記図4のように、動作することでetcd内のPodリソースに、コンテナの動作状態が登録されるのです。
次に、kubectlクライアントによる読み取りについて動作図を図5に記載します。
図5 kubectlによるPodリソース読み込み
上記図5の動作をみると、kubectlによるPodリソースの読み取りはetcdに登録された値を見ているのに過ぎません。
CRIランタイムの確認
Kubernetesでコンテナの状態を確認するもう一つの方法として、直接CRIランタイムを操作して、状態確認する方法があります。この流れについて、図6に示しました。
図6 Kubernetesのコンテナ状態を直接確認方法(CRI-O)
上記図6について簡単に説明します。この図はCRI-Oと呼ばれるCRIランタイムでKubernetesクラスタを組んでいる際に、クラスタ内の特定PCで、CRI-Oのクライアントであるcri-toolsを使用して直接コンテナのプロセス状態を確認している絵となります。このようにKubernetesクラスタ内のコンテナ状態を直接確認することもできます。
以上の説明より、Kubernetesのコンテナプロセスの状態確認はkubeletによる収集値を間接的に確認するのか、直接コンテナが動作しているPCに接続して、専用クライアントで確認する2種類あることがわかります。後者の方法はPCの台数が多いほどコンテナが動作しているPCの特定が難しいため、kubeletによる確認が一般的になります。
まとめ
以上の説明でDockerやKubernetesでコンテナ起動や動作確認の違いについてまとめると以下表1の通りになります。
表1 DockerとKubernetesの比較
| Docker | Kubernetes | |
| 操作クライアント | docker | kubectl |
| コンテナ制御 | 直接 | 間接 |
| コンテナエンジン | docker | CRIランタイム |
| 制御 | 簡易 | 複雑 |
またKubernetesでコンテナアプリを起動させるにも、Dockerに比べて複雑な制御の結果立ち上がっていることがわかったと思います。
次回ではKubernetesの制御について解説を行い、それをカスタマイズして作るKubernetes Operatorの説明を行います。
