Kubernetes のマルチコンテナ Pod と Pod 内のコンテナ間通信

コンテナはマイクロサービスなどの単一の問題を解決するためによく使用されますが、実際のシナリオでは、問題を解決するには複数のコンテナ ソリューションが必要になることがよくあります。この記事では、複数のコンテナを単一の Kubernetes Pod に統合する方法と、Pod 内のコンテナが相互に通信する方法について説明します。

[[282920]]

1. Kubernetes Podについて

1.1 Kubernetes Pod とは何ですか?

まず、Pod とは何かについて説明しましょう。 Pod は、Kubernetes でデプロイおよび管理可能な最小の単位です。つまり、Kubernetes で単一のコンテナを実行する必要がある場合は、そのコンテナ用の Pod を作成する必要があります。同時に、Pod には複数のコンテナを含めることができ、多くの場合、コンテナは密接に結合されています。タイトカップリングとは何ですか?ポッド内の複数のコンテナが、同じサーバー上で実行する必要がある複数のプロセスを表すシナリオを想像してみてください。この類推は、多くの点で Pod がサーバーに似ているため、理にかなっています。たとえば、各コンテナは localhost を介してそのポッド内の他のコンテナにアクセスできます。

1.2 Kubernetes では、デプロイ可能な最小単位として単一のコンテナではなく Pod を使用するのはなぜですか?

単一のコンテナを直接デプロイする方が簡単かもしれませんが、Pod の新しい抽象化レイヤーを追加すると、新たな利点がもたらされます。コンテナは、特定のものを表す実際のエンティティです。この「何か」は、Docker コンテナまたは rkt コンテナになります。それぞれの「もの」には異なる目的があります。コンテナを管理するには、Kubernetes には、コンテナが終了したときに再起動する方法を定義する再起動ポリシーや、Web サーバー プロセスが HTTP 要求に応答できるかどうかなど、アプリケーションの観点からコンテナ内のプロセスがアクティブかどうかを検出する方法を定義するライブネス プローブなどの追加の情報が必要です。

既存のコンテナ エンティティにこれらの新しい属性が追加されないようにするために、Kubernetes アーキテクトは新しいエンティティである Pod を使用することを決定しました。論理的には 1 つ以上のコンテナーが含まれます。

1.3 Kubernetes では、なぜ Pod 内に 1 つ以上のコンテナが存在することを許可するのですか?

Pod 内のコンテナは論理的な「ホスト」上で実行されます。これらは同じネットワーク名前空間 (つまり、同じ IP アドレスとポート空間)、同じ IPC (プロセス間通信) 名前空間を使用し、共有ボリュームも使用します。これらの機能により、Pod 内のコンテナは効率的に相互に通信できるようになります。同時に、Pod を使用すると、密に結合された複数のアプリケーション コンテナーを単一のエンティティとして管理できます。

したがって、アプリケーションを同じサーバー上の複数のコンテナーで実行する必要がある場合、すべてを 1 つのコンテナーに配置してはいかがでしょうか。まず第一に、それは「コンテナごとに 1 つのプロセス」仕様に違反することになります。この仕様が重要なのは、コンテナ内に複数のプロセスがある場合、異なるプロセスのログが混在し、これらのプロセスのライフサイクルを管理するのが難しくなるため、デバッグが非常に困難になるためです。 2 番目に、アプリケーションに複数のコンテナを使用すると、よりシンプルでわかりやすくなり、ソフトウェアの依存関係が分離されます。さらに、より細かい粒度のコンテナをチーム間で再利用できます。

1.4 マルチコンテナポッドの使用例

マルチコンテナ Pod の主な目的は、共存および共同管理されるヘルパー プロセスをサポートすることです。プロセスを支援する一般的なシナリオはいくつかあります。

サイドカー コンテナー: たとえば、ログまたはデータ変更モニター。チームがログウォッチャーを作成すると、さまざまなアプリケーションで使用できるようになります。サイドカー コンテナーのもう 1 つの例は、メイン コンテナーのデータを生成するファイル ローダーまたはデータ ローダーです。

プロキシ、ブリッジ、アダプター: メイン コンテナーを外部に接続します。たとえば、Apache HTTP サーバーまたは nginx は静的ファイルを読み取ります。メイン コンテナー内の Web アプリケーションのリバース プロキシとしても使用できます。

マルチティアアプリケーション (WordPress など) を Pod で実行する場合、各ティアに個別の Pod を使用することをお勧めします。最も単純な理由は、これにより各レイヤーを個別にスケーリングし、異なるノードに分散できるようになることです。

2. ポッド内のコンテナ間の通信

Pod 内で複数のコンテナを実行すると、コンテナ間の通信が非常に簡単になります。独自のコミュニケーション方法がいくつかあります。

2.1 共有ボリューム経由の通信

Kubernetes では、Pod 内のコンテナは、データを共有するためのシンプルで効率的な方法として共有ボリュームを使用できます。ほとんどのシナリオでは、ホスト上の単一のディレクトリを使用し、それを複数のコンテナー間で共有するのが効率的なアプローチです。

Kubernetes ボリュームを使用すると、コンテナの再起動後もデータを保持できます。ボリュームのライフサイクルはポッドと同じです。つまり、ポッドが存在する限り、ボリュームも存在することになります。 Pod が削除された場合、同一の Pod が作成されたとしても、元の Pod の共有ボリュームは破棄され、新しい共有ボリュームが作成されます。

ポッド内の複数のコンテナで共有ボリュームを使用する標準的な使用例は、1 つのコンテナがログやその他のファイルを共有ディレクトリに書き込み、他のコンテナが共有ディレクトリからデータを読み取る場合です。たとえば、次の Pod を作成します。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: mc1
仕様:
 ボリューム:
  -名前:html
   空ディレクトリ: {}
 コンテナ:
  -名前: 1st
   画像: nginx
   ボリュームマウント:
    -名前:html
     マウントパス: /usr/share/nginx/html
  -名前: 2番目
   画像: debian
   ボリュームマウント:
    -名前:html
     マウントパス: /html
   コマンド: [ "/bin/sh" , "-c" ]
   引数:
     -真の場合;する
日付>> /html/ index .html;
         睡眠1;
       終わり

この例では、html という名前のボリュームが定義されています。そのタイプは emptyDir です。つまり、Pod がノードに割り当てられると、空のディレクトリに基づいてボリュームが作成され、Pod が実行されている限りボリュームが存在することになります。最初のコンテナは nginx サーバーを実行し、共有ボリュームを /usr/share/nginx/html ディレクトリにマウントします。 2 番目のコンテナは Debian イメージを使用し、共有ボリュームを /html ディレクトリにマウントします。 2 番目のコンテナは、毎秒、現在の日付と時刻を共有ボリューム内の index.html ファイルに書き込みます。ユーザーが Pod に HTTP リクエストを送信すると、Nginx はこのファイルの内容を読み取り、ユーザーに返します。

nginx ポートを公開するか、ブラウザでアクセスするか、コンテナの共有ディレクトリを直接確認することで、Pod を検査できます。

 $ kubectl exec mc1 -c 1st -- /bin/cat/usr/share/nginx/html/index.html  
 ...
 2019年8月25日金曜日 18:36:06 UTC 
  
 $kubectl exec mc1 -c 2番目-- /bin/cat /html/index.html  
 ...
 2019年8月25日金曜日 18:36:06 UTC
 2019年8月25日金曜日 18:36:07 UTC

2.2 プロセス間通信 (IPC)

Pod 内のコンテナは同じ IPC 名前空間を共有します。つまり、SystemV セマフォや POSIX 共有メモリなどの標準のプロセス間通信方法を使用して相互に通信できます。

次の例では、2 つのコンテナを含む Pod を定義します。同じ画像を使用します。最初のコンテナーはプロデューサーであり、標準の Linux メッセージ キューを作成し、いくつかのランダムな文字列をキューに書き込み、その後に特殊な終了文字を書き込みます。 2 番目のコンテナーはコンシューマーであり、同じキューを開いて、特殊な終了文字を読み取るまで文字を読み取ります。 Pod の再起動ポリシーを「Never」に設定しているため、両方のコンテナが終了した後に Pod は停止します。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: mc2
仕様:
 コンテナ:
  -名前：プロデューサー
   画像: allingeek/ch6_ipc
   コマンド: [ "./ipc" , "-producer" ]
  -名前: 消費者
   画像: allingeek/ch6_ipc
   コマンド: [ "./ipc" , "-consumer" ]
 再起動ポリシー: なし

Pod の実行後、各コンテナのログをチェックして、特定の終了メッセージを含む、2 番目のコンテナが 1 番目のコンテナからのすべてのメッセージを受信したことを確認します。

 $ kubectl ログ mc2 -c プロデューサー
...
生産: f4
生産: 1日
制作: 9e
生産数: 27
 $ kubectl ログ mc2 -c コンシューマー
...
消費: f4
消費: 1d
消費: 9e
消費: 27
消費: 完了

デフォルトでは、1 つのコンテナを別のコンテナの後に起動するように指定する方法がないため、Pod 内のすべてのコンテナは並行して起動されます。たとえば、IPC の例では、最初のコンテナが起動されてメッセージ キューが作成される前に、2 番目のコンテナが起動される可能性があります。この時点で、2 番目のコンテナーは失敗するため、起動時にメッセージ キューが既に存在している必要があります。

Kubernetes Init Containers など、コンテナの起動順序を制御する方法はいくつかあり、初期化コンテナが最初に起動されます。しかし、クラウドネイティブ環境では、あらゆる制御不能な障害に備えることが最善です。たとえば、上記の問題を解決する最善の方法は、メッセージ キューが作成されるまで待機するようにアプリケーションを変更することです。

2.3 コンテナ間のネットワーク通信

Pod 内のコンテナは同じネットワーク名前空間を使用するため、「localhost」を介して相互に通信できます。さらに、コンテナの場合、ホスト名は Pod の名前になります。 Pod 内のすべてのコンテナは同じ IP アドレスとポート空間を共有するため、接続を受信する必要があるコンテナごとに異なるポートを割り当てる必要があります。つまり、Pod 内のアプリケーションはポートの使用を自ら調整する必要があります。

次の例では、1 つのコンテナで Nginx を実行し、別のコンテナで実行されている Web アプリケーションのリバース プロキシとして機能するマルチコンテナ Pod を作成します。

（1）ステップ1、nginx設定ファイルのConfigMapを作成します。ポート 80 から受信した HTTP リクエストは、ローカルホストのポート 5000 に転送されます。

 APIバージョン: v1
種類: ConfigMap
メタデータ:
名前: mc3-nginx-conf
データ：
 nginx.conf: |-
ユーザーnginx;
   ワーカープロセス 1; 
  
   error_log /var/log/nginx/error.log 警告;
   pid /var/run/nginx.pid; 
  
   イベント {
       ワーカー接続 1024;
    } 
  
   http {
       /etc/nginx/mime.types を含めます。
       デフォルトタイプ アプリケーション/オクテットストリーム; 
  
       ファイル送信オン;
       キープアライブタイムアウト65; 
  
       アップストリームウェブアプリケーション {
           サーバー 127.0.0.1:5000;
       }

（2）ステップ2：2つのコンテナのポッドを作成します。1つのコンテナはnginxを実行し、もう1つのコンテナは単純なWebアプリケーションを実行します。 Pod にはポート 80 のみを定義していることに注意してください。ポート 5000 には Pod の外部からアクセスできません。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: mc3
 ラベル:
   アプリ: mc3
仕様:
 コンテナ:
  -名前: ウェブアプリ
   画像: トレーニング/ウェブアプリ
  -名前: nginx
   画像: nginx:alpine
   ポート:
    -コンテナポート: 80
   ボリュームマウント:
    -名前: nginx-proxy-config
     マウントパス: /etc/nginx/nginx.conf
     サブパス: nginx.conf
 ボリューム:
  -名前: nginx-proxy-config
   構成マップ:
名前: mc3-nginx-conf

ポッド内のポートスペースを確認すると、ポート 80 と 5000 が表示されます。

 # ネットスタット -lntp
アクティブなインターネット接続（サーバーのみ）
プロトコル 受信Q 送信Qローカルアドレス外部アドレス 状態 PID/プログラム名 
 tcp 0 0 0.0.0.0:80 0.0.0.0:* 聞く -
 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 1/python

（3）ステップ3：PodをNodePortサービスとして公開する

$ kubectl ポッド mc3 を公開--type=NodePort--port=80  
サービス「mc3」が公開されました

（4）ステップ4：サービスを確認する

[root@master1 ~]# kubectl describe svc mc3
名前: mc3
名前空間: testproject
ラベル: app=mc3
注釈: <なし>
セレクター: app=mc3
タイプ: NodePort
 IP: 172.30.34.232
ポート: <未設定> 80/TCP
ターゲットポート: 80/TCP
ノードポート: <未設定> 32728/TCP
エンドポイント: 10.130.0.190:80
セッションアフィニティ: なし
外部トラフィックポリシー: クラスター
イベント: <なし>

これで、ブラウザまたは curl ツールを使用して Web アプリケーションにアクセスできるようになります。

 [root@master1 ~]# カール 10.70.209.68:32728
こんにちは世界！

nginx コンテナのポート 80 で受信した HTTP リクエストは、Web アプリケーション コンテナのポート 5000 に転送されます。

上記の例では、ポッド内の 1 つのコンテナが他のコンテナにアクセスするだけを示しています。実際、Pod 内の複数のコンテナが異なるポートをリッスンし、それらのポートがすべて公開されるのが一般的です。これを実装するには、複数のポートを公開するサービスを作成するか、公開するポートごとにサービスを作成します。

3. まとめ

Kubernetes は、Pod コンセプトを作成することで、コンテナの動作とコンテナ間の通信のオーケストレーションに非常に便利です。コンテナはストレージ ボリュームを共有し、ネットワークや IPC を介して相互に通信できます。

元記事: https://www.mirantis.com/blog/multi-container-pods-and-container-communication-in-kubernetes/

原作者: パベル・チェキン