Red Hat OpenStack Platform に Red Hat OpenShift Container Platform をデプロイするためのリファレンスアーキテクチャー

インストーラープロビジョニングインフラストラクチャー (IPI) では、インストーラーがインストールのあらゆる側面を管理します。これには、OpenShift の独自のベストプラクティスのデプロイを伴うインフラストラクチャーのプロビジョニングも含まれます。インストーラーは、そのインフラストラクチャーの知識を持つインフラストラクチャー対応プロバイダーを介して、基盤となるインフラストラクチャーを直接要求、デプロイ、および管理できます。IPI を使用すると、最小限の設定で実稼働環境に対応したインストールを実現し、マネージドサービスにより自己管理型クラスターをデプロイできます。

IPI では、既存のネットワークインフラストラクチャーを使用することもできます。

図3.1 OpenShift IPI のワークフロー

ユーザープロビジョニングインフラストラクチャー (UPI) インストール方式 では、管理者は基盤となる独自のインフラストラクチャーをインストール前に作成および管理する必要があります。インストーラーはインフラストラクチャー対応プロバイダーを使用しますが、管理者は事前にコンポーネントを準備する必要があります。その後、OpenShift インストーラーはインフラストラクチャープロバイダーを使用して、準備されたインフラストラクチャーとやりとりできます。OpenShift on OpenStack の場合、Red Hat は、この目的のためにサンプルの Ansible スクリプトを提供しています。

プラットフォーム非依存のインストール は、インフラストラクチャープロバイダーを使用しないため、どのような基盤インフラストラクチャーでも使用できます。インストーラーは、基盤となるインフラストラクチャーの操作を制御することはできません。つまり、管理者はインフラストラクチャーを準備し、独自のカスタムメソッドを使用して、インストールを調整する必要があります。このタイプのインストールは最も柔軟ですが、クラウド統合が行われないため、追加のカスタム自動化が必要です。

インストーラープロビジョニングインフラストラクチャー方式、ユーザープロビジョニングインフラストラクチャー方式、およびプラットフォーム非依存のインストール方式は、Red Hat によって完全にサポートされています。

インストールパターンとプラットフォームの包括的な概要については、公式ドキュメントの クラスターインストール方法の選択とユーザー向けの準備 を参照してください。

OpenShift on OpenStack をデプロイする場合は、OpenShift ノードの配置を慎重に検討する必要があります。

Red Hat は、OpenShift on OpenStack コントロールプレーン仮想マシンの高可用性を管理するためのサポートされている方法をいくつか提供しています。

OpenStack アベイラビリティーゾーンを使用することは、コントロールプレーンノードが HA に対して適切に管理されるようにするための推奨される方法です。

図3.2 Nova アベイラビリティーゾーンを使用してコンピュートホストに OpenShift コントロールプレーンノードを配置する

OpenStack では、アベイラビリティーゾーンの概念により、クラウドを論理的に分割し、クラウドテナントが簡単に使用できる物理インフラストラクチャーのシンプルな抽象化を提供できます。アベイラビリティーゾーンは、OpenStack では非常に細かく設定されています。Nova、Cinder、Neutron などの一部の OpenStack サービスには、独自のアベイラビリティーゾーンの実装があります。

HA OpenShift コントロールプレーンの場合、OpenStack クラウド管理者は、3 つ以上のアベイラビリティーゾーンを提供し、提供されるコンピュートリソースが適切に設定されていることを確認する必要があります。

OpenShift 4.12 では、コントロールプレーンノードが同じ L2 ネットワークに属している必要があります。コントロールプレーンノードを 3 つのアベイラビリティーゾーンに分散する場合、通常はそれらをストレッチ L2 プロバイダーネットワークに接続します。通常、VLAN または VXLAN でセグメント化された小規模な専用 L2 ネットワークを使用するか、このネットワークを相互接続できる障害ドメインファブリックを備えた Geneve プロトコルを使用して、インフラストラクチャーを設定する必要があります。ゾーン間の遅延は 100 ミリ秒未満である必要があります。

コンピュートアベイラビリティーゾーンを使用する場合は、同じ名前の対応するボリュームアベイラビリティーゾーンが必要です。これは、OpenShift 4.12 で有効な CSI トポロジー認識を使用する場合の要件です。

IPI インストールの場合、インストール前にコントロールプレーンのアベイラビリティーゾーンを install-config.yaml ファイルに手動で追加する必要があります。ガイド付きインストールでは、ゾーンの入力を求めるプロンプトが表示されないためです。ゾーンは、設定ファイルに YAML 配列として追加します。

controlPlane:
  name: master
  platform:
    openstack:
      zones: ['AZ0', 'AZ1', 'AZ2']
  replicas: 3

インストール時、OpenShift インストーラーは仮想マシンの作成時に各コントロールプレーンノードを異なる AZ に割り当てます。

OpenStack は、アフィニティーポリシーを通じてインスタンスを決定論的に配置する機能をサポートしています。アフィニティールールは、管理者が配置を制御できるように、詳細なポリシーにグループ化されます。これらのポリシーと OpenStack サーバーグループを使用することにより、Nova アベイラビリティーゾーンのないデプロイメントでも HA を維持できます。

OpenShift on OpenStack インストーラーは、コントロールプレーンとコンピュートノードの両方のサーバーグループを作成します。これらのサーバーグループは、インスタンスを別々の OpenStack コンピュートホストに配置することを要求するソフト非アフィニティーポリシーとともに使用されます。

ワーカーノードのアベイラビリティーゾーンを使用するには、次の 2 つの方法があります。

ワーカーノードの場合、インストーラーには次の配置ルールがあります。

次の図は、ノードをアベイラビリティーゾーンに設定する 1 つの方法を示しています。

図3.3 3 つの Nova アベイラビリティーゾーンにデプロイされた OpenShift コントロールプレーンとワーカーノードの例。

ワーカーノードはコントロールプレーンノードとは異なるタイプのワークロードを実行するため、Ceph を基盤とするルートボリュームを利用できます。

これを行うには、OpenShift の install-config.yaml インストールファイルのコンピュートセクションで、ワーカーの rootVolume を明示的に設定します。これにより、コントロールプレーンノードのように一時ディスクではなく、Ceph を使用するようにインストーラーに指示します。

さらに、ボリュームゾーン名がコンピュートゾーン名と一致する必要があります。

compute:
- name: worker
  platform:
    openstack:
      zones: ['AZ0', 'AZ1', 'AZ2']
      rootVolume:
        size: 100
        zones: ['AZ0', 'AZ1', 'AZ2']
  replicas: 3

デフォルトでは、Red Hat Ceph Storage (RHCS) デプロイメントは高可用性です。このソリューションでは、Director を使用して、RHCS をデプロイします。この方法で RHCS をデプロイすると、コンピュート、イメージ、ブロックストレージ、およびオブジェクトストレージサービスに HA ストレージを自動的に統合して提供できます。

OpenStack 向けのソリューションに高可用性を実装するには、複数のコンポーネントを使用します。

OpenShift アプリケーションに 外部負荷分散 を実装するために、OpenStack は Octavia ロードバランシングソリューション を提供します。Octavia は、Red Hat OpenStack Platform 16.2 の Load-Balancing-as-a-Service コンポーネントで、完全にサポートおよびテストされています。

Red Hat は、Nova アベイラビリティーゾーンと非アフィニティーポリシーを使用して、OpenShift ソリューションの高可用性を実装しています。各コントローラーノードを別々のアベイラビリティーゾーンに配置して、それらが同じ物理サーバー上にないようにします。

ワーカーノードは、同じアベイラビリティーゾーン全体で可能なかぎり均等に分散されます。これにより、物理インフラストラクチャー全体で均等に分散されます。非アフィニティーポリシーを使用して、ワーカーノードを別々の物理サーバーに配置するよう要求します。ワーカーノードは、障害ドメインごとに異なるタイプのルートボリュームを使用します。Cinder アベイラビリティーゾーン名は、Nova アベイラビリティーゾーン名と同じです。

Red Hat OpenStack Platform 16.2 は、Director 主導のストレージソリューションの一部として Red Hat Ceph Storage (RHCS) 4 を使用します。BlueStore バックエンドがデフォルトで使用されます。RHCS 4 以降のインストールでは、よりパフォーマンスの高い BlueStore バックエンドの使用のみがサポートされます。

RHCS でサポートされるストレージバックエンドの詳細は、「アーキテクチャーガイド」の Ceph ObjectStore を参照してください。

RHCS の設定の詳細は、サポート対象の設定 を参照してください。

OpenShift インストーラーは、スケーリングされたレジストリーの推奨プラクティス に従い、OpenStack のオブジェクトストレージサービスを、内部イメージレジストリーバックエンドの場所として優先的に使用します。これを行うために、インストーラーはアクセス可能なオブジェクトストレージの場所をチェックし、見つかった場合は、それを使用します。見つからない場合は、スケーリングなしのレジストリーの推奨ベストプラクティス を使用し、ReadWriteOnce (RWO) Cinder ボリュームを作成します。

OpenShift は、OpenStack Manila CSI Driver Operator をサポートしているため、OpenStack の Shared File System サービス (manila) と対話して、リモートの共有可能なファイルシステムから PV をプロビジョニングできます。

Shared File Systems サービスを使用してリモートの共有ファイルシステムにアクセスするということは、コンテナーワークロードが、コンピュートインスタンス、ベアメタルノード、およびコンテナーへの同時アクセスを実現するストレージバックエンドを使用できることを意味します。OpenShift PV では、アクセスモードとして認識されるこのようなアクセスは、ReadWriteMany (RWX) と呼ばれており、複雑なコンテナーのユースケースに必要です。

OpenShift ユーザーは、Manila-CSI を使用すると、OpenStack API および Shared File System サービスを介して、リモートの共有ファイルシステムを簡単に使用できます。

図3.4 コンテナーワークロードに Manila を使用する

OpenShift インストーラーは、OpenShift が基盤となる OpenStack クラウドで Manila を検出すると、ストレージクラスを自動的に作成します。インストーラーは、そのストレージクラスをデフォルトとして設定しません。

$ oc get sc
NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
csi-manila-default     manila.csi.openstack.org   Delete          Immediate              false                  37d
standard-csi (default) cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   37d

デフォルトの StorageClass を設定する方法の詳細は、デフォルトストレージクラスの変更 を参照してください。

Openshift は、ボリュームをプロビジョニングするための Cinder CSI ドライバーをサポートしています。このドライバーでプロビジョニングされた PV は動的に割り当てられます。このボリュームは通常、ReadWriteOnce (RWO) アクセスモードで使用されます。ただし、マルチアタッチボリュームタイプ を使用する場合は、ボリュームを複数のインスタンスに同時に接続できます。一般に、このボリュームはブロックストレージや低遅延を必要とするアプリケーションに適しています。

このドキュメントではこれを考慮し、目的に応じて最適なオプションを使用します。

コントロールプレーン仮想マシンは、etcd キー値ストアを実行するための既知のリソース要件を満たす必要があります。etcd の安定性とパフォーマンスを確保するために、書き込みレイテンシーが低いことが要件として求められます。Red Hat では、安定性を確保し、サポート性を保証するために、すべてのコントローラーが高速ディスク (SSD 以上) にアクセスできる必要があります。OSD が使用するディスクテクノロジーに関係なく、OpenShift コントロールプレーンで Ceph を使用する場合は、その他にも考慮事項があります。コントロールプレーンインスタンスに Ceph が必要な場合は、Red Hat サポートにガイダンスとサポート対象範囲の詳細をお問い合わせください。

etcd ディスク要件の詳細は、etcd のドキュメント を参照してください。

クラスターにストレージを提供するには、複数のオプションがあります。決定に役立つように、次の 3 つのオプションを取り上げます。

# cat /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
...
CinderEnableIscsiBackend: false
CinderEnableRbdBackend: true
CinderBackupBackend: ceph
NovaEnableRbdBackend: true
GlanceBackend: rbd
...

他の多くの OpenStack コンポーネントと同様、ネットワークサブシステム (Neutron) はプラグイン可能であるため、ビジネス要件とテクノロジー要件に最適なソリューションを選択できます。Red Hat OpenStack Platform の場合は、サポートされているオプションから選択できます。

Red Hat OpenStack Platform 16.2 によって実装されるデフォルトの Neutron バックエンドは OVN です。

固有の状況に合った Neutron バックエンドを選択する必要があります。

OpenStack 16.2 で OpenShift 4.12 を運用する予定の場合は、OVN のデフォルトバックエンドの使用を強く推奨します。これは、最もテストされた設定であり、必要に応じて LoadBalancer サービスに Octavia OVN プロバイダーを使用できるためです。

OpenShift on OpenStack をデプロイする際に Neutron バックエンドを選択するには、次の点を考慮してください。

Red Hat OpenStack Platform は、Load Balancing as a Service (LBaaS) の実装に Octavia プロジェクトを使用します。OVN とともにデプロイされた OSP 16.2 では、デフォルトの Amphora と OVN プロバイダーという 2 つの Octavia バックエンドが利用可能です。主な違いとしては、Amphora は仮想マシンを作成し、その上に HAProxy インスタンスを設定して各ロードバランサーをデプロイする点が挙げられます。一方、OVN プロバイダーは OpenFlow ルールを使用してロードバランサーを実装します。

デフォルトでは、OpenShift は Octavia バックエンドとして Amphora を使用します。

制限を含む OVN Octavia プロバイダーの詳細については、アップストリームのドキュメント を確認し、Red Hat ソリューションアーキテクトまたはサポートアソシエイトにお問い合わせください。

このソリューションでは、Red Hat OpenStack Platform 16.2 のデフォルトの Neutron ネットワークバックエンドである OVN を使用します。

OpenShift の LoadBalancer サービスは、cloud-provider-openstack および OpenStack Octavia によって処理されます。LoadBalancer タイプの各サービスに対して、Octavia にロードバランサーが作成されます。デフォルトでは、OpenShift は、より機能が豊富なソリューションである Amphora バックエンドを使用します。欠点としては、リソースの消費量が増加する点があります。Amphora はロードバランサーごとに仮想マシンを作成するためです。

ロードバランサーサービスは比較的静的である傾向があるため、Amphora はほとんどのユースケースに適していることが判明しました。

また、Amphora は、Pod が受信するトラフィックの送信元 IP を、常にロードバランサーの IP に設定することに注意してください。そのため、.spec.externalTrafficPolicy を Local に設定しても、PROXY プロトコルなどの追加機能を使用しない限り、元のソース IP を取得することはできません。

リソースの消費量が懸念される場合は、OVN Octavia プロバイダーを使用するように Openshift クラスター を設定できます。Octavia プロバイダーを変更する前に、次の制限事項を考慮する必要があります。

OSP 16.2 および OpenShift 4.12 では、cloud-provider-openstack で使用される Octavia バックエンドとしてデフォルトの Amphora を使用することを推奨します。

このソリューションでは、OpenShift ネットワークに OVN-Kubernetes を、Octavia バックエンドとして Amphora を使用しています。

クラスターをインストールする前に、到達可能な IP アドレスが DNS に存在している必要があります。次のアドレス空間を解決する必要があります。

api.<cluster name>.<base domain>

インストーラーは、install-config.yaml の OpenStack プラットフォームセクションの apiFloatingIP 値により、既存の Floating IP を API ポートに自動的に関連付けることができます。

platform:
  openstack:
...
    apiFloatingIP:     "10.46.43.176"

このドメインは、OpenShift で実行されているアプリケーションへのアクセスに使用されます。DNS で、次の名前構造を解決するワイルドカードエントリーを作成します。

*.apps.<cluster name>.<base domain>.

install-config.yaml の ingressFloatingIP 値を使用して、この OpenShift アプリケーションの IP をクラスターに自動的に関連付けることができます。ingressVIP と ingressFloatingIP を混同しないでください。ingressVIP は Machine ネットワーク用であり、ingressFloatingIP は外部ネットワーク用です。

ブートストラップノードは、ブートストラップクラスターと実稼働クラスターを起動するための基本的なリソースを取得します。そのため、レジストリードメイン名を直接解決できる必要があります。

OpenShift on OpenStack をインストールする場合、インストーラーは機能的なインストールに必要な OpenStack セキュリティーグループを作成します。インストーラーは、コントロールプレーンノードとワーカーノードのセキュリティーグループを作成します。

セキュリティーグループを確認して、内部のセキュリティー要件にどのように影響するかを明確に理解する必要があります。

作成されるルールの詳細を確認するには、コントロールプレーンノード と ワーカーノード のアップストリームのコードを確認してください。

これらのグループの使用方法の詳細については、OpenStack のアップストリームクラスター API ドキュメントの セキュリティーグループルール を参照してください。

インストール時にセキュリティーグループを直接追加する方法については、インストールガイドの Optional RHOSP configuration parameters セクションを参照してください。