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