検索

5.8. プライベートクラスターの Azure へのインストール

download PDF

OpenShift Container Platform バージョン 4.16 では、Microsoft Azure 上の既存の Azure Virtual Network (VNet) にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

5.8.1. 前提条件

5.8.2. プライベートクラスター

外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。

重要

クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。

プライベートクラスターをデプロイするには、以下を行う必要があります。

  • 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
  • 以下にアクセスできるマシンからデプロイ。

    • プロビジョニングするクラウドの API サービス。
    • プロビジョニングするネットワーク上のホスト。
    • インストールメディアを取得するインターネット。

これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。

5.8.2.1. Azure のプライベートクラスター

Microsoft Azure でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VNet とサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、内部トラフィック用としてのみ Ingress Operator および API サーバーを設定します。

ネットワークがプライベート VNET に接続される方法によって、クラスターのプライベート DNS レコードを解決するために DNS フォワーダーを使用する必要がある場合があります。クラスターのマシンは、DNS 解決に 168.63.129.16 を内部で使用します。詳細は、Azure ドキュメントの What is Azure Private DNS? および What is IP address 168.63.129.16? を参照してください。

クラスターには、Azure API にアクセスするためにインターネットへのアクセスが依然として必要です。

以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。

  • BaseDomainResourceGroup (クラスターがパブリックレコードを作成しないため)
  • パブリック IP アドレス
  • パブリック DNS レコード
  • パブリックエンドポイント

    The cluster is configured so that the Operators do not create public records for the cluster and all cluster machines are placed in the private subnets that you specify.
5.8.2.1.1. 制限事項

Azure 上のプライベートクラスターは、既存の VNet の使用に関連する制限のみの制限を受けます。

5.8.2.2. ユーザー定義のアウトバウンドルーティング

OpenShift Container Platform では、クラスターがインターネットに接続するために独自のアウトバウンドルーティングを選択できます。これにより、パブリック IP アドレスおよびパブリックロードバランサーの作成を省略できます。

クラスターをインストールする前に、install-config.yaml ファイルのパラメーターを変更してユーザー定義のルーティングを設定できます。クラスターのインストール時にアウトバウンドルーティングを使用するには、既存の VNet が必要です。インストールプログラムはこれを設定しません。

クラスターをユーザー定義のルーティングを使用するように設定する際に、インストールプログラムは以下のリソースを作成しません。

  • インターネットにアクセスするためのアウトバウンドルール。
  • パブリックロードバランサーのパブリック IP。
  • アウトバウンド要求のパブリックロードバランサーにクラスターマシンを追加する Kubernetes Service オブジェクト。

ユーザー定義のルーティングを設定する前に、以下の項目が利用可能であることを確認する必要があります。

  • OpenShift イメージレジストリーミラーを使用しない場合は、コンテナーイメージのプルにインターネットへの Egress を使用できます。
  • クラスターは Azure API にアクセスできます。
  • 各種の allowlist エンドポイントが設定されます。これらのエンドポイントについては、ファイアウォールの設定セクションで参照できます。

ユーザー定義のルーティングを使用したインターネットアクセスでサポートされる既存のネットワーク設定がいくつかあります。

ネットワークアドレス変換のあるプライベートクラスター

Azure VNET NAT (ネットワークアドレス変換) を使用して、クラスター内のサブネットのアウトバウンドインターネットアクセスを提供できます。設定手順については、Azure ドキュメントの Create a NAT gateway using Azure CLI を参照してください。

Azure NAT およびユーザー定義のルーティングが設定された VNet 設定を使用する場合、パブリックエンドポイントのないプライベートクラスターを作成できます。

Azure ファイアウォールのあるプライベートクラスター

Azure ファイアウォールを使用して、クラスターのインストールに使用される VNet のアウトバウンドルーティングを提供できます。Azure ドキュメントで Azure ファイアウォールのあるユーザー定義のルーティングを提供する方法 について確認することができます。

Azure ファイアウォールおよびユーザー定義のルーティングが設定された VNet 設定を使用する場合、パブリックエンドポイントのないプライベートクラスターを作成できます。

プロキシー設定のあるプライベートクラスター

ユーザー定義のルーティングと共にプロキシーを使用し、インターネットへの Egress を許可することができます。クラスター Operator がプロキシーを使用して Azure API にアクセスしないようにする必要があります。Operator はプロキシー外から Azure API にアクセスできる必要があります。

0.0.0.0/0 が Azure によって自動的に設定された状態で、サブネットのデフォルトのルートテーブルを使用する場合、すべての Azure API 要求は、IP アドレスがパブリックな場合でも Azure の内部ネットワークでルーティングされます。ネットワークセキュリティーグループのルールが Azure API エンドポイントへの Egress を許可している限り、ユーザー定義のルーティングが設定されたプロキシーにより、パブリックエンドポイントのないプライベートクラスターを作成できます。

インターネットアクセスのないプライベートクラスター

Azure API を除く、インターネットへのすべてのアクセスを制限するプライベートネットワークをインストールできます。これは、リリースイメージレジストリーをローカルにミラーリングすることによって実現されます。クラスターは以下にアクセスできる必要があります。

  • コンテナーイメージのプルを可能にする OpenShift イメージレジストリーミラー
  • Azure API へのアクセス

各種の要件を利用可能な場合、ユーザー定義のルーティングを使用して、パブリックエンドポイントのないプライベートクラスターを作成できます。

5.8.3. OpenShift Container Platform クラスターでの VNet の再利用について

OpenShift Container Platform 4.16 では、クラスターを Microsoft Azure の既存の Azure Virtual Network (VNet) にデプロイできます。これを実行する場合、VNet 内の既存のサブネットおよびルーティングルールも使用する必要があります。

OpenShift Container Platform を既存の Azure VNet にデプロイすることで、新規アカウントでのサービス制限の制約を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VNet の作成に必要なインフラストラクチャーの作成パーミッションを取得できない場合には、このオプションを使用できます。

5.8.3.1. VNet を使用するための要件

既存の VNet を使用してクラスターをデプロイする場合、クラスターをインストールする前に追加のネットワーク設定を実行する必要があります。installer-provisioned infrastructure クラスターでは、インストーラーは通常以下のコンポーネントを作成しますが、既存の VNet にインストールする場合にはこれらを作成しません。

  • サブネット
  • ルートテーブル
  • VNets
  • ネットワークセキュリティーグループ
注記

インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。

カスタム VNet を使用する場合、インストールプログラムおよびクラスターで使用できるようにカスタム VNet およびそのサブネットを適切に設定する必要があります。インストールプログラムは、使用するクラスターのネットワーク範囲を細分化できず、サブネットのルートテーブルを設定するか、DHCP などの VNet オプションを設定します。これは、クラスターのインストール前に設定する必要があります。

クラスターは、既存の VNet およびサブネットを含むリソースグループにアクセスできる必要があります。クラスターが作成するすべてのリソースは、作成される別個のリソースグループに配置され、一部のネットワークリソースが別個のグループから使用されます。一部のクラスター Operator は両方のリソースグループのリソースにアクセスできる必要があります。たとえばマシン API コントローラーは、ネットワークリソースグループから、作成される仮想マシンの NIC をサブネットに割り当てます。

VNet には以下の特徴が確認される必要があります。

  • VNet の CIDR ブロックには、クラスターマシンの IP アドレスプールである Networking.MachineCIDR 範囲が含まれる必要があります。
  • VNet およびそのサブネットは同じリソースグループに属する必要があり、サブネットは静的 IP アドレスではなく、Azure で割り当てられた DHCP IP アドレスを使用するように設定される必要があります。

コントロールプレーンマシンのサブネットおよびコンピュートマシン用のサブネットの 2 つのサブネットを VNet 内に指定する必要があります。Azure はマシンを指定するリージョン内の複数の異なるアベイラビリティーゾーンに分散するため、デフォルトのクラスターには高可用性があります。

注記

デフォルトでは、install-config.yaml ファイルでアベイラビリティゾーンを指定すると、インストールプログラムはコントロールプレーンマシンとコンピューティングマシンを リージョン 内の これらのアベイラビリティゾーン に分散します。クラスターの高可用性を確保するには、少なくとも 3 つ以上のアベイラビリティーゾーンのあるリージョンを選択します。リージョンに含まれるアベイラビリティーゾーンが 3 つ未満の場合、インストールプログラムは複数のコントロールプレーンマシンを利用可能なゾーンに配置します。

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定されたサブネットがすべて存在します。
  • コントロールプレーンマシンのサブネットおよびコンピュートマシンのサブネットの 2 つのサブネットがあります
  • サブネットの CIDR は指定されたマシン CIDR に属します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。
注記

既存の VNet を使用するクラスターを破棄しても、VNet は削除されません。

5.8.3.1.1. ネットワークセキュリティーグループの要件

コンピュートマシンおよびコントロールプレーンマシンをホストするサブネットのネットワークセキュリティーグループには、クラスターの通信が正しいことを確認するための特定のアクセスが必要です。必要なクラスター通信ポートへのアクセスを許可するルールを作成する必要があります。

重要

ネットワークセキュリティーグループルールは、クラスターのインストール前に有効にされている必要があります。必要なアクセスなしにクラスターのインストールを試行しても、インストールプログラムは Azure API に到達できず、インストールに失敗します。

表5.18 必須ポート
ポート説明コントロールプレーンCompute

80

HTTP トラフィックを許可します。

 

x

443

HTTPS トラフィックを許可します

 

x

6443

コントロールプレーンマシンとの通信を許可します。

x

 

22623

マシンをプロビジョニングするためのマシン設定サーバーへの内部通信を許可します。

x

 
  1. Azure Firewall を使用してインターネットアクセスを制限している場合は、Azure API を許可するように Azure Firewall を設定できます。ネットワークセキュリティーグループルールは必要ありません。
重要

現在、マシン設定サーバーエンドポイントをブロックまたは制限する方法はサポートされていません。マシン設定サーバーは、既存の設定または状態を持たない新しくプロビジョニングされたマシンが設定を取得できるように、ネットワークに公開する必要があります。このモデルでは、信頼のルートは証明書署名要求 (CSR) エンドポイントであり、kubelet がクラスターに参加するための承認のために証明書署名要求を送信する場所です。このため、シークレットや証明書などの機密情報を配布するためにマシン設定を使用しないでください。

マシン設定サーバーエンドポイント、ポート 22623 および 22624 がベアメタルシナリオで確実に保護されるようにするには、顧客は適切なネットワークポリシーを設定する必要があります。

クラスターコンポーネントは、Kubernetes コントローラーが更新する、ユーザーによって提供されるネットワークセキュリティーグループを変更しないため、擬似セキュリティーグループが環境の残りの部分に影響を及ぼさずに Kubernetes コントローラー用に作成されます。

表5.19 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリック

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

UDP

4789

VXLAN

6081

Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

123

UDP ポート 123 のネットワークタイムプロトコル (NTP)

外部 NTP タイムサーバーを設定する場合は、UDP ポート 123 を開く必要があります。

TCP/UDP

30000-32767

Kubernetes ノードポート

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

表5.20 コントロールプレーンマシンからコントロールプレーンマシンへの通信に使用されるポート
プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

5.8.3.2. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、ストレージ、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VNet、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する Azure の認証情報には、VNet、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VNet 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ロードバランサー、セキュリティーグループ、ストレージアカウントおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

5.8.3.3. クラスター間の分離

クラスターは既存のサブネットのネットワークセキュリティーグループを変更できないため、VNet でクラスターを相互に分離する方法はありません。

5.8.4. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

5.8.5. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

5.8.6. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。

手順

  1. OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. インフラストラクチャープロバイダーを選択します。
  3. インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。

    重要

    インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。

    重要

    インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。

  4. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  5. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。

5.8.7. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

5.8.7.1. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表5.21 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

重要

premiumIO パラメーターが true に設定されている Azure 仮想マシンを使用する必要があります。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

5.8.7.2. Azure のテスト済みインスタンスタイプ

以下の Microsoft Azure インスタンスタイプは OpenShift Container Platform でテストされています。

例5.33 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*

5.8.7.3. 64 ビット ARM インフラストラクチャー上の Azure のテスト済みインスタンスタイプ

以下の Microsoft Azure Azure64 インスタンスタイプは OpenShift Container Platform でテストされています。

例5.34 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*

5.8.7.4. Azure VM の信頼された起動の有効化

Azure にクラスターをインストールするときに、セキュアブート仮想化された信頼できるプラットフォームモジュール という 2 つの信頼された起動機能を有効にできます。

これらの機能をサポートする 仮想マシンのサイズ については、仮想マシンのサイズに関する Azure のドキュメントを参照してください。

重要

信頼できる起動はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

前提条件

  • install-config.yaml ファイルを作成しました。

手順

  • クラスターをデプロイする前に、テキストエディターを使用して install-config.yaml ファイルを編集し、次のスタンザを追加します。

    controlPlane: 1
      platform:
        azure:
          settings:
            securityType: TrustedLaunch 2
            trustedLaunch:
              uefiSettings:
                secureBoot: Enabled 3
                virtualizedTrustedPlatformModule: Enabled 4
    1
    controlPlane.platform.azure または compute.platform.azure を指定すると、それぞれコントロールプレーンまたはコンピュートノードのみで信頼された起動が有効になります。すべてのノードで信頼できる起動を有効にするには、platform.azure.defaultMachinePlatform を指定します。
    2
    信頼できる起動機能を有効にします。
    3
    Secure Boot を有効にします。詳細は、セキュアブート に関する Azure ドキュメントを参照してください。
    4
    仮想化された Trusted Platform Module を有効にします。詳細は、仮想化された Trusted Platform Module に関する Azure のドキュメントを参照してください。

5.8.7.5. Confidential VM の有効化

クラスターをインストールするときに、Confidential VM を有効にできます。コンピューティングノード、コンピュートノード、またはすべてのノードに対して Confidential VM を有効にできます。

重要

Confidential VM の使用はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

次の仮想マシンサイズの Confidential VM を使用できます。

  • DCasv5 シリーズ
  • DCadsv5 シリーズ
  • ECasv5 シリーズ
  • ECadsv5 シリーズ
重要

現在、Confidential VM は 64 ビット ARM アーキテクチャーではサポートされていません。

前提条件

  • install-config.yaml ファイルを作成しました。

手順

  • クラスターをデプロイする前に、テキストエディターを使用して install-config.yaml ファイルを編集し、次のスタンザを追加します。

    controlPlane: 1
      platform:
        azure:
          settings:
            securityType: ConfidentialVM 2
            confidentialVM:
              uefiSettings:
                secureBoot: Enabled 3
                virtualizedTrustedPlatformModule: Enabled 4
          osDisk:
            securityProfile:
              securityEncryptionType: VMGuestStateOnly 5
    1
    controlPlane.platform.azure または compute.platform.azure を指定して、それぞれコントロールプレーンまたはコンピュートノードのみに Confidential VM をデプロイします。すべてのノードに Confidential VM をデプロイするには、platform.azure.defaultMachinePlatform を指定します。
    2
    Confidential VM を有効にします。
    3
    Secure Boot を有効にします。詳細は、セキュアブート に関する Azure ドキュメントを参照してください。
    4
    仮想化された Trusted Platform Module を有効にします。詳細は、仮想化された Trusted Platform Module に関する Azure のドキュメントを参照してください。
    5
    仮想マシンゲストの状態を暗号化するには、VMGuestStateOnly を指定します。

5.8.7.6. Azure のカスタマイズされた install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 1
controlPlane: 2
  hyperthreading: Enabled 3 4
  name: master
  platform:
    azure:
      encryptionAtHost: true
      ultraSSDCapability: Enabled
      osDisk:
        diskSizeGB: 1024 5
        diskType: Premium_LRS
        diskEncryptionSet:
          resourceGroup: disk_encryption_set_resource_group
          name: disk_encryption_set_name
          subscriptionId: secondary_subscription_id
      osImage:
        publisher: example_publisher_name
        offer: example_image_offer
        sku: example_offer_sku
        version: example_image_version
      type: Standard_D8s_v3
  replicas: 3
compute: 6
- hyperthreading: Enabled 7
  name: worker
  platform:
    azure:
      ultraSSDCapability: Enabled
      type: Standard_D2s_v3
      encryptionAtHost: true
      osDisk:
        diskSizeGB: 512 8
        diskType: Standard_LRS
        diskEncryptionSet:
          resourceGroup: disk_encryption_set_resource_group
          name: disk_encryption_set_name
          subscriptionId: secondary_subscription_id
      osImage:
        publisher: example_publisher_name
        offer: example_image_offer
        sku: example_offer_sku
        version: example_image_version
      zones: 9
      - "1"
      - "2"
      - "3"
  replicas: 5
metadata:
  name: test-cluster 10
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 11
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    defaultMachinePlatform:
      osImage: 12
        publisher: example_publisher_name
        offer: example_image_offer
        sku: example_offer_sku
        version: example_image_version
      ultraSSDCapability: Enabled
    baseDomainResourceGroupName: resource_group 13
    region: centralus 14
    resourceGroupName: existing_resource_group 15
    networkResourceGroupName: vnet_resource_group 16
    virtualNetwork: vnet 17
    controlPlaneSubnet: control_plane_subnet 18
    computeSubnet: compute_subnet 19
    outboundType: UserDefinedRouting 20
    cloudName: AzurePublicCloud
pullSecret: '{"auths": ...}' 21
fips: false 22
sshKey: ssh-ed25519 AAAA... 23
publish: Internal 24
1 10 14 21
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2 6
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
3 7
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
4
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して Standard_D8s_v3 などの大規模な仮想マシンタイプを使用します。

5 8
使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
9
マシンをデプロイするゾーンのリストを指定します。高可用性を確保するには、少なくとも 2 つのゾーンを指定します。
11
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
12
オプション: コントロールプレーンとコンピュートマシンを起動するために使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。platform.azure.defaultMachinePlatform.osImage の下の publisheroffersku、および version パラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。controlPlane.platform.azure.osImage または compute.platform.azure.osImage の下のパラメーターが設定されている場合、それらは platform.azure.defaultMachinePlatform.osImage パラメーターをオーバーライドします。
13
ベースドメインの DNS ゾーンが含まれるリソースグループの名前を指定します。
15
クラスターをインストールする既存のリソースグループの名前を指定します。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
16
既存の VNet を使用する場合は、それが含まれるリソースグループの名前を指定します。
17
既存の VNet を使用する場合は、その名前を指定します。
18
既存の VNet を使用する場合は、コントロールプレーンマシンをホストするサブネットの名前を指定します。
19
既存の VNet を使用する場合は、コンピュートマシンをホストするサブネットの名前を指定します。
20
独自のアウトバウンドルーティングをカスタマイズすることができます。ユーザー定義のルーティングを設定すると、クラスターに外部エンドポイントが公開されなくなります。エグレスのユーザー定義のルーティングでは、クラスターを既存の VNet にデプロイする必要があります。
22
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

23
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

24
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

5.8.7.7. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    5
    オプション: trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

関連情報

5.8.8. OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.16 のすべてのコマンドを実行することはできません。新しいバージョンの oc をダウンロードしてインストールしてください。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.16 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.16 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.16 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.16 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

5.8.9. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

デフォルトでは、管理者のシークレットは kube-system プロジェクトに保存されます。install-config.yaml ファイルの credentialsMode パラメーターを Manual に設定した場合は、次のいずれかの代替手段を使用する必要があります。

5.8.9.1. 長期認証情報を手動で作成する

Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
      ...

  5. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

    シークレットを含む CredentialsRequest オブジェクトのサンプル

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AzureProviderSpec
        roleBindings:
        - role: Contributor
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    apiVersion: v1
    kind: Secret
    metadata:
      name: <component_secret>
      namespace: <component_namespace>
    data:
      azure_subscription_id: <base64_encoded_azure_subscription_id>
      azure_client_id: <base64_encoded_azure_client_id>
      azure_client_secret: <base64_encoded_azure_client_secret>
      azure_tenant_id: <base64_encoded_azure_tenant_id>
      azure_resource_prefix: <base64_encoded_azure_resource_prefix>
      azure_resourcegroup: <base64_encoded_azure_resourcegroup>
      azure_region: <base64_encoded_azure_region>

重要

手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。

5.8.9.2. 短期認証情報を使用するように Azure クラスターを設定する

Microsoft Entra Workload ID を使用するクラスターをインストールするには、Cloud Credential Operator ユーティリティーを設定し、クラスターに必要な Azure リソースを作成する必要があります。

5.8.9.2.1. Cloud Credential Operator ユーティリティーの設定

Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。

注記

ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) がインストールされている。
  • 次の権限で使用する ccoctl ユーティリティー用のグローバル Microsoft Azure アカウントが作成されました。

    例5.35 必要な Azure 権限

    • Microsoft.Resources/subscriptions/resourceGroups/read
    • Microsoft.Resources/subscriptions/resourceGroups/write
    • Microsoft.Resources/subscriptions/resourceGroups/delete
    • Microsoft.Authorization/roleAssignments/read
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleDefinitions/read
    • Microsoft.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Storage/storageAccounts/listkeys/action
    • Microsoft.Storage/storageAccounts/delete
    • Microsoft.Storage/storageAccounts/read
    • Microsoft.Storage/storageAccounts/write
    • Microsoft.Storage/storageAccounts/blobServices/containers/write
    • Microsoft.Storage/storageAccounts/blobServices/containers/delete
    • Microsoft.Storage/storageAccounts/blobServices/containers/read
    • Microsoft.ManagedIdentity/userAssignedIdentities/delete
    • Microsoft.ManagedIdentity/userAssignedIdentities/read
    • Microsoft.ManagedIdentity/userAssignedIdentities/write
    • Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read
    • Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
    • Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/delete
    • Microsoft.Storage/register/action
    • Microsoft.ManagedIdentity/register/action

手順

  1. 次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    $ oc image extract $CCO_IMAGE \
      --file="/usr/bin/ccoctl.<rhel_version>" \1
      -a ~/.pull-secret
    1
    <rhel_version> には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトで ccoctl.rhel8 が使用されます。次の値が有効です。
    • rhel8: RHEL 8 を使用するホストの場合はこの値を指定します。
    • rhel9: RHEL 9 を使用するホストの場合はこの値を指定します。
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    $ chmod 775 ccoctl.<rhel_version>

検証

  • ccoctl が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。

    $ ./ccoctl.rhel9

    出力例

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      aws          Manage credentials objects for AWS cloud
      azure        Manage credentials objects for Azure
      gcp          Manage credentials objects for Google cloud
      help         Help about any command
      ibmcloud     Manage credentials objects for IBM Cloud
      nutanix      Manage credentials objects for Nutanix
    
    Flags:
      -h, --help   help for ccoctl
    
    Use "ccoctl [command] --help" for more information about a command.

5.8.9.2.2. Cloud Credential Operator ユーティリティーを使用した Azure リソースの作成

ccoctl azure create-all コマンドを使用して、Azure リソースの作成を自動化できます。

注記

デフォルトで、ccoctl はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir フラグを使用します。この手順では、<path_to_ccoctl_output_dir> を使用してこの場所を参照します。

前提条件

以下が必要になります。

  • ccoctl バイナリーを抽出して準備している。
  • Azure CLI を使用して Microsoft Azure アカウントにアクセスします。

手順

  1. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. ccoctl ユーティリティーが Azure 認証情報を自動的に検出できるようにするには、次のコマンドを実行して Azure CLI にログインします。

    $ az login
  4. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    $ ccoctl azure create-all \
      --name=<azure_infra_name> \1
      --output-dir=<ccoctl_output_dir> \2
      --region=<azure_region> \3
      --subscription-id=<azure_subscription_id> \4
      --credentials-requests-dir=<path_to_credentials_requests_directory> \5
      --dnszone-resource-group-name=<azure_dns_zone_resource_group_name> \6
      --tenant-id=<azure_tenant_id> 7
    1
    トラッキングに使用される、作成されたすべての Azure リソースのユーザー定義名を指定します。
    2
    オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
    3
    クラウドリソースが作成される Azure リージョンです。
    4
    使用する Azure サブスクリプション ID を指定します。
    5
    コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
    6
    クラスターのベースドメイン Azure DNS ゾーンを含むリソースグループの名前を指定します。
    7
    使用する Azure テナント ID を指定します。
    注記

    クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

    追加のオプションパラメーターとその使用方法の説明を表示するには、azure create-all --help コマンドを実行します。

検証

  • OpenShift Container Platform シークレットが作成されることを確認するには、<path_to_ccoctl_output_dir>/manifests ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    azure-ad-pod-identity-webhook-config.yaml
    cluster-authentication-02-config.yaml
    openshift-cloud-controller-manager-azure-cloud-credentials-credentials.yaml
    openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml
    openshift-cluster-api-capz-manager-bootstrap-credentials-credentials.yaml
    openshift-cluster-csi-drivers-azure-disk-credentials-credentials.yaml
    openshift-cluster-csi-drivers-azure-file-credentials-credentials.yaml
    openshift-image-registry-installer-cloud-credentials-credentials.yaml
    openshift-ingress-operator-cloud-credentials-credentials.yaml
    openshift-machine-api-azure-cloud-credentials-credentials.yaml

    Azure をクエリーすることで、Microsoft Entra ID サービスアカウントが作成されていることを確認できます。詳細は、Entra ID サービスアカウントのリストに関する Azure ドキュメントを参照してください。

5.8.9.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • Cloud Credential Operator ユーティリティー (ccoctl) が設定されている。
  • ccoctl ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. 既存のリソースグループを使用する代わりに、ccoctl ユーティリティーを使用して新しい Azure リソースグループを作成した場合は、次のように install-config.yamlresourceGroupName パラメーターを変更します。

    設定ファイルのサンプルスニペット

    apiVersion: v1
    baseDomain: example.com
    # ...
    platform:
      azure:
        resourceGroupName: <azure_infra_name> 1
    # ...

    1
    この値は、ccoctl azure create-all コマンドの --name 引数で指定された Azure リソースのユーザー定義名と一致する必要があります。
  3. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  4. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  5. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

5.8.10. オプション: プライベート Image Registry 用のプライベート Microsoft Azure クラスターを準備する

プライベートイメージレジストリーをプライベート Microsoft Azure クラスターにインストールすることで、プライベートストレージのエンドポイントを作成できます。プライベートストレージのエンドポイントは、レジストリーのストレージアカウントに対する公開エンドポイントを無効にし、OpenShift Container Platform デプロイメントにセキュリティーのレイヤーを追加します。

重要

Microsoft Azure Red Hat OpenShift (ARO) にプライベートイメージレジストリーをインストールしないでください。エンドポイントによって Microsoft Azure Red Hat OpenShift クラスターが回復不能な状態になる可能性があります。

次のガイドに従い、プライベートイメージレジストリーを使用してインストールするためのプライベート Microsoft Azure クラスターを準備します。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) がインストールされている。
  • 以下の情報を含む install-config.yaml の準備が完了している。

    • publish フィールドは Internal に設定されている。
  • プライベートストレージエンドポイントの作成権限を設定している。詳細は、「installer-provisioned infrastructure の Azure 権限」を参照してください。

手順

  1. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ ./openshift-install create manifests --dir <installation_directory>

    このコマンドを実行すると、以下の情報が表示されます。

    出力例

    INFO Consuming Install Config from target directory
    INFO Manifests created in: <installation_directory>/manifests and <installation_directory>/openshift

  2. イメージレジストリー設定オブジェクトを作成し、Microsoft Azure から提供された networkResourceGroupNamesubnetNamevnetName を渡します。以下に例を示します。

    $ touch imageregistry-config.yaml
    apiVersion: imageregistry.operator.openshift.io/v1
    kind: Config
    metadata:
      name: cluster
    spec:
      managementState: "Managed"
      replicas: 2
      rolloutStrategy: RollingUpdate
      storage:
        azure:
          networkAccess:
            internal:
              networkResourceGroupName: <vnet_resource_group> 1
              subnetName: <subnet_name> 2
              vnetName: <vnet_name> 3
            type: Internal
    1
    オプション: 既存の VNet およびサブネット設定がある場合は、<vnet_resource_group> を既存の仮想ネットワーク (VNet) を含むリソースグループ名に置き換えます。
    2
    オプション: 既存の VNet およびサブネット設定がある場合は、<subnet_name> を指定されたリソースグループ内にある既存のコンピュートサブネットの名前に置き換えます。
    3
    オプション: 既存の VNet およびサブネット設定がある場合は、<vnet_name> を指定されたリソースグループ内にある既存の仮想ネットワーク (VNet) の名前に置き換えます。
    注記

    imageregistry-config.yaml ファイルはインストールプロセス時に使用されます。必要に応じて、インストール前にバックアップする必要があります。

  3. 次のコマンドを実行して、imageregistry-config.yaml ファイルを<installation_directory/manifests> フォルダーに移動します。

    $ mv imageregistry-config.yaml <installation_directory/manifests/>

次のステップ

  • imageregistry-config.yaml ファイルを <installation_directory/manifests> フォルダーに移動し、必要な権限を設定してから、「クラスターのデプロイ」に進みます。

関連情報

5.8.11. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • Azure サブスクリプション ID とテナント ID がある。
  • サービスプリンシパルを使用してクラスターをインストールしている場合は、そのアプリケーション ID とパスワードが必要です。
  • システムが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、インストールプログラムを実行する仮想マシン上でそれが有効になっています。
  • ユーザーが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、次の前提条件を満たしている必要があります。

    • そのクライアント ID がある。
    • これは、インストールプログラムを実行する仮想マシンに割り当てられている。

手順

  1. オプション: 以前にこのコンピューターでインストールプログラムを実行したことがあり、代替のサービスプリンシパルまたはマネージド ID を使用する場合は、~/.azure/ ディレクトリーに移動して、osServicePrincipal.json 設定ファイルを削除します。

    このファイルを削除すると、インストールプログラムが以前のインストールのサブスクリプション値と認証値を自動的に再利用できなくなります。

  2. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> については、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    インストールプログラムが以前のインストールの osServicePrincipal.json 設定ファイルを見つけることができない場合は、Azure サブスクリプションと認証の値の入力を求められます。

  3. サブスクリプションの次の Azure パラメーター値を入力します。

    • azure subscription id: クラスターに使用するサブスクリプション ID を入力します。
    • azure tenant id: テナント ID を入力します。
  4. クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアント ID の入力を求められたら、次のいずれかを行います。

    • サービスプリンシパルを使用している場合は、そのアプリケーション ID を入力します。
    • システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
    • ユーザー割り当てのマネージド ID を使用している場合は、そのクライアント ID を指定します。
  5. クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアントシークレット の入力を求められたら、次のいずれかを実行します。

    • サービスプリンシパルを使用している場合は、そのパスワードを入力します。
    • システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
    • ユーザー割り当てのマネージド ID を使用している場合は、この値を空白のままにします。

以前に検出されなかった場合は、インストールプログラムが osServicePrincipal.json 設定ファイルを作成し、このファイルをコンピューターの ~/.azure/ ディレクトリーに保存します。これにより、インストールプログラムがターゲットプラットフォーム上で OpenShift Container Platform クラスターを作成するときにプロファイルをロードできるようになります。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

5.8.12. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

関連情報

5.8.13. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

5.8.14. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.