6.2. アプリケーション要件に基づく環境計画
このドキュメントでは、アプリケーション要件に応じて AWS 上の Red Hat OpenShift Service 環境をプランニングする方法を説明します。
アプリケーション環境の例を考えてみましょう。
| Pod タイプ | Pod 数 | 最大メモリー | CPU コア数 | 永続ストレージ | 
|---|---|---|---|---|
| apache | 100 | 500 MB | 0.5 | 1 GB | 
| node.js | 200 | 1 GB | 1 | 1 GB | 
| postgresql | 100 | 1 GB | 2 | 10 GB | 
| JBoss EAP | 100 | 1 GB | 1 | 1 GB | 
推定要件: CPU コア 550 個、メモリー 450 GB、および 1.4 TB ストレージ
ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスあたりのコストなどの要因を考慮する必要があります。
| ノードのタイプ | 数量 | CPU | RAM (GB) | 
|---|---|---|---|
| ノード (オプション 1) | 100 | 4 | 16 | 
| ノード (オプション 2) | 50 | 8 | 32 | 
| ノード (オプション 3) | 25 | 16 | 64 | 
アプリケーションによってはオーバーコミットの環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。
アプリケーション Pod は環境変数または DNS のいずれかを使用してサービスにアクセスできます。環境変数を使用する場合、それぞれのアクティブなサービスについて、変数が Pod がノードで実行される際に kubelet によって挿入されます。クラスター対応の DNS サーバーは、Kubernetes API で新規サービスの有無を監視し、それぞれに DNS レコードのセットを作成します。DNS がクラスター全体で有効にされている場合、すべての Pod は DNS 名でサービスを自動的に解決できるはずです。DNS を使用したサービス検出は、5000 サービスを超える使用できる場合があります。サービス検出に環境変数を使用し、namespace で 5000 サービスを超える場合に引数のリストが許可される長さを超えると、Pod およびデプロイメントが失敗し始めます。
デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。
例
				namespace で実行できるアプリケーション Pod の数は、環境変数がサービス検出に使用される場合にサービスの数およびサービス名の長さによって異なります。システムの ARG_MAX は、新規プロセスの引数の最大の長さを定義し、デフォルトで 2097152 バイト (2 MiB) に設定されます。kubelet は、以下を含む namespace で実行するようにスケジュールされる各 Pod に環境変数を挿入します。
			
- 
						<SERVICE_NAME>_SERVICE_HOST=<IP>
- 
						<SERVICE_NAME>_SERVICE_PORT=<PORT>
- 
						<SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
- 
						<SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
- 
						<SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
- 
						<SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
- 
						<SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>
引数の長さが許可される値を超え、サービス名の文字数がこれに影響を及ぼす場合は、namespace の Pod が起動に失敗し始めます。