コンテナの設定に関するヒント

可能な限り、一般的なコンテナベースのOSに標準化することをお勧めします。

AlpineやBusyBoxのような小規模なディストリビューションは、コンテナイメージのサイズを削減し、一般的に攻撃面および脆弱性のリスクが低減されます。

Ubuntu、Fedora、CentOSのような人気のあるディストリビューションは、より多くのフィールドテストを受けており、より多くの機能を提供します。

マイクロサービスがスタンドアロンの静的バイナリである場合は、FROM scratchコンテナを使用するべきです。

FROM scratchコンテナは、最小限のイメージを設計するために使用できる空の 公式Dockerイメージです。

これにより、最小の攻撃面と最小のイメージサイズが得られます。

可能な限り、コンテナ内でプロセスを実行する際には、特権のないユーザーを使用してください。コンテナランタイムは隔離を提供しますが、脆弱性や攻撃は依然として可能です。コンテナがルートとして実行されている場合、意図しないホストマウントにも影響を与える可能性があります。ポッドまたはコンテナのセキュリティコンテキストを構成する詳細については、 Kubernetesドキュメントを参照してください。

ポッドにCPUとメモリの制限を適用してください。これにより、ワーカーノードのリソースを管理し、故障したマイクロサービスが他のマイクロサービスに影響を与えるのを防ぐことができます。

標準のKubernetesでは、ネームスペースレベルでリソース制限を設定できます。Rancherでは、プロジェクトレベルでリソース制限を設定でき、それがプロジェクト内のすべてのネームスペースに伝播します。詳細については、Rancherのドキュメントを参照してください。

リソースクォータを設定する際に、プロジェクトまたはネームスペースにCPUまたはメモリ（すなわち制限または予約）に関連するものを設定すると、すべてのコンテナは作成時にそれぞれのCPUまたはメモリフィールドを設定する必要があります。ワークロード作成時にこれらの制限をすべてのコンテナに設定しないようにするために、ネームスペースにデフォルトのコンテナリソース制限を指定できます。

Kubernetesのドキュメントには、リソース制限を コンテナレベルおよびネームスペースレベルで設定する方法に関する詳細が記載されています。

ポッドにCPUおよびメモリの要件を適用する必要があります。これは、スケジューラにポッドが配置されるべきコンピュートノードの種類を通知し、そのノードが過剰にプロビジョニングされないようにするために重要です。Kubernetesでは、ポッドのコンテナ仕様のリソースリクエストフィールドで`resources.requests`を定義することにより、リソース要件を設定できます。詳細については、 Kubernetesのドキュメントを参照してください。

リソース要件はコンテナレベルで定義することをお勧めします。そうしないと、スケジューラはクラスタが負荷を受けているときにアプリケーションに役立たない仮定をする可能性があります。

コンテナのライブネスおよびレディネスプローブを設定してください。コンテナが完全にクラッシュしない限り、状態を報告するエンドポイントまたは仕組みがなければ、Kubernetesはその不健康状態を検知できません。あるいは、不健康な場合はコンテナが停止してクラッシュすることを確認してください。

Kubernetesのドキュメントには、 コンテナのライブネスおよびレディネスプローブを設定する方法が示されています。