K8s のポッドとコンテナの設計パターン

著者: Qiu Ming、PaaS 製品部門、中国モバイル クラウド機能センター

近年、コンテナ技術は急速に世界を席巻し、アプリケーションの開発、配信、運用モードを覆しています。コンテナ テクノロジーは、クラウド ネイティブ テクノロジーの分野の技術的な基礎として、今日最も人気のあるサーバー側テクノロジーの 1 つでもあります。コンテナとコンテナオーケストレーション技術は、インフラストラクチャ分野で最もホットなキーワードとなっています。コンテナとそれを取り巻くエコシステム技術の活発な発展により、コンテナ コミュニティはオープン ソース コミュニティで最も活発なエコシステムの 1 つになりました。同時に、コンテナ技術を中核とするコンテナエコシステムは、クラウドコンピューティングやインターネットなどの分野で広く利用されるようになりました。

01コンテナの概念

コンテナ技術の概念は 2000 年にはすでに登場しており、当初は chroot 環境でのプロセス分離に使用されていました。 2013 年に Docker プロジェクトが正式にリリースされ、Linux コンテナ テクノロジーが徐々に世界を席巻するようになりました。 2014 年に Kubernetes プロジェクトが正式にリリースされ、コンテナ テクノロジはオーケストレーション システムと連携して進歩し始めました。

コンテナの本質は、分離を試み、リソースが制限されているプロセスです。使用される分離テクノロジはすべて Linux カーネルに基づいており、リソースの分離には名前空間が使用され、リソースの制限 (CPU、メモリ、ストレージ、ネットワークの使用制限) には cgroup が使用されます。言及する必要がある分離テクノロジの 1 つは仮想マシンです。以下の仮想マシンとコンテナの比較表から、仮想マシンの動作原理の最も重要な部分はハイパーバイザー層であることがわかります。ハイパーバイザー層は、ハードウェア仮想化機能を実行し、オペレーティング システムの実行に必要なさまざまなハードウェア (CPU、メモリ、I/O デバイスなど) をシミュレートし、これらの仮想ハードウェアにオペレーティング システムのゲスト OS をインストールします。コンテナには独自の OS はありませんが、コンテナ デーモンを通じてホスト カーネルを直接共有します。コンテナ プロセスに対するすべての制限は、ホスト オペレーティング システム自体の機能に基づいています。そのため、コンテナも非常に軽量です。

02ポッドコンセプト

2.1 オペレーティングシステムの例

まず、仮想マシンで簡単な Java プログラムを実行し、次に pstree コマンドを実行すると、この Java プログラムが実際にはスレッドのグループ (Linux の場合) で構成されており、スレッドがリソースを共有して連携して Java プログラムの業務作業を完了していることがわかります。

2.2 ポッド実装の原則

クラウド時代のオペレーティングシステムとして称賛されているKubernetesでは、コンテナはプロセスに例えられますが、ではポッドはどうでしょうか?実際、Pod は単なる抽象的な論理概念です。これは、前の例の Java プログラムと比較できます。これは、同じネットワーク (ネットワーク名前空間)、ストレージ (ボリューム)、およびその他のリソースを共有するグループ (1 つ以上の) コンテナーのコレクションです。

2.2.1 ネットワーク共有

まず、Pod 内にインフラストラクチャ コンテナが作成されます。次に、他のコンテナは、ネットワーク名前空間に参加することで、インフラストラクチャ コンテナのネットワークに関連付けられます。これにより、ポッド内のコンテナ間でネットワーク リソースを共有できるようになります。したがって、ベース コンテナは常に Pod 内で最初に作成されるコンテナであり、他のコンテナが参加するのを待機します。 Pod のライフサイクルは、基盤となるコンテナのライフサイクルとのみ一致します。基本的なコンテナは、k8s.gcr.io/pause と呼ばれる非常に小さなイメージで、サイズは約 100 ～ 200 KB です。これはアセンブリ言語で記述されたコンテナであり、常に「一時停止」状態にあります。

2.2.2 ストレージ共有

ポッドはボリュームを通じて共有ストレージを実装します。最初にポッドがボリュームにバインドされ、その後、ポッド内のコンテナはボリュームをマウントすることを宣言している限り、ボリュームに対応するホスト ディレクトリを共有できます。すべてのコンテナに表示されるボリューム ディレクトリの内容は同じです。次の YAML ファイルは、単一の Pod で 2 つのコンテナを起動する例を示しています。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: 1 つのポッド、 2 つのコンテナ、 デモ
仕様:
 ボリューム: #Podは最初にボリュームをバインドします
- 名前: 共有- ログ
空のディレクトリ: {}
 コンテナ:
 - 名前: ウェブ- nginx
 画像: nginx
 volumeMounts : #コンテナはこのボリュームをマウントします
- 名前: 共有- ログ
マウントパス: /var/ log / nginx
 - 名前： サイドカー- コンテナ
画像: ビジーボックス
コマンド: [ "sh" 、 "-c" 、 "true の間、cat /var/log/nginx/access.log /var/log/nginx/error.log を実行します。30 分間スリープします。完了" ]
 volumeMounts : #コンテナはこのボリュームをマウントします
- 名前: 共有- ログ
マウントパス: /var/ log / nginx

03コンテナデザインパターン

Kubernetes コミュニティは、Kubernetes クラスターのマイクロサービス モデルに基づいて、一般的な分散システムの問題を解決する一連のコンテナー設計パターンを提案しています。それらは 3 つのカテゴリに分類できます。

• 単一コンテナ管理モード。
• 単一ノード マルチコンテナ モード。
• マルチノード、マルチコンテナ モード。

3.1 単一コンテナ管理モード

Kubernetes コンテナ設計モードでは、単一コンテナ管理モードが最もシンプルです。単一のコンテナ マイクロサービス インスタンスを起動するコマンドは、Docker ネイティブ コマンドに似ています。

 kubectl run nginx --image=nginx:latest -n qiuqiu を実行します。
 pod/nginx が作成されました

$ kubectl get all -n qiuqiu
名前 準備完了 ステータス 再起動 年齢
pod/nginx 1/1 実行中 0 9s 

3.2 シングルノードマルチコンテナモード

関心の分離 (SOC) の原則に基づき、コンテナ化されたアプリケーションはコンテナ間の責任を分離します。各コンテナは、最も得意とする業務のみを実行し、その他の追加タスクは他のコンテナ (サイドカー コンテナ) に割り当てる必要があります。シングルノード マルチコンテナ モードでは、Kubernetes の Pod 内のすべてのコンテナが同じストレージ スペース (ボリューム) とネットワーク アドレス スペース (ネットワーク名前空間) を共有できるという事実を利用して、SOC の原則を完全に反映します。

3.2.1 サイドカーパターン

サイドカー モードは、主に同じポッド内のコンテナのストレージ共有機能を活用します。次の図は、アプリケーション ログ収集サービスのシナリオを示しています。アプリケーション サービス A (Nginx など) の場合、ログ (access.log など) の永続的な保存と管理に重点が置かれているわけではありませんが、運用および保守担当者がサービスの異常をトラブルシューティングするためにログを使用する必要がある場合があります。したがって、ログ コレクター サービスは必要な補助ツールです。関心の分離 (SOC) の原則に従って、ログ コレクター サービスのサイドカー コンテナーをアプリケーション サービスの Pod に追加できます。アプリケーション サービス コンテナーはメイン コンテナーとしてビジネスにのみ集中する必要があり、ログ情報はサイドカー コンテナーによって収集および処理されます。実稼働環境では、Filebeat や Logstash などのツールを使用してログを収集し、ElasticSearch クラスターに配布できます。サイドカー モードでは、通常補助ツールとして使用されるサイドカー コンテナー イメージが標準化され、再利用可能になるため、反復的なアップグレードを行うたびにアプリケーション サービスを補助ツールの実行可能ファイルとともにパッケージ化する必要がありません。

次の yaml ファイルは、Pod を定義し、2 つのコンテナ (ベース コンテナを除く) を起動し、emptyDir ボリュームを共有ストレージとして使用します。サイドカー コンテナは通常、定義の 2 番目にリストされるため、kubectl コマンドを実行すると、デフォルトのターゲットはメイン コンテナになります。 Nginx サービスがメイン コンテナとして使用され、生成されたログは共有ストレージ ボリュームにマウントされた /var/log/nginx ディレクトリに書き込まれます。これにより、Nginx サービス ログがコンテナの標準出力形式で出力されるのを防ぎ (つまり、/dev/stdout および /dev/stderr にソフト接続されてコンテナのフォアグラウンド ログに出力されるのを防ぎ)、access.log ファイルと error.log ファイルに書き込みます。最後に、サイドカー コンテナ (busybox) が関連するログを処理します。

 APIバージョン: v1
種類: ポッド
メタデータ:
 名前: アプリログ集約サーバー
仕様:
 ボリューム:
 - 名前: 共有ログ
 空ディレクトリ: {}
 コンテナ:
 - 名前: nginx
 画像: nginx
 ボリュームマウント:
 - 名前: 共有ログ
 マウントパス: /var/log/nginx
 - 名前: サイドカーコンテナ
 画像: ビジーボックス
 コマンド: ["sh","-c","true の間、cat /var/log/nginx/access.log /var/log/nginx/error.log を実行します。30 分間スリープします。完了"]
 ボリュームマウント:
 - 名前: 共有ログ
 マウントパス: /var/log/nginx 

3.2.2 アンバサダーパターン

ディプロマット モードは、主に同じ Pod 内のコンテナがネットワーク アドレス空間を共有できる機能を使用します。ディプロマット パターンには、ディプロマット コンテナーとも呼ばれるサイドカー コンテナー (SideCar コンテナー) があり、アプリケーション コンテナーから他のサービスへの接続をプロキシする役割を担います。たとえば、ほとんどすべてのアプリケーションでは、ある段階でデータベース接続が必要になります。アプリケーション開発の反復には、開発データベース、テスト データベース、運用データベースなど、複数の環境データベースが存在します。アプリケーションの Pod を作成する場合、開発者/実装者は、環境変数または configMap を通じてデータベース接続構成項目を変更することで、データベースを切り替えることができる必要があります。この場合、実行環境に応じて、外交官モードを使用して、データベース接続を対応するデータベースにプロキシすることもできます。開発者/実装者は、構成項目を変更する必要はありません (開発環境のデータベース構成項目を使用する場合と同様)。テスト環境または本番環境にデプロイされると、Diplomat コンテナーは実行されている環境 (リフレクション モードなど) を検出し、正しいデータベースに接続します。

次の YAML ファイルは、さまざまな環境の Redis ライブラリにアクセスする Redis クライアントの例を示しています。メイン コンテナーは Redis クライアントによって提供され、Diplomat コンテナーは malexer/twemproxy イメージに基づいて起動されるコンテナーであり、Redis データ サービスへのリレー リンクを提供します。 malexer/twemproxy イメージでは、Redis インスタンスを address:port:weight の形式で環境変数として渡す必要があることに注意してください (行 13 ～ 15)。デフォルトでは、コンテナはポート 6380 をリッスンします (追加の高度な構成は github で入手できます: https://github.com/malexer/docker-twemproxy)。

 # Redis クライアント yaml
 APIバージョン: v1
種類: ポッド
メタデータ:
 名前空間: qiuqiu
 名前: 大使例
仕様:
 コンテナ:
 - 名前: redis-client
 画像: redis
 - 名前: 大使
 画像: malexer/twemproxy
 環境:
 - 名前: REDIS_SERVERS
 値: redis-st-0.redis-svc.qiuqiu.svc.cluster.local:6379:1
 ポート:
 - コンテナポート: 6380 

次の図は、アプリケーション (Redis クライアントによってシミュレート) が localhost:6380 への要求を開始し、Diplomat コンテナーが要求を受信して​​、構成で定義されている Redis サーバーに転送することを示しています。

3.2.3 アダプタパターン

アダプタ パターンは主に、標準化および正規化されたアプリケーションを通じてサービス インターフェイスを外部に公開します。各アプリケーションは、さまざまな形式 (JSON、XML、StatsD など) で監視インジケーター データを出力できます。ただし、監視システムは、統一されたデータ モデルでデータを受信することを期待しています。このとき、アダプタ パターンを使用して、同じ Pod 内にアプリケーション コンテナと対応する監視指標データ変換用のアダプタ コンテナを作成し、異なるアプリケーションの異種監視指標データを 1 つの統一されたモデル データに変換することができます。

次の yaml は、Prometheus を使用して Nginx サービスのステータス インジケーターを監視する例です。 Nginx には Web サーバーの状態を照会するためのインターフェースがあり、default.conf ファイルの構成項目を変更するだけで有効にできます。次に、このインターフェースの出力を Prometheus に必要なデータ形式に変換するアダプター コンテナーを追加します。 default.conf ファイルの内容を configMap で設定します。ここで (行 20 ～ 24)、stub_status モジュールを使用して Nginx のステータス情報を表示するインターフェイス (/nginx_status) を定義します。次に、Nginx コンテナとアダプタ コンテナを含む Pod を作成します。アダプター コンテナーは、nginx/nginx-prometheus-exporter イメージを使用して作成されます。このイメージは、Nginx によって /nginx_status インターフェイスで公開されるインジケーター データ形式を Prometheus 形式に変換します。

 # Nginx の設定
APIバージョン: v1
種類: ConfigMap
メタデータ:
 名前空間: qiuqiu
 名前: nginx-conf
データ：
 デフォルト.conf: |
 サーバー{
 聞く 80;
 server_name ローカルホスト;
 位置 / {
 ルート /usr/share/nginx/html;
 インデックス index.html index.htm;
 }
 エラーページ 500 502 503 504 /50x.html;
 場所 = /50x.html {
 ルート /usr/share/nginx/html;
 }
 場所 /nginx_status {
 スタブステータス;
 127.0.0.1 を許可します。 #ローカルホストからのリクエストのみ許可する
 すべてを否定する; #他のすべてのホストを拒否
 }
 }




 # Nginx Podとアダプタコンテナ
APIバージョン: v1
種類: ポッド
メタデータ:
 名前空間: qiuqiu
 名前: ウェブサーバー
仕様:
 ボリューム:
 - 名前: nginx-conf
 構成マップ:
 名前: nginx-conf
 アイテム:
 - キー: default.conf
 パス: default.conf
 コンテナ:
 - 名前: ウェブサーバー
 画像: nginx
 ポート:
 - コンテナポート: 80
 ボリュームマウント:
 - マウントパス: /etc/nginx/conf.d
 名前: nginx-conf
 読み取り専用: true
 - 名前: アダプター
 イメージ: nginx/nginx-prometheus-exporter:0.4.2
 引数: ["-nginx.scrape-uri","http://localhost/nginx_status"]
 ポート:
 - コンテナポート: 9113 

次の図は検証操作です。yaml を実行してサービスを作成した後、まず Web サーバー Pod にログインし、curl コマンドをインストールして (HTTP リクエストの開始を容易にするため)、/nginx_status インターフェースとアダプター コンテナーの変換インターフェース (9113/metrics) を確認します。

3.3 マルチノードマルチコンテナモード

3.3.1 選挙パターン

選挙モードは、マルチノードとマルチコンテナの組み合わせモードであり、分散システムでは特に重要です。分散システムでは、高可用性と水平スケーラビリティの問題を解決するためにステートフル アプリケーション サービスを使用する場合、各インスタンスと状態シャード データ (グローバル情報) 間の対応を保存するために外部システムに依存する必要があります。マスターノード選出メカニズムを導入することで、自身のステータスを維持するために外部システムに依存する必要がなくなります。マスター ノードは、アプリケーション サービス コンテナーと再利用可能な選択コンテ​​ナー (つまり、選択モード) を組み合わせて、グローバル情報を保存および配布する役割を担います。

次の yaml ファイルは、選挙結果を検出するためのアプリケーション コンテナとして使用される Node.js サービスを提供します (詳細については、Kubernetes コミュニティの contrib プロジェクト election (https://github.com/kubernetes/contrib/tree/master/election) を参照してください)

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
 名前: デモエレクター-nodejs
 名前空間: qiuqiu
仕様:
 レプリカ: 3
 セレクタ：
 一致ラベル:
 名前: リーダー選挙人
 テンプレート：
 メタデータ:
 ラベル:
 名前: リーダー選挙人
 仕様:
 コンテナ:
 - イメージ: k8s.gcr.io/nodejs-election-client:0.1
 イメージプルポリシー: IfNotPresent
 名前: Node.js
 ポート:
 - コンテナポート: 8080
 プロトコル: TCP
 リソース：
 リクエスト:
 CPU: 100m
 - イメージ: k8s.gcr.io/leader-elector:0.5
 imagePullPolicy: 常に
 名前: 選挙人
 引数:
 - --election=マスターを選出する
 - --http=ローカルホスト:4040
 ポート:
 - コンテナポート: 4040
 プロトコル: TCP
 リソース：
 リクエスト:
 CPU: 100m

04概要

上記では、コンテナとポッドの概念を簡単に紹介し、コンテナとポッドの関係に基づいたコンテナ設計パターンを紹介しました。クロスカントリーモデル、外交官モデル、アダプタモデル、選挙モデルを例とともに紹介します。以下のリストは、上記で紹介したモードの簡単な概要です。

スペースの制限により、読者は、ワーク キュー パターンや Scatter/gather パターンなどの他の優れた設計パターンについて、必要に応じてコミュニティ ドキュメント (https://kubernetes.io/blog) を参照できます。