2021.09.16

Operator作成について 連載第1回目 DockerとKubernetesの動作について

文:

Operator作成について説明する前段階として、DockerとKubernetesのコンテナ起動やプロセス確認の動作について説明します。

CONTENTS

この記事をシェア:

Facebook Twitter LINE

はじめに

 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の流れを時系列順に書くと以下の通りになります。

  1. ユーザがKubernetesクライアントのkubectlを使用して、コマンド「kubectl create depolyment nginx –image=nginx」を実行
  2. kubectlがコマンド解釈して、kube-apiserverコントローラにDeploymentリソース情報を登録
  3. kube-apiserverがDeploymentリソース情報をetcdに登録
  4. kube-controller-managerコントローラがDeploymentリソース情報の登録を検出
  5. kube-controller-managerがDeploymentリソース情報より、Podリソース情報を作成して登録
  6. kube-schedulerコントローラがPodリソース情報の登録を検出
  7. kube-schedulerが各Nodeの負荷状態を確認して、起動場所を指定してPodリソース情報に書き込む
  8. kubeletコントローラがPodリソース情報の登録を検出
  9. kubeletがPodリソース情報をもとに、CRIランタイム(dockerデーモンやCRI-Oなど)にコンテナ起動のAPI指示
  10. CRIランタイムがnginxコンテナをレジストリサーバからpull
  11. pullしたnginxコンテナを使用してOCIランタイムで実行
  12. 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の比較

DockerKubernetes
操作クライアントdockerkubectl
コンテナ制御直接間接
コンテナエンジンdockerCRIランタイム
制御簡易複雑

 またKubernetesでコンテナアプリを起動させるにも、Dockerに比べて複雑な制御の結果立ち上がっていることがわかったと思います。

次回ではKubernetesの制御について解説を行い、それをカスタマイズして作るKubernetes Operatorの説明を行います。

今解決したいDXの
お困りごとなんですか?

DXの知識、導入事例を知りたい DXの知識、導入事例を知りたい セミナーに参加する

今取り組むべき事業のDX推進や、本当に活用できるコンテナ製品の導入プランをご紹介しています。お気軽に無料ウェビナーにご参加ください。

何から手をつけていいか分からない 何から手をつけていいか分からない サービスソリューションをみる

DX推進に取り組みたいが詳しい人材がいない。
まずどこから始めればいいのか、どういう方法があるのかイメージが掴め切れていない。

自社の具体的な導入を検討している 自社の具体的な導入を検討している 各種お問い合わせへ

コンテナ製品のご提案や人材育成支援も行います。事業のDX推進でお困りの方は、こちらからお問い合わせください。