Kubernetes の Pause コンテナとは何ですか?

導入

Kubernetes によって報告されたエラーは次のとおりです。

 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image "k8s.gcr.io/pause:3.5": failed to pull image "k8s.gcr.io/pause:3.5": failed to pull and unpack image "k8s.gcr.io/pause:3.5": failed to resolve reference "k8s.gcr.io/pause:3.5": failed to do request: Head "https://k8s.gcr.io/v2/pause/manifests/3.5": x509: certificate signed by unknown authority

k8s.gcr.io アドレスは、プルする外部ネットワークに接続されている必要があります。これにより、一時停止イメージのプルダウンに失敗し、Pod の起動に失敗します。これまで一時停止コンテナに注意を払ったことがなかったかもしれません。それは何で、何に使われるのですか、そしてなぜポッドで見たことがないのですか?この記事は、一時停止コンテナを理解するのに役立ちます。

一時停止コンテナとは何ですか?

Kubernetes では、Pod は最小のスケジューリング単位ですが、その内部構造には多くの複雑なメカニズムが満載されており、そのうちの 1 つが Pause コンテナです。 Pause コンテナは重要ではないと思われるかもしれませんが、Kubernetes クラスター全体において重要な役割を果たします。 kubernetes のノードで docker ps を実行すると、次のように各ノードで一時停止プロセスのコンテナが実行されていることがわかります。

 [root@localhost ~]# docker ps |grep traefik 66032431a20e 2ae1addee1b2 "/entrypoint.sh --gl…" 30 hours ago Up 30 hours k8s_traefik_traefik-68b9ccfc77-x8sqg_traefik_aa5b97bf-3db8-4b92-89a7-1fe551645e6a_0 10d393461904 registry.aliyuncs.com/google_containers/pause:3.5 "/pause" 30 hours ago Up 30 hours k8s_POD_traefik-68b9ccfc77-x8sqg_traefik_aa5b97bf-3db8-4b92-89a7-1fe551645e6a_0

サーバー上では多数の一時停止コンテナが実行されていることがわかります。コンテナの命名も非常に標準化されています。すると、コンテナが起動されるたびに、一時停止コンテナが起動されます。それで、それは具体的に何をするのでしょうか?これは一時停止コンテナーであり、インフラコンテナーとも呼ばれます。 Kubernetes クラスターをデプロイした後、kubelet プロセスをチェックして、構成にパラメータがあることを確認します。

 [root@localhost ~]# ps -ef|grep kubelet root 8675 1 10 Sep18 ? 03:15:07 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.5

一時停止コンテナで使用されるイメージは、registry.aliyuncs.com/google_containers/pause:3.5 です。この画像は非常に小さく、わずか 683kB です。常に一時停止（一時的）状態にあるため、一時停止と名付けられています。

 [root@localhost ~]# docker images|grep pause registry.aliyuncs.com/google_containers/pause 3.5 ed210e3e4a5b 2 years ago 683kB

一時停止コンテナの構造を知りたい場合（コードは C 言語で書かれています）、公式リポジトリにアクセスして確認できます: https://github.com/kubernetes/kubernetes/tree/master/build/pause

一時停止コンテナの役割

ネットワーク名前空間の分離: Pod は Kubernetes の最小のスケジューリング単位であり、1 つ以上のコンテナを含めることができます。コンテナ間のネットワーク分離を実現するために、各 Pod には独自の独立したネットワーク名前空間があります。 Pause コンテナは、他のコンテナによって共有されるこのネットワーク名前空間の作成と維持を担当し、他の Pod 内のコンテナと競合することなく相互に通信できるようにします。
プロセスの分離: 一時停止コンテナは、ポッド内の他のコンテナが停止している場合でも、軽量プロセスを実行し続けます。このプロセスは実際には有用な作業を実行しませんが、このプロセスが存在することで、コンテナが実行されていない状態で Pod が削除されないことが保証されます。他のコンテナが停止しても、一時停止コンテナは Pod のライフサイクルを維持するために実行されたままになります。
リソースの分離: 通常、一時停止コンテナーには大量の CPU およびメモリリソースは割り当てられませんが、一部のリソースを使用するように構成できます。これにより、ポッド内で他のコンテナが実行されていない場合でも、Kubernetes がポッドのリソース使用状況を監視および管理できるようになります。これは、同じリソース要件を持つ他のポッドによってポッドが追い抜かれるのを防ぐのにも役立ちます。
IP アドレスのメンテナンス: Pause コンテナは、Pod の IP アドレスのメンテナンスを担当します。 Pod の IP アドレスは通常は動的に割り当てられますが、Pause コンテナは常に実行されているため、他のコンテナがそのアドレスを介して通信できるように Pod の IP アドレスを維持することができます。これにより、Pod の IP アドレスが Pod の存続期間中一貫して維持されるようになります。
ライフサイクル管理: Pause コンテナのライフサイクルは Pod のライフサイクルと同じです。 Pod が作成されると、Pause コンテナが作成されます。 Pod が削除されると、一時停止コンテナも削除されます。これにより、作成、スケーリング、削除など、Pod のライフサイクル全体が Kubernetes によって管理されるようになります。

一時停止コンテナの仕組み

Pod は、ストレージとネットワークリソースを共有するコンテナのグループで構成できます。では、ネットワークリソースはどのように共有されるのでしょうか?次に例を示します。

写真

たとえば、コンテナ A とコンテナ B を含む Pod があり、それらがネットワーク名前空間を共有する必要がある場合です。 Kubernetes での解決策は次のとおりです。各 Pod に追加のインフラコンテナを作成し、Pod 全体のネットワーク名前空間を共有します。インフラコンテナーは、C 言語で記述され、常に「一時停止」状態にある、約 683 KB の非常に小さなイメージです。このようなインフラコンテナーでは、他のすべてのコンテナーが Join Namespace メソッドを通じてインフラコンテナーのネットワーク名前空間に追加されます。したがって、ポッド内のすべてのコンテナはまったく同じネットワークビューを参照します。つまり、表示されるネットワークデバイス、IP アドレス、Mac アドレス、およびその他のネットワーク関連情報はすべて、実際にはすべて、Pod によって初めて作成された Infra コンテナからのものです。これは、Pod がネットワーク共有を解決するために使用するソリューションの 1 つです。 Pod には IP アドレスが必要です。これは、Pod のネットワーク名前空間に対応するアドレスであり、インフラコンテナの IP アドレスでもあります。したがって、全員が目にするのは 1 つのコピーであり、他のすべてのネットワークリソースは Pod ごとに 1 つのコピーであり、Pod 内のすべてのコンテナーによって共有されます。これが Pod のネットワークの実装方法です。中間コンテナが必要なので、Pod 全体で最初に Infra コンテナを起動する必要があります。そして、Pod 全体のライフサイクルは、Infra コンテナのライフサイクルと同等であり、コンテナ A および B とは何の関係もありません。これは非常に重要な設計です。 Kubernetes 一時停止コンテナは、主に各ビジネスコンテナに対して 2 つのコア機能を提供します。

まず、ポッド全体の Linux 名前空間の基礎を提供します。
次に、各ポッドで PID 1 のプロセスとして実行され、ゾンビプロセスをリサイクルする PID 名前空間を有効にします。

ポッドを手動でシミュレートする

ポッドは表面的には少なくとも 1 つのコンテナで構成されていることは既にわかっていますが、実際にはポッドには少なくとも 2 つのコンテナが含まれている必要があります。1 つはアプリケーションコンテナで、もう 1 つは一時停止コンテナです。一時停止コンテナを実行します。

 [root@localhost ~]# docker run -d --name pause -p 8080:80 registry.aliyuncs.com/google_containers/pause:3.5 fd315974f5d1a5f52ca47c5dc31aea3774cebf90c88ce065cc9e9ea2f52c103c

--name: 一時停止コンテナの名前を指定します。一時停止
-p 8080:80: ホストのポート8080をコンテナのポート80にマップします

nginxコンテナを実行し、127.0.0.1:8888 springbootアプリケーションをプロキシします。

 # 准备nginx配置文件[root@k8s001 ~]# cat <<EOF >> nginx.conf error_log stderr; events { worker_connections 1024; } http { server { listen 80 default_server; server_name www.kubesre.com; location / { proxy_pass http://127.0.0.1:8888; } } } EOF # 创建nginx容器[root@localhost ~]# docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause --ipc=shareable nginx fa9f858adae826ad536178747e00fffc829c7baf98c3bc29e945230abbf2a5cb

--net=container:pause: 別のコンテナとネットワーク名前空間を共有するために使用されます。この場合、コンテナ「nginx」は「pause」という名前のコンテナとネットワーク名前空間を共有し、同じネットワーク構成とインターフェースを使用できます。
--ipc=container:pause: IPC 名前空間を別のコンテナと共有するために使用されます。 IPC 名前空間により、コンテナ間のプロセス間通信が可能になります。ここで、コンテナ「nginx」は「pause」という名前のコンテナと IPC 名前空間を共有します。
--pid=container:pause: PID 名前空間を別のコンテナと共有するために使用されます。 PID 名前空間により、コンテナは他のコンテナのプロセスを表示および管理できるようになります。
--ipc=shareable: IPC 名前空間が共有可能であり、他のコンテナもこの共有名前空間に参加できることを示します。

アプリケーションコンテナspringbootを作成する

[root@localhost ~]# docker run -d --name springboot --net=container:pause --ipc=container:pause --pid=container:pause --ipc=shareable registry.cn-shanghai.aliyuncs.com/kubesre02/springboot e33cfa3cebd5aafa714ca6ef0f6a16be52a282c64b8d24b2d98890ccf02c436a

この時点で、K8S Pod モデルに準拠した「Pod」を手動でシミュレートしましたが、これは K8S によって管理されていません。実行中のコンテナを確認して表示する

[root@localhost ]~# docker ps | grep -E "pause|nginx|springboot" 4f877cdcba5d registry.cn-shanghai.aliyuncs.com/kubesre02/springboot "java -jar /app.jar" 3 seconds ago Up 2 seconds springboot e541dc010fb3 nginx "/docker-entrypoint.…" 19 hours ago Up 19 hours nginx 09f94a052d50 registry.aliyuncs.com/google_containers/pause:3.5 "/pause" 19 hours ago Up 19 hours 0.0.0.0:8080->80/tcp, :::8080->80/tcp pause

ブラウザからhttp://ip:8080ポートにアクセスします

[root@localhost ~]# curl http://localhost:8080 Hello Docker World

上記の手順から、次のことがわかります。

一時停止コンテナーは、内部ポート 80 をホストポート 8080 にマップします。
一時停止コンテナがホスト上にネットワーク名前空間を設定した後、nginx コンテナがネットワークの名前空間に追加されます。
nginx コンテナを起動するときに、-net=container:pause が指定されます。
springboot コンテナが起動されると、同様にネットワークの名前空間に追加されます。
このようにして、3 つのコンテナーはネットワークを共有し、localhost を使用して相互に直接通信できるようになります。
--ipc=container:pause、--pid=container:pause は、3 つのコンテナの ipc と pid が同じ名前空間にあり、init プロセスが一時停止されていることを意味します。

ここで、springboot コンテナに入って以下を表示します。

 [root@localhost ~]# /tmp/test# docker exec -it springboot sh / # ps aux PID USER TIME COMMAND 1 65535 0:00 /pause 205 root 0:22 java -jar /app.jar 240 root 0:00 nginx: master process nginx -g daemon off; 261 101 0:00 nginx: worker process 263 root 0:00 sh 269 root 0:00 ps aux

springboot コンテナでは、pause コンテナと nginx コンテナのプロセスが表示され、pause コンテナの PID は 1 です。kubernetes コンテナでは、PID=1 のプロセスはコンテナ自体のビジネスプロセスです。

K8S Pod がない場合、ビジネスコンテナを起動するには、3 つのコンテナを手動で作成する必要があります。サービスを破棄する場合は、3 つのコンテナも削除する必要があります。 K8S Pod では、3 つのコンテナーは論理的に 1 つの全体になります。 Pod を作成すると 3 つのコンテナが自動的に作成され、Pod を削除すると 3 つのコンテナも削除されます。管理の観点から見ると、はるかに便利です。

これが Pod が存在する根本的な理由です。

ゾンビプロセスをリサイクルする方法

Linux では、PID 名前空間内のプロセスはツリー構造になっており、各プロセスには親プロセスがあります。ツリーのルートには、実際の親を持たないプロセスが 1 つだけあります。これは init プロセスであり、その PID は 1 です。

ゾンビプロセスとは、実行が停止しているが、プロセステーブルエントリがまだ存在しているプロセスです。 UNIX システムでは、子プロセスが終了しても親プロセスがそれを待たない場合 (wait/waitpid を呼び出す)、子プロセスはゾンビプロセスになります。

ゾンビプロセスはどのように出現するのでしょうか?

ゾンビプロセスが発生する状況の 1 つは、親プロセスが適切に記述されておらず、wait 呼び出しを省略している場合、または親プロセスが予期せずクラッシュして子プロセスより先に終了し、新しい親プロセスが wait を呼び出さない場合です。プロセスの親が子より先に終了した場合、オペレーティングシステムは子を init プロセスまたは PID 1 のプロセスに割り当てます。つまり、init プロセスは子プロセスを受け入れ、その親プロセスになります。つまり、子プロセスが終了すると、新しい親プロセス (init) は wait を呼び出して終了コードを取得する必要があります。そうしないと、プロセステーブルエントリが永久に残り、ゾンビプロセスになります。

Kubernetes ポッドでは、コンテナは上記とほぼ同じ方法で実行されますが、ポッドごとに特別な一時停止コンテナが作成されます。

この一時停止コンテナーは、関数を実行せず、基本的に永久にスリープする非常に単純なプロセスを実行します。ソースコードの実装は次のとおりです。

 /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> static void sigdown(int signo) { psignal(signo, "Shutting down, got signal"); exit(0); } static void sigreap(int signo) { while (waitpid(-1, NULL, WNOHANG) > 0); } int main() { if (getpid() != 1) /* Not an error because pause sees use outside of infra containers. */ fprintf(stderr, "Warning: pause should be the first process\n"); if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0) return 1; if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0) return 2; if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap, .sa_flags = SA_NOCLDSTOP}, NULL) < 0) return 3; for (;;) pause(); fprintf(stderr, "Error: infinite loop terminated\n"); return 42; }

上記のコードから、一時停止コンテナーはプロセスをスリープ状態にするために pause() を呼び出すだけでなく、別の重要な機能も持っていることがわかります。

自身を PID 1 と想定します。ゾンビプロセスが親プロセスによって分離されると、一時停止コンテナーによって採用され、wait を呼び出すことによってゾンビプロセスが取得されます。こうすることで、ゾンビプロセスが Kubernetes ポッドの PID 名前空間に蓄積されなくなります。

そのため、kubectl create や kubectl apply などのコマンドを使用して Pod を作成すると、通常は Pause コンテナが明示的に表示されません。これは、一時停止コンテナが Kubernetes によって自動的に作成および管理され、通常、ユーザーによる手動アクションや注意を必要としないためです。これは Pod の暗黙的な部分であり、Pod のインフラストラクチャとコンテナ間のネットワーク分離を維持するために使用されます。

このプロセスが非常に複雑であることは想像に難くありません。さらに、これらのコンテナのライフサイクルを監視および管理する方法についてもまだ詳しく説明していません。しかし、心配しないでください。Kubernetes がすでにコンテナを管理しているので、コンテナをそれほど複雑に管理する必要はありません。

<<: Kubernetes オーケストレーションツール Minikube を 1 つの記事で理解する

>>: K8S の汚染と耐性を 5 分で理解する