第4章 コンピュートリソースの最適化

4.1. オーバーコミット

CPU およびメモリーなどのリソースを必要とするクラスターの部分から、このようなリソースにアクセスしやすくなるように、オーバーコミットの手順を使用します。

重要

ハイパーバイザーと Kubernetes 間のスケジュールの衝突による不安定なクラスター動作を防ぐために、ハイパーバイザーレベルではオーバーコミットしないでください。

オーバーコミットすると、別のアプリケーションが必要としているリソースを必要な時にアクセスできなくなってしまうリスクがあり、これにより、結果的にパフォーマンスが低下します。ただし、パフォーマンスが低下する代わりに、密度が高まり、コストが削減されるので、許容できるトレードオフになる場合もあります。たとえば、開発、品質保証 (QA) またはテスト環境でオーバーコミットできても、実稼働環境ではできない場合があります。

OpenShift Container Platform は、コンピュートリソースモデルやクォータシステムでリソース管理を実装します。詳細は、「OpenShift リソースモデル」を参照してください。

オーバーコミットに関する詳細情報およびストラテジーは、『クラスター管理ガイド』の「オーバーコミット」を参照してください。

4.2. イメージの留意事項

4.2.1. 事前デプロイ済みのイメージを使用した効率の強化

効率の強化や全ノードホストでの設定の一貫性の維持、反復タスクの削減を図るため、複数のタスクを組み込んだベースの OpenShift Container Platform イメージを作成できます。これは、事前デプロイ済みのイメージとして知られています。

たとえば、Pod を実行するために、すべてのノードには ose-pod イメージが必要なので、各ノードは定期的にコンテナーイメージレジストリーに接続して最新のイメージをプルする必要があります。100 のノードが同時にレジストリーに接続し、最新のイメージをプルしようとすると問題が発生する場合があり、イメージレジストリーでのリソースの競合や、ネットワーク帯域幅の無駄な使用、および Pod の起動にかかる時間の増加などが生じる可能性があります。

事前にデプロイ済みのイメージをビルドするには、以下を実行します。

  • 必要とされるタイプおよびサイズのインスタンスを作成します。
  • コンテナー用の永続ボリュームとは別に、専用のストレージデバイスが CRI-O または Docker のローカルイメージやコンテナーストレージで利用できるようにします。
  • システムを完全に更新すると共に、CRI-O または Docker がインストールされていることを確認します。
  • ホストがすべての yum リポジトリーにアクセスできるようにします。
  • シンプロビジョニングされた LVM ストレージを設定します
  • 一般的に使用するイメージ (rhel7 ベースイメージ) および OpenShift Container Platform インフラストラクチャーコンテナーイメージ (ose-podose-deployer など) を事前にデプロイ済みのイメージに事前に設定します。

OpenStack または AWS で実行できるなど、事前デプロイ済みのイメージが適切なクラスター設定やその他のクラスター設定用に設定されていることを確認します。

4.2.2. イメージの事前プル

イメージを効率的に生成するには、全ノードホストに、必要とされるコンテナーイメージをすべてのノードホストに事前にプルしておきます。これは、最初にイメージをプルする必要がないことを意味するため、サイズが大きくなる可能性のある S2I、メトリクス、ロギングなどのイメージの場合などに、接続速度が遅いことが原因でパフォーマンスが低下することなく、時間を節約できます。

また、この方法はセキュリティー上の理由でレジストリーにアクセスできないマシンにも役立ちます。

または、指定したデフォルトレジストリーではなく、ローカルイメージを使用できます。このためには、以下を実行します。

  1. Pod 設定の imagePullPolicy パラメーターを IfNotPresent または Never に設定して、ローカルイメージからプルします。
  2. クラスターのすべてのノードで、同じイメージがローカルに保存されていることを確認します。
注記

ノードの設定を制御できる場合は、ローカルレジストリーからプルすることが適切ですが、GCE など、自動的にノードを交換しないクラウドプロバイダーでは確実に機能しない場合があります。Google Container Engine (GKE) で実行している場合は、各ノードに、Google Container Registry の認証情報が設定された .dockercfg ファイルが配置されています。

4.3. RHEL ツールのコンテナーイメージを使用したデバッグ

Red Hat は rhel-tools コンテナーイメージを配信します。これは、スケーリングがパフォーマンスの問題のデバッグをサポートするパッケージツールです。このコンテナーイメージを使用すると、以下が可能です。

  • ベースのディストリビューションからこのサポートコンテナーにパッケージを移動して、フットプリントが最小のコンテナーホストをデプロイできます。
  • 不変のパッケージツリーを含む Red Hat Enterprise Linux 7 Atomic Host 用のデバッグ機能が提供されます。rhel-tools には、tcpdump、sosreport、git、gdb、perf など、多くの一般的なシステム管理ユーティリティーが含まれます。

以下を実行して rhel-tools コンテナーを使用します。

# atomic run rhel7/rhel-tools

詳しい情報は、「RHEL ツールコンテナーのドキュメント」を参照してください。

4.4. Ansible ベースのヘルスチェックを使用したデバッグ

追加のヘルスチェックは、OpenShift Container Platform クラスターのインストールおよび管理に使用する Ansible ベースのツールで利用できます。このヘルスチェックでは、現行の OpenShift Container Platform インストールによくあるデプロイメントの問題を報告します。

これらのチェックは、ansible-playbook コマンドの使用 (クラスターインストールで使用されるのと同じ方式) によるか、または openshift-ansibleコンテナー化されたバージョンとして実行できます。ansible-playbook 方式については、チェックは openshift-ansible RPM パッケージを使って行われます。コンテナー化方式の場合は、openshift3/ose-ansible コンテナーイメージが Red Hat Container Registry 経由で配布されます。

利用可能なヘルスチェックや使用例については、『クラスター管理ガイド』の「Ansible ベースのヘルスチェック」を参照してください。