3.6. AWS のクラスターの既存 VPC へのインストール


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

3.6.1. 前提条件

3.6.2. カスタム VPC の使用について

OpenShift Container Platform 4.18 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

3.6.2.1. VPC を使用するための要件

インストールプログラムは、以下のコンポーネントを作成しなくなりました。

  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • サブネット
  • ルートテーブル
  • VPC
  • VPC DHCP オプション
  • VPC エンドポイント
注記

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

カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。AWS VPC コンソールウィザードの設定と AWS VPC の作成および管理の詳細は、Amazon Web Services ドキュメントの VPC の作成 を参照してください。

インストールプログラムには、以下の機能はありません。

  • 使用するクラスターのネットワーク範囲を細分化する。
  • サブネットのルートテーブルを設定する。
  • DHCP などの VPC オプションを設定する。

クラスターをインストールする前に、以下のタスクを完了する必要があります。AWS VPC でのネットワーキングの設定の詳細は、VPC ネットワーキングコンポーネントVPC のルートテーブル を参照してください。

VPC は以下の特性を満たす必要があります。

  • クラスターが使用するアベイラビリティーゾーンごとにパブリックサブネットとプライベートサブネットを作成します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。このタイプの設定の例は、AWS ドキュメントの パブリックサブネットとプライベートサブネット (NAT) を使用した VPC を参照してください。

    各サブネット ID を記録します。インストールを完了するには、install-config.yaml ファイルの プラットフォーム セクションにこれらの値を入力する必要があります。AWS ドキュメントの サブネット ID の検索 を参照してください。

  • VPC の CIDR ブロックには、クラスターマシンの IP アドレスプールである Networking.MachineCIDR 範囲が含まれている必要があります。サブネット CIDR ブロックは、指定したマシン CIDR に属している必要があります。
  • VPC には、パブリックインターネットゲートウェイが接続されている必要があります。アベイラビリティーゾーンごとに以下が必要です。

    • パブリックサブネットには、インターネットゲートウェイへのルートが必要です。
    • パブリックサブネットには、EIP アドレスが割り当てられた NAT ゲートウェイが必要です。
    • プライベートサブネットには、パブリックサブネットの NAT ゲートウェイへのルートが必要です。
  • VPC は kubernetes.io/cluster/.*: ownedNameopenshift.io/cluster タグを使用できません。

    インストールプログラムは kubernetes.io/cluster/.*: shared タグを追加するようにサブネットを変更するため、サブネットでは 1 つ以上の空のタグスロットが利用可能である必要があります。AWS ドキュメントで タグ制限 を確認し、インストールプログラムでタグを指定する各サブネットに追加できるようにします。Name タグは EC2 Name フィールドと重複し、その結果インストールが失敗するため、使用できません。

  • OpenShift Container Platform クラスターを AWS Outpost に拡張し、既存の Outpost サブネットを使用する場合、既存のサブネットで kubernetes.io/cluster/unmanaged: true タグを使用する必要があります。このタグを適用しないと、Cloud Controller Manager が Outpost サブネットにサービスロードバランサーを作成するため、インストールが失敗する可能性があります。これはサポートされていない設定です。
  • VPC で enableDnsSupport および enableDnsHostnames 属性を有効にし、クラスターが VPC に割り当てられている Route 53 ゾーンを使用してクラスターの内部 DNS レコードを解決できるようにする必要があります。AWS ドキュメントの DNS Support in Your VPC を参照してください。

    独自の Route 53 ホストプライベートゾーンを使用する場合、クラスターのインストール前に既存のホストゾーンを VPC に関連付ける必要があります。install-config.yaml ファイルの platform.aws.hostedZone フィールドと platform.aws.hostedZoneRole フィールドを使用して、ホストゾーンを定義できます。クラスターをインストールするアカウントとプライベートホストゾーンを共有することで、別のアカウントからプライベートホストゾーンを使用できます。別のアカウントからプライベートホストゾーンを使用する場合は、Passthrough または Manual 認証情報モードを使用する必要があります。

非接続環境で作業している場合、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達することはできません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

オプション 1: VPC エンドポイントを作成する

VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<aws_region>.amazonaws.com
  • elasticloadbalancing.<aws_region>.amazonaws.com
  • s3.<aws_region>.amazonaws.com

このオプションを使用すると、VPC および必要な AWS サービスの間でネットワークトラフィックがプライベートのままになります。

オプション 2: VPC エンドポイントなしでプロキシーを作成する

インストールプロセスの一環として、HTTP または HTTPS プロキシーを設定できます。このオプションを使用すると、インターネットトラフィックはプロキシーを経由して、必要な AWS サービスに到達します。

オプション 3: VPC エンドポイントでプロキシーを作成する

インストールプロセスの一環として、VPC エンドポイントを使用して HTTP または HTTPS プロキシーを設定できます。VPC エンドポイントを作成し、クラスターが使用しているサブネットにアタッチします。次のようにエンドポイントに名前を付けます。

  • ec2.<aws_region>.amazonaws.com
  • elasticloadbalancing.<aws_region>.amazonaws.com
  • s3.<aws_region>.amazonaws.com

install-config.yaml ファイルでプロキシーを設定するときに、これらのエンドポイントを noProxy フィールドに追加します。このオプションを使用すると、プロキシーはクラスターがインターネットに直接アクセスするのを防ぎます。ただし、VPC と必要な AWS サービスの間のネットワークトラフィックはプライベートのままです。

必要な VPC コンポーネント

お使いのマシンとの通信を可能にする適切な VPC およびサブネットを指定する必要があります。

コンポーネントAWS タイプ説明

VPC

  • AWS::EC2::VPC
  • AWS::EC2::VPCEndpoint

使用するクラスターのパブリック VPC を指定する必要があります。VPC は、各サブネットのルートテーブルを参照するエンドポイントを使用して、S3 でホストされているレジストリーとの通信を強化します。

パブリックサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::SubnetNetworkAclAssociation

VPC には 1 から 3 のアベイラビリティーゾーンのパブリックサブネットが必要であり、それらを適切な Ingress ルールに関連付ける必要があります。

インターネットゲートウェイ

  • AWS::EC2::InternetGateway
  • AWS::EC2::VPCGatewayAttachment
  • AWS::EC2::RouteTable
  • AWS::EC2::Route
  • AWS::EC2::SubnetRouteTableAssociation
  • AWS::EC2::NatGateway
  • AWS::EC2::EIP

VPC に割り当てられたパブリックルートを持つパブリックインターネットゲートウェイが必要です。提供されるテンプレートでは、各パブリックサブネットに EIP アドレスと NAT ゲートウェイがあります。これらの NAT ゲートウェイは、プライベートサブネットインスタンスなどのクラスターリソースがインターネットに到達できるようにするもので、一部のネットワークが制限された環境またはプロキシーのシナリオでは必要ありません。

ネットワークアクセス制御

  • AWS::EC2::NetworkAcl
  • AWS::EC2::NetworkAclEntry

VPC が以下のポートにアクセスできるようにする必要があります。

ポート

理由

80

インバウンド HTTP トラフィック

443

インバウンド HTTPS トラフィック

22

インバウンド SSH トラフィック

1024 - 65535

インバウンド一時 (ephemeral) トラフィック

0 - 65535

アウトバウンド一時 (ephemeral) トラフィック

プライベートサブネット

  • AWS::EC2::Subnet
  • AWS::EC2::RouteTable
  • AWS::EC2::SubnetRouteTableAssociation

VPC にはプライベートサブネットを使用できます。提供される CloudFormation テンプレートは 1 から 3 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

3.6.2.2. VPC 検証

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

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

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

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

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

3.6.2.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。

3.6.2.5. オプション: AWS セキュリティーグループ

デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。

ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml ファイルを変更してカスタムセキュリティーグループを適用します。

詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。

3.6.2.6. 共有 VPC にインストールする場合の信頼ポリシーの変更

共有 VPC を使用してクラスターをインストールする場合は、Passthrough または Manual 認証情報モードを使用できます。クラスターをインストールするために使用される IAM ロールを、VPC を所有するアカウントの信頼ポリシーのプリンシパルとして追加する必要があります。

Passthrough モードを使用する場合は、クラスターを作成するアカウントの Amazon Resource Name (ARN) (arn:aws:iam::123456789012:user/clustercreator など) をプリンシパルとして信頼ポリシーに追加します。

Manual モードを使用する場合は、クラスターを作成するアカウントの ARN と、クラスター所有者アカウントの Ingress オペレーターロールの ARN (arn:aws:iam::123456789012:role/<cluster-name>-openshift-ingress-operator-cloud-credentials など) をプリンシパルとして信頼ポリシーに追加します。

次のアクションをポリシーに追加する必要があります。

例3.5 共有 VPC のインストールに必要なアクション

  • route53:ChangeResourceRecordSets
  • route53:ListHostedZones
  • route53:ListHostedZonesByName
  • route53:ListResourceRecordSets
  • route53:ChangeTagsForResource
  • route53:GetAccountLimit
  • route53:GetChange
  • route53:GetHostedZone
  • route53:ListTagsForResource
  • route53:UpdateHostedZoneComment
  • tag:GetResources
  • tag:UntagResources

3.6.3. インストール設定ファイルの作成

Amazon Web Services (AWS) での OpenShift Container Platform のインストールをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ ./openshift-install create install-config --dir <installation_directory> 
      1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

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

      2. ターゲットに設定するプラットフォームとして AWS を選択します。
      3. Amazon Web Services (AWS) プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。
      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

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

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

表3.14 最小リソース要件
マシンオペレーティングシステム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 つの物理コアと同等です。これが有効にされている場合、(コアごとのスレッド x コア数) x ソケット数 = 仮想 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.18 の場合、RHCOS は RHEL バージョン 9.4 に基づいており、マイクロアーキテクチャー要件が更新されています。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

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

詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。

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

3.6.3.2. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。

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

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

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

次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。

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

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

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

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。すべてのインストール設定パラメーターの完全なリストと説明については、AWS のインストール設定パラメーター を参照してください。

AWS のサンプル install-config.yaml ファイル

Copy to Clipboard Toggle word wrap
apiVersion: v1 
1

baseDomain: example.com
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'
metadata:
  name: example-cluster
controlPlane: 
2

  name: master
  platform:
    aws:
      type: m6i.xlarge
  replicas: 3
compute: 
3

-  name: worker
  platform:
    aws:
      type: c5.4xlarge
  replicas: 3
networking: 
4

  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
platform: 
5

  aws:
    region: us-west-2

1
最初のインデントレベルのパラメーターは、クラスター全体にグローバルに適用されます。
2
controlPlane スタンザは、コントロールプレーンマシンに適用されます。
3
compute スタンザは、コンピュートマシンに適用されます。
4
networking スタンザは、クラスターネットワーク設定に適用されます。networking の値を指定しない場合、インストールプログラムによってデフォルト値が提供されます。
5
platform スタンザは、クラスターをホストするインフラストラクチャープラットフォームに適用されます。

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

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.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 には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。Amazon EC2Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

3.6.3.6. 既存の AWS セキュリティーグループをクラスターに適用する

既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

前提条件

  • AWS でセキュリティーグループを作成している。詳細は、セキュリティーグループ の操作に関する AWS ドキュメントを参照してください。
  • セキュリティーグループは、クラスターをデプロイする既存の VPC に関連付ける必要があります。セキュリティーグループを別の VPC に関連付けることはできません。
  • 既存の install-config.yaml ファイルがある。

手順

  1. install-config.yaml ファイルで、compute.platform.aws.additionalSecurityGroupIDs パラメーターを編集して、コンピュートマシンに 1 つ以上のカスタムセキュリティーグループを指定します。
  2. controlPlane.platform.aws.additionalSecurityGroupIDs パラメーターを編集して、コントロールプレーンマシンに 1 つ以上のカスタムセキュリティーグループを指定します。
  3. ファイルを保存し、クラスターをデプロイする際に参照します。

カスタムセキュリティーグループを指定するサンプル install-config.yaml ファイル

Copy to Clipboard Toggle word wrap
# ...
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 
1

        - sg-2
  replicas: 3
controlPlane:
  hyperthreading: Enabled
  name: master
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-3
        - sg-4
  replicas: 3
platform:
  aws:
    region: us-east-1
    subnets: 
2

      - subnet-1
      - subnet-2
      - subnet-3

1
Amazon EC2 コンソールに表示されるセキュリティーグループの名前を、sg 接頭辞を含めて指定します。
2
クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。

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

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

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

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

手順

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

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

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

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

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

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

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

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

    Copy to Clipboard Toggle word wrap
    $ 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 オブジェクト

    Copy to Clipboard Toggle word wrap
    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: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    Copy to Clipboard Toggle word wrap
    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: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: Secret
    metadata:
      name: <component_secret>
      namespace: <component_namespace>
    data:
      aws_access_key_id: <base64_encoded_aws_access_key_id>
      aws_secret_access_key: <base64_encoded_aws_secret_access_key>

重要

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

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

AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。

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

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

注記

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

前提条件

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

    必要な iam 権限

    • iam:CreateOpenIDConnectProvider
    • iam:CreateRole
    • iam:DeleteOpenIDConnectProvider
    • iam:DeleteRole
    • iam:DeleteRolePolicy
    • iam:GetOpenIDConnectProvider
    • iam:GetRole
    • iam:GetUser
    • iam:ListOpenIDConnectProviders
    • iam:ListRolePolicies
    • iam:ListRoles
    • iam:PutRolePolicy
    • iam:TagOpenIDConnectProvider
    • iam:TagRole

    必要な s3 権限

    • s3:CreateBucket
    • s3:DeleteBucket
    • s3:DeleteObject
    • s3:GetBucketAcl
    • s3:GetBucketTagging
    • s3:GetObject
    • s3:GetObjectAcl
    • s3:GetObjectTagging
    • s3:ListBucket
    • s3:PutBucketAcl
    • s3:PutBucketPolicy
    • s3:PutBucketPublicAccessBlock
    • s3:PutBucketTagging
    • s3:PutObject
    • s3:PutObjectAcl
    • s3:PutObjectTagging

    必要な cloudfront 権限

    • cloudfront:ListCloudFrontOriginAccessIdentities
    • cloudfront:ListDistributions
    • cloudfront:ListTagsForResource
  • OIDC 設定を、パブリック CloudFront ディストリビューション URL 経由で IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに保存する予定の場合、ccoctl ユーティリティーを実行する AWS アカウントには次の追加パーミッションが必要です。

    • cloudfront:CreateCloudFrontOriginAccessIdentity
    • cloudfront:CreateDistribution
    • cloudfront:DeleteCloudFrontOriginAccessIdentity
    • cloudfront:DeleteDistribution
    • cloudfront:GetCloudFrontOriginAccessIdentity
    • cloudfront:GetCloudFrontOriginAccessIdentityConfig
    • cloudfront:GetDistribution
    • cloudfront:TagResource
    • cloudfront:UpdateDistribution
    注記

    これらの追加のパーミッションは、ccoctl aws create-all コマンドで認証情報要求を処理する際の --create-private-s3-bucket オプションの使用をサポートします。

手順

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

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

    Copy to Clipboard Toggle word wrap
    $ 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 バイナリーを抽出します。

    Copy to Clipboard Toggle word wrap
    $ 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 を実行可能にします。

    Copy to Clipboard Toggle word wrap
    $ chmod 775 ccoctl.<rhel_version>

検証

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

    Copy to Clipboard Toggle word wrap
    $ ./ccoctl.rhel9

    出力例

    Copy to Clipboard Toggle word wrap
    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-title}
      nutanix      Manage credentials objects for Nutanix
    
    Flags:
      -h, --help   help for ccoctl
    
    Use "ccoctl [command] --help" for more information about a command.

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

AWS リソースを作成するときは、次のオプションがあります。

  • ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。
  • AWS リソースの変更前に ccoctl ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
3.6.4.2.2.1. 単一コマンドでの AWS リソースの作成

ccoctl ツールが AWS リソースの作成に使用するプロセスが組織の要件を自動的に満たす場合は、ccoctl aws create-all コマンドを使用して AWS リソースの作成を自動化できます。

それ以外の場合は、AWS リソースを個別に作成できます。詳細は、「AWS リソースの個別の作成」を参照してください。

注記

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

前提条件

以下が必要になります。

  • ccoctl バイナリーを展開して準備した。

手順

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

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

    Copy to Clipboard Toggle word wrap
    $ 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 ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-all \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --credentials-requests-dir=<path_to_credentials_requests_directory> \
    3
    
      --output-dir=<path_to_ccoctl_output_dir> \
    4
    
      --create-private-s3-bucket 
    5
    1
    追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    クラウドリソースが作成される AWS リージョンです。
    3
    コンポーネント CredentialsRequest オブジェクトのファイルを含むディレクトリーを指定します。
    4
    オプション: ccoctl ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
    5
    オプション: デフォルトでは、ccoctl ユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucket パラメーターを使用します。
    注記

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

検証

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

    Copy to Clipboard Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    cluster-authentication-02-config.yaml
    openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
    openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml
    openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml
    openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
    openshift-image-registry-installer-cloud-credentials-credentials.yaml
    openshift-ingress-operator-cloud-credentials-credentials.yaml
    openshift-machine-api-aws-cloud-credentials-credentials.yaml

    AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示を参照してください。

3.6.4.2.2.2. AWS リソースの個別の作成

ccoctl ツールを使用して、AWS リソースを個別に作成できます。このオプションは、異なるユーザーや部門間でこれらのリソースを作成する責任を共有する組織に役に立ちます。

それ以外の場合は、ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。詳細は、「単一コマンドによる AWS リソースの作成」を参照してください。

注記

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

一部の ccoctl コマンドは AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json パラメーターを使用して適用できます。

前提条件

  • ccoctl バイナリーを展開して準備しておく。

手順

  1. 次のコマンドを実行して、クラスターの OpenID Connect プロバイダーを設定するために使用されるパブリックおよびプライベート RSA キーファイルを生成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-key-pair

    出力例

    Copy to Clipboard Toggle word wrap
    2021/04/13 11:01:02 Generating RSA keypair
    2021/04/13 11:01:03 Writing private key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.private
    2021/04/13 11:01:03 Writing public key to /<path_to_ccoctl_output_dir>/serviceaccount-signer.public
    2021/04/13 11:01:03 Copying signing key for use by installer

    serviceaccount-signer.private および serviceaccount-signer.public は、生成されるキーファイルです。

    このコマンドは、クラスターがインストール時に必要とするプライベートキーを /<path_to_ccoctl_output_dir>/tls/bound-service-account-signing-key.key に作成します。

  2. 次のコマンドを実行して、AWS 上に OpenID Connect ID プロバイダーと S3 バケットを作成します。

    Copy to Clipboard Toggle word wrap
    $ ccoctl aws create-identity-provider \
      --name=<name> \
    1
    
      --region=<aws_region> \
    2
    
      --public-key-file=<path_to_ccoctl_output_dir>/serviceaccount-signer.public 
    3
    1
    <name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
    2
    <aws_region> は、クラウドリソースが作成される AWS リージョンです。
    3
    <path_to_ccoctl_output_dir> は、ccoctl aws create-key-pair コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    Copy to Clipboard Toggle word wrap
    2021/04/13 11:16:09 Bucket <name>-oidc created
    2021/04/13 11:16:10 OpenID Connect discovery document in the S3 bucket <name>-oidc at .well-known/openid-configuration updated
    2021/04/13 11:16:10 Reading public key
    2021/04/13 11:16:10 JSON web key set (JWKS) in the S3 bucket <name>-oidc at keys.json updated
    2021/04/13 11:16:18 Identity Provider created with ARN: arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com

    openid-configuration は検出ドキュメントであり、keys.json は JSON Web キーセットファイルです。

    このコマンドは、YAML 設定ファイルを /<path_to_ccoctl_output_dir>/manifests/cluster-authentication-02-config.yaml にも作成します。このファイルは、AWS IAM アイデンティティープロバイダーがトークンを信頼するように、クラスターが生成するサービスアカウントトークンの発行側の URL フィールドを設定します。

  3. クラスターの各コンポーネントに IAM ロールを作成します。

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

      Copy to Clipboard Toggle word wrap
      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      Copy to Clipboard Toggle word wrap
      $ 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 ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      Copy to Clipboard Toggle word wrap
      $ ccoctl aws create-iam-roles \
        --name=<name> \
        --region=<aws_region> \
        --credentials-requests-dir=<path_to_credentials_requests_directory> \
        --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
      注記

      GovCloud などの代替の IAM API エンドポイントを使用する AWS 環境では、--region パラメーターでリージョンを指定する必要もあります。

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

      それぞれの CredentialsRequest オブジェクトに、ccoctl は指定された OIDC アイデンティティープロバイダーに関連付けられた信頼ポリシーと、OpenShift Container Platform リリースイメージの各 CredentialsRequest オブジェクトに定義されるパーミッションポリシーを使用して IAM ロールを作成します。

検証

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

    Copy to Clipboard Toggle word wrap
    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    Copy to Clipboard Toggle word wrap
    cluster-authentication-02-config.yaml
    openshift-cloud-credential-operator-cloud-credential-operator-iam-ro-creds-credentials.yaml
    openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml
    openshift-cluster-api-capa-manager-bootstrap-credentials-credentials.yaml
    openshift-cluster-csi-drivers-ebs-cloud-credentials-credentials.yaml
    openshift-image-registry-installer-cloud-credentials-credentials.yaml
    openshift-ingress-operator-cloud-credentials-credentials.yaml
    openshift-machine-api-aws-cloud-credentials-credentials.yaml

    AWS にクエリーを実行すると、IAM ロールが作成されていることを確認できます。詳細は AWS ドキュメントの IAM ロールの一覧表示を参照してください。

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

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

前提条件

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

手順

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

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

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

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

    Copy to Clipboard Toggle word wrap
    $ openshift-install create manifests --dir <installation_directory>

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

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

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

    Copy to Clipboard Toggle word wrap
    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

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

    Copy to Clipboard Toggle word wrap
    $ ./openshift-install create cluster --dir <installation_directory> \ 
    1
    
        --log-level=info 
    2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
  2. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

    AdministratorAccess ポリシーが提供する昇格したパーミッションはインストール時にのみ必要です。

検証

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

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

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

出力例

Copy to Clipboard Toggle word wrap
...
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 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

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

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

前提条件

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

手順

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

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

    Copy to Clipboard Toggle word wrap
    $ oc whoami

    出力例

    Copy to Clipboard Toggle word wrap
    system:admin

3.6.7. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    Copy to Clipboard Toggle word wrap
    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    Copy to Clipboard Toggle word wrap
    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

3.6.8. 次のステップ

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.