7.10. Deployment Manager テンプレートの使用による GCP でのユーザーによってプロビジョニングされるインフラストラクチャーへのクラスターのインストール
OpenShift Container Platform バージョン 4.9 では、プロビジョニングするインフラストラクチャーを使用するクラスターを Google Cloud Platform (GCP) にインストールできます。
以下に、ユーザーによって提供されるインフラストラクチャーのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
ユーザーによってプロビジョニングされるインフラストラクチャーのインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスについて理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
7.10.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認している。
- クラスターンストール方法の選択およびそのユーザー向けの準備 を確認している。
- ファイアウォールを使用し、Telemetry を使用する予定の場合、クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 する必要があります。
お使いの環境でクラウドアイデンティティーおよびアクセス管理 (IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-system
namespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 することができます。注記プロキシーを設定する場合は、このサイト一覧も確認してください。
7.10.2. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
7.10.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.9 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
7.10.4. GCP プロジェクトの設定
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud Platform (GCP) プロジェクトを設定する必要があります。
7.10.4.1. GCP プロジェクトの作成
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud Platform (GCP) アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。GCP ドキュメントの プロジェクトの作成と管理 を参照してください。
重要GCP プロジェクトは、インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合には、Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>
の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
7.10.4.2. GCP での API サービスの有効化
Google Cloud Platform (GCP) プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。GCP ドキュメントの サービスの有効化 を参照してください。
表7.35 必要な API サービス API サービス コンソールサービス名 Cloud Deployment Manager V2 API
deploymentmanager.googleapis.com
Compute Engine API
compute.googleapis.com
Google Cloud API
cloudapis.googleapis.com
Cloud Resource Manager API
cloudresourcemanager.googleapis.com
Google DNS API
dns.googleapis.com
IAM Service Account Credentials API
iamcredentials.googleapis.com
Identity and Access Management (IAM) API
iam.googleapis.com
Service Management API
servicemanagement.googleapis.com
Service Usage API
serviceusage.googleapis.com
Google Cloud Storage JSON API
storage-api.googleapis.com
Cloud Storage
storage-component.googleapis.com
7.10.4.3. GCP の DNS の設定
OpenShift Container Platform をインストールするには、使用する Google Cloud Platform (GCP) アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、GCP または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法についての詳細は、 Google ドメイン を参照してください。
GCP プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。GCP ドキュメントの ゾーンの管理 を参照してください。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。GCP ドキュメントの Cloud DNS ネームサーバーを検索する を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。GCP ドキュメントの Cloud DNS への移行 を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
7.10.4.4. GCP アカウントの制限
OpenShift Container Platform クラスターは多くの Google Cloud Platform (GCP) コンポーネントを使用しますが、デフォルトの 割り当て (Quota) はデフォルトの OpenShift Container Platform クラスターをインストールする機能に影響を与えません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
---|---|---|---|---|
サービスアカウント | IAM | グローバル | 5 | 0 |
ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
転送ルール | コンピュート | グローバル | 2 | 0 |
ヘルスチェック | コンピュート | グローバル | 2 | 0 |
イメージ | コンピュート | グローバル | 1 | 0 |
ネットワーク | ネットワーク | グローバル | 1 | 0 |
ルーター | ネットワーク | グローバル | 1 | 0 |
ルート | ネットワーク | グローバル | 2 | 0 |
サブネットワーク | コンピュート | グローバル | 2 | 0 |
ターゲットプール | ネットワーク | グローバル | 2 | 0 |
インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。
実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD(ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。
以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。
-
asia-east2
-
asia-northeast2
-
asia-south1
-
australia-southeast1
-
europe-north1
-
europe-west2
-
europe-west3
-
europe-west6
-
northamerica-northeast1
-
southamerica-east1
-
us-west2
GCP コンソール からリソースクォータを増やすことは可能ですが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
7.10.4.5. GCP でのサービスアカウントの作成
OpenShift Container Platform には、Google API でデータにアクセスするための認証および承認を提供する Google Cloud Platform (GCP) サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。GCP ドキュメントで サービスアカウントの作成 を参照してください。
サービスアカウントに適切なパーミッションを付与します。付随する個別のパーミッションを付与したり、
オーナー
ロールをこれに割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることが必要なパーミッションを取得する最も簡単な方法になります。 つまりこれは、サービスアカウントはプロジェクトを完全に制御できることを意味します。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
JSON 形式でサービスアカウントキーを作成します。GCP ドキュメントの サービスアカウントキーの作成 を参照してください。
クラスターを作成するには、サービスアカウントキーが必要になります。
7.10.4.5.1. 必要な GCP パーミッション
作成するサービスアカウントに オーナー
ロールを割り当てると、OpenShift Container Platform のインストールに必要なパーミッションも含め、そのサービスアカウントにすべてのパーミッションが付与されます。OpenShift Container Platform クラスターをデプロイするには、サービスアカウントに以下のパーミッションが必要です。クラスターを既存の VPC にデプロイする場合、サービスアカウントでは一部のネットワークのパーミッションを必要としません。これについては、以下の一覧に記載されています。
インストールプログラムに必要なロール
- Compute 管理者
- セキュリティー管理者
- サービスアカウント管理者
- サービスアカウントユーザー
- ストレージ管理者
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
ユーザーによってプロビジョニングされる GCP インフラストラクチャーに必要なロール
- Deployment Manager Editor
- サービスアカウントキー管理者
オプションのロール
クラスターで Operator の制限された認証情報を新たに作成できるようにするには、以下のロールを追加します。
- サービスアカウントキー管理者
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
アカウント | ロール |
---|---|
コントロールプレーン |
|
| |
| |
| |
| |
コンピュート |
|
|
7.10.4.6. サポートされている GCP リージョン
OpenShift Container Platform クラスターを以下の Google Cloud Platform (GCP) リージョンにデプロイできます。
-
asia-east1
(Changhua County, Taiwan) -
asia-east2
(Hong Kong) -
asia-northeast1
(Tokyo, Japan) -
asia-northeast2
(Osaka, Japan) -
asia-northeast3
(Seoul, South Korea) -
asia-south1
(Mumbai, India) -
asia-southeast1
(Jurong West, Singapore) -
asia-southeast2
(Jakarta, Indonesia) -
australia-southeast1
(Sydney, Australia) -
europe-central2
(Warsaw, Poland) -
europe-north1
(Hamina, Finland) -
europe-west1
(St. Ghislain, Belgium) -
europe-west2
(London, England, UK) -
europe-west3
(Frankfurt, Germany) -
europe-west4
(Eemshaven, Netherlands) -
europe-west6
(Zürich, Switzerland) -
northamerica-northeast1
(Montréal, Québec, Canada) -
southamerica-east1
(São Paulo, Brazil) -
us-central1
(Council Bluffs, Iowa, USA) -
us-east1
(Moncks Corner, South Carolina, USA) -
us-east4
(Ashburn, Northern Virginia, USA) -
us-west1
(The Dalles, Oregon, USA) -
us-west2
(Los Angeles, California, USA) -
us-west3
(Salt Lake City, Utah, USA) -
us-west4
(Las Vegas, Nevada, USA)
7.10.4.7. GCP の CLI ツールのインストールおよび設定
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud Platform (GCP) に OpenShift Container Platform をインストールするには、GCP の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATH
で以下のバイナリーをインストールします。-
gcloud
-
gsutil
GCP ドキュメントの Google Cloud SDK のドキュメント を参照してください。
-
設定したサービスアカウントで、
gcloud
ツールを使用して認証します。GCP ドキュメントで、サービスアカウントでの認証 を参照してください。
7.10.5. ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件
ユーザーによってプロビジョニングされるインフラストラクチャーを含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、ユーザーによってプロビジョニングされるインフラストラクチャーに OpenShift Container Platform をデプロイする要件について説明します。
7.10.5.1. クラスターのインストールに必要なマシン
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンについて別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 7.9、または RHEL 8.4 のいずれかを選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
7.10.5.2. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | IOPS [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
コンピュート | RHCOS、RHEL 7.9、または RHEL 8.4 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
- ユーザーによってプロビジョニングされるすべてのインストールと同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピュートマシンの使用は非推奨となり、OpenShift Container Platform 4 の今後のリリースで削除される予定です。
7.10.5.3. カスタムマシンタイプの使用
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細については、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>
たとえば、
custom-6-20480
です。
7.10.6. GCP のインストール設定ファイルの作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud Platform (GCP) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml
ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var
パーティションを設定するオプションもあります。
7.10.6.1. オプション: 別個の /var
パーティションの作成
OpenShift Container Platform のディスクパーティション設定はインストーラー側で行う必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var
パーティションまたは /var
のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers
: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd
: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 -
/var
: 監査などの目的に合わせて分離させる必要のあるデータを保持します。
/var
ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var
は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install
の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var
パーティションを設定します。
この手順で個別の /var
パーティションを作成する手順を実行する場合、このセクションで後に説明されるように、Kubernetes マニフェストおよび Ignition 設定ファイルを再び作成する必要はありません。
手順
OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。
$ mkdir $HOME/clusterconfig
openshift-install
を実行して、manifest
およびopenshift
のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。$ openshift-install create manifests --dir $HOME/clusterconfig
出力例
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift
オプション: インストールプログラムで
clusterconfig/openshift
ディレクトリーにマニフェストが作成されたことを確認します。$ ls $HOME/clusterconfig/openshift/
出力例
99_kubeadmin-password-secret.yaml 99_openshift-cluster-api_master-machines-0.yaml 99_openshift-cluster-api_master-machines-1.yaml 99_openshift-cluster-api_master-machines-2.yaml ...
追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.bu
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。variant: openshift version: 4.9.0 metadata: labels: machineconfiguration.openshift.io/role: worker name: 98-var-partition storage: disks: - device: /dev/<device_name> 1 partitions: - label: var start_mib: <partition_start_offset> 2 size_mib: <partition_size> 3 filesystems: - device: /dev/disk/by-partlabel/var path: /var format: xfs mount_options: [defaults, prjquota] 4 with_mount_unit: true
- 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshift
ディレクトリーに保存します。たとえば、以下のコマンドを実行します。$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
openshift-install
を再度実行し、manifest
およびopenshift
のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。$ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ign
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。
7.10.6.2. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション: クラスターでコンピュートマシンをプロビジョニングするよう設定する必要がない場合は、
install-config.yaml
ファイルでcompute
プールのreplicas
を0
に設定してコンピュートプールを空にします。compute: - hyperthreading: Enabled name: worker platform: {} replicas: 0 1
- 1
0
に設定します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、インストール設定パラメーターのセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
7.10.6.3. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yaml
ファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドについてのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxy
オブジェクトのspec.noProxy
フィールドに追加している。注記Proxy
オブジェクトのstatus.noProxy
フィールドには、インストール設定のnetworking.machineNetwork[].cidr
、networking.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
) も設定されます。
手順
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----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
7.10.6.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、
<installation_directory>/manifests/cluster-dns-02-config.yml
DNS 設定ファイルからprivateZone
およびpublicZone
セクションを削除します。apiVersion: config.openshift.io/v1 kind: DNS metadata: creationTimestamp: null name: cluster spec: baseDomain: example.openshift.com privateZone: 1 id: mycluster-100419-private-zone publicZone: 2 id: example.openshift.com status: {}
これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ ./openshift-install create ignition-configs --dir <installation_directory> 1
- 1
<installation_directory>
については、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
7.10.7. 一般的な変数のエクスポート
7.10.7.1. インフラストラクチャー名の抽出
Ignition 設定ファイルには、Google Cloud Platform (GCP) でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な GCP リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jq
パッケージをインストールしている。
7.10.7.2. Deployment Manager テンプレートの一般的な変数のエクスポート
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud Platform (GCP) で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- クラスターの Ignition 設定ファイルを生成します。
-
jq
パッケージをインストールします。
手順
提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
$ export BASE_DOMAIN='<base_domain>' $ export BASE_DOMAIN_ZONE_NAME='<base_domain_zone_name>' $ export NETWORK_CIDR='10.0.0.0/16' $ export MASTER_SUBNET_CIDR='10.0.0.0/17' $ export WORKER_SUBNET_CIDR='10.0.128.0/17' $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1 $ export CLUSTER_NAME=`jq -r .clusterName <installation_directory>/metadata.json` $ export INFRA_ID=`jq -r .infraID <installation_directory>/metadata.json` $ export PROJECT_NAME=`jq -r .gcp.projectID <installation_directory>/metadata.json` $ export REGION=`jq -r .gcp.region <installation_directory>/metadata.json`
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
7.10.8. GCP での VPC の作成
OpenShift Container Platform クラスターで使用する VPC を Google Cloud Platform (GCP) で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
手順
-
本トピックの VPC の Deployment Manager テンプレートセクションを確認し、これを
01_vpc.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。 01_xvdb.yaml
リソース定義ファイルを作成します。$ cat <<EOF >01_vpc.yaml imports: - path: 01_vpc.py resources: - name: cluster-vpc type: 01_vpc.py properties: infra_id: '${INFRA_ID}' 1 region: '${REGION}' 2 master_subnet_cidr: '${MASTER_SUBNET_CIDR}' 3 worker_subnet_cidr: '${WORKER_SUBNET_CIDR}' 4 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml
7.10.8.1. VPC の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例7.1 01_vpc.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-network', 'type': 'compute.v1.network', 'properties': { 'region': context.properties['region'], 'autoCreateSubnetworks': False } }, { 'name': context.properties['infra_id'] + '-master-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['master_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-worker-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['worker_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-router', 'type': 'compute.v1.router', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'nats': [{ 'name': context.properties['infra_id'] + '-nat-master', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 7168, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-master-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }, { 'name': context.properties['infra_id'] + '-nat-worker', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 512, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-worker-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }] } }] return {'resources': resources}
7.10.9. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
7.10.9.1. DHCP を使用したクラスターノードのホスト名の設定
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
7.10.9.2. ネットワーク接続の要件
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
本セクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN および Geneve |
| VXLAN および Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
7.10.10. GCP でのロードバランサーの作成
OpenShift Container Platform クラスターで使用するロードバランシングを Google Cloud Platform (GCP) で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックの内部ロードバランサーの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを
02_lb_int.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な内部負荷分散オブジェクトについて記述しています。 -
また、外部クラスターについては、本トピックの外部ロードバランサーの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを
02_lb_ext.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な外部負荷分散オブジェクトについて記述しています。 デプロイメントテンプレートが使用する変数をエクスポートします。
クラスターネットワークの場所をエクスポートします。
$ export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)
コントロールプレーンのサブネットの場所をエクスポートします。
$ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)
クラスターが使用する 3 つのゾーンをエクスポートします。
$ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)
$ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)
$ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)
02_infra.yaml
リソース定義ファイルを作成します。$ cat <<EOF >02_infra.yaml imports: - path: 02_lb_ext.py - path: 02_lb_int.py 1 resources: - name: cluster-lb-ext 2 type: 02_lb_ext.py properties: infra_id: '${INFRA_ID}' 3 region: '${REGION}' 4 - name: cluster-lb-int type: 02_lb_int.py properties: cluster_network: '${CLUSTER_NETWORK}' control_subnet: '${CONTROL_SUBNET}' 5 infra_id: '${INFRA_ID}' region: '${REGION}' zones: 6 - '${ZONE_0}' - '${ZONE_1}' - '${ZONE_2}' EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml
クラスター IP アドレスをエクスポートします。
$ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)
外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。
$ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)
7.10.10.1. 外部ロードバランサーの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な外部ロードバランサーをデプロイすることができます。
例7.2 02_lb_ext.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-cluster-public-ip', 'type': 'compute.v1.address', 'properties': { 'region': context.properties['region'] } }, { # Refer to docs/dev/kube-apiserver-health-check.md on how to correctly setup health check probe for kube-apiserver 'name': context.properties['infra_id'] + '-api-http-health-check', 'type': 'compute.v1.httpHealthCheck', 'properties': { 'port': 6080, 'requestPath': '/readyz' } }, { 'name': context.properties['infra_id'] + '-api-target-pool', 'type': 'compute.v1.targetPool', 'properties': { 'region': context.properties['region'], 'healthChecks': ['$(ref.' + context.properties['infra_id'] + '-api-http-health-check.selfLink)'], 'instances': [] } }, { 'name': context.properties['infra_id'] + '-api-forwarding-rule', 'type': 'compute.v1.forwardingRule', 'properties': { 'region': context.properties['region'], 'IPAddress': '$(ref.' + context.properties['infra_id'] + '-cluster-public-ip.selfLink)', 'target': '$(ref.' + context.properties['infra_id'] + '-api-target-pool.selfLink)', 'portRange': '6443' } }] return {'resources': resources}
7.10.10.2. 内部ロードバランサーの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な内部ロードバランサーをデプロイすることができます。
例7.3 02_lb_int.py
Deployment Manager テンプレート
def GenerateConfig(context): backends = [] for zone in context.properties['zones']: backends.append({ 'group': '$(ref.' + context.properties['infra_id'] + '-master-' + zone + '-instance-group' + '.selfLink)' }) resources = [{ 'name': context.properties['infra_id'] + '-cluster-ip', 'type': 'compute.v1.address', 'properties': { 'addressType': 'INTERNAL', 'region': context.properties['region'], 'subnetwork': context.properties['control_subnet'] } }, { # Refer to docs/dev/kube-apiserver-health-check.md on how to correctly setup health check probe for kube-apiserver 'name': context.properties['infra_id'] + '-api-internal-health-check', 'type': 'compute.v1.healthCheck', 'properties': { 'httpsHealthCheck': { 'port': 6443, 'requestPath': '/readyz' }, 'type': "HTTPS" } }, { 'name': context.properties['infra_id'] + '-api-internal-backend-service', 'type': 'compute.v1.regionBackendService', 'properties': { 'backends': backends, 'healthChecks': ['$(ref.' + context.properties['infra_id'] + '-api-internal-health-check.selfLink)'], 'loadBalancingScheme': 'INTERNAL', 'region': context.properties['region'], 'protocol': 'TCP', 'timeoutSec': 120 } }, { 'name': context.properties['infra_id'] + '-api-internal-forwarding-rule', 'type': 'compute.v1.forwardingRule', 'properties': { 'backendService': '$(ref.' + context.properties['infra_id'] + '-api-internal-backend-service.selfLink)', 'IPAddress': '$(ref.' + context.properties['infra_id'] + '-cluster-ip.selfLink)', 'loadBalancingScheme': 'INTERNAL', 'ports': ['6443','22623'], 'region': context.properties['region'], 'subnetwork': context.properties['control_subnet'] } }] for zone in context.properties['zones']: resources.append({ 'name': context.properties['infra_id'] + '-master-' + zone + '-instance-group', 'type': 'compute.v1.instanceGroup', 'properties': { 'namedPorts': [ { 'name': 'ignition', 'port': 22623 }, { 'name': 'https', 'port': 6443 } ], 'network': context.properties['cluster_network'], 'zone': zone } }) return {'resources': resources}
外部クラスターの作成時に、02_lb_ext.py
テンプレートに加えてこのテンプレートが必要になります。
7.10.11. GCP でのプライベート DNS ゾーンの作成
OpenShift Container Platform クラスターで使用するプライベート DNS ゾーンを Google Cloud Platform (GCP) で設定する必要があります。このコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックのプライベート DNS の Deployment Manager テンプレートセクションのテンプレートをコピーし、これを
02_dns.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトについて記述しています。 02_dns.yaml
リソース定義ファイルを作成します。$ cat <<EOF >02_dns.yaml imports: - path: 02_dns.py resources: - name: cluster-dns type: 02_dns.py properties: infra_id: '${INFRA_ID}' 1 cluster_domain: '${CLUSTER_NAME}.${BASE_DOMAIN}' 2 cluster_network: '${CLUSTER_NETWORK}' 3 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml
このテンプレートは Deployment Manager の制限により DNS エントリーを作成しないので、手動で作成する必要があります。
内部 DNS エントリーを追加します。
$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone
外部クラスターの場合、外部 DNS エントリーも追加します。
$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}
7.10.11.1. プライベート DNS の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なプライベート DNS をデプロイすることができます。
例7.4 02_dns.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-private-zone', 'type': 'dns.v1.managedZone', 'properties': { 'description': '', 'dnsName': context.properties['cluster_domain'] + '.', 'visibility': 'private', 'privateVisibilityConfig': { 'networks': [{ 'networkUrl': context.properties['cluster_network'] }] } } }] return {'resources': resources}
7.10.12. GCP でのファイアウォールルールの作成
OpenShift Container Platform クラスターで使用するファイアウォールルールを Google Cloud Platform (GCP) で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックのファイアウォールの Deployment Manager テンプレートセクションのテンプレートをコピーし、これを
03_firewall.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループについて記述しています。 03_firewall.yaml
リソース定義ファイルを作成します。$ cat <<EOF >03_firewall.yaml imports: - path: 03_firewall.py resources: - name: cluster-firewall type: 03_firewall.py properties: allowed_external_cidr: '0.0.0.0/0' 1 infra_id: '${INFRA_ID}' 2 cluster_network: '${CLUSTER_NETWORK}' 3 network_cidr: '${NETWORK_CIDR}' 4 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml
7.10.12.1. ファイアウォールルール用の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なファイアウォールルールをデプロイすることができます。
例7.5 03_firewall.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-bootstrap-in-ssh', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['22'] }], 'sourceRanges': [context.properties['allowed_external_cidr']], 'targetTags': [context.properties['infra_id'] + '-bootstrap'] } }, { 'name': context.properties['infra_id'] + '-api', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['6443'] }], 'sourceRanges': [context.properties['allowed_external_cidr']], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-health-checks', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['6080', '6443', '22624'] }], 'sourceRanges': ['35.191.0.0/16', '130.211.0.0/22', '209.85.152.0/22', '209.85.204.0/22'], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-etcd', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['2379-2380'] }], 'sourceTags': [context.properties['infra_id'] + '-master'], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-control-plane', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['10257'] },{ 'IPProtocol': 'tcp', 'ports': ['10259'] },{ 'IPProtocol': 'tcp', 'ports': ['22623'] }], 'sourceTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-internal-network', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'icmp' },{ 'IPProtocol': 'tcp', 'ports': ['22'] }], 'sourceRanges': [context.properties['network_cidr']], 'targetTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ] } }, { 'name': context.properties['infra_id'] + '-internal-cluster', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'udp', 'ports': ['4789', '6081'] },{ 'IPProtocol': 'udp', 'ports': ['500', '4500'] },{ 'IPProtocol': 'esp', },{ 'IPProtocol': 'tcp', 'ports': ['9000-9999'] },{ 'IPProtocol': 'udp', 'ports': ['9000-9999'] },{ 'IPProtocol': 'tcp', 'ports': ['10250'] },{ 'IPProtocol': 'tcp', 'ports': ['30000-32767'] },{ 'IPProtocol': 'udp', 'ports': ['30000-32767'] }], 'sourceTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ], 'targetTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ] } }] return {'resources': resources}
7.10.14. GCP インフラストラクチャー用の RHCOS クラスターイメージの作成
OpenShift Container Platform ノードに Google Cloud Platform (GCP) 用の有効な Red Hat Enterprise Linux CoreOS (RHCOS) イメージを使用する必要があります。
手順
RHCOS イメージミラー ページから RHCOS イメージを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
ファイル名には、
rhcos-<version>-<arch>-gcp.<arch>.tar.gz
形式の OpenShift Container Platform のバージョン番号が含まれます。Google ストレージバケットを作成します。
$ gsutil mb gs://<bucket_name>
RHCOS イメージを Google ストレージバケットにアップロードします。
$ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>
アップロードした RHCOS イメージの場所を変数としてエクスポートします。
$ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz
クラスターイメージを作成します。
$ gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"
7.10.15. GCP でのブートストラップマシンの作成
OpenShift Container Platform クラスターの初期化を実行する際に使用するブートストラップマシンを Google Cloud Platform (GCP) で作成する必要があります。このマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供されている Deployment Manager テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- pyOpenSSL がインストールされていることを確認します。
手順
-
本トピックのブートストラップマシンの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを
04_bootstrap.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なブートストラップマシンについて記述しています。 インストールプログラムで必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所をエクスポートします。
$ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)
バケットを作成し、
bootstrap.ign
ファイルをアップロードします。$ gsutil mb gs://${INFRA_ID}-bootstrap-ignition $ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/
Ignition 設定にアクセスするために使用するブートストラップインスタンスの署名付き URL を作成します。出力から URL を変数としてエクスポートします。
$ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`
04_bootstrap.yaml
リソース定義ファイルを作成します。$ cat <<EOF >04_bootstrap.yaml imports: - path: 04_bootstrap.py resources: - name: cluster-bootstrap type: 04_bootstrap.py properties: infra_id: '${INFRA_ID}' 1 region: '${REGION}' 2 zone: '${ZONE_0}' 3 cluster_network: '${CLUSTER_NETWORK}' 4 control_subnet: '${CONTROL_SUBNET}' 5 image: '${CLUSTER_IMAGE}' 6 machine_type: 'n1-standard-4' 7 root_volume_size: '128' 8 bootstrap_ign: '${BOOTSTRAP_IGN}' 9 EOF
- 1
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 2
region
はクラスターをデプロイするリージョンです (例:us-central1
)。- 3
zone
はブートストラップインスタンスをデプロイするゾーンです (例:us-central1-b
)。- 4
cluster_network
はクラスターネットワークのselfLink
URL です。- 5
control_subnet
は、コントロールサブセットのselfLink
URL です。- 6
image
は RHCOS イメージのselfLink
URL です。- 7
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 8
root_volume_size
はブートストラップマシンのブートディスクサイズです。- 9
bootstrap_ign
は署名付き URL の作成時の URL 出力です。
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml
Deployment Manager の制限によりテンプレートではロードバランサーのメンバーシップを管理しないため、ブートストラップマシンは手動で追加する必要があります。
ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。
$ gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap
ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。
$ gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}
7.10.15.1. ブートストラップマシンの Deployment Manager テンプレート
以下の Deployment Mananger テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。
例7.7 04_bootstrap.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-bootstrap-public-ip', 'type': 'compute.v1.address', 'properties': { 'region': context.properties['region'] } }, { 'name': context.properties['infra_id'] + '-bootstrap', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zone'] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': '{"ignition":{"config":{"replace":{"source":"' + context.properties['bootstrap_ign'] + '"}},"version":"3.1.0"}}', }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'], 'accessConfigs': [{ 'natIP': '$(ref.' + context.properties['infra_id'] + '-bootstrap-public-ip.address)' }] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-bootstrap' ] }, 'zone': context.properties['zone'] } }, { 'name': context.properties['infra_id'] + '-bootstrap-instance-group', 'type': 'compute.v1.instanceGroup', 'properties': { 'namedPorts': [ { 'name': 'ignition', 'port': 22623 }, { 'name': 'https', 'port': 6443 } ], 'network': context.properties['cluster_network'], 'zone': context.properties['zone'] } }] return {'resources': resources}
7.10.16. GCP でのコントロールプレーンマシンの作成
クラスターで使用するコントロールプレーンマシンを Google Cloud Platform (GCP) で作成する必要があります。これらのマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
手順
-
本トピックのコントロールプレーンマシンの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを
05_control_plane.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンについて記述しています。 リソース定義で必要な以下の変数をエクスポートします。
$ export MASTER_IGNITION=`cat <installation_directory>/master.ign`
05_control_plane.yaml
リソース定義ファイルを作成します。$ cat <<EOF >05_control_plane.yaml imports: - path: 05_control_plane.py resources: - name: cluster-control-plane type: 05_control_plane.py properties: infra_id: '${INFRA_ID}' 1 zones: 2 - '${ZONE_0}' - '${ZONE_1}' - '${ZONE_2}' control_subnet: '${CONTROL_SUBNET}' 3 image: '${CLUSTER_IMAGE}' 4 machine_type: 'n1-standard-4' 5 root_volume_size: '128' service_account_email: '${MASTER_SERVICE_ACCOUNT}' 6 ignition: '${MASTER_IGNITION}' 7 EOF
- 1
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 2
zones
は、コントロールプレーンインスタンスをデプロイするゾーンです (例:us-central1-a
、us-central1-b
、およびus-central1-c
)。- 3
control_subnet
は、コントロールサブセットのselfLink
URL です。- 4
image
は RHCOS イメージのselfLink
URL です。- 5
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 6
service_account_email
は作成したマスターサービスアカウントのメールアドレスです。- 7
ignition
はmaster.ign
ファイルの内容です。
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml
Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。
以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。
$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-master-0 $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-instance-group --zone=${ZONE_1} --instances=${INFRA_ID}-master-1 $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-instance-group --zone=${ZONE_2} --instances=${INFRA_ID}-master-2
外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。
$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0 $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1 $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2
7.10.16.1. コントロールプレーンマシンの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。
例7.8 05_control_plane.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-master-0', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][0] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][0] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][0] } }, { 'name': context.properties['infra_id'] + '-master-1', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][1] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][1] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][1] } }, { 'name': context.properties['infra_id'] + '-master-2', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][2] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][2] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][2] } }] return {'resources': resources}
7.10.17. ブートストラップの完了を待機し、GCP のブートストラップリソースを削除する
Google Cloud Platform (GCP) ですべての必要なインフラストラクチャーを作成した後に、ブートストラッププロセスが、インストールプログラムで生成した Ignition 設定ファイルを使用してプロビジョニングしたマシンで完了するのを待機します。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
手順
インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1 --log-level info 2
コマンドが
FATAL
警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。ブートストラップリソースを削除します。
$ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0} $ gsutil rm gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign $ gsutil rb gs://${INFRA_ID}-bootstrap-ignition $ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap
7.10.18. GCP での追加のワーカーマシンの作成
Google Cloud Platform (GCP) でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、または自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。
この例では、Deployment Manager テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_worker.py
というタイプのリソースを追加して起動することができます。
ワーカーマシンを使用するために提供される Deployment Manager テンプレートを使用しない場合は、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
手順
-
本トピックのワーカーマシンの Deployment Manager テンプレートからテンプレートをコピーし、これを
06_worker.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なワーカーマシンについて記述しています。 リソース定義が使用する変数をエクスポートします。
コンピュートマシンをホストするサブネットをエクスポートします。
$ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)
サービスアカウントのメールアドレスをエクスポートします。
$ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)
コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。
$ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`
06_worker.yaml
リソース定義ファイルを作成します。$ cat <<EOF >06_worker.yaml imports: - path: 06_worker.py resources: - name: 'worker-0' 1 type: 06_worker.py properties: infra_id: '${INFRA_ID}' 2 zone: '${ZONE_0}' 3 compute_subnet: '${COMPUTE_SUBNET}' 4 image: '${CLUSTER_IMAGE}' 5 machine_type: 'n1-standard-4' 6 root_volume_size: '128' service_account_email: '${WORKER_SERVICE_ACCOUNT}' 7 ignition: '${WORKER_IGNITION}' 8 - name: 'worker-1' type: 06_worker.py properties: infra_id: '${INFRA_ID}' 9 zone: '${ZONE_1}' 10 compute_subnet: '${COMPUTE_SUBNET}' 11 image: '${CLUSTER_IMAGE}' 12 machine_type: 'n1-standard-4' 13 root_volume_size: '128' service_account_email: '${WORKER_SERVICE_ACCOUNT}' 14 ignition: '${WORKER_IGNITION}' 15 EOF
- 1
name
はワーカーマシンの名前です (例:worker-0
)。- 2 9
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 3 10
zone
はワーカーマシンをデプロイするゾーンです (例:us-central1-a
)。- 4 11
compute_subnet
はコンピュートサブネットのselfLink
URL です。- 5 12
image
は RHCOS イメージのselfLink
URL です。1- 6 13
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 7 14
service_account_email
は作成したワーカーサービスアカウントのメールアドレスです。- 8 15
Ignition
はworker.ign
ファイルの内容です。
-
オプション: 追加のインスタンスを起動する必要がある場合には、
06_worker.py
タイプの追加のリソースを06_worker.yaml
リソース定義ファイルに組み込みます。 gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml
GCP Marketplace イメージを使用するには、使用するオファーを指定します。
-
OpenShift Container Platform:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
-
OpenShift Platform Plus:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
-
OpenShift Kubernetes Engine:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145
-
OpenShift Container Platform:
7.10.18.1. ワーカーマシンの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。
例7.9 06_worker.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-' + context.env['name'], 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zone'] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['compute_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-worker', ] }, 'zone': context.properties['zone'] } }] return {'resources': resources}
7.10.19. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.9 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.9 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.9 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.9 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
7.10.20. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
7.10.21. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.22.1 master-1 Ready master 63m v1.22.1 master-2 Ready master 64m v1.22.1
出力には作成したすべてのマシンが一覧表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.22.1 master-1 Ready master 73m v1.22.1 master-2 Ready master 74m v1.22.1 worker-0 Ready worker 11m v1.22.1 worker-1 Ready worker 11m v1.22.1
注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
7.10.22. オプション: Ingress DNS レコードの追加
Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除した場合、Ingress ロードバランサーをポイントする DNS レコードを手動で作成する必要があります。ワイルドカード *.apps.{baseDomain}.
または特定のレコードのいずれかを作成できます。要件に基づいて A、CNAME その他のレコードを使用できます。
前提条件
- GCP アカウントを設定します。
- Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
- ワーカーマシンを作成します。
手順
Ingress ルーターがロードバランサーを作成し、
EXTERNAL-IP
フィールドにデータを設定するのを待機します。$ oc -n openshift-ingress get service router-default
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98
A レコードをゾーンに追加します。
A レコードを使用するには、以下を実行します。
ルーター IP アドレスの変数をエクスポートします。
$ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`
A レコードをプライベートゾーンに追加します。
$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone
また、外部クラスターの場合は、A レコードをパブリックゾーンに追加します。
$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}
ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。
$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes
出力例
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com grafana-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com
7.10.23. ユーザーによってプロビジョニングされるインフラストラクチャーでの GCP インストールの完了
Google Cloud Platform (GCP) のユーザーによってプロビジョニングされるインフラストラクチャーで OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。
前提条件
- OpenShift Container Platform クラスターのブートストラップマシンを、ユーザーによってプロビジョニングされる GCP インフラストラクチャーにデプロイします。
-
oc
CLI をインストールし、ログインします。
手順
クラスターのインストールを完了します。
$ ./openshift-install --dir <installation_directory> wait-for install-complete 1
出力例
INFO Waiting up to 30m0s for the cluster to initialize...
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターの稼働状態を確認します。
以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。
$ oc get clusterversion
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% complete
以下のコマンドを実行し、 Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。
$ oc get clusteroperators
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.5.4 True False False 7m56s cloud-credential 4.5.4 True False False 31m cluster-autoscaler 4.5.4 True False False 16m console 4.5.4 True False False 10m csi-snapshot-controller 4.5.4 True False False 16m dns 4.5.4 True False False 22m etcd 4.5.4 False False False 25s image-registry 4.5.4 True False False 16m ingress 4.5.4 True False False 16m insights 4.5.4 True False False 17m kube-apiserver 4.5.4 True False False 19m kube-controller-manager 4.5.4 True False False 20m kube-scheduler 4.5.4 True False False 20m kube-storage-version-migrator 4.5.4 True False False 16m machine-api 4.5.4 True False False 22m machine-config 4.5.4 True False False 22m marketplace 4.5.4 True False False 16m monitoring 4.5.4 True False False 10m network 4.5.4 True False False 23m node-tuning 4.5.4 True False False 23m openshift-apiserver 4.5.4 True False False 17m openshift-controller-manager 4.5.4 True False False 15m openshift-samples 4.5.4 True False False 16m operator-lifecycle-manager 4.5.4 True False False 22m operator-lifecycle-manager-catalog 4.5.4 True False False 22m operator-lifecycle-manager-packageserver 4.5.4 True False False 18m service-ca 4.5.4 True False False 23m service-catalog-apiserver 4.5.4 True False False 23m service-catalog-controller-manager 4.5.4 True False False 23m storage 4.5.4 True False False 17m
以下のコマンドを実行して、クラスター Pod を表示します。
$ oc get pods --all-namespaces
出力例
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system etcd-member-ip-10-0-3-111.us-east-2.compute.internal 1/1 Running 0 35m kube-system etcd-member-ip-10-0-3-239.us-east-2.compute.internal 1/1 Running 0 37m kube-system etcd-member-ip-10-0-3-24.us-east-2.compute.internal 1/1 Running 0 35m openshift-apiserver-operator openshift-apiserver-operator-6d6674f4f4-h7t2t 1/1 Running 1 37m openshift-apiserver apiserver-fm48r 1/1 Running 0 30m openshift-apiserver apiserver-fxkvv 1/1 Running 0 29m openshift-apiserver apiserver-q85nm 1/1 Running 0 29m ... openshift-service-ca-operator openshift-service-ca-operator-66ff6dc6cd-9r257 1/1 Running 0 37m openshift-service-ca apiservice-cabundle-injector-695b6bcbc-cl5hm 1/1 Running 0 35m openshift-service-ca configmap-cabundle-injector-8498544d7-25qn6 1/1 Running 0 35m openshift-service-ca service-serving-cert-signer-6445fc9c6-wqdqn 1/1 Running 0 35m openshift-service-catalog-apiserver-operator openshift-service-catalog-apiserver-operator-549f44668b-b5q2w 1/1 Running 0 32m openshift-service-catalog-controller-manager-operator openshift-service-catalog-controller-manager-operator-b78cr2lnm 1/1 Running 0 31m
現在のクラスターバージョンが
AVAILABLE
の場合、インストールが完了します。
7.10.24. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.9 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
7.10.25. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
- GCP にグローバルにアクセスできる Ingress コントローラーを設定 します。