AWS へのインストール


OpenShift Container Platform 4.17

Amazon Web Services への OpenShift Container Platform のインストール

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Amazon Web Services に OpenShift Container Platform をインストールする方法を説明します。

第1章 インストール方法

installer-provisioned infrastructure または user-provisioned infrastructure を使用して、Amazon Web Services (AWS) に OpenShift Container Platform をインストールできます。デフォルトのインストールタイプは、installer-provisioned infrastructure を使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーがプロビジョニングするインスラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。OpenShift Container Platform をシングルノードにインストールすることもできます。これは、エッジコンピューティング環境に最適な特殊なインストール方法です。

1.1. installer-provisioned infrastructure へのクラスターのインストール

以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされる AWS インフラストラクチャーに、クラスターをインストールできます。

1.2. user-provisioned infrastructure へのクラスターのインストール

以下の方法のいずれかを使用して、独自にプロビジョニングする AWS インフラストラクチャーにクラスターをインストールできます。

  • クラスターの各自でプロビジョニングする AWS インフラストラクチャーへのインストール: OpenShift Container Platform を、プロビジョニングする AWS インフラストラクチャーにインストールできます。提供される CloudFormation テンプレートを使用して、OpenShift Container Platform インストールに必要な各コンポーネントを表す AWS リソースのスタックを作成できます。
  • user-provisioned infrastructure を使用したネットワークが制限された環境での AWS へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを使用して、独自に提供する AWS インフラストラクチャーに OpenShift Container Platform をインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。ミラーリングされたコンテンツを使用して OpenShift Container Platform をインストールすることは可能ですが、クラスターが AWS API を使用するにはインターネットへのアクセスが必要です。

1.3. 単一ノードへのクラスターのインストール

OpenShift Container Platform を単一ノードにインストールすると、高可用性および大規模なクラスターの一部の要件が軽減されます。ただし、シングルノードにインストールするための要件 と、クラウドプロバイダーにシングルノードの OpenShift をインストールするための追加要件 に対処する必要があります。単一ノードのインストールの要件に対処した後、AWS へのカスタマイズされたクラスターのインストール 手順を使用してクラスターをインストールします。単一ノード OpenShift の手動インストール セクションには、OpenShift Container Platform クラスターを単一ノードにインストールする場合の例示的な install-config.yaml ファイルが含まれています。

1.4. 関連情報

第2章 AWS アカウントの設定

OpenShift Container Platform をインストールする前に、Amazon Web Services (AWS) アカウントを設定する必要があります。

2.1. Route 53 の設定

OpenShift Container Platform をインストールするには、使用する Amazon Web Services (AWS) アカウントに、Route 53 サービスの専用のパブリックホストゾーンが必要になります。このゾーンはドメインに対する権威を持っている必要があります。Route 53 サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。

手順

  1. ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、AWS または他のソースから新規のものを取得できます。

    注記

    AWS で新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかります。AWS 経由でドメインを購入する方法の詳細は、AWS ドキュメントの Registering Domain Names Using Amazon Route 53 を参照してください。

  2. 既存のドメインおよびレジストラーを使用している場合、その DNS を AWS に移行します。AWS ドキュメントの Making Amazon Route 53 the DNS Service for an Existing Domain を参照してください。
  3. ドメインまたはサブドメインのパブリックホストゾーンを作成します。AWS ドキュメントの Creating a Public Hosted Zone を参照してください。

    openshiftcorp.com などのルートドメインや、clusters.openshiftcorp.com などのサブドメインを使用します。

  4. ホストゾーンレコードから新規の権威ネームサーバーを抽出します。AWS ドキュメントの Getting the Name Servers for a Public Hosted Zone を参照してください。
  5. ドメインが使用する AWS Route 53 ネームサーバーのレジストラーレコードを更新します。たとえば、別のアカウントを使用してドメインを Route 53 サービスに登録している場合は、AWS ドキュメントの Adding or Changing Name Servers or Glue Records のトピックを参照してください。
  6. サブドメインを使用している場合は、その委任レコードを親ドメインに追加します。これにより、サブドメインの Amazon Route 53 の責任が付与されます。親ドメインの DNS プロバイダーによって要約された委任手順に従います。ハイレベルの手順の例は、AWS ドキュメントの Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain を参照してください。

2.1.1. AWS Route 53 の Ingress Operator エンドポイント設定

Amazon Web Services (AWS) GovCloud (US) US-West または US-East リージョンのいずれかにインストールする場合、Ingress Operator は Route53 およびタグ付けする API クライアントに us-gov-west-1 リージョンを使用します。

Ingress Operator は、タグ付けするエンドポイントが文字列 'us-gov-east-1' を含むように設定される場合、タグ付けする API エンドポイントとして https://tagging.us-gov-west-1.amazonaws.com を使用します。

AWS GovCloud (US) エンドポイントの詳細は、GovCloud (US) に関する AWS ドキュメントの Service Endpoints を参照してください。

重要

us-gov-east-1 リージョンにインストールする場合、プライベート、非接続インストールは AWS GovCloud ではサポートされません。

Route 53 設定の例

platform:
  aws:
    region: us-gov-west-1
    serviceEndpoints:
    - name: ec2
      url: https://ec2.us-gov-west-1.amazonaws.com
    - name: elasticloadbalancing
      url: https://elasticloadbalancing.us-gov-west-1.amazonaws.com
    - name: route53
      url: https://route53.us-gov.amazonaws.com 1
    - name: tagging
      url: https://tagging.us-gov-west-1.amazonaws.com 2

1
Route 53 は、AWS GovCloud (US) リージョンの両方で https://route53.us-gov.amazonaws.com にデフォルト設定されます。
2
US-West リージョンのみにタグ付けするためのエンドポイントがあります。クラスターが別のリージョンにある場合は、このパラメーターを省略します。

2.2. AWS アカウントの制限

OpenShift Container Platform クラスターは数多くの Amazon Web Services (AWS) コンポーネントを使用し、デフォルトの サービス制限 は、OpenShift Container Platform クラスターをインストールする機能に影響を与えます。特定のクラスター設定を使用し、クラスターを特定の AWS リージョンにデプロイするか、アカウントを使用して複数のクラスターを実行する場合、AWS アカウントの追加リソースを要求することが必要になる場合があります。

以下の表は、OpenShift Container Platform クラスターのインストールおよび実行機能に影響を与える可能性のある AWS コンポーネントの制限を要約しています。

コンポーネントデフォルトで利用できるクラスターの数デフォルトの AWS の制限説明

インスタンスの制限

変動あり。

変動あり。

デフォルトで、各クラスターは以下のインスタンスを作成します。

  • 1 つのブートストラップマシン。これはインストール後に削除されます。
  • 3 つのコントロールプレーンノード
  • 3 つのワーカーノード

これらのインスタンスタイプの数は、新規アカウントのデフォルト制限内の値です。追加のワーカーノードをデプロイし、自動スケーリングを有効にし、大規模なワークロードをデプロイするか、異なるインスタンスタイプを使用するには、アカウントの制限を見直し、クラスターが必要なマシンをデプロイできることを確認します。

ほとんどのリージョンでは、ワーカーマシンは m6i.large インスタンスを使用し、ブートストラップおよびコントロールプレーンマシンは m6i.xlarge インスタンスを使用します。これらのインスタンスタイプをサポートしないすべてのリージョンを含む一部のリージョンでは、m5.large および m5.xlarge インスタンスが代わりに使用されます。

Elastic IP (EIP)

0 - 1

アカウントごとに 5 つの EIP

クラスターを高可用性設定でプロビジョニングするために、インストールプログラムはそれぞれの リージョン内のアベイラビリティーゾーン にパブリックおよびプライベートのサブネットを作成します。各プライベートサブネットには NAT ゲートウェイ が必要であり、各 NAT ゲートウェイには別個の Elastic IP が必要です。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。デフォルトの高可用性を利用するには、少なくとも 3 つのアベイラビリティーゾーンがあるリージョンにクラスターをインストールします。アベイラビリティーゾーンが 6 つ以上あるリージョンにクラスターをインストールするには、EIP 制限を引き上げる必要があります。

重要

us-east-1 リージョンを使用するには、アカウントの EIP 制限を引き上げる必要があります。

Virtual Private Cloud (VPC)

5

リージョンごとに 5 つの VPC

各クラスターは独自の VPC を作成します。

Elastic Load Balancing (ELB/NLB)

3

リージョンごとに 20

デフォルトで、各クラスターは、マスター API サーバーの内部および外部のネットワークロードバランサーおよびルーターの単一の Classic Load Balancer を作成します。追加の Kubernetes Service オブジェクトをタイプ LoadBalancer を指定してデプロイすると、追加の ロードバランサー が作成されます。

NAT ゲートウェイ

5

アベイラビリティゾーンごとに 5 つ

クラスターは各アベイラビリティーゾーンに 1 つの NAT ゲートウェイをデプロイします。

Elastic Network Interface (ENI)

12 以上

リージョンごとに 350

デフォルトのインストールは 21 の ENI を作成し、リージョンの各アベイラビリティーゾーンに 1 つの ENI を作成します。たとえば、us-east-1 リージョンには 6 つのアベイラビリティーゾーンが含まれるため、そのゾーンにデプロイされるクラスターは 27 の ENI を使用します。AWS リージョンマップ を確認して、各リージョンにあるアベイラビリティーゾーンの数を判別します。

クラスターの使用量やデプロイされたワークロード別に作成された追加のマシンや ELB ロードバランサーに対して、追加の ENI が作成されます。

VPC ゲートウェイ

20

アカウントごとに 20

各クラスターは、S3 アクセス用の単一の VPC ゲートウェイを作成します。

S3 バケット

99

アカウントごとに 100 バケット

インストールプロセスでは 1 つの一時的なバケットを作成し、各クラスターのレジストリーコンポーネントがバケットを作成するため、AWS アカウントごとに 99 の OpenShift Container Platform クラスターのみを作成できます。

セキュリティーグループ

250

アカウントごとに 2,500

各クラスターは、10 の個別のセキュリティーグループを作成します。

2.3. IAM ユーザーに必要な AWS パーミッション

注記

ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1 にアクセス許可 tag:GetResources を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。

AdministratorAccess ポリシーを、Amazon Web Services (AWS) で作成する IAM ユーザーに割り当てる場合、そのユーザーには必要なパーミッションすべてを付与します。OpenShift Container Platform クラスターのすべてのコンポーネントをデプロイするために、IAM ユーザーに以下のパーミッションが必要になります。

例2.1 インストールに必要な EC2 パーミッション

  • ec2:AttachNetworkInterface
  • ec2:AuthorizeSecurityGroupEgress
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CopyImage
  • ec2:CreateNetworkInterface
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:CreateVolume
  • ec2:DeleteSecurityGroup
  • ec2:DeleteSnapshot
  • ec2:DeleteTags
  • ec2:DeregisterImage
  • ec2:DescribeAccountAttributes
  • ec2:DescribeAddresses
  • ec2:DescribeAvailabilityZones
  • ec2:DescribeDhcpOptions
  • ec2:DescribeImages
  • ec2:DescribeInstanceAttribute
  • ec2:DescribeInstanceCreditSpecifications
  • ec2:DescribeInstances
  • ec2:DescribeInstanceTypes
  • ec2:DescribeInternetGateways
  • ec2:DescribeKeyPairs
  • ec2:DescribeNatGateways
  • ec2:DescribeNetworkAcls
  • ec2:DescribeNetworkInterfaces
  • ec2:DescribePrefixLists
  • ec2:DescribePublicIpv4Pools (install-config.yamlpublicIpv4Pool が指定されている場合にのみ必要)
  • ec2:DescribeRegions
  • ec2:DescribeRouteTables
  • ec2:DescribeSecurityGroupRules
  • ec2:DescribeSecurityGroups
  • ec2:DescribeSubnets
  • ec2:DescribeTags
  • ec2:DescribeVolumes
  • ec2:DescribeVpcAttribute
  • ec2:DescribeVpcClassicLink
  • ec2:DescribeVpcClassicLinkDnsSupport
  • ec2:DescribeVpcEndpoints
  • ec2:DescribeVpcs
  • ec2:DisassociateAddress (install-config.yamlpublicIpv4Pool が指定されている場合にのみ必要)
  • ec2:GetEbsDefaultKmsKeyId
  • ec2:ModifyInstanceAttribute
  • ec2:ModifyNetworkInterfaceAttribute
  • ec2:RevokeSecurityGroupEgress
  • ec2:RevokeSecurityGroupIngress
  • ec2:RunInstances
  • ec2:TerminateInstances

例2.2 インストール時のネットワークリソースの作成に必要なパーミッション

  • ec2:AllocateAddress
  • ec2:AssociateAddress
  • ec2:AssociateDhcpOptions
  • ec2:AssociateRouteTable
  • ec2:AttachInternetGateway
  • ec2:CreateDhcpOptions
  • ec2:CreateInternetGateway
  • ec2:CreateNatGateway
  • ec2:CreateRoute
  • ec2:CreateRouteTable
  • ec2:CreateSubnet
  • ec2:CreateVpc
  • ec2:CreateVpcEndpoint
  • ec2:ModifySubnetAttribute
  • ec2:ModifyVpcAttribute
注記

既存の Virtual Private Cloud (VPC) を使用する場合、アカウントではネットワークリソースの作成にこれらのパーミッションを必要としません。

例2.3 インストールに必要な Elastic Load Balancing (ELB) のパーミッション

  • elasticloadbalancing:AddTags
  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
  • elasticloadbalancing:AttachLoadBalancerToSubnets
  • elasticloadbalancing:ConfigureHealthCheck
  • elasticloadbalancing:CreateListener
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateLoadBalancerListeners
  • elasticloadbalancing:CreateTargetGroup
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer
  • elasticloadbalancing:DeregisterTargets
  • elasticloadbalancing:DescribeInstanceHealth
  • elasticloadbalancing:DescribeListeners
  • elasticloadbalancing:DescribeLoadBalancerAttributes
  • elasticloadbalancing:DescribeLoadBalancers
  • elasticloadbalancing:DescribeTags
  • elasticloadbalancing:DescribeTargetGroupAttributes
  • elasticloadbalancing:DescribeTargetHealth
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:ModifyTargetGroup
  • elasticloadbalancing:ModifyTargetGroupAttributes
  • elasticloadbalancing:RegisterInstancesWithLoadBalancer
  • elasticloadbalancing:RegisterTargets
  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener
  • elasticloadbalancing:SetSecurityGroups
重要

OpenShift Container Platform は、ELB と ELBv2 API サービスの両方を使用してロードバランサーをプロビジョニングします。パーミッションリストには、両方のサービスに必要なパーミッションが表示されます。AWS Web コンソールには、両方のサービスが同じ elasticloadbalancing アクション接頭辞を使用しているにもかかわらず、同じアクションを認識しないという既知の問題が存在します。サービスが特定の elasticloadbalancing アクションを認識しないという警告は無視できます。

例2.4 インストールに必要な IAM パーミッション

  • iam:AddRoleToInstanceProfile
  • iam:CreateInstanceProfile
  • iam:CreateRole
  • iam:DeleteInstanceProfile
  • iam:DeleteRole
  • iam:DeleteRolePolicy
  • iam:GetInstanceProfile
  • iam:GetRole
  • iam:GetRolePolicy
  • iam:GetUser
  • iam:ListInstanceProfilesForRole
  • iam:ListRoles
  • iam:ListUsers
  • iam:PassRole
  • iam:PutRolePolicy
  • iam:RemoveRoleFromInstanceProfile
  • iam:SimulatePrincipalPolicy
  • iam:TagInstanceProfile
  • iam:TagRole
注記
  • install-config.yaml ファイルで既存の IAM ロールを指定する場合、iam:CreateRoleiam:DeleteRoleiam:DeleteRolePolicy、および iam:PutRolePolicy の IAM 権限は必要ありません。
  • AWS アカウントにロードバランサーを作成していない場合、IAM ユーザーには iam:CreateServiceLinkedRole パーミッションも必要です。

例2.5 インストールに必要な Route 53 パーミッション

  • route53:ChangeResourceRecordSets
  • route53:ChangeTagsForResource
  • route53:CreateHostedZone
  • route53:DeleteHostedZone
  • route53:GetChange
  • route53:GetHostedZone
  • route53:ListHostedZones
  • route53:ListHostedZonesByName
  • route53:ListResourceRecordSets
  • route53:ListTagsForResource
  • route53:UpdateHostedZoneComment

例2.6 インストールに必要な Amazon Simple Storage Service (S3) パーミッション

  • s3:CreateBucket
  • s3:DeleteBucket
  • s3:GetAccelerateConfiguration
  • s3:GetBucketAcl
  • s3:GetBucketCors
  • s3:GetBucketLocation
  • s3:GetBucketLogging
  • s3:GetBucketObjectLockConfiguration
  • s3:GetBucketPolicy
  • s3:GetBucketRequestPayment
  • s3:GetBucketTagging
  • s3:GetBucketVersioning
  • s3:GetBucketWebsite
  • s3:GetEncryptionConfiguration
  • s3:GetLifecycleConfiguration
  • s3:GetReplicationConfiguration
  • s3:ListBucket
  • s3:PutBucketAcl
  • s3:PutBucketPolicy
  • s3:PutBucketTagging
  • s3:PutEncryptionConfiguration

例2.7 クラスター Operator が必要とする S3 パーミッション

  • s3:DeleteObject
  • s3:GetObject
  • s3:GetObjectAcl
  • s3:GetObjectTagging
  • s3:GetObjectVersion
  • s3:PutObject
  • s3:PutObjectAcl
  • s3:PutObjectTagging

例2.8 ベースクラスターリソースの削除に必要なパーミッション

  • autoscaling:DescribeAutoScalingGroups
  • ec2:DeleteNetworkInterface
  • ec2:DeletePlacementGroup
  • ec2:DeleteVolume
  • elasticloadbalancing:DeleteTargetGroup
  • elasticloadbalancing:DescribeTargetGroups
  • iam:DeleteAccessKey
  • iam:DeleteUser
  • iam:DeleteUserPolicy
  • iam:ListAttachedRolePolicies
  • iam:ListInstanceProfiles
  • iam:ListRolePolicies
  • iam:ListUserPolicies
  • s3:DeleteObject
  • s3:ListBucketVersions
  • tag:GetResources

例2.9 ネットワークリソースの削除に必要なパーミッション

  • ec2:DeleteDhcpOptions
  • ec2:DeleteInternetGateway
  • ec2:DeleteNatGateway
  • ec2:DeleteRoute
  • ec2:DeleteRouteTable
  • ec2:DeleteSubnet
  • ec2:DeleteVpc
  • ec2:DeleteVpcEndpoints
  • ec2:DetachInternetGateway
  • ec2:DisassociateRouteTable
  • ec2:ReleaseAddress
  • ec2:ReplaceRouteTableAssociation
注記

既存の VPC を使用する場合、アカウントではネットワークリソースの削除にこれらのパーミッションを必要としません。代わりに、アカウントではネットワークリソースの削除に tag:UntagResources パーミッションのみが必要になります。

例2.10 カスタムキー管理サービス (KMS) キーを使用してクラスターをインストールするためのオプションの権限

  • kms:CreateGrant
  • kms:Decrypt
  • kms:DescribeKey
  • kms:Encrypt
  • kms:GenerateDataKey
  • kms:GenerateDataKeyWithoutPlainText
  • kms:ListGrants
  • kms:RevokeGrant

例2.11 共有インスタンスロールが割り当てられたクラスターを削除するために必要なパーミッション

  • iam:UntagRole

例2.12 マニフェストの作成に必要な追加の IAM および S3 パーミッション

  • iam:GetUserPolicy
  • iam:ListAccessKeys
  • iam:PutUserPolicy
  • iam:TagUser
  • s3:AbortMultipartUpload
  • s3:GetBucketPublicAccessBlock
  • s3:ListBucket
  • s3:ListBucketMultipartUploads
  • s3:PutBucketPublicAccessBlock
  • s3:PutLifecycleConfiguration
注記

クラウドプロバイダーのクレデンシャルをミントモードで管理している場合に、IAM ユーザーには iam:CreateAccessKeyiam:CreateUser 権限も必要です。

例2.13 インスタンスのオプションのパーミッションおよびインストールのクォータチェック

  • ec2:DescribeInstanceTypeOfferings
  • servicequotas:ListAWSDefaultServiceQuotas

例2.14 共有 VPC にクラスターをインストールする場合のクラスター所有者アカウントのオプションの権限

  • sts:AssumeRole

例2.15 インストール時に Bring your own public IPv4 アドレス (BYOIP) 機能を有効にするために必要な権限

  • ec2:DescribePublicIpv4Pools
  • ec2:DisassociateAddress

2.4. IAM ユーザーの作成

各 Amazon Web Services (AWS) アカウントには、アカウントの作成に使用するメールアドレスに基づく root ユーザーアカウントが含まれます。これは高度な権限が付与されたアカウントであり、初期アカウントにのみ使用し、請求設定また初期のユーザーセットの作成およびアカウントのセキュリティー保護のために使用することが推奨されています。

OpenShift Container Platform をインストールする前に、セカンダリー IAM 管理ユーザーを作成します。AWS ドキュメントの Creating an IAM User in Your AWS Account 手順を実行する際に、以下のオプションを設定します。

手順

  1. IAM ユーザー名を指定し、Programmatic access を選択します。
  2. AdministratorAccess ポリシーを割り当て、アカウントにクラスターを作成するために十分なパーミッションがあることを確認します。このポリシーはクラスターに対し、各 OpenShift Container Platform コンポーネントに認証情報を付与する機能を提供します。クラスターはコンポーネントに対し、それらが必要とする認証情報のみを付与します。

    注記

    必要なすべての AWS パーミッションを付与し、これをユーザーに割り当てるポリシーを作成することは可能ですが、これは優先されるオプションではありません。クラスターには追加の認証情報を個別コンポーネントに付与する機能がないため、同じ認証情報がすべてのコンポーネントによって使用されます。

  3. オプション: タグを割り当て、メタデータをユーザーに追加します。
  4. 指定したユーザー名に AdministratorAccess ポリシーが付与されていることを確認します。
  5. アクセスキー ID およびシークレットアクセスキーの値を記録します。ローカルマシンをインストールプログラムを実行するように設定する際にこれらの値を使用する必要があります。

    重要

    クラスターのデプロイ時に、マルチファクター認証デバイスの使用中に生成した一時的なセッショントークンを使用して AWS に対する認証を行うことはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。

2.5. IAM ポリシーと AWS 認証

デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびコンピュートインスタンスのインスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。

注記

シングルノードの OpenShift クラスターでインストール後のタスクとして Amazon Elastic Container Registry (ECR) からイメージをプルできるようにするには、クラスターのコントロールプレーンロールに関連付けられた IAM ロールに AmazonEC2ContainerRegistryReadOnly ポリシーを追加する必要があります。

ただし、独自の IAM ロールを作成して、インストールプロセスの一部として指定できます。クラスターをデプロイするため、またはインストール後にクラスターを管理するために、独自のロールを指定する必要がある場合があります。以下に例を示します。

  • 組織のセキュリティーポリシーでは、より制限的なアクセス許可セットを使用してクラスターをインストールする必要があります。
  • インストール後、クラスターは、追加サービスへのアクセスを必要とする Operator で設定されます。

独自の IAM ロールを指定する場合は、次の手順を実行できます。

  • デフォルトのポリシーから始めて、必要に応じて調整します。詳細は、「IAM インスタンスプロファイルのデフォルトのアクセス許可」を参照してください。
  • クラスターのアクティビティーに基づいたポリシーテンプレートを作成するには、「AWS IAM Analyzer を使用してポリシーテンプレートの作成」を参照してください。

2.5.1. IAM インスタンスプロファイルのデフォルトのアクセス許可

デフォルトでは、インストールプログラムは、ブートストラップ、コントロールプレーン、およびワーカーインスタンスの IAM インスタンスプロファイルを作成し、クラスターの動作に必要な権限を付与します。

次のリストでは、コントロールプレーンとコンピュートマシンのデフォルトのアクセス許可を指定します。

例2.16 コントロールプレーンインスタンスのプロファイル向けデフォルト IAM ロールのパーミッション

  • ec2:AttachVolume
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:CreateVolume
  • ec2:DeleteSecurityGroup
  • ec2:DeleteVolume
  • ec2:Describe*
  • ec2:DetachVolume
  • ec2:ModifyInstanceAttribute
  • ec2:ModifyVolume
  • ec2:RevokeSecurityGroupIngress
  • elasticloadbalancing:AddTags
  • elasticloadbalancing:AttachLoadBalancerToSubnets
  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
  • elasticloadbalancing:CreateListener
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateLoadBalancerPolicy
  • elasticloadbalancing:CreateLoadBalancerListeners
  • elasticloadbalancing:CreateTargetGroup
  • elasticloadbalancing:ConfigureHealthCheck
  • elasticloadbalancing:DeleteListener
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeleteLoadBalancerListeners
  • elasticloadbalancing:DeleteTargetGroup
  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer
  • elasticloadbalancing:DeregisterTargets
  • elasticloadbalancing:Describe*
  • elasticloadbalancing:DetachLoadBalancerFromSubnets
  • elasticloadbalancing:ModifyListener
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:ModifyTargetGroup
  • elasticloadbalancing:ModifyTargetGroupAttributes
  • elasticloadbalancing:RegisterInstancesWithLoadBalancer
  • elasticloadbalancing:RegisterTargets
  • elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer
  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener
  • kms:DescribeKey

例2.17 コンピュートインスタンスプロファイル向けデフォルト IAM ロールのパーミッション

  • ec2:DescribeInstances
  • ec2:DescribeRegions

2.5.2. 既存の IAM ロールの指定

インストールプログラムがデフォルトのアクセス許可で IAM インスタンスプロファイルを作成できるようにする代わりに、install-config.yaml ファイルを使用して、コントロールプレーンとコンピュートインスタンスの既存の IAM ロールを指定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。

手順

  1. コンピュートマシンの既のロールを使用して compute.platform.aws.iamRole を更新します。

    コンピュートインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          iamRole: ExampleRole

  2. コントロールプレーンマシンの既存ロールを使用して controlPlane.platform.aws.iamRole を更新します。

    コントロールプレーンインスタンスの IAM ロールを含む install-config.yaml ファイルのサンプル

    controlPlane:
      hyperthreading: Enabled
      name: master
      platform:
        aws:
          iamRole: ExampleRole

  3. ファイルを保存し、OpenShift Container Platform クラスターのインストール時に参照します。
注記

クラスターのインストール後に IAM アカウントを変更または更新する場合は、RHOCP 4 AWS cloud-credentials access key is expired (Red Hat ナレッジベース) を参照してください。

2.5.3. AWS IAM Analyzer を使用してポリシーテンプレートの作成

コントロールプレーンとコンピュートインスタンスプロファイルに必要な最小限のアクセス許可セットは、クラスターが日常の運用のためにどのように設定されているかによって異なります。

クラスターインスタンスに必要なアクセス許可を決定する 1 つの方法は、IAM Access Analyzer (AWS Identity and Access Management Access Analyzer) を使用してポリシーテンプレートを作成することです。

  • ポリシーテンプレートには、クラスターが指定された期間に使用したアクセス許可が含まれています。
  • その後、テンプレートを使用して、きめ細かい権限を持つポリシーを作成できます。

手順

全体的なプロセスは次のようになります。

  1. CloudTrail が有効になっていることを確認します。CloudTrail は、ポリシーテンプレートの作成に必要な API 呼び出しを含め、AWS アカウントのすべてのアクションとイベントを記録します。詳細は、CloudTrail の操作 に関する AWS ドキュメントを参照してください。
  2. コントロールプレーンインスタンスのインスタンスプロファイルとコンピューティングインスタンスのインスタンスプロファイルを作成します。PowerUserAccess などの寛容なポリシーを各ロールに割り当ててください。詳細は、インスタンスプロファイルロールの作成 に関する AWS ドキュメントを参照してください。
  3. クラスターを開発環境にインストールし、必要に応じて設定します。クラスターが本番環境でホストするすべてのアプリケーションを必ずデプロイしてください。
  4. クラスターを徹底的にテストします。クラスターをテストすると、必要なすべての API 呼び出しがログに記録されることが保証されます。
  5. IAM Access Analyzer を使用して、各インスタンスプロファイルのポリシーテンプレートを作成します。詳細は、CloudTrail ログに基づいてポリシーを生成する ための AWS ドキュメントを参照してください。
  6. きめ細かいポリシーを作成し、各インスタンスプロファイルに追加します。
  7. 各インスタンスプロファイルから許容ポリシーを削除します。
  8. 新しいポリシーで既存のインスタンスプロファイルを使用して実稼働クラスターをデプロイします。
注記

ポリシーに IAM 条件 を追加して、ポリシーをより制限し、組織のセキュリティー要件に準拠させることができます。

2.6. サポートされている AWS Marketplace リージョン

北米でオファーを購入したお客様は、AWS Marketplace イメージを使用して、OpenShift Container Platform クラスターをインストールすることができます。

このオファーは北米で購入する必要がありますが、以下のサポートされているパーティションのいずれかにクラスターをデプロイできます。

  • 公開
  • GovCloud
注記

AWS Marketplace イメージを使用した OpenShift Container Platform クラスターのデプロイは、AWS シークレットリージョンまたは中国リージョンではサポートされていません。

2.7. サポートされている AWS リージョン

OpenShift Container Platform クラスターを以下のリージョンにデプロイできます。

注記

ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1 にアクセス許可 tag:GetResources を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。

2.7.1. AWS パブリックリージョン

以下の AWS パブリックリージョンがサポートされます。

  • af-south-1 (Cape Town)
  • ap-east-1 (Hong Kong)
  • ap-northeast-1 (Tokyo)
  • ap-northeast-2 (Seoul)
  • ap-northeast-3 (Osaka)
  • ap-south-1 (Mumbai)
  • ap-south-2 (Hyderabad)
  • ap-southeast-1 (Singapore)
  • ap-southeast-2 (Sydney)
  • ap-southeast-3 (Jakarta)
  • ap-southeast-4 (Melbourne)
  • ca-central-1 (Central)
  • ca-west-1 (Calgary)
  • eu-central-1 (Frankfurt)
  • eu-central-2 (Zurich)
  • eu-north-1 (Stockholm)
  • eu-south-1 (Milan)
  • eu-south-2 (Spain)
  • eu-west-1 (Ireland)
  • eu-west-2 (London)
  • eu-west-3 (Paris)
  • il-central-1 (Tel Aviv)
  • me-central-1 (UAE)
  • me-south-1 (Bahrain)
  • sa-east-1 (São Paulo)
  • us-east-1 (N. Virginia)
  • us-east-2 (Ohio)
  • us-west-1 (N. California)
  • us-west-2 (Oregon)

2.7.2. AWS GovCloud リージョン

以下の AWS GovCloud リージョンがサポートされます。

  • us-gov-west-1
  • us-gov-east-1

2.7.3. AWS SC2S および C2S シークレットリージョン

以下の AWS シークレットリージョンがサポートされています。

  • us-isob-east-1 Secret Commercial Cloud Services (SC2S)
  • us-iso-east-1 Commercial Cloud Services (C2S)

2.7.4. AWS China リージョン

以下の AWS China リージョンがサポートされます。

  • cn-north-1 (Beijing)
  • cn-northwest-1 (Ningxia)

2.8. 次のステップ

第3章 installer-provisioned infrastructure

3.1. AWS にクラスターをインストールする準備

以下の手順を実行して、AWS に OpenShift Container Platform クラスターをインストールする準備をします。

  • クラスターのインターネット接続を検証します。
  • AWS アカウントを設定します
  • インストールプログラムをダウンロードします。

    注記

    非接続環境にインストールする場合は、ミラーリングしたコンテンツからインストールプログラムを抽出します。詳細は、非接続インストール用のイメージのミラーリング を参照してください。

  • OpenShift CLI (oc) をインストールします。

    注記

    非接続環境にインストールする場合は、ミラーホストに oc をインストールします。

  • SSH キーペアを生成します。OpenShift Container Platform クラスターのデプロイ後にこのキーペアを使用して、クラスターのノードに対する認証を行うことができます。
  • クラウドアイデンティティーおよびアクセス管理 (IAM) API が環境内でアクセスできない場合、または管理者レベルの認証情報シークレットを kube-system namespace に保存しない場合は、AWS の長期認証情報を手動で作成 するか、Amazon Web Services Security Token Service (AWS STS) で 短期認証情報を使用するように AWS クラスターを設定 します。

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

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

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

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

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

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

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

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

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

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

3.1.3. OpenShift CLI のインストール

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

重要

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

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

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

手順

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

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

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

    $ echo $PATH

検証

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

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

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

手順

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

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

    C:\> path

検証

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

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

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

手順

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

    注記

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

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

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

    $ echo $PATH

検証

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

    $ oc <command>

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

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

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

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

重要

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

注記

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

手順

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

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

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

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

    $ cat <path>/<file_name>.pub

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

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

    注記

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

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

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

      出力例

      Agent pid 31874

      注記

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

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

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

    出力例

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

次のステップ

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

3.1.5. OpenShift Container Platform の Telemetry アクセス

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

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

関連情報

3.2. AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、デフォルトの設定オプションを使用するクラスターを Amazon Web Services (AWS) にインストールできます。

3.2.1. 前提条件

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

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

重要

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

前提条件

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

手順

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

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

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

    • ディレクトリーに 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 およびシークレットアクセスキーを入力します。

      注記

      AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

    4. クラスターのデプロイ先とする AWS リージョンを選択します。
    5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
    6. クラスターの記述名を入力します。
    7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  3. オプション: クラスターのインストールに使用した IAM アカウントから AdministratorAccess ポリシーを削除するか、無効にします。

    注記

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

検証

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

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

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

出力例

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

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

関連情報

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

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.2.5. 次のステップ

3.3. カスタマイズによる AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、インストールプログラムが Amazon Web Services (AWS) 上にプロビジョニングするインフラストラクチャーにカスタマイズしたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

注記

OpenShift Container Platform インストール設定のスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後にさらに多くの OpenShift Container Platform 設定タスクを実行することができます。

3.3.1. 前提条件

3.3.2. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.com
    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          amiID: ami-06c4d345f7c207239 1
          type: m5.4xlarge
      replicas: 3
    metadata:
      name: test-cluster
    platform:
      aws:
        region: us-east-2 2
    sshKey: ssh-ed25519 AAAA...
    pullSecret: '{"auths": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

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

前提条件

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

手順

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

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

      $ ./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 ノードクラスターをインストールする場合は、必ず compute.replicas パラメーターを 0 に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「AWS に 3 ノードクラスターをインストールする」を参照してください。

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

    重要

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

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

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

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

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

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

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

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

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

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

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

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

注記

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

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

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
3.3.3.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

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

注記

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

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

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*
3.3.3.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

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

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-0c5d3e03c0ab9b19a 16
    serviceEndpoints: 17
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 18
sshKey: ssh-ed25519 AAAA... 19
pullSecret: '{"auths": ...}' 20
1 12 14 20
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
17
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
18
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

3.3.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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

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

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.3.4.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.3 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.4 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.3.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.3.4.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.3.6. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.3.8. 次のステップ

3.4. ネットワークのカスタマイズによる AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、カスタマイズしたネットワーク設定オプションを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

3.4.1. 前提条件

3.4.2. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    詳細は、「インストール設定パラメーター」を参照してください。

    注記

    優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように networking.machineNetwork を設定します。

    重要

    CIDR 範囲 172.17.0.0/16libVirt によって予約されています。クラスター内のネットワークに 172.17.0.0/16 CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 では、install-config.yaml ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。

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

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

前提条件

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

手順

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

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

      $ ./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.4.3.1. クラスターインストールの最小リソース要件

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

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

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

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

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

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

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

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

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

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

注記

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

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

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
3.4.3.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

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

注記

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

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

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*
3.4.3.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

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

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 12
networking: 13
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 14
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 15
    propagateUserTags: true 16
    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-0c5d3e03c0ab9b19a 17
    serviceEndpoints: 18
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 19
sshKey: ssh-ed25519 AAAA... 20
pullSecret: '{"auths": ...}' 21
1 12 15 21
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 13 16
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

14
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
17
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
18
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
19
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

3.4.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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

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

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.4.4.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.7 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.8 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.4.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.4.4.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

3.4.5. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
クラスターネットワークプラグイン。OVNKubernetes は、インストール時にサポートされる唯一のプラグインです。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

3.4.5.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表3.3 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表3.4 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表3.5 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

ipv4

object

IPv4 設定の設定オブジェクトを指定します。

ipv6

object

IPv6 設定の設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表3.6 ovnKubernetesConfig.ipv4 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが 100.88.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は 100.88.0.0/16 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

デフォルト値は 100.64.0.0/16 です。

表3.7 ovnKubernetesConfig.ipv6 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが fd97::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は fd97::/64 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが fd98::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

デフォルト値は fd98::/64 です。

表3.8 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表3.9 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

ipv4

object

オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

ipv6

object

オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

表3.10 gatewayConfig.ipv4 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 169.254.169.0/29 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして 169.254.0.0/17 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表3.11 gatewayConfig.ipv6 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は fd69::/125 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして fd69::/112 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表3.12 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPSec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

3.4.6. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。

高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。
注記

AWS で Network Load Balancer (NLB) を使用する方法の詳細は、Network Load Balancer を使用した AWS での Ingress クラスタートラフィックの設定 を参照してください。

3.4.7. 新規 AWS クラスターでの Ingress コントローラーネットワークロードバランサーの設定

新規クラスターに AWS Network Load Balancer (NLB) がサポートする Ingress Controller を作成できます。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了します。

手順

新規クラスターの AWS NLB がサポートする Ingress Controller を作成します。

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-ingress-default-ingresscontroller.yaml という名前のファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 1
    1
    <installation_directory> については、クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。

    ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが manifests/ ディレクトリーに置かれます。

    $ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml

    出力例

    cluster-ingress-default-ingresscontroller.yaml

  3. エディターで cluster-ingress-default-ingresscontroller.yaml ファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
  4. cluster-ingress-default-ingresscontroller.yaml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-ingress-default-ingresscontroller.yaml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。

3.4.8. OVN-Kubernetes を使用したハイブリッドネットワークの設定

OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。

注記

この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。

前提条件

  • install-config.yaml ファイルで networking.networkType パラメーターの OVNKubernetes を定義していること。詳細は、選択したクラウドプロバイダーでの OpenShift Container Platform ネットワークのカスタマイズの設定に関するインストールドキュメントを参照してください。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

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

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    $ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    EOF

    ここでは、以下のようになります。

    <installation_directory>
    クラスターの manifests/ ディレクトリーが含まれるディレクトリー名を指定します。
  3. cluster-network-03-config.yml ファイルをエディターで開き、次の例のようにハイブリッドネットワークを使用して OVN-Kubernetes を設定します。

    ハイブリッドネットワーク設定の指定

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          hybridOverlayConfig:
            hybridClusterNetwork: 1
            - cidr: 10.132.0.0/14
              hostPrefix: 23
            hybridOverlayVXLANPort: 9898 2

    1
    追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。hybridClusterNetwork CIDR は clusterNetwork CIDR と重複できません。
    2
    追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの 4789 ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
    注記

    Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの hybridOverlayVXLANPort 値を持つクラスターではサポートされません。

  4. cluster-network-03-config.yml ファイルを保存し、テキストエディターを終了します。
  5. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、クラスターの作成時に manifests/ ディレクトリーを削除します。
注記

同じクラスターで Linux ノードと Windows ノードを使用する方法の詳細は、Windows コンテナーワークロードについて を参照してください。

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.4.10. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.4.12. 次のステップ

3.5. ネットワークが制限された環境での AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、既存の Amazon Virtual Private Cloud (VPC) にインストールリリースコンテンツの内部ミラーを作成することにより、制限付きネットワーク内の Amazon Web Services (AWS) にクラスターをインストールできます。

3.5.1. 前提条件

  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
  • 非接続インストールのイメージのミラーリング をレジストリーに対して行っており、使用しているバージョンの OpenShift Container Platform の imageContentSources データを取得している。

    重要

    インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。

  • AWS に既存の VPC が必要です。installer-provisioned infrastructure を使用してネットワークが制限された環境にインストールする場合は、installer-provisioned VPC を使用することはできません。以下の要件のいずれかを満たす user-provisioned VPC を使用する必要があります。

    • ミラーレジストリーが含まれる。
    • 別の場所でホストされるミラーレジストリーにアクセスするためのファイアウォールルールまたはピアリング接続がある。
  • クラスターをホストするために AWS アカウントを設定 している。

    重要

    AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。AWS ドキュメントの Install the AWS CLI Using the Bundled Installer (Linux, macOS, or UNIX) を参照してください。
  • クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。

    注記

    プロキシーを設定する場合は、このサイトリストも確認してください。

3.5.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.17 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、installer-provisioned infrastructure または user-provisioned infrastructure を使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

3.5.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

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

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

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

3.5.3.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 は以下の特性を満たす必要があります。

  • 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.5.3.2. VPC 検証

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

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

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

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

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

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

3.5.3.4. クラスター間の分離

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

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

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

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

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • ミラーレジストリーの作成時に生成された imageContentSources 値がある。
  • ミラーレジストリーの証明書の内容を取得している。

手順

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

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

      $ ./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 ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。

      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      <mirror_host_name> の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials> の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

      この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

    3. クラスターをインストールする VPC のサブネットを定義します。

      subnets:
      - subnet-1
      - subnet-2
      - subnet-3
    4. 次の YAML の抜粋のようなイメージコンテンツリソースを追加します。

      imageContentSources:
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: registry.redhat.io/ocp/release

      これらの値には、ミラーレジストリーの作成時に記録された imageContentSources を使用します。

    5. オプション: パブリッシュストラテジーを Internal に設定します。

      publish: Internal

      このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。

  3. 必要な install-config.yaml ファイルに他の変更を加えます。

    パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

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

    重要

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

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

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

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

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

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

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

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

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

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

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

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

重要

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

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 17
    serviceEndpoints: 18
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 19
fips: false 20
sshKey: ssh-ed25519 AAAA... 21
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 22
additionalTrustBundle: | 23
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
imageContentSources: 24
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
1 12 14
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
17
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
18
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
19
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
20
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

22
<local_registry> には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。
23
ミラーレジストリーに使用した証明書ファイルの内容を指定します。
24
リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを指定します。
3.5.4.3. インストール時のクラスター全体のプロキシーの設定

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

前提条件

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

    注記

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

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

手順

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

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: 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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

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

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.5.5.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.9 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.10 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.5.5.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.5.5.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.5.7. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

3.5.8. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

3.5.9. 次のステップ

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

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

3.6.1. 前提条件

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

OpenShift Container Platform 4.17 では、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.11 共有 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. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

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

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

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

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

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

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

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

注記

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

例3.12 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.13 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 ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 17
    serviceEndpoints: 18
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 19
fips: false 20
sshKey: ssh-ed25519 AAAA... 21
pullSecret: '{"auths": ...}' 22
1 12 14 22
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
17
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
18
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
19
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
20
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./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 ファイル

# ...
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 に設定しなかった場合は、次のように値を変更します。

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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 アカウントを作成し、次の権限で使用できるようにしました。

    例3.14 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.15 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      aws          Manage credentials objects for AWS cloud
      azure        Manage credentials objects for Azure
      gcp          Manage credentials objects for Google cloud
      help         Help about any command
      ibmcloud     Manage credentials objects for {ibm-cloud-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 変数に設定します。

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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 に設定しなかった場合は、次のように値を変更します。

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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 認証情報をエクスポートします。

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.6.8. 次のステップ

3.7. プライベートクラスターの AWS へのインストール

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

3.7.1. 前提条件

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

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

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

重要

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

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

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

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

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

3.7.2.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

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

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

3.7.2.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

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

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

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

3.7.3.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 は以下の特性を満たす必要があります。

  • 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.7.3.2. VPC 検証

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

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

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

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

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

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

3.7.3.4. クラスター間の分離

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

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

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

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

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

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

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

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

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

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

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

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

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

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

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

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

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

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

注記

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

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

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
3.7.4.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

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

注記

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

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

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*
3.7.4.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

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

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 17
    serviceEndpoints: 18
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 19
fips: false 20
sshKey: ssh-ed25519 AAAA... 21
publish: Internal 22
pullSecret: '{"auths": ...}' 23
1 12 14 23
必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
17
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
18
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
19
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
20
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

22
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
3.7.4.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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

3.7.4.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 ファイル

# ...
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.7.5. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.7.5.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.18 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.19 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.7.5.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.7.5.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.7.7. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.7.9. 次のステップ

3.8. AWS の government リージョンへのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、Amazon Web Services (AWS) 上のクラスターを government リージョンにインストールできます。リージョンを設定するには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

3.8.1. 前提条件

3.8.2. AWS government リージョン

OpenShift Container Platform は、AWS GovCloud (US) リージョンへのクラスターのデプロイをサポートします。

以下の AWS GovCloud パーティションがサポートされます。

  • us-gov-east-1
  • us-gov-west-1

3.8.3. インストール要件

クラスターをインストールする前に、以下を行う必要があります。

  • クラスターをホストするために、既存のプライベート AWS VPC とサブネットを提供します。

    パブリックゾーンは、AWS GovCloud の Route 53 ではサポートされません。その結果、AWS government リージョンにデプロイする場合、クラスターはプライベートである必要があります。

  • インストール設定ファイル (install-config.yaml) を手動で作成します。

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

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

注記

パブリックゾーンは、AWS GovCloud リージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS GovCloud リージョンにデプロイする場合は、クラスターをプライベートにする必要があります。

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

重要

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

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

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

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

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

3.8.4.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

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

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

3.8.4.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

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

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

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

3.8.5.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 は以下の特性を満たす必要があります。

  • 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.8.5.2. VPC 検証

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

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

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

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

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

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

3.8.5.4. クラスター間の分離

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

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

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

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

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

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

3.8.6. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.com
    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          amiID: ami-06c4d345f7c207239 1
          type: m5.4xlarge
      replicas: 3
    metadata:
      name: test-cluster
    platform:
      aws:
        region: us-east-2 2
    sshKey: ssh-ed25519 AAAA...
    pullSecret: '{"auths": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

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

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

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

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

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

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

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

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

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

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

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

注記

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

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

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
3.8.7.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

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

注記

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

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

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*
3.8.7.4. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-gov-west-1a
      - us-gov-west-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-gov-west-1c
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-gov-west-1 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-0c5d3e03c0ab9b19a 17
    serviceEndpoints: 18
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 19
fips: false 20
sshKey: ssh-ed25519 AAAA... 21
publish: Internal 22
pullSecret: '{"auths": ...}' 23
1 12 14 23
必須。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
17
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
18
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
19
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
20
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

22
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
3.8.7.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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

3.8.7.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 ファイル

# ...
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.8.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.8.8.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.22 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.23 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.8.8.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.8.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.8.10. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

関連情報

3.8.12. 次のステップ

3.9. AWS 上のクラスターをシークレットまたはトップシークレットリージョンにインストールする

OpenShift Container Platform バージョン 4.17 では、Amazon Web Services (AWS) 上のクラスターを以下のシークレットリージョンにインストールできます。

  • シークレット Commercial Cloud Services (SC2S)
  • Commercial Cloud Services (C2S)

いずれかのリージョンでクラスターを設定するには、クラスターをインストールする前に、install config.yaml ファイルのパラメーターを変更します。

警告

OpenShift Container Platform 4.17 では、インストールプログラムは Terraform の代わりに Cluster API を使用して、AWS へのインストール中にクラスターインフラストラクチャーをプロビジョニングします。Cluster API 実装を使用した AWS のクラスターをシークレットまたはトップシークレットリージョンにインストールすることは、OpenShift Container Platform 4.17 のリリース時点ではテストされていません。このドキュメントは、シークレットリージョンへのインストールがテストされたときに更新されます。

Network Load Balancer のシークレットまたはトップシークレットリージョンのセキュリティーグループのサポートには既知の問題があり、これらのリージョンのインストールが失敗します。詳細は、OCPBUGS-33311 を参照してください。

3.9.1. 前提条件

3.9.2. AWS シークレットリージョン

次の AWS シークレットパーティションがサポートされています。

  • us-isob-east-1 (SC2S)
  • us-iso-east-1 (C2S)
注記

AWS SC2S および C2S リージョンでサポートされる最大 MTU は、AWS コマーシャルと同じではありません。インストール中の MTU の設定に関する詳細は、ネットワークをカスタマイズした AWS へのクラスターのインストールクラスターネットワークオペレーターの設定オブジェクト セクションを参照してください。

3.9.3. インストール要件

Red Hat は、AWS Secret およびトップシークレットリージョン用の Red Hat Enterprise Linux CoreOS (RHCOS) Amzaon Machine Image を公開していません。

クラスターをインストールする前に、以下を行う必要があります。

  • カスタム RHCOS AMI をアップロードします。
  • インストール設定ファイル (install-config.yaml) を手動で作成します。
  • インストール設定ファイルで、AWS リージョンおよび付随するカスタム AMI を指定します。

OpenShift Container Platform インストールプログラムを使用してインストール設定ファイルを作成することはできません。インストーラーは RHCOS AMI のネイティブサポートのない AWS リージョンをリスト表示しません。

重要

AWS API にはカスタム CA 信頼バンドルが必要なため、install-config.yaml ファイルの additionalTrustBundle フィールドで、カスタム CA 証明書も定義する必要があります。インストールプログラムが AWS API にアクセスできるようにするには、インストールプログラムを実行するマシンに CA 証明書を定義する必要もあります。マシン上のトラストストアに CA バンドルを追加するか、AWS_CA_BUNDLE 環境変数を使用するか、AWS 設定ファイルの ca_bundle フィールドで CA バンドルを定義する必要があります。

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

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

注記

パブリックゾーンは、AWS トップシークレットリージョンの Route 53 ではサポートされていません。したがって、クラスターを AWS トップシークレットリージョンにデプロイする場合は、クラスターをプライベートにする必要があります。

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

重要

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

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

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

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

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

3.9.4.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

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

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

3.9.4.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

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

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

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

3.9.5.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 は以下の特性を満たす必要があります。

  • 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 認証情報モードを使用する必要があります。

SC2S または C2S リージョンのクラスターは、EC2、ELB、および S3 エンドポイントのパブリック IP アドレスに到達できません。インストール中にインターネットトラフィックを制限するレベルに応じて、次の設定オプションを使用できます。

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

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

SC2S
  • elasticloadbalancing.<aws_region>.sc2s.sgov.gov
  • ec2.<aws_region>.sc2s.sgov.gov
  • s3.<aws_region>.sc2s.sgov.gov
C2S
  • elasticloadbalancing.<aws_region>.c2s.ic.gov
  • ec2.<aws_region>.c2s.ic.gov
  • s3.<aws_region>.c2s.ic.gov

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

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

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

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

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

SC2S
  • elasticloadbalancing.<aws_region>.sc2s.sgov.gov
  • ec2.<aws_region>.sc2s.sgov.gov
  • s3.<aws_region>.sc2s.sgov.gov
C2S
  • elasticloadbalancing.<aws_region>.c2s.ic.gov
  • ec2.<aws_region>.c2s.ic.gov
  • s3.<aws_region>.c2s.ic.gov

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.9.5.2. VPC 検証

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

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

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

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

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

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

3.9.5.4. クラスター間の分離

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

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

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

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

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

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

3.9.6. AWS でのカスタム RHCOS AMI のアップロード

カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。

前提条件

  • AWS アカウントを設定している。
  • 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
  • RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。

手順

  1. AWS プロファイルを環境変数としてエクスポートします。

    $ export AWS_PROFILE=<aws_profile> 1
  2. カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。

    $ export AWS_DEFAULT_REGION=<aws_region> 1
  3. 環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。

    $ export RHCOS_VERSION=<version> 1
    1 1 1
    4.17.0 などの RHCOS VMDK バージョン。
  4. Amazon S3 バケット名を環境変数としてエクスポートします。

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. containers.json ファイルを作成し、RHCOS VMDK ファイルを定義します。

    $ cat <<EOF > containers.json
    {
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
       }
    }
    EOF
  6. RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ 1
         --disk-container "file://<file_path>/containers.json" 2
    1
    rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64 などの RHCOS ディスクがインポートされていることの説明。
    2
    RHCOS ディスクを説明する JSON ファイルへのファイルパス。JSON ファイルには、Amazon S3 バケット名とキーが含まれている必要があります。
  7. イメージインポートのステータスを確認します。

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}

    出力例

    {
        "ImportSnapshotTasks": [
            {
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"
                    }
                }
            }
        ]
    }

    SnapshotId をコピーして、イメージを登録します。

  8. RHCOS スナップショットからカスタム RHCOS AMI を作成します。

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ 1
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 2
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 3
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' 4
    1
    x86_64aarch64s390x、または ppc64le などの RHCOS VMDK アーキテクチャータイプ。
    2
    インポートされたスナップショットの Description
    3
    RHCOS AMI の名前。
    4
    インポートされたスナップショットからの SnapshotID

これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。

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

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

前提条件

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

手順

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

    $ mkdir <installation_directory>
    重要

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

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

    注記

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

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

    重要

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

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

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

注記

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

例3.24 シークレット領域の 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • i3.*
  • m4.*
  • m5.*
  • r4.*
  • r5.*
  • t3.*
3.9.7.2. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - us-iso-east-1a
      - us-iso-east-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - us-iso-east-1a
      - us-iso-east-1b
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-iso-east-1 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 17 18
    serviceEndpoints: 19
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
    hostedZone: Z3URY6TWQ91KVV 20
fips: false 21
sshKey: ssh-ed25519 AAAA... 22
publish: Internal 23
pullSecret: '{"auths": ...}' 24
additionalTrustBundle: | 25
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
1 12 14 17 24
必須。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

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

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
18
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
19
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
20
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
21
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

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

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

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

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

23
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
25
カスタム CA 証明書。これは、SC2S または C2S リージョンにデプロイするときに必要です。これは、AWS API がカスタム CA 信頼バンドルを必要とするためです。
3.9.7.3. インストール時のクラスター全体のプロキシーの設定

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

前提条件

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

    注記

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

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

手順

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

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: 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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

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

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

注記

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

3.9.7.4. 既存の 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 ファイル

# ...
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.9.8. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

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

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

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.9.8.2. 短期認証情報を使用するように AWS クラスターを設定

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

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

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

注記

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

前提条件

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

    例3.25 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.26 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

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

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

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

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

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

    $ chmod 775 ccoctl.<rhel_version>

検証

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

    $ ./ccoctl.rhel9

    出力例

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

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

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

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

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

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

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

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

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.9.8.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

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

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

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.9.8.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

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

前提条件

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

手順

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

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

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

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

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

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

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

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

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

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

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

重要

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

前提条件

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

手順

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

    $ ./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 にも出力されます。
重要

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

出力例

...
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.9.10. CLI の使用によるクラスターへのログイン

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

前提条件

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

手順

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

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

    $ oc whoami

    出力例

    system:admin

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

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

前提条件

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

手順

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

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

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

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

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

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

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

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

3.9.12. 次のステップ

3.10. AWS China でのクラスターのアンインストール

OpenShift Container Platform バージョン 4.17 では、クラスターを以下の Amazon Web Services (AWS) China リージョンにインストールできます。

  • cn-north-1 (Beijing)
  • cn-northwest-1 (Ningxia)

3.10.1. 前提条件

重要

AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

3.10.2. インストール要件

Red Hat は、AWS China リージョンの Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を公開しません。

クラスターをインストールする前に、以下を行う必要があります。

  • カスタム RHCOS AMI をアップロードします。
  • インストール設定ファイル (install-config.yaml) を手動で作成します。
  • インストール設定ファイルで、AWS リージョンおよび付随するカスタム AMI を指定します。

OpenShift Container Platform インストールプログラムを使用してインストール設定ファイルを作成することはできません。インストーラーは RHCOS AMI のネイティブサポートのない AWS リージョンをリスト表示しません。

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

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

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

重要

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

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

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

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

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

注記

AWS China は、VPC とネットワーク間の VPN 接続をサポートしません。Beijing および Ningxia リージョンの Amazon VPC サービスの詳細は、AWS China ドキュメントの Amazon Virtual Private Cloud を参照してください。

3.10.3.1. AWS のプライベートクラスター

Amazon Web Services (AWS) でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、プライベートネットワークからのみアクセスできるように Ingress Operator および API サーバーを設定します。

クラスターには、引き続き AWS API にアクセスするためにインターネットへのアクセスが必要になります。

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

  • パブリックサブネット
  • パブリック Ingress をサポートするパブリックロードバランサー
  • クラスターの baseDomain に一致するパブリック Route 53 ゾーン

インストールプログラムは、プライベート Route 53 ゾーンを作成するために指定する baseDomain とクラスターに必要なレコードを使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。

3.10.3.1.1. 制限事項

プライベートクラスターにパブリック機能を追加する機能には制限があります。

  • Kubernetes API エンドポイントは、追加のアクションを実行せずにインストールする場合はパブリックにすることができません。これらのアクションには、使用中のアベイラビリティーゾーンごとに VPC でパブリックサブネットやパブリックのロードバランサーを作成することや、6443 のインターネットからのトラフィックを許可するようにコントロールプレーンのセキュリティーグループを設定することなどが含まれます。
  • パブリックのサービスタイプのロードバランサーを使用する場合には、各アベイラビリティーゾーンのパブリックサブネットに kubernetes.io/cluster/<cluster-infra-id>: shared のタグを付け、AWS がそれらを使用してパブリックロードバランサーを作成できるようにします。

3.10.4. カスタム VPC の使用について

OpenShift Container Platform 4.17 では、Amazon Web Services (AWS) の既存の Amazon Virtual Private Cloud (VPC) における既存サブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の AWS VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。

インストールプログラムは既存のサブネットにある他のコンポーネントを把握できないため、ユーザーの代わりにサブネットの CIDR を選択することはできません。クラスターをインストールするサブネットのネットワークを独自に設定する必要があります。

3.10.4.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 は以下の特性を満たす必要があります。

  • 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.cn
  • 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.cn
  • 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.10.4.2. VPC 検証

指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。

  • 指定したサブネットすべてが存在します。
  • プライベートサブネットを指定します。
  • サブネットの CIDR は指定されたマシン CIDR に属します。
  • 各アベイラビリティーゾーンのサブネットを指定します。それぞれのアベイラビリティーゾーンには、複数のパブリックおよびプライベートサブネットがありません。プライベートクラスターを使用する場合、各アベイラビリティーゾーンのプライベートサブネットのみを指定します。それ以外の場合は、各アベイラビリティーゾーンのパブリックサブネットおよびプライベートサブネットを指定します。
  • 各プライベートサブネットアベイラビリティーゾーンのパブリックサブネットを指定します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。

既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。VPC から OpenShift Container Platform クラスターを削除する場合、kubernetes.io/cluster/.*: shared タグは、それが使用したサブネットから削除されます。

3.10.4.3. パーミッションの区分

OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。

クラスターの作成時に使用する AWS の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ELB、セキュリティーグループ、S3 バケットおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。

3.10.4.4. クラスター間の分離

OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。

  • 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
  • ICMP Ingress はネットワーク全体から許可されます。
  • TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
  • コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
3.10.4.5. オプション: AWS セキュリティーグループ

デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。

ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml ファイルを変更してカスタムセキュリティーグループを適用します。

詳細は、「既存の AWS セキュリティーグループのクラスターへの適用」を参照してください。

3.10.5. AWS でのカスタム RHCOS AMI のアップロード

カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。

前提条件

  • AWS アカウントを設定している。
  • 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
  • RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。

手順

  1. AWS プロファイルを環境変数としてエクスポートします。

    $ export AWS_PROFILE=<aws_profile> 1
    1
    beijingadmin などの AWS 認証情報を保持する AWS プロファイル名。
  2. カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。

    $ export AWS_DEFAULT_REGION=<aws_region> 1
    1
    cn-north-1 などの AWS リージョン
  3. 環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。

    $ export RHCOS_VERSION=<version> 1
    1
    4.17.0 などの RHCOS VMDK バージョン。
  4. Amazon S3 バケット名を環境変数としてエクスポートします。

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. containers.json ファイルを作成し、RHCOS VMDK ファイルを定義します。

    $ cat <<EOF > containers.json
    {
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
       }
    }
    EOF
  6. RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ 1
         --disk-container "file://<file_path>/containers.json" 2
    1
    rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64 などの RHCOS ディスクがインポートされていることの説明。
    2
    RHCOS ディスクを説明する JSON ファイルへのファイルパス。JSON ファイルには、Amazon S3 バケット名とキーが含まれている必要があります。
  7. イメージインポートのステータスを確認します。

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}

    出力例

    {
        "ImportSnapshotTasks": [
            {
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"
                    }
                }
            }
        ]
    }

    SnapshotId をコピーして、イメージを登録します。

  8. RHCOS スナップショットからカスタム RHCOS AMI を作成します。

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ 1
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 2
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 3
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' 4
    1
    x86_64aarch64s390x、または ppc64le などの RHCOS VMDK アーキテクチャータイプ。
    2
    インポートされたスナップショットの Description
    3
    RHCOS AMI の名前。
    4
    インポートされたスナップショットからの SnapshotID

これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。

3.10.6. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • カスタムの RHCOS AMI をアップロードしている。
  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

3.10.6.1. AWS のカスタマイズされた install-config.yaml ファイルのサンプル

インストール設定ファイル install-config.yaml をカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。これを使用して、手動で作成したインストール設定ファイルにパラメーター値を入力します。

apiVersion: v1
baseDomain: example.com 1
credentialsMode: Mint 2
controlPlane: 3 4
  hyperthreading: Enabled 5
  name: master
  platform:
    aws:
      zones:
      - cn-north-1a
      - cn-north-1b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 6
      metadataService:
        authentication: Optional 7
      type: m6i.xlarge
  replicas: 3
compute: 8
- hyperthreading: Enabled 9
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 10
      metadataService:
        authentication: Optional 11
      type: c5.4xlarge
      zones:
      - cn-north-1a
  replicas: 3
metadata:
  name: test-cluster 12
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 13
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: cn-north-1 14
    propagateUserTags: true 15
    userTags:
      adminContact: jdoe
      costCenter: 7536
    subnets: 16
    - subnet-1
    - subnet-2
    - subnet-3
    amiID: ami-96c6f8f7 17 18
    serviceEndpoints: 19
      - name: ec2
        url: https://vpce-id.ec2.cn-north-1.vpce.amazonaws.com.cn
    hostedZone: Z3URY6TWQ91KVV 20
fips: false 21
sshKey: ssh-ed25519 AAAA... 22
publish: Internal 23
pullSecret: '{"auths": ...}' 24
1 12 14 17 24
必須。
2
オプション: Cloud Credential Operator (CCO) に指定されたモードの使用を強制するには、このパラメーターを追加します。デフォルトでは、CCO は kube-system namespace のルート認証情報を使用して、認証情報の機能を動的に判断しようとします。CCO モードの詳細は、認証および認可 ガイドの「Cloud Credential Operator について」セクションを参照してください。
3 8 15
これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
4
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
5 9
同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して m4.2xlarge または m5.2xlarge などの大規模なインスタンスタイプを使用します。

6 10
大規模なクラスターの場合などに etcd の高速のストレージを設定するには、ストレージタイプを io1 として設定し、iops2000 に設定します。
7 11
Amazon EC2 Instance Metadata Service v2 (IMDSv2) を要求するかどうか。IMDSv2 を要求するには、パラメーター値を Required に設定します。IMDSv1 と IMDSv2 の両方の使用を許可するには、パラメーター値を Optional に設定します。値が指定されていない場合、IMDSv1 と IMDSv2 の両方が許可されます。
注記

クラスターのインストール中に設定されるコントロールプレーンマシンの IMDS 設定は、AWS CLI を使用してのみ変更できます。コンピュートマシンの IMDS 設定は、コンピュートマシンセットを使用して変更できます。

13
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
16
独自の VPC を指定する場合は、クラスターが使用する各アベイラビリティーゾーンのサブネットを指定します。
18
クラスターのマシンを起動するために使用される AMI の ID。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。
19
AWS サービスエンドポイント。未確認の AWS リージョンにインストールする場合は、カスタムエンドポイントが必要です。エンドポイントの URL は https プロトコルを使用しなければならず、ホストは証明書を信頼する必要があります。
20
既存の Route 53 プライベートホストゾーンの ID。既存のホストゾーンを指定するには、独自の VPC を指定する必要があり、ホストゾーンはすでにクラスターをインストールする前に VPC に関連付けられます。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。
21
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

22
クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

23
クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。
3.10.6.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表3.17 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

3.10.6.3. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。

例3.27 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
3.10.6.4. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。

例3.28 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*
3.10.6.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 ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

3.10.6.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 ファイル

# ...
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.10.7. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法

デフォルトでは、管理者のシークレットは kube-system プロジェクトに保存されます。install-config.yaml ファイルの credentialsMode パラメーターを Manual に設定した場合は、次のいずれかの代替手段を使用する必要があります。

3.10.7.1. 長期認証情報を手動で作成する

Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、インストールファイルのリリースイメージを $RELEASE_IMAGE 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  4. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest カスタムリソース (CR) のリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。

    このコマンドにより、それぞれの CredentialsRequest オブジェクトに YAML ファイルが作成されます。

    サンプル CredentialsRequest オブジェクト

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
      ...

  5. 以前に生成した openshift-install マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトについて spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

    シークレットを含む CredentialsRequest オブジェクトのサンプル

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component_credentials_request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - effect: Allow
          action:
          - s3:CreateBucket
          - s3:DeleteBucket
          resource: "*"
          ...
      secretRef:
        name: <component_secret>
        namespace: <component_namespace>
      ...

    サンプル Secret オブジェクト

    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.10.7.2. 短期認証情報を使用するように AWS クラスターを設定

AWS Security Token Service (STS) を使用するように設定されたクラスターをインストールするには、CCO ユーティリティーを設定し、クラスターに必要な AWS リソースを作成する必要があります。

3.10.7.2.1. Cloud Credential Operator ユーティリティーの設定

Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。

注記

ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) がインストールされている。
  • ccoctl ユーティリティー用の AWS アカウントを作成し、次の権限で使用できるようにしました。

    例3.29 必要な 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 アカウントには次の追加パーミッションが必要です。

    例3.30 CloudFront を使用したプライベート S3 バケットに対する追加の権限

    • 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 リリースイメージの変数を設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注記

    $RELEASE_IMAGE のアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。

  3. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

    $ oc image extract $CCO_IMAGE \
      --file="/usr/bin/ccoctl.<rhel_version>" \1
      -a ~/.pull-secret
    1
    <rhel_version> には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトで ccoctl.rhel8 が使用されます。次の値が有効です。
    • rhel8: RHEL 8 を使用するホストの場合はこの値を指定します。
    • rhel9: RHEL 9 を使用するホストの場合はこの値を指定します。
  4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

    $ chmod 775 ccoctl.<rhel_version>

検証

  • ccoctl が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。

    $ ./ccoctl.rhel9

    出力例

    OpenShift credentials provisioning tool
    
    Usage:
      ccoctl [command]
    
    Available Commands:
      aws          Manage credentials objects for AWS cloud
      azure        Manage credentials objects for Azure
      gcp          Manage credentials objects for Google cloud
      help         Help about any command
      ibmcloud     Manage credentials objects for {ibm-cloud-title}
      nutanix      Manage credentials objects for Nutanix
    
    Flags:
      -h, --help   help for ccoctl
    
    Use "ccoctl [command] --help" for more information about a command.

3.10.7.2.2. Cloud Credential Operator ユーティリティーを使用した AWS リソースの作成

AWS リソースを作成するときは、次のオプションがあります。

  • ccoctl aws create-all コマンドを使用して AWS リソースを自動的に作成できます。これはリソースを作成する最も簡単な方法です。単一コマンドでの AWS リソースの作成 を参照してください。
  • AWS リソースの変更前に ccoctl ツールが作成する JSON ファイルを確認する必要がある場合や、ccoctl ツールが AWS リソースを自動作成するために使用するプロセスが組織の要件を満たさない場合は、AWS リソースを個別に作成できます。AWS リソースの個別の作成 を参照してください。
3.10.7.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 変数に設定します。

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
  2. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトのリストを抽出します。

    $ oc adm release extract \
      --from=$RELEASE_IMAGE \
      --credentials-requests \
      --included \1
      --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
      --to=<path_to_directory_for_credentials_requests> 3
    1
    --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
    2
    install-config.yaml ファイルの場所を指定します。
    3
    CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    注記

    このコマンドの実行には少し時間がかかる場合があります。

  3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

    $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.10.7.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 キーファイルを生成します。

    $ ccoctl aws create-key-pair

    出力例

    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 バケットを作成します。

    $ 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 コマンドが生成したパブリックキーファイルへのパスです。

    出力例

    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 変数に設定します。

      $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
    2. OpenShift Container Platform リリースイメージから CredentialsRequest オブジェクトの一覧を抽出します。

      $ oc adm release extract \
        --from=$RELEASE_IMAGE \
        --credentials-requests \
        --included \1
        --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2
        --to=<path_to_directory_for_credentials_requests> 3
      1
      --included パラメーターには、特定のクラスター設定に必要なマニフェストのみが含まれます。
      2
      install-config.yaml ファイルの場所を指定します。
      3
      CredentialsRequest オブジェクトを保存するディレクトリーへのパスを指定します。指定したディレクトリーが存在しない場合は、このコマンドによって作成されます。
    3. 次のコマンドを実行し、ccoctl ツールを使用して CredentialsRequest オブジェクトをすべて処理します。

      $ 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 ディレクトリーのファイルを一覧表示します。

    $ ls <path_to_ccoctl_output_dir>/manifests

    出力例

    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.10.7.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み

個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • Cloud Credential Operator ユーティリティー (ccoctl) が設定されている。
  • ccoctl ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。

手順

  1. install-config.yaml 設定ファイルの credentialsMode パラメーターを Manual に設定しなかった場合は、次のように値を変更します。

    設定ファイルのサンプルスニペット

    apiVersion: v1
    baseDomain: example.com
    credentialsMode: Manual
    # ...

  2. インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。

    $ openshift-install create manifests --dir <installation_directory>

    ここで、<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。

  3. 次のコマンドを実行して、ccoctl ユーティリティーが生成したマニフェストを、インストールプログラムが作成した manifests ディレクトリーにコピーします。

    $ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
  4. 秘密鍵を含む tls ディレクトリーをインストールディレクトリーにコピーします。

    $ cp -a /<path_to_ccoctl_output_dir>/tls .

3.10.8. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./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 にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
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.10.9. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.10.10. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

3.10.11. 次のステップ

3.11. AWS Local Zones 上のコンピュートノードを使用してクラスターをインストールする

install-config.yaml ファイルのエッジコンピュートプールにゾーン名を設定することで、OpenShift Container Platform クラスターを Amazon Web Services (AWS) Local Zones にすばやくインストールできます。または、Local Zone サブネットを持つ既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールすることもできます。

AWS Local Zones は、クラウドリソースを大都市圏の近くに配置するインフラストラクチャーです。詳細は、AWS Local Zones Documentation を参照してください。

3.11.1. インフラストラクチャーの前提条件

  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択とユーザー用にクラスターを準備する方法 を理解している。
  • クラスターをホストするために AWS アカウントを設定 している。

    警告

    AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。AWS ドキュメントの Install the AWS CLI Using the Bundled Installer (Linux, macOS, or UNIX) を参照してください。
  • ファイアウォールを使用している場合は、クラスターがアクセスする必要がある サイトを許可するようにファイアウォールを設定 している。
  • ネットワークリソースを作成するために、リージョンとサポートされている AWS ローカルゾーンの場所 を書き留めている。
  • AWS ドキュメントの AWS Local Zones features を確認している。
  • AWS Local Zones をサポートするネットワークリソースを作成する権限を、アイデンティティーおよびアクセス管理 (IAM) ユーザーまたはロールに追加している。次の例では、AWS Local Zones をサポートするネットワークリソースを作成するためのユーザーまたはロールアクセスを提供できるゾーングループを有効にします。

    IAM ユーザーまたはロールに割り当てられた ec2:ModifyAvailabilityZoneGroup 権限を持つ追加の IAM ポリシーの例

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Action": [
            "ec2:ModifyAvailabilityZoneGroup"
          ],
          "Effect": "Allow",
          "Resource": "*"
        }
      ]
    }

3.11.2. AWS Local Zones とエッジコンピュートプールについて

AWS Local Zones 環境でのインフラストラクチャーの動作とクラスターの制限を理解するには、以降のセクションをお読みください。

3.11.2.1. AWS Local Zone でのクラスターの制限

デフォルトのインストール設定で Amazon Web Services (AWS) の Local Zone にクラスターをデプロイする場合、いくつかの制限があります。

重要

次のリストは、事前設定された AWS ゾーンにクラスターをデプロイする場合の制限の詳細を示しています。

  • ゾーン内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。これにより、デプロイメントで使用されるネットワークプラグインに応じて、クラスター全体のネットワーク MTU が変わります。
  • Network Load Balancer (NLB)、Classic Load Balancer、Network Address Translation (NAT) ゲートウェイなどのネットワークリソースは、グローバルにサポートされていません。
  • AWS 上の OpenShift Container Platform クラスターの場合、AWS Elastic Block Storage (EBS) gp3 タイプのボリュームがノードボリュームのデフォルトであり、ストレージクラスのデフォルトです。このボリュームタイプは、ゾーンの場所ではグローバルに使用できません。デフォルトでは、ゾーン内で実行されるノードは、gp2 EBS ボリュームを使用してデプロイされます。ゾーンのノードにワークロードを作成する場合は、gp2-csi StorageClass パラメーターを設定する必要があります。

インストールプログラムで OpenShift Container Platform クラスターの Local Zone サブネットを自動的に作成する場合、この方法に伴う固有の設定制限が適用されます。

重要

OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを設定する場合は、次の設定制限が適用されます。

  • インストールプログラムは、AWS Local Zones にプライベートサブネットを作成するときに、各サブネットをその親ゾーンのルートテーブルに関連付けます。この操作により、各プライベートサブネットが AWS リージョンの NAT ゲートウェイ経由で Egress トラフィックをインターネットにルーティングできるようになります。
  • クラスターのインストール時に親ゾーンのルートテーブルが存在しない場合、インストールプログラムは、プライベートサブネットを Amazon Virtual Private Cloud (VPC) 内の最初に使用可能なプライベートルートテーブルに関連付けます。このアプローチは、OpenShift Container Platform クラスター内の AWS Local Zones サブネットに対してのみ有効です。
3.11.2.2. エッジコンピュートプールについて

エッジコンピュートノードは、AWS Local Zones の場所で実行される taint されたコンピュートノードです。

Local Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。

  • Local Zone の Amazon EC2 インスタンスは、アベイラビリティゾーンの Amazon EC2 インスタンスよりも高価です。
  • AWS Local Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。たとえば、ローカルゾーンとアベイラビリティゾーンの間で受信トラフィックが混在している場合は、一部のワークロードに遅延の影響が発生します。
重要

通常、Local Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes です。

ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。

詳細は、AWS ドキュメントの ローカルゾーンの仕組み を参照してください。

OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプール設定は、AWS Local Zone の場所間で共通です。Local Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。

Local Zones の場所のデフォルト Elastic Block Store (EBS) は gp2 であり、非エッジコンピュートプールとは異なります。各 Local Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。

エッジコンピュートプールは、開発者が AWS Local Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。

  • node-role.kubernetes.io/edge=''
  • machine.openshift.io/zone-type=local-zone
  • machine.openshift.io/zone-group=$ZONE_GROUP_NAME

デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule taint を定義して、Local Zones インスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。

3.11.3. インストールの要件

AWS Local Zones 環境にクラスターをインストールする前に、Local Zone 機能を導入できるようにインフラストラクチャーを設定する必要があります。

3.11.3.1. AWS Local Zones へのオプトイン

AWS Local Zones にサブネットを作成する予定がある場合は、各ゾーングループに個別にオプトインする必要があります。

前提条件

  • AWS CLI をインストールしている。
  • OpenShift Container Platform クラスターをデプロイする AWS リージョンを決定しました。
  • ゾーングループにオプトインするユーザーまたはロールアカウントに、寛容な IAM ポリシーをアタッチしました。

手順

  1. 次のコマンドを実行して、AWS リージョンで利用可能なゾーンをリスト表示します。

    AWS リージョンで利用可能な AWS Local Zones をリスト表示するコマンドの例

    $ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
        --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
        --filters Name=zone-type,Values=local-zone \
        --all-availability-zones

    AWS リージョンによっては、利用可能なゾーンのリストが長くなる場合があります。このコマンドは次のフィールドを返します。

    ZoneName
    Local Zones の名前。
    GroupName
    ゾーンで構成されるグループ。リージョンにオプトインするには、この名前を保存しておきます。
    Status
    Local Zones グループのステータス。ステータスが not-opted-in の場合は、次の手順で説明するように GroupName をオプトインする必要があります。
  2. 次のコマンドを実行して、AWS アカウントのゾーングループにオプトインします。

    $ aws ec2 modify-availability-zone-group \
        --group-name "<value_of_GroupName>" \1
        --opt-in-status opted-in
    1
    <value_of_GroupName> は、サブネットを作成する Local Zones のグループの名前に置き換えます。たとえば、ゾーン us-east-1-nyc-1a (米国東部 (ニューヨーク)) を使用するには us-east-1-nyc-1 と指定します。
3.11.3.2. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.com
    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          amiID: ami-06c4d345f7c207239 1
          type: m5.4xlarge
      replicas: 3
    metadata:
      name: test-cluster
    platform:
      aws:
        region: us-east-2 2
    sshKey: ssh-ed25519 AAAA...
    pullSecret: '{"auths": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

3.11.4. インストールの準備

ノードを Local Zone に拡張する前に、クラスターのインストール環境用に特定のリソースを準備する必要があります。

3.11.4.1. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表3.18 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

3.11.4.2. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) インスタンスタイプは、AWS Local Zones で使用するために OpenShift Container Platform でテストされています。

注記

AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。

例3.31 AWS Local Zones の 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c5.*
  • c5d.*
  • m6i.*
  • m5.*
  • r5.*
  • t3.*

関連情報

3.11.4.3. インストール設定ファイルの作成

インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。

前提条件

  • user-provisioned infrastructure 用の OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、install-config.yaml ファイルを手動で作成する必要があります。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
      重要

      空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして aws を選択します。
      3. AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

        注記

        AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. オプション: install-config.yaml ファイルをバックアップします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.11.4.4. エッジコンピュートプールを含むインストール設定ファイルの例

次の例は、エッジマシンプール設定を含む install-config.yaml ファイルを示しています。

カスタムインスタンスタイプのエッジプールを使用する設定

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-edgezone
compute:
- name: edge
  platform:
    aws:
      type: r5.2xlarge
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

インスタンスのタイプは場所によって異なります。クラスターを実行する Local Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。

カスタム Amazon Elastic Block Store (EBS) タイプのエッジプールを使用する設定

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-edgezone
compute:
- name: edge
  platform:
    aws:
      zones:
      - us-west-2-lax-1a
      - us-west-2-lax-1b
      - us-west-2-phx-2a
      rootVolume:
        type: gp3
        size: 120
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Elastic Block Storage (EBS) タイプは場所によって異なります。クラスターを実行する Local Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。

カスタムセキュリティーグループを持つエッジプールを使用する設定

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-edgezone
compute:
- name: edge
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 1
        - sg-2
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

1
Amazon EC2 コンソールに表示されるセキュリティーグループの名前を指定します。必ず sg 接頭辞を含めてください。
3.11.4.5. クラスターネットワークの MTU のカスタマイズ

AWS にクラスターをデプロイする前に、インフラストラクチャーのニーズに合わせて、クラスターネットワークの最大伝送単位 (MTU) をカスタマイズできます。

デフォルトでは、サポートされている Local Zones 機能を使用してクラスターをインストールすると、クラスターネットワークの MTU 値が、ネットワークプラグインによって許可される最低値に自動的に調整されます。

重要

サポートされていない MTU 値を Local Zones インフラストラクチャーで動作する EC2 インスタンスに設定すると、OpenShift Container Platform クラスターに問題が発生する可能性があります。

Local Zone と AWS リージョンの EC2 インスタンス間の MTU 値を引き上げることが可能な場合は、より高い値を手動で設定して、クラスターネットワークのネットワークパフォーマンスを向上できます。

install-config.yaml 設定ファイルで networking.clusterNetworkMTU パラメーターを指定することにより、クラスターの MTU をカスタマイズできます。

重要

Local Zones 内のすべてのサブネットは、そのゾーン内の各ノードが AWS リージョン内のサービスと正常に通信してワークロードをデプロイできるように、より高い MTU 値をサポートしている必要があります。

デフォルトの MTU 値を上書きする例

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: edge-zone
networking:
  clusterNetworkMTU: 8901
compute:
- name: edge
  platform:
    aws:
      zones:
      - us-west-2-lax-1a
      - us-west-2-lax-1b
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

関連情報

3.11.5. AWS Local Zones 環境のクラスターインストールオプション

以下のいずれかのインストール方法を選択して、Local Zones に定義されたエッジコンピュートノードを使用して OpenShift Container Platform クラスターを AWS にインストールします。

  • 完全に自動化された方法: クラスターをインストールして、コンピュートノードをエッジコンピュートプールに迅速に拡張します。インストールプログラムが、OpenShift Container Platform クラスター用のインフラストラクチャーリソースを自動的に作成します。
  • 既存の VPC を使用する方法: AWS 上のクラスターを既存の VPC にインストールします。この場合、Local Zones サブネットを install-config.yaml ファイルに指定します。

次のステップ

次のいずれかの方法を選択して、OpenShift Container Platform クラスターを AWS Local Zones 環境にインストールします。

3.11.6. AWS Local Zones にクラスターを迅速にインストールする

OpenShift Container Platform 4.17 では、Amazon Web Services (AWS) にクラスターをすばやくインストールして、コンピュートノードを Local Zones の場所に拡張できます。このインストール方法を使用すると、設定ファイルで定義した各ゾーンのネットワークリソースと Local Zones サブネットが、インストールプログラムによって自動的に作成されます。インストールをカスタマイズするには、クラスターをデプロイする前に、install-config.yaml ファイル内のパラメーターを変更する必要があります。

3.11.6.1. AWS Local Zones を使用するためのインストール設定ファイルの変更

install-config.yaml ファイルを変更して、AWS Local Zones を含めます。

前提条件

  • AWS アカウントが設定されている。
  • aws configure を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。
  • OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを指定する際に適用される設定上の制限を理解している。
  • 各ゾーンの Local Zones グループにオプトインしている。
  • 「インストール設定ファイルの作成」手順を使用して、install-config.yaml ファイルを作成している。

手順

  1. install-config.yaml ファイルを変更して、エッジコンピュートプールの platform.aws.zones プロパティーで Local Zones 名を指定します。

    # ...
    platform:
      aws:
        region: <region_name> 1
    compute:
    - name: edge
      platform:
        aws:
          zones: 2
          - <local_zone_name>
    #...
    1
    AWS リージョン名。
    2
    使用する Local Zones 名のリストは、platform.aws.region フィールドで指定した同じ AWS リージョンに存在する必要があります。

    エッジノードを Los AngelesLas Vegas の Local Zones に拡張する us-west-2 AWS リージョンにクラスターをインストールする設定の例

    apiVersion: v1
    baseDomain: example.com
    metadata:
      name: cluster-name
    platform:
      aws:
        region: us-west-2
    compute:
    - name: edge
      platform:
        aws:
          zones:
          - us-west-2-lax-1a
          - us-west-2-lax-1b
          - us-west-2-las-1a
    pullSecret: '{"auths": ...}'
    sshKey: 'ssh-ed25519 AAAA...'
    #...

  2. クラスターをデプロイします。

次のステップ

3.11.7. Local Zone のサブネットを持つ既存の VPC へのクラスターのインストール

クラスターを Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

AWS 上のクラスターを既存の VPC にインストールするには、AWS Local Zones を使用してコンピュートノードをクラウドインフラストラクチャーのエッジまで拡張する必要があります。

Local Zone のサブネットは、通常のコンピュートノードをエッジネットワークに拡張します。各エッジコンピュートノードは、ユーザーワークロードを実行します。Amazon Web Services (AWS) の Local Zone 環境を作成し、クラスターをデプロイした後、エッジコンピュートノードを使用して Local Zone のサブネットにユーザーワークロードを作成できます。

注記

プライベートサブネットを作成する場合は、提供されている CloudFormation テンプレートを変更するか、独自のテンプレートを作成する必要があります。

このドキュメントの CloudFormation テンプレートを使用して、ネットワークリソースを作成できます。さらに、テンプレートを変更してインフラストラクチャーをカスタマイズしたり、テンプレートに含まれる情報を使用して会社のポリシーに基づいて AWS リソースを作成したりできます。

重要

installer-provisioned infrastructure のインストールを実行する手順は、例としてのみ提供されています。既存の VPC にクラスターをインストールするには、クラウドプロバイダーと OpenShift Container Platform のインストールプロセスに関する知識が必要です。CloudFormation テンプレートを使用すると、これらの手順の完了を支援したり、独自のクラスターのインストールをモデル化したりできます。CloudFormation テンプレートを使用してリソースを作成する代わりに、これらのリソースを生成するために他の方法を使用することを決定できます。

3.11.7.1. AWS での VPC の作成

OpenShift Container Platform クラスター用の Amazon Web Services (AWS) で、Virtual Private Cloud (VPC) を作成し、Local Zones のすべての場所にサブネットを作成すると、コンピュートノードをエッジロケーションに拡張できます。VPC は、VPN やルートテーブルなどの要件に合わせてさらにカスタマイズできます。初期デプロイメントに含まれていない新しい Local Zones サブネットを追加することもできます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。
  • AWS アカウントで AWS Local Zones にオプトインしている。

手順

  1. CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "VpcCidr", 1
        "ParameterValue": "10.0.0.0/16" 2
      },
      {
        "ParameterKey": "AvailabilityZoneCount", 3
        "ParameterValue": "3" 4
      },
      {
        "ParameterKey": "SubnetBits", 5
        "ParameterValue": "12" 6
      }
    ]
    1
    VPC の CIDR ブロック。
    2
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    3
    VPC をデプロイするアベイラビリティーゾーンの数。
    4
    1 から 3 の間の整数を指定します。
    5
    各アベイラビリティーゾーン内の各サブネットのサイズ。
    6
    5 から 13 の間の整数を指定します。ここで、5/27 であり、13/19 です。
  2. このドキュメントの「VPC の CloudFormation テンプレート」セクションに移動し、記載されているテンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  3. 次のコマンドを実行して、CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> \1
         --template-body file://<template>.yaml \2
         --parameters file://<parameters>.json  3
    1
    <name>cluster-vpc などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーターの JSON ファイルの相対パスと名前です。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f

  4. 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    VpcId

    VPC の ID。

    PublicSubnetIds

    新規パブリックサブネットの ID。

    PrivateSubnetIds

    新規プライベートサブネットの ID。

    PublicRouteTableId

    新しいパブリックルートテーブル ID の ID。

3.11.7.2. VPC の CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。

例3.32 VPC の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable
  PrivateRouteTableIds:
    Description: Private Route table IDs
    Value:
      !Join [
        ",",
        [
          !Join ["=", [
            !Select [0, "Fn::GetAZs": !Ref "AWS::Region"],
            !Ref PrivateRouteTable
          ]],
          !If [DoAz2,
               !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]],
               !Ref "AWS::NoValue"
          ],
          !If [DoAz3,
               !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]],
               !Ref "AWS::NoValue"
          ]
        ]
      ]
3.11.7.3. Local Zones のサブネットの作成

OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、Local Zones にサブネットを作成する必要があります。コンピュートノードをデプロイする Local Zone ごとに次の手順を実行してください。

このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • Local Zones グループにオプトインしている。

手順

  1. このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \2
      --parameters \
        ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3
        ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4
        ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5
        ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6
        ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7
        ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8
        ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
    1
    <stack_name> は、CloudFormation スタックの名前です (cluster-wl-<local_zone_shortname> など)。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    ${VPC_ID} は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値 VpcID です。
    4
    ${ZONE_NAME} は、サブネットを作成する Local Zones 名の値です。
    5
    ${CLUSTER_NAME} は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。
    6
    ${SUBNET_CIDR_PUB} は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。
    7
    ${ROUTE_TABLE_PVT} は、VPC の CloudFormation スタックの出力から抽出した PrivateRouteTableId です。
    8
    ${SUBNET_CIDR_PVT} は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。

出力例

arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f

検証

  • 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

    PublicSubnetId

    CloudFormation スタックによって作成されたパブリックサブネットの ID。

    PrivateSubnetId

    CloudFormation スタックによって作成されたプライベートサブネットの ID。

3.11.7.4. VPC サブネット用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、Local Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。

例3.33 VPC サブネット用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice Subnets (Public and Private)

Parameters:
  VpcId:
    Description: VPC ID that comprises all the target subnets.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster name or prefix name to prepend the Name tag for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.
  ZoneName:
    Description: Zone Name to create the subnets, such as us-west-2-lax-1a.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ZoneName parameter must be specified.
  PublicRouteTableId:
    Description: Public Route Table ID to associate the public subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PublicRouteTableId parameter must be specified.
  PublicSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for public subnet.
    Type: String
  PrivateRouteTableId:
    Description: Private Route Table ID to associate the private subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PrivateRouteTableId parameter must be specified.
  PrivateSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for private subnet.
    Type: String


Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]]

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PrivateSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]]

  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTableId

Outputs:
  PublicSubnetId:
    Description: Subnet ID of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

  PrivateSubnetId:
    Description: Subnet ID of the private subnets.
    Value:
      !Join ["", [!Ref PrivateSubnet]]

関連情報

3.11.7.5. AWS Local Zones サブネットを使用するためのインストール設定ファイルの変更

install-config.yaml ファイルを変更して、Local Zones のサブネットを含めます。

前提条件

  • 「Local Zone のサブネットの作成」手順を使用して、サブネットを作成している。
  • 「インストール設定ファイルの作成」手順を使用して、install-config.yaml ファイルを作成している。

手順

  • install-config.yaml 設定ファイルを変更して、platform.aws.subnets パラメーターで Local Zones のサブネットを指定します。

    Local Zones のサブネットを含むインストール設定ファイルの例

    # ...
    platform:
      aws:
        region: us-west-2
        subnets: 1
        - publicSubnetId-1
        - publicSubnetId-2
        - publicSubnetId-3
        - privateSubnetId-1
        - privateSubnetId-2
        - privateSubnetId-3
        - publicSubnetId-LocalZone-1
    # ...

    1
    ゾーン (アベイラビリティーゾーンと Local Zones) 内に作成したサブネット ID のリスト。

関連情報

次のステップ

3.11.8. オプション: AWS セキュリティーグループ

デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。

ただし、既存の VPC に関連付けられている追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。

インストールプロセスの一環として、クラスターをデプロイする前に install-config.yaml ファイルを変更してカスタムセキュリティーグループを適用します。

詳細は、「エッジコンピュートプールと AWS Local Zones」を参照してください。

3.11.9. オプション: パブリック IP アドレスをエッジコンピュートノードに割り当てます。

ワークロードによっては、Local Zones インフラストラクチャー上のパブリックサブネットにエッジコンピュートノードをデプロイすることが必要になります。その場合は、クラスターのインストール時にマシンセットマニフェストを設定できます。

AWS Local Zones インフラストラクチャーは、指定されたゾーン内のネットワークトラフィックにアクセスします。そのため、そのゾーンに近いエンドユーザーにサービスを提供する際に、アプリケーションで低遅延を利用できます。

デフォルト設定は、プライベートサブネットにコンピュートノードをデプロイする設定であり、お客様のニーズに合わない可能性があります。そのため、インフラストラクチャーにさらにカスタマイズを適用する必要がある場合は、パブリックサブネットにエッジコンピュートノードを作成することを検討してください。

重要

デフォルトでは、OpenShift Container Platform はプライベートサブネットにコンピュートノードをデプロイします。最高のパフォーマンスを得るには、パブリック IP アドレスがサブネットに接続されているサブネットにコンピュートノードを配置することを検討してください。

追加のセキュリティーグループを作成する必要があります。ただし、インターネット経由でグループのルールを開くのは、本当に必要な場合だけに留めてください。

手順

  1. インストールプログラムが含まれるディレクトリーに移動し、マニフェストファイルを生成します。インストールマニフェストが openshift および manifests ディレクトリーレベルに作成されていることを確認します。

    $ ./openshift-install create manifests --dir <installation_directory>
  2. インストールプログラムが Local Zones 用に生成するマシンセットマニフェストを編集して、マニフェストがパブリックサブネットにデプロイされるようにします。spec.template.spec.providerSpec.value.publicIP パラメーターに true を指定します。

    クラスターを Local Zones に迅速にインストールするためのマシンセットマニフェスト設定の例

    spec:
      template:
        spec:
          providerSpec:
            value:
              publicIp: true
              subnet:
                filters:
                  - name: tag:Name
                    values:
                      - ${INFRA_ID}-public-${ZONE_NAME}

    Local Zones サブネットを持つ既存の VPC にクラスターをインストールするためのマシンセットマニフェスト設定の例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      name: <infrastructure_id>-edge-<zone>
      namespace: openshift-machine-api
    spec:
      template:
        spec:
          providerSpec:
            value:
              publicIp: true

3.11.10. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./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 にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
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.11.11. デプロイしたクラスターのステータスの確認

OpenShift Container Platform が AWS Local Zones に正常にデプロイされたことを確認します。

3.11.11.1. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.11.11.2. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。
3.11.11.3. エッジコンピューティングプールで作成されたノードの検証

AWS Local Zones インフラストラクチャーを使用するクラスターをインストールしたら、インストール時に作成したマシンセットマニフェストによって作成されたマシンのステータスを確認します。

  1. install-config.yaml ファイルに追加したサブネットから作成されたマシンセットを確認するには、次のコマンドを実行します。

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                  DESIRED   CURRENT   READY   AVAILABLE   AGE
    cluster-7xw5g-edge-us-east-1-nyc-1a   1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1a       1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1b       1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1c       1         1         1       1           3h4m

  2. マシンセットから作成されたマシンを確認するには、次のコマンドを実行します。

    $ oc get machines -n openshift-machine-api

    出力例

    NAME                                        PHASE     TYPE          REGION      ZONE               AGE
    cluster-7xw5g-edge-us-east-1-nyc-1a-wbclh   Running   c5d.2xlarge   us-east-1   us-east-1-nyc-1a   3h
    cluster-7xw5g-master-0                      Running   m6i.xlarge    us-east-1   us-east-1a         3h4m
    cluster-7xw5g-master-1                      Running   m6i.xlarge    us-east-1   us-east-1b         3h4m
    cluster-7xw5g-master-2                      Running   m6i.xlarge    us-east-1   us-east-1c         3h4m
    cluster-7xw5g-worker-us-east-1a-rtp45       Running   m6i.xlarge    us-east-1   us-east-1a         3h
    cluster-7xw5g-worker-us-east-1b-glm7c       Running   m6i.xlarge    us-east-1   us-east-1b         3h
    cluster-7xw5g-worker-us-east-1c-qfvz4       Running   m6i.xlarge    us-east-1   us-east-1c         3h

  3. エッジロールを持つノードを確認するには、次のコマンドを実行します。

    $ oc get nodes -l node-role.kubernetes.io/edge

    出力例

    NAME                           STATUS   ROLES         AGE    VERSION
    ip-10-0-207-188.ec2.internal   Ready    edge,worker   172m   v1.25.2+d2e245f

次のステップ

3.12. AWS Wavelength Zones 上のコンピュートノードを使用してクラスターをインストールする

install-config.yaml ファイルのエッジコンピュートプールにゾーン名を設定することで、OpenShift Container Platform クラスターを Amazon Web Services (AWS) Wavelength Zones にすばやくインストールできます。または、Wavelength Zone サブネットを持つ既存の Amazon Virtual Private Cloud (VPC) にクラスターをインストールすることもできます。

AWS Wavelength Zones は、AWS がモバイルエッジコンピューティング (MEC) アプリケーション用に構成したインフラストラクチャーです。

Wavelength Zone は、通信サービスプロバイダー (CSP) の 5G ネットワーク内に AWS のコンピュートサービスとストレージサービスを組み込みます。アプリケーションサーバーを Wavelength Zone に配置することで、5G デバイスからのアプリケーショントラフィックを 5G ネットワーク内に留めることができます。デバイスのアプリケーショントラフィックがターゲットサーバーに直接到達するため、遅延が問題になりません。

関連情報

3.12.1. インフラストラクチャーの前提条件

  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択とユーザー用にクラスターを準備する方法 を理解している。
  • クラスターをホストするために AWS アカウントを設定 している。

    警告

    AWS プロファイルがご使用のコンピューターに保存されている場合、マルチファクター認証デバイスを使用中に生成した一時的なセッショントークンを使用することはできません。クラスターは継続的に現行の AWS 認証情報を使用して、クラスターの有効期間全体にわたって AWS リソースを作成するため、キーをベースとした有効期間の長い認証情報を使用する必要があります。適切なキーを生成するには、AWS ドキュメントの Managing Access Keys for IAM Users を参照してください。キーは、インストールプログラムの実行時に指定できます。

  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。AWS ドキュメントの Install the AWS CLI Using the Bundled Installer (Linux, macOS, or UNIX) を参照してください。
  • ファイアウォールを使用している場合は、クラスターがアクセスする必要がある サイトを許可するようにファイアウォールを設定 している。
  • ネットワークリソースを作成するために、リージョンとサポートされている AWS Wavelength Zone の場所 を書き留めている。
  • AWS ドキュメントの AWS Wavelength features を確認している。
  • AWS ドキュメントの Quotas and considerations for Wavelength Zones を確認している。
  • AWS Wavelength Zones をサポートするネットワークリソースを作成する権限を、アイデンティティーおよびアクセス管理 (IAM) ユーザーまたはロールに追加している。以下に例を示します。

    ユーザーまたはロールに ec2:ModifyAvailabilityZoneGroupec2:CreateCarrierGateway、および ec2:DeleteCarrierGateway 権限を割り当てた追加の IAM ポリシーの例

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "ec2:DeleteCarrierGateway",
            "ec2:CreateCarrierGateway"
          ],
          "Resource": "*"
        },
        {
          "Action": [
            "ec2:ModifyAvailabilityZoneGroup"
          ],
          "Effect": "Allow",
          "Resource": "*"
        }
      ]
    }

3.12.2. AWS Wavelength Zones とエッジコンピュートプールについて

AWS Wavelength Zones 環境でのインフラストラクチャーの動作とクラスターの制限を理解するには、以降のセクションをお読みください。

3.12.2.1. AWS Wavelength Zones のクラスターの制限

デフォルトのインストール設定で Amazon Web Services (AWS) の Local Zone にクラスターをデプロイする場合、いくつかの制限があります。

重要

次のリストは、事前設定された AWS ゾーンにクラスターをデプロイする場合の制限の詳細を示しています。

  • ゾーン内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。これにより、デプロイメントで使用されるネットワークプラグインに応じて、クラスター全体のネットワーク MTU が変わります。
  • Network Load Balancer (NLB)、Classic Load Balancer、Network Address Translation (NAT) ゲートウェイなどのネットワークリソースは、グローバルにサポートされていません。
  • AWS 上の OpenShift Container Platform クラスターの場合、AWS Elastic Block Storage (EBS) gp3 タイプのボリュームがノードボリュームのデフォルトであり、ストレージクラスのデフォルトです。このボリュームタイプは、ゾーンの場所ではグローバルに使用できません。デフォルトでは、ゾーン内で実行されるノードは、gp2 EBS ボリュームを使用してデプロイされます。ゾーンのノードにワークロードを作成する場合は、gp2-csi StorageClass パラメーターを設定する必要があります。

インストールプログラムで OpenShift Container Platform クラスターの Wavelength Zone サブネットを自動的に作成する場合、この方法に伴う固有の設定制限が適用されます。次の注記で、これらの制限の一部を詳しく説明します。その他の制限は、「インフラストラクチャーの前提条件」セクションに記載されている「Quotas and considerations for Wavelength Zones」ドキュメントをお読みください。

重要

OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを設定する場合は、次の設定制限が適用されます。

  • インストールプログラムは、AWS Wavelength Zones にプライベートサブネットを作成するときに、各サブネットをその親ゾーンのルートテーブルに関連付けます。この操作により、各プライベートサブネットが AWS リージョンの NAT ゲートウェイ経由で Egress トラフィックをインターネットにルーティングできるようになります。
  • クラスターのインストール時に親ゾーンのルートテーブルが存在しない場合、インストールプログラムは、プライベートサブネットを Amazon Virtual Private Cloud (VPC) 内の最初に使用可能なプライベートルートテーブルに関連付けます。このアプローチは、OpenShift Container Platform クラスター内の AWS Wavelength Zones サブネットに対してのみ有効です。
3.12.2.2. エッジコンピュートプールについて

エッジコンピュートノードは、AWS Wavelength Zones の場所で実行される taint されたコンピュートノードです。

Wavelength Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。

  • Wavelength Zones 内の Amazon EC2 インスタンスは、アベイラビリティーゾーン内の Amazon EC2 インスタンスよりも高コストです。
  • AWS Wavelength Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。一部のワークロードでは、遅延の影響が発生します。たとえば、Wavelength Zones とアベイラビリティーゾーンの間で Ingress トラフィックが混在している場合などです。
重要

通常、Wavelength Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes です。

ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。

詳細は、AWS ドキュメントの How AWS Wavelength work を参照してください。

OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプールの設定は、Wavelength Zones の場所間で共通です。Wavelength Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。

Wavelength Zones の場所のデフォルト Elastic Block Store (EBS) は gp2 であり、非エッジコンピュートプールとは異なります。各 Wavelength Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。

エッジコンピュートプールは、開発者が AWS Wavelength Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。

  • node-role.kubernetes.io/edge=''
  • machine.openshift.io/zone-type=wavelength-zone
  • machine.openshift.io/zone-group=$ZONE_GROUP_NAME

デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule taint を定義して、Wavelength Zones インスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。

3.12.3. インストールの要件

AWS Wavelength Zones 環境にクラスターをインストールする前に、Wavelength Zone 機能を導入できるようにインフラストラクチャーを設定する必要があります。

3.12.3.1. AWS Wavelength Zones へのオプトイン

AWS Wavelength Zones でサブネットを作成する予定がある場合は、各ゾーングループに個別にオプトインする必要があります。

前提条件

  • AWS CLI をインストールしている。
  • OpenShift Container Platform クラスターをデプロイする AWS リージョンを決定しました。
  • ゾーングループにオプトインするユーザーまたはロールアカウントに、寛容な IAM ポリシーをアタッチしました。

手順

  1. 次のコマンドを実行して、AWS リージョンで利用可能なゾーンをリスト表示します。

    AWS リージョンで利用可能な AWS Wavelength Zones をリストするコマンドの例

    $ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
        --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
        --filters Name=zone-type,Values=wavelength-zone \
        --all-availability-zones

    AWS リージョンによっては、利用可能なゾーンのリストが長くなる場合があります。このコマンドは次のフィールドを返します。

    ZoneName
    Wavelength Zones の名前。
    GroupName
    ゾーンで構成されるグループ。リージョンにオプトインするには、この名前を保存しておきます。
    Status
    Wavelength Zones グループのステータス。ステータスが not-opted-in の場合は、次の手順で説明するように GroupName をオプトインする必要があります。
  2. 次のコマンドを実行して、AWS アカウントのゾーングループにオプトインします。

    $ aws ec2 modify-availability-zone-group \
        --group-name "<value_of_GroupName>" \1
        --opt-in-status opted-in
    1
    <value_of_GroupName> は、サブネットを作成する Wavelength Zones のグループの名前に置き換えます。たとえば、Wavelength Zones としてゾーン us-east-1-wl1-nyc-wlz-1 (米国東部ニューヨーク) を使用するには、us-east-1-wl1 を指定します。
3.12.3.2. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。
  2. ご使用の AWS リージョンの AMI ID を記録します。インストールプロセスの一環として、クラスターをデプロイする前に、この値で install-config.yaml ファイルを更新する必要があります。

    AWS Marketplace コンピュートノードを含む install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.com
    compute:
    - hyperthreading: Enabled
      name: worker
      platform:
        aws:
          amiID: ami-06c4d345f7c207239 1
          type: m5.4xlarge
      replicas: 3
    metadata:
      name: test-cluster
    platform:
      aws:
        region: us-east-2 2
    sshKey: ssh-ed25519 AAAA...
    pullSecret: '{"auths": ...}'

    1
    AWS Marketplace サブスクリプションの AMI ID。
    2
    AMI ID は特定の AWS リージョンに関連付けられています。インストール設定ファイルを作成するときは、サブスクリプションの設定時に指定したものと同じ AWS リージョンを選択してください。

3.12.4. インストールの準備

ノードを Wavelength Zone に拡張する前に、クラスターのインストール環境用に特定のリソースを準備する必要があります。

3.12.4.1. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表3.19 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

3.12.4.2. AWS のテスト済みインスタンスタイプ

次の Amazon Web Services (AWS) インスタンスタイプは、AWS Wavelength Zones で使用できることを OpenShift Container Platform でテスト済みです。

注記

AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。

例3.34 AWS Wavelength Zones で使用できる 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • r5.*
  • t3.*

関連情報

3.12.4.3. インストール設定ファイルの作成

インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、install-config.yaml ファイルを手動で作成する必要があります。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
      重要

      空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして aws を選択します。
      3. AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

        注記

        AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. オプション: install-config.yaml ファイルをバックアップします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

3.12.4.4. エッジコンピュートプールを含むインストール設定ファイルの例

次の例は、エッジマシンプール設定を含む install-config.yaml ファイルを示しています。

カスタムインスタンスタイプのエッジプールを使用する設定

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-edgezone
compute:
- name: edge
  platform:
    aws:
      type: r5.2xlarge
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

インスタンスのタイプは場所によって異なります。クラスターを実行する Wavelength Zones で利用可能かどうかを確認するには、AWS のドキュメントを参照してください。

カスタムセキュリティーグループを持つエッジプールを使用する設定

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-edgezone
compute:
- name: edge
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 1
        - sg-2
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

1
Amazon EC2 コンソールに表示されるセキュリティーグループの名前を指定します。必ず sg 接頭辞を含めてください。

3.12.5. AWS Wavelength Zones 環境のクラスターインストール方法

以下のいずれかのインストール方法を選択して、Wavelength Zones に定義されたエッジコンピュートノードを使用して OpenShift Container Platform クラスターを AWS にインストールします。

  • 完全に自動化された方法: クラスターをインストールして、コンピュートノードをエッジコンピュートプールに迅速に拡張します。インストールプログラムが、OpenShift Container Platform クラスター用のインフラストラクチャーリソースを自動的に作成します。
  • 既存の VPC を使用する方法: AWS 上のクラスターを既存の VPC にインストールします。この場合、Wavelength Zones サブネットを install-config.yaml ファイルに指定します。

次のステップ

次のいずれかの方法を選択して、OpenShift Container Platform クラスターを AWS Wavelength Zones 環境にインストールします。

3.12.6. クラスターの AWS Wavelength Zones へのクイックインストール

OpenShift Container Platform 4.17 では、Amazon Web Services (AWS) にクラスターをすばやくインストールして、コンピュートノードを Wavelength Zones の場所に拡張できます。このインストール方法を使用すると、設定ファイルで定義した各ゾーンのネットワークリソースと Wavelength Zones サブネットが、インストールプログラムによって自動的に作成されます。インストールをカスタマイズするには、クラスターをデプロイする前に、install-config.yaml ファイル内のパラメーターを変更する必要があります。

3.12.6.1. AWS Wavelength Zones を使用するためのインストール設定ファイルの変更

install-config.yaml ファイルを変更して、AWS Wavelength Zones を含めます。

前提条件

  • AWS アカウントが設定されている。
  • aws configure を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。
  • OpenShift Container Platform クラスターのサブネットを自動的に作成するようにインストールプログラムを指定する際に適用される設定上の制限を理解している。
  • 各ゾーンの Wavelength Zones グループにオプトインしている。
  • 「インストール設定ファイルの作成」手順を使用して、install-config.yaml ファイルを作成している。

手順

  1. install-config.yaml ファイルを変更して、エッジコンピュートプールの platform.aws.zones プロパティーで Wavelength Zones 名を指定します。

    # ...
    platform:
      aws:
        region: <region_name> 1
    compute:
    - name: edge
      platform:
        aws:
          zones: 2
          - <wavelength_zone_name>
    #...
    1
    AWS リージョン名。
    2
    使用する Wavelength Zones 名のリストは、platform.aws.region フィールドで指定した同じ AWS リージョンに存在する必要があります。

    エッジノードを Los AngelesLas Vegas の Wavelength Zones に拡張する us-west-2 AWS リージョンにクラスターをインストールする設定の例

    apiVersion: v1
    baseDomain: example.com
    metadata:
      name: cluster-name
    platform:
      aws:
        region: us-west-2
    compute:
    - name: edge
      platform:
        aws:
          zones:
          - us-west-2-wl1-lax-wlz-1
          - us-west-2-wl1-las-wlz-1
    pullSecret: '{"auths": ...}'
    sshKey: 'ssh-ed25519 AAAA...'
    #...

  2. クラスターをデプロイします。

次のステップ

3.12.7. Wavelength Zone のサブネットを持つ既存の VPC へのクラスターのインストール

クラスターを Amazon Web Services (AWS) 上の既存の Amazon Virtual Private Cloud (VPC) にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

AWS 上のクラスターを既存の VPC にインストールするには、AWS Wavelength Zones を使用してコンピュートノードをクラウドインフラストラクチャーのエッジまで拡張する必要があります。

このドキュメントの CloudFormation テンプレートを使用して、ネットワークリソースを作成できます。さらに、テンプレートを変更してインフラストラクチャーをカスタマイズしたり、テンプレートに含まれる情報を使用して会社のポリシーに基づいて AWS リソースを作成したりできます。

重要

installer-provisioned infrastructure のインストールを実行する手順は、例としてのみ提供されています。既存の VPC にクラスターをインストールするには、クラウドプロバイダーと OpenShift Container Platform のインストールプロセスに関する知識が必要です。CloudFormation テンプレートを使用すると、これらの手順の完了を支援したり、独自のクラスターのインストールをモデル化したりできます。CloudFormation テンプレートを使用してリソースを作成する代わりに、これらのリソースを生成するために他の方法を使用することを決定できます。

3.12.7.1. AWS での VPC の作成

OpenShift Container Platform クラスター用の Amazon Web Services (AWS) で、Virtual Private Cloud (VPC) を作成し、Wavelength Zones のすべての場所にサブネットを作成すると、コンピュートノードをエッジロケーションに拡張できます。VPC は、VPN やルートテーブルなどの要件に合わせてさらにカスタマイズできます。初期デプロイメントに含まれていない新しい Wavelength Zones サブネットを追加することもできます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーと AWS リージョンをローカル AWS プロファイルに追加している。
  • AWS アカウントで AWS Wavelength Zones にオプトインしている。

手順

  1. CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "VpcCidr", 1
        "ParameterValue": "10.0.0.0/16" 2
      },
      {
        "ParameterKey": "AvailabilityZoneCount", 3
        "ParameterValue": "3" 4
      },
      {
        "ParameterKey": "SubnetBits", 5
        "ParameterValue": "12" 6
      }
    ]
    1
    VPC の CIDR ブロック。
    2
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    3
    VPC をデプロイするアベイラビリティーゾーンの数。
    4
    1 から 3 の間の整数を指定します。
    5
    各アベイラビリティーゾーン内の各サブネットのサイズ。
    6
    5 から 13 の間の整数を指定します。ここで、5/27 であり、13/19 です。
  2. このドキュメントの「VPC の CloudFormation テンプレート」セクションに移動し、記載されているテンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  3. 次のコマンドを実行して、CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> \1
         --template-body file://<template>.yaml \2
         --parameters file://<parameters>.json  3
    1
    <name>cluster-vpc などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーターの JSON ファイルの相対パスと名前です。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f

  4. 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    VpcId

    VPC の ID。

    PublicSubnetIds

    新規パブリックサブネットの ID。

    PrivateSubnetIds

    新規プライベートサブネットの ID。

    PublicRouteTableId

    新しいパブリックルートテーブル ID の ID。

3.12.7.2. VPC の CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。

例3.35 VPC の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable
  PrivateRouteTableIds:
    Description: Private Route table IDs
    Value:
      !Join [
        ",",
        [
          !Join ["=", [
            !Select [0, "Fn::GetAZs": !Ref "AWS::Region"],
            !Ref PrivateRouteTable
          ]],
          !If [DoAz2,
               !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]],
               !Ref "AWS::NoValue"
          ],
          !If [DoAz3,
               !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]],
               !Ref "AWS::NoValue"
          ]
        ]
      ]
3.12.7.3. VPC キャリアーゲートウェイの作成

Wavelength Zones で実行される OpenShift Container Platform クラスターでパブリックサブネットを使用するには、キャリアーゲートウェイを作成し、キャリアーゲートウェイを VPC に関連付ける必要があります。サブネットは、ロードバランサーまたはエッジコンピュートノードをデプロイするのに役立ちます。

OpenShift Container Platform クラスター用の Wavelength Zones の場所に、エッジノードやインターネットに接続されたロードバランサーを作成するには、以下の必要なネットワークコンポーネントを作成する必要があります。

  • 既存の VPC に関連付けるキャリアーゲートウェイ
  • ルートエントリーをリストするキャリールートテーブル
  • キャリアールートテーブルに関連付けるサブネット

キャリアーゲートウェイは、Wavelength Zone 内のサブネットのみを含む VPC に存在します。

以下では、AWS Wavelength Zones の場所に関連するキャリアーゲートウェイの機能を説明します。

  • Wavelength Zone とキャリアーネットワーク (キャリアーネットワークから利用可能なデバイスを含む) の間の接続を提供します。
  • ネットワークボーダーグループに格納されているパブリック IP アドレスである IP アドレスを Wavelength Zones からキャリアー IP アドレスに変換するなど、ネットワークアドレス変換 (NAT) 機能を実行します。このような変換機能は、受信トラフィックと送信トラフィックに適用されます。
  • 特定の場所にあるキャリアーネットワークからの受信トラフィックを許可します。
  • キャリアーネットワークとインターネットへの送信トラフィックを許可します。
注記

インターネットからキャリアーゲートウェイを経由した Wavelength Zone への受信接続設定は存在しません。

このドキュメントの CloudFormation テンプレートを使用して、次の AWS リソースのスタックを作成できます。

  • テンプレート内の VPC ID に関連付ける 1 つのキャリアーゲートウェイ
  • <ClusterName>-public-carrier という名前の Wavelength Zone の 1 つのパブリックルートテーブル
  • キャリアーゲートウェイをターゲットとする新しいルートテーブルのデフォルトの IPv4 ルートエントリー
  • AWS Simple Storage Service (S3) の VPC ゲートウェイエンドポイント
注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。

手順

  1. ドキュメントの次のセクション「VPC キャリアーゲートウェイ用の CloudFormation テンプレート」に移動し、VPC キャリアーゲートウェイ用の CloudFormation テンプレート から構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \2
      --parameters \//
        ParameterKey=VpcId,ParameterValue="${VpcId}" \3
        ParameterKey=ClusterName,ParameterValue="${ClusterName}" 4
    1
    <stack_name> は CloudFormation スタックの名前です (例: clusterName-vpc-carrier-gw)。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    <VpcId> は、「AWS での VPC の作成」セクションで作成した CloudFormation スタックの出力から抽出した VPC ID です。
    4
    <ClusterName> は、CloudFormation スタックによって作成されるリソースに接頭辞として付加するカスタム値です。install-config.yaml 設定ファイルの metadata.name セクションで定義されているのと同じ名前を使用できます。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f

検証

  • 次のコマンドを実行して、CloudFormation テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。このパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

    PublicRouteTableId

    キャリアーインフラストラクチャーのルートテーブルの ID。

関連情報

  • AWS ドキュメントの Amazon S3 を参照してください。
3.12.7.4. VPC キャリアーゲートウェイ用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、AWS Wavelength インフラストラクチャーにキャリアーゲートウェイをデプロイできます。

例3.36 VPC キャリアーゲートウェイ用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Creating Wavelength Zone Gateway (Carrier Gateway).

Parameters:
  VpcId:
    Description: VPC ID to associate the Carrier Gateway.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster Name or Prefix name to prepend the tag Name for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.

Resources:
  CarrierGateway:
    Type: "AWS::EC2::CarrierGateway"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "cagw"]]

  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public-carrier"]]

  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: CarrierGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      CarrierGatewayId: !Ref CarrierGateway

  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VpcId

Outputs:
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable
3.12.7.5. Wavelength Zones のサブネットの作成

OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、Wavelength Zones にサブネットを作成する必要があります。コンピュートノードをデプロイする Wavelength Zone ごとに次の手順を実行してください。

このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • Wavelength Zones グループにオプトインしている。

手順

  1. このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \ 1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \ 2
      --parameters \
        ParameterKey=VpcId,ParameterValue="${VPC_ID}" \ 3
        ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \ 4
        ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \ 5
        ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \ 6
        ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \ 7
        ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \ 8
        ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
    1
    <stack_name> は、CloudFormation スタックの名前です (cluster-wl-<wavelength_zone_shortname> など)。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    ${VPC_ID} は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値 VpcID です。
    4
    ${ZONE_NAME} は、サブネットを作成する Wavelength Zones 名の値です。
    5
    ${CLUSTER_NAME} は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。
    6
    ${ROUTE_TABLE_PUB} は、VPC のキャリアーゲートウェイ CloudFormation スタックの出力から抽出した PublicRouteTableId です。
    7
    ${SUBNET_CIDR_PUB} は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。
    8
    ${ROUTE_TABLE_PVT} は、VPC の CloudFormation スタックの出力から抽出した PrivateRouteTableId です。
    9
    ${SUBNET_CIDR_PVT} は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。

出力例

arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f

検証

  • 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

    PublicSubnetId

    CloudFormation スタックによって作成されたパブリックサブネットの ID。

    PrivateSubnetId

    CloudFormation スタックによって作成されたプライベートサブネットの ID。

3.12.7.6. VPC サブネット用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、Wavelength Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。

例3.37 VPC サブネット用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice Subnets (Public and Private)

Parameters:
  VpcId:
    Description: VPC ID that comprises all the target subnets.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster name or prefix name to prepend the Name tag for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.
  ZoneName:
    Description: Zone Name to create the subnets, such as us-west-2-lax-1a.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ZoneName parameter must be specified.
  PublicRouteTableId:
    Description: Public Route Table ID to associate the public subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PublicRouteTableId parameter must be specified.
  PublicSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for public subnet.
    Type: String
  PrivateRouteTableId:
    Description: Private Route Table ID to associate the private subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PrivateRouteTableId parameter must be specified.
  PrivateSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for private subnet.
    Type: String


Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]]

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PrivateSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]]

  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTableId

Outputs:
  PublicSubnetId:
    Description: Subnet ID of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

  PrivateSubnetId:
    Description: Subnet ID of the private subnets.
    Value:
      !Join ["", [!Ref PrivateSubnet]]
3.12.7.7. AWS Wavelength Zones サブネットを使用するためのインストール設定ファイルの変更

install-config.yaml ファイルを変更して、Wavelength Zones のサブネットを含めます。

前提条件

  • 「Wavelength Zone のサブネットの作成」手順を使用して、サブネットを作成している。
  • 「インストール設定ファイルの作成」手順を使用して、install-config.yaml ファイルを作成している。

手順

  • install-config.yaml 設定ファイルを変更して、platform.aws.subnets パラメーターで Wavelength Zones のサブネットを指定します。

    Wavelength Zones のサブネットを含むインストール設定ファイルの例

    # ...
    platform:
      aws:
        region: us-west-2
        subnets: 1
        - publicSubnetId-1
        - publicSubnetId-2
        - publicSubnetId-3
        - privateSubnetId-1
        - privateSubnetId-2
        - privateSubnetId-3
        - publicOrPrivateSubnetID-Wavelength-1
    # ...

    1
    ゾーン (アベイラビリティーゾーンと Wavelength Zones) 内に作成したサブネット ID のリスト。

関連情報

次のステップ

3.12.8. オプション: パブリック IP アドレスをエッジコンピュートノードに割り当てます。

ワークロードによっては、Wavelength Zones インフラストラクチャー上のパブリックサブネットにエッジコンピュートノードをデプロイすることが必要になります。その場合は、クラスターのインストール時にマシンセットマニフェストを設定できます。

AWS Wavelength Zones インフラストラクチャーは、指定されたゾーン内のネットワークトラフィックにアクセスします。そのため、そのゾーンに近いエンドユーザーにサービスを提供する際に、アプリケーションで低遅延を利用できます。

デフォルト設定は、プライベートサブネットにコンピュートノードをデプロイする設定であり、お客様のニーズに合わない可能性があります。そのため、インフラストラクチャーにさらにカスタマイズを適用する必要がある場合は、パブリックサブネットにエッジコンピュートノードを作成することを検討してください。

重要

デフォルトでは、OpenShift Container Platform はプライベートサブネットにコンピュートノードをデプロイします。最高のパフォーマンスを得るには、パブリック IP アドレスがサブネットに接続されているサブネットにコンピュートノードを配置することを検討してください。

追加のセキュリティーグループを作成する必要があります。ただし、インターネット経由でグループのルールを開くのは、本当に必要な場合だけに留めてください。

手順

  1. インストールプログラムが含まれるディレクトリーに移動し、マニフェストファイルを生成します。インストールマニフェストが openshift および manifests ディレクトリーレベルに作成されていることを確認します。

    $ ./openshift-install create manifests --dir <installation_directory>
  2. インストールプログラムが Wavelength Zones 用に生成するマシンセットマニフェストを編集して、マニフェストがパブリックサブネットにデプロイされるようにします。spec.template.spec.providerSpec.value.publicIP パラメーターに true を指定します。

    クラスターを Wavelength Zones に迅速にインストールするためのマシンセットマニフェスト設定の例

    spec:
      template:
        spec:
          providerSpec:
            value:
              publicIp: true
              subnet:
                filters:
                  - name: tag:Name
                    values:
                      - ${INFRA_ID}-public-${ZONE_NAME}

    Wavelength Zones サブネットを持つ既存の VPC にクラスターをインストールするためのマシンセットマニフェスト設定の例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      name: <infrastructure_id>-edge-<zone>
      namespace: openshift-machine-api
    spec:
      template:
        spec:
          providerSpec:
            value:
              publicIp: true

3.12.9. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./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 にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
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.12.10. デプロイしたクラスターのステータスの確認

OpenShift Container Platform が AWS Wavelength Zones に正常にデプロイされたことを確認します。

3.12.10.1. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.12.10.2. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。
3.12.10.3. エッジコンピューティングプールで作成されたノードの検証

AWS Wavelength Zones インフラストラクチャーを使用するクラスターをインストールしたら、インストール時に作成したマシンセットマニフェストによって作成されたマシンのステータスを確認します。

  1. install-config.yaml ファイルに追加したサブネットから作成されたマシンセットを確認するには、次のコマンドを実行します。

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                         DESIRED   CURRENT   READY   AVAILABLE   AGE
    cluster-7xw5g-edge-us-east-1-wl1-nyc-wlz-1   1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1a              1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1b              1         1         1       1           3h4m
    cluster-7xw5g-worker-us-east-1c              1         1         1       1           3h4m

  2. マシンセットから作成されたマシンを確認するには、次のコマンドを実行します。

    $ oc get machines -n openshift-machine-api

    出力例

    NAME                                        PHASE     TYPE          REGION      ZONE               AGE
    cluster-7xw5g-edge-us-east-1-wl1-nyc-wlz-1-wbclh  Running   c5d.2xlarge   us-east-1   us-east-1-wl1-nyc-wlz-1  3h
    cluster-7xw5g-master-0                            Running   m6i.xlarge    us-east-1   us-east-1a               3h4m
    cluster-7xw5g-master-1                            Running   m6i.xlarge    us-east-1   us-east-1b               3h4m
    cluster-7xw5g-master-2                            Running   m6i.xlarge    us-east-1   us-east-1c               3h4m
    cluster-7xw5g-worker-us-east-1a-rtp45             Running   m6i.xlarge    us-east-1   us-east-1a               3h
    cluster-7xw5g-worker-us-east-1b-glm7c             Running   m6i.xlarge    us-east-1   us-east-1b               3h
    cluster-7xw5g-worker-us-east-1c-qfvz4             Running   m6i.xlarge    us-east-1   us-east-1c               3h

  3. エッジロールを持つノードを確認するには、次のコマンドを実行します。

    $ oc get nodes -l node-role.kubernetes.io/edge

    出力例

    NAME                           STATUS   ROLES         AGE    VERSION
    ip-10-0-207-188.ec2.internal   Ready    edge,worker   172m   v1.25.2+d2e245f

次のステップ

3.13. AWS VPC クラスターの AWS Outpost への拡張

OpenShift Container Platform バージョン 4.14 では、テクノロジープレビュー機能として、AWS Outposts で実行されているコンピュートノードを使用して、Amazon Web Services (AWS) にクラスターをインストールすることができました。OpenShift Container Platform バージョン 4.15 以降、このインストール方法はサポートされなくなりました。代わりに、AWS 上のクラスターを既存の VPC にインストールし、インストール後の設定タスクとして AWS Outposts にコンピュートノードをプロビジョニングできます。

Amazon Web Services (AWS) 上のクラスターを既存の Amazon Virtual Private Cloud (VPC) にインストール した後、AWS Outposts にコンピュートマシンをデプロイするコンピュートマシンセットを作成できます。AWS Outposts は、低遅延のオンプレミス環境とともに、クラウドベースの AWS デプロイメントの多くの機能を使用できるようにする AWS エッジコンピュートサービスです。詳細は、AWS Outposts のドキュメント を参照してください。

3.13.1. OpenShift Container Platform 上の AWS Outposts の要件と制限

以下の要件と制限に対応するように OpenShift Container Platform クラスターを設定すると、クラウドベースの AWS クラスター上のリソースと同様に AWS Outpost 上のリソースを管理できます。

  • AWS 上の OpenShift Container Platform クラスターを Outpost に拡張するには、クラスターを既存の Amazon Virtual Private Cloud (VPC) にインストールしておく必要があります。
  • Outpost のインフラストラクチャーは、AWS リージョンのアベイラビリティーゾーンに関連付けられており、専用のサブネットを使用します。Outpost にデプロイされた Edge コンピュートマシンは、Outpost のサブネットと、Outpost が関連付けられているアベイラビリティーゾーンを使用する必要があります。
  • AWS Kubernetes クラウドコントローラーマネージャーは、Outpost サブネットを検出すると、Outpost サブネット内にサービスロードバランサーを作成しようとします。AWS Outposts は、サービスロードバランサーの実行をサポートしていません。クラウドコントローラーマネージャーが Outpost サブネットでサポート対象外のサービスを作成しないようにするには、Outpost サブネット設定に kubernetes.io/cluster/unmanaged タグを含める必要があります。この要件は、OpenShift Container Platform バージョン 4.17 における回避策です。詳細は、OCPBUGS-30041 を参照してください。
  • AWS 上の OpenShift Container Platform クラスターには、gp3-csi および gp2-csi ストレージクラスがあります。これらのクラスは、Amazon Elastic Block Store (EBS) の gp3 および gp2 ボリュームに対応します。OpenShift Container Platform クラスターはデフォルトで gp3-csi ストレージクラスを使用しますが、AWS Outposts は EBS gp3 ボリュームをサポートしません。
  • この実装では、node-role.kubernetes.io/outposts taint を使用して、通常のクラスターのワークロードが Outpost ノードに分散するのを防ぎます。Outpost でユーザーのワークロードをスケジュールするには、アプリケーションの Deployment リソースで対応する toleration を指定する必要があります。ユーザーのワークロード用に AWS Outpost インフラストラクチャーを予約すると、互換性を保つためにデフォルトの CSI を gp2-csi に更新するなど、追加の設定要件が回避されます。
  • Outpost にボリュームを作成するには、CSI ドライバーに Outpost の Amazon Resource Name (ARN) が必要です。ドライバーは、CSINode オブジェクトに保存されているトポロジーキーを使用して、Outpost の ARN を特定します。ドライバーが正しいトポロジー値を使用するようにするには、ボリュームバインドモードを WaitForConsumer に設定した上で、作成する新しいストレージクラスに、許可されるトポロジーを設定しないようにする必要があります。
  • AWS VPC クラスターを Outpost に拡張すると、2 種類のコンピューティングリソースが得られます。Outpost にはエッジコンピュートノードがあり、VPC にはクラウドベースのコンピュートノードがあります。クラウドベースの AWS Elastic Block ボリュームは、Outpost エッジコンピュートノードに接続できません。また、Outpost ボリュームはクラウドベースのコンピュートノードに接続できません。

    そのため、CSI スナップショットを使用して、永続ストレージを使用するアプリケーションをクラウドベースのコンピュートノードからエッジコンピュートノードに移行したり、元の永続ボリュームを直接使用したりすることはできません。アプリケーションの永続ストレージデータを移行するには、手動でバックアップおよび復元操作を実行する必要があります。

  • AWS Outposts は、AWS Network Load Balancer または AWS Classic Load Balancer をサポートしていません。AWS Outposts 環境でエッジコンピュートリソースの負荷分散を有効にするには、AWS Application Load Balancer を使用する必要があります。

    Application Load Balancer をプロビジョニングするには、Ingress リソースを使用し、AWS Load Balancer Operator をインストールする必要があります。クラスターに、ワークロードを共有するエッジベースとクラウドベースの両方のコンピュートインスタンスが含まれている場合は、追加の設定が必要です。

    詳細は、「Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用」を参照してください。

3.13.2. 環境に関する情報の取得

AWS VPC クラスターを Outpost に拡張するには、OpenShift Container Platform クラスターと Outpost 環境に関する情報を提供する必要があります。この情報を使用して、ネットワーク設定タスクを完了し、Outpost 内にコンピュートマシンを作成するコンピュートマシンセットを設定します。必要な詳細情報は、コマンドラインツールを使用して収集できます。

3.13.2.1. OpenShift Container Platform クラスターからの情報の取得

OpenShift CLI (oc) を使用して、OpenShift Container Platform クラスターから情報を取得できます。

ヒント

これらの値の一部またはすべてを、export コマンドを使用して環境変数として保存すると便利な場合があります。

前提条件

  • OpenShift Container Platform クラスターを AWS のカスタム VPC にインストールしている。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、クラスターのインフラストラクチャー ID をリスト表示します。この値を保存しておきます。

    $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructures.config.openshift.io cluster
  2. 次のコマンドを実行して、インストールプログラムが作成したコンピュートマシンセットに関する詳細を取得します。

    1. クラスター上のコンピュートマシンセットをリスト表示します。

      $ oc get machinesets.machine.openshift.io -n openshift-machine-api

      出力例

      NAME                           DESIRED   CURRENT   READY   AVAILABLE   AGE
      <compute_machine_set_name_1>   1         1         1       1           55m
      <compute_machine_set_name_2>   1         1         1       1           55m

    2. リストされたコンピュートマシンセットのいずれかの Amazon Machine Image (AMI) ID を表示します。この値を保存しておきます。

      $ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \
        -n openshift-machine-api \
        -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}'
    3. AWS VPC クラスターのサブネット ID を表示します。この値を保存しておきます。

      $ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \
        -n openshift-machine-api \
        -o jsonpath='{.spec.template.spec.providerSpec.value.subnet.id}'
3.13.2.2. AWS アカウントからの情報の取得

AWS CLI (aws) を使用して、AWS アカウントから情報を取得できます。

ヒント

これらの値の一部またはすべてを、export コマンドを使用して環境変数として保存すると便利な場合があります。

前提条件

  • 必要なハードウェアのセットアップが完了した AWS Outposts サイトがある。
  • Outpost が AWS アカウントに接続されている。
  • 必要なタスクを実行する権限を持つユーザーとして AWS CLI (aws) を使用して、AWS アカウントにアクセスできる。

手順

  1. 次のコマンドを実行して、AWS アカウントに接続されている Outpost をリスト表示します。

    $ aws outposts list-outposts
  2. aws outposts list-outposts コマンドの出力の次の値を保存しておきます。

    • Outpost ID
    • Outpost の Amazon Resource Name (ARN)
    • Outpost のアベイラビリティーゾーン

      注記

      aws outposts list-outposts コマンドの出力には、アベイラビリティーゾーンに関連する 2 つの値、AvailabilityZoneAvailabilityZoneId が含まれています。Outpost 内にコンピュートマシンを作成するコンピュートマシンセットを設定するには、AvailablilityZone 値を使用します。

  3. Outpost ID の値を使用して次のコマンドを実行し、Outpost で利用可能なインスタンスタイプを表示します。利用可能なインスタンスタイプの値を保存しておきます。

    $ aws outposts get-outpost-instance-types \
      --outpost-id <outpost_id_value>
  4. Outpost ARN の値を使用して次のコマンドを実行し、Outpost のサブネット ID を表示します。この値を保存しておきます。

    $ aws ec2 describe-subnets \
      --filters Name=outpost-arn,Values=<outpost_arn_value>

3.13.3. Outpost のネットワークの設定

VPC クラスターを Outpost に拡張するには、次のネットワーク設定タスクを完了する必要があります。

  • クラスターネットワークの MTU を変更します。
  • Outpost にサブネットを作成します。
3.13.3.1. AWS Outposts をサポートするためのクラスターネットワーク MTU の変更

クラスターネットワークの最大伝送単位 (MTU) は、インストール中に、クラスター内のノードのプライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。場合によっては、AWS Outposts サブネットをサポートするために、クラスターネットワークの MTU 値を減らす必要があります。

重要

移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。

サービス中断に関する重要な考慮事項など、移行プロセスの詳細は、この手順の関連情報の「クラスターネットワークの MTU 変更」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • クラスターのターゲット MTU を特定している。OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から 100 を引いた値に設定する必要があります。

手順

  1. クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

    $ oc describe network.config cluster

    出力例

    ...
    Status:
      Cluster Network:
        Cidr:               10.217.0.0/22
        Host Prefix:        23
      Cluster Network MTU:  1400
      Network Type:         OVNKubernetes
      Service Network:
        10.217.4.0/23
    ...

  2. MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'

    ここでは、以下のようになります。

    <overlay_from>
    現在のクラスターネットワークの MTU 値を指定します。
    <overlay_to>
    クラスターネットワークのターゲット MTU を指定します。この値は、<machine_to> の値を基準にして設定します。OVN-Kubernetes の場合、この値は <machine_to> の値から 100 を引いた値である必要があります。
    <machine_to>
    基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。

    クラスターの MTU を減らす例

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 1000 } , "machine": { "to" : 1100} } } } }'

  3. Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get machineconfigpools

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

    注記

    Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。

  4. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

    2. 以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    3. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      ここで、<config_name>machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。

      マシン設定には、systemd 設定に以下の更新を含める必要があります。

      ExecStart=/usr/local/bin/mtu-migration.sh
  5. MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

    ここでは、以下のようになります。

    <mtu>
    <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。
  6. MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get machineconfigpools

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

検証

  • 次のコマンドを入力して、クラスター内のノードが指定した MTU を使用していることを確認します。

    $ oc describe network.config cluster
3.13.3.2. AWS エッジコンピュートサービス用のサブネットの作成

OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、AWS Outposts にサブネットを作成する必要があります。

このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • OpenShift Container Platform クラスター、Outpost、および AWS アカウントから環境に関する必要な情報を取得している。

手順

  1. このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \2
      --parameters \
        ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3
        ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4
        ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5
        ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6
        ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7
        ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8
        ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" \9
        ParameterKey=PrivateSubnetLabel,ParameterValue="private-outpost" \
        ParameterKey=PublicSubnetLabel,ParameterValue="public-outpost" \
        ParameterKey=OutpostArn,ParameterValue="${OUTPOST_ARN}" 10
    1
    <stack_name> は、CloudFormation スタックの名前です (cluster-<outpost_name> など)。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    ${VPC_ID} は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値 VpcID です。
    4
    ${CLUSTER_NAME} は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。
    5
    ${ZONE_NAME} は、サブネットを作成する AWS Outposts 名の値です。
    6
    ${ROUTE_TABLE_PUB} は、Outpost 上のパブリックサブネットを関連付けるために使用する、${VPC_ID} に作成されたパブリックルートテーブル ID です。このスタックによって作成された Outpost サブネットを関連付けるパブリックルートテーブルを指定します。
    7
    ${SUBNET_CIDR_PUB} は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。
    8
    ${ROUTE_TABLE_PVT} は、Outpost 上のプライベートサブネットを関連付けるために使用する、${VPC_ID} に作成されたプライベートルートテーブル ID です。このスタックによって作成された Outpost サブネットを関連付けるプライベートルートテーブルを指定します。
    9
    ${SUBNET_CIDR_PVT} は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。
    10
    ${OUTPOST_ARN} は、Outpost の Amazon Resource Name (ARN) です。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f

検証

  • 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。

    PublicSubnetId

    CloudFormation スタックによって作成されたパブリックサブネットの ID。

    PrivateSubnetId

    CloudFormation スタックによって作成されたプライベートサブネットの ID。

    これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

3.13.3.3. VPC サブネット用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、Outpost サブネットをデプロイできます。

例3.38 VPC サブネット用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice Subnets (Public and Private)

Parameters:
  VpcId:
    Description: VPC ID that comprises all the target subnets.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster name or prefix name to prepend the Name tag for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.
  ZoneName:
    Description: Zone Name to create the subnets, such as us-west-2-lax-1a.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ZoneName parameter must be specified.
  PublicRouteTableId:
    Description: Public Route Table ID to associate the public subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PublicRouteTableId parameter must be specified.
  PublicSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for public subnet.
    Type: String
  PrivateRouteTableId:
    Description: Private Route Table ID to associate the private subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PrivateRouteTableId parameter must be specified.
  PrivateSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for private subnet.
    Type: String
  PrivateSubnetLabel:
    Default: "private"
    Description: Subnet label to be added when building the subnet name.
    Type: String
  PublicSubnetLabel:
    Default: "public"
    Description: Subnet label to be added when building the subnet name.
    Type: String
  OutpostArn:
    Default: ""
    Description: OutpostArn when creating subnets on AWS Outpost.
    Type: String

Conditions:
  OutpostEnabled: !Not [!Equals [!Ref "OutpostArn", ""]]

Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"]
      Tags:
      - Key: Name
        Value: !Join ['-', [ !Ref ClusterName, !Ref PublicSubnetLabel, !Ref ZoneName]]
      - Key: kubernetes.io/cluster/unmanaged 1
        Value: true

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PrivateSubnetCidr
      AvailabilityZone: !Ref ZoneName
      OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"]
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, !Ref PrivateSubnetLabel, !Ref ZoneName]]
      - Key: kubernetes.io/cluster/unmanaged 2
        Value: true

  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTableId

Outputs:
  PublicSubnetId:
    Description: Subnet ID of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

  PrivateSubnetId:
    Description: Subnet ID of the private subnets.
    Value:
      !Join ["", [!Ref PrivateSubnet]]
1
AWS Outposts のパブリックサブネット設定に kubernetes.io/cluster/unmanaged タグを含める必要があります。
2
AWS Outposts のプライベートサブネット設定に kubernetes.io/cluster/unmanaged タグを含める必要があります。

3.13.4. Outpost にエッジコンピュートマシンをデプロイするコンピュートマシンセットの作成

AWS Outposts でエッジコンピュートマシンを作成するには、互換性のある設定を使用して新しいコンピュートマシンセットを作成する必要があります。

前提条件

  • AWS Outposts サイトがある。
  • OpenShift Container Platform クラスターを AWS のカスタム VPC にインストールしている。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。

    $ oc get machinesets.machine.openshift.io -n openshift-machine-api

    出力例

    NAME                            DESIRED   CURRENT   READY   AVAILABLE   AGE
    <original_machine_set_name_1>   1         1         1       1           55m
    <original_machine_set_name_2>   1         1         1       1           55m

  2. 既存のコンピュートマシンセットの名前を記録します。
  3. 次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (CR) の値を含む YAML ファイルを作成します。

    • 次のコマンドを実行して、既存のコンピュートマシンセット設定を新しいファイルにコピーします。

      $ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \
        -n openshift-machine-api -o yaml > <new_machine_set_name_1>.yaml

      この YAML ファイルは、任意のテキストエディターで編集できます。

    • 任意のテキストエディターを使用して <new_machine_set_name_1>.yaml という名前の空の YAML ファイルを作成し、新しいコンピュートマシンセットに必要な値を含めます。

      特定のフィールドに設定する値がわからない場合は、次のコマンドを実行して、既存のコンピュートマシンセット CR の値を確認できます。

      $ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \
        -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role>-<availability_zone> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone>
          spec:
            providerSpec: 3
      # ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。AWS Outposts の場合は、outposts ロールを使用します。
      3
      省略されている providerSpec セクションには、Outpost 用に設定する必要がある値が含まれています。
  4. <new_machine_set_name_1>.yaml ファイルを編集して、Outpost にエッジコンピュートマシンを作成するように新しいコンピュートマシンセットを設定します。

    AWS Outposts 用のコンピュートマシンセットの例

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
      name: <infrastructure_id>-outposts-<availability_zone> 2
      namespace: openshift-machine-api
    spec:
      replicas: 1
      selector:
        matchLabels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id>
          machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone>
      template:
        metadata:
          labels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machine-role: outposts
            machine.openshift.io/cluster-api-machine-type: outposts
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone>
        spec:
          metadata:
            labels:
              node-role.kubernetes.io/outposts: ""
              location: outposts
          providerSpec:
            value:
              ami:
                id: <ami_id> 3
              apiVersion: machine.openshift.io/v1beta1
              blockDevices:
                - ebs:
                    volumeSize: 120
                    volumeType: gp2 4
              credentialsSecret:
                name: aws-cloud-credentials
              deviceIndex: 0
              iamInstanceProfile:
                id: <infrastructure_id>-worker-profile
              instanceType: m5.xlarge 5
              kind: AWSMachineProviderConfig
              placement:
                availabilityZone: <availability_zone>
                region: <region> 6
              securityGroups:
                - filters:
                  - name: tag:Name
                    values:
                      - <infrastructure_id>-worker-sg
              subnet:
                id: <subnet_id> 7
              tags:
                - name: kubernetes.io/cluster/<infrastructure_id>
                  value: owned
              userDataSecret:
                name: worker-user-data
          taints: 8
            - key: node-role.kubernetes.io/outposts
              effect: NoSchedule

    1
    クラスターインフラストラクチャー ID を指定します。
    2
    コンピュートマシンセットの名前を指定します。この名前は、クラスターインフラストラクチャー ID、outposts ロール名、および Outpost のアベイラビリティーゾーンで構成されます。
    3
    Amazon Machine Image (AMI) ID を指定します。
    4
    EBS ボリュームのタイプを指定します。AWS Outposts には gp2 ボリュームが必要です。
    5
    AWS インスタンスのタイプを指定します。Outpost で設定されているインスタンスタイプを使用する必要があります。
    6
    Outpost のアベイラビリティーゾーンが存在する AWS リージョンを指定します。
    7
    Outpost の専用サブネットを指定します。
    8
    node-role.kubernetes.io/outposts ラベルを持つノードでワークロードがスケジュールされないように taint を指定します。Outpost でユーザーのワークロードをスケジュールするには、アプリケーションの Deployment リソースで対応する toleration を指定する必要があります。
  5. 変更を保存します。
  6. 次のコマンドを実行して、コンピュートマシンセット CR を作成します。

    $ oc create -f <new_machine_set_name_1>.yaml

検証

  • コンピュートマシンセットが作成されたことを確認するには、次のコマンドを実行してクラスター内のコンピュートマシンセットをリスト表示します。

    $ oc get machinesets.machine.openshift.io -n openshift-machine-api

    出力例

    NAME                            DESIRED   CURRENT   READY   AVAILABLE   AGE
    <new_machine_set_name_1>        1         1         1       1           4m12s
    <original_machine_set_name_1>   1         1         1       1           55m
    <original_machine_set_name_2>   1         1         1       1           55m

  • 新しいコンピュートマシンセットによって管理されるマシンをリスト表示するには、次のコマンドを実行します。

    $ oc get -n openshift-machine-api machines.machine.openshift.io \
      -l machine.openshift.io/cluster-api-machineset=<new_machine_set_name_1>

    出力例

    NAME                             PHASE          TYPE        REGION      ZONE         AGE
    <machine_from_new_1>             Provisioned    m5.xlarge   us-east-1   us-east-1a   25s
    <machine_from_new_2>             Provisioning   m5.xlarge   us-east-1   us-east-1a   25s

  • 新しいコンピューティングマシンセットによって作成されたマシンの設定が正しいことを確認するには、次のコマンドを実行して、いずれかの新しいマシンの CR に含まれる関連フィールドを調べます。

    $ oc describe machine <machine_from_new_1> -n openshift-machine-api

3.13.5. Outpost でのユーザーワークロードの作成

AWS VPC クラスター内の OpenShift Container Platform を Outpost に拡張した後、ラベル node-role.kubernetes.io/outposts を持つエッジコンピュートノードを使用して、Outpost にユーザーワークロードを作成できます。

前提条件

  • AWS VPC クラスターを Outpost に拡張した。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Outpost 環境と互換性のあるエッジコンピュートマシンをデプロイするコンピュートマシンセットを作成している。

手順

  1. エッジサブネットのエッジコンピュートノードにデプロイするアプリケーションの Deployment リソースファイルを設定します。

    Deployment マニフェストの例

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <application_name> 1
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: <application_name>
      namespace: <application_namespace> 2
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: gp2-csi 3
      volumeMode: Filesystem
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <application_name>
      namespace: <application_namespace>
    spec:
      selector:
        matchLabels:
          app: <application_name>
      replicas: 1
      template:
        metadata:
          labels:
            app: <application_name>
            location: outposts 4
        spec:
          securityContext:
            seccompProfile:
              type: RuntimeDefault
          nodeSelector: 5
            node-role.kubernetes.io/outpost: ''
          tolerations: 6
          - key: "node-role.kubernetes.io/outposts"
            operator: "Equal"
            value: ""
            effect: "NoSchedule"
          containers:
            - image: openshift/origin-node
              command:
               - "/bin/socat"
              args:
                - TCP4-LISTEN:8080,reuseaddr,fork
                - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
              imagePullPolicy: Always
              name: <application_name>
              ports:
                - containerPort: 8080
              volumeMounts:
                - mountPath: "/mnt/storage"
                  name: data
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: <application_name>

    1
    アプリケーションの名前を指定します。
    2
    アプリケーションの namespace を指定します。アプリケーションの namespace はアプリケーション名と同じにすることができます。
    3
    ストレージクラス名を指定します。エッジコンピュート設定の場合は、gp2-csi ストレージクラスを使用する必要があります。
    4
    Outpost にデプロイされるワークロードを識別するラベルを指定します。
    5
    エッジコンピュートノードをターゲットとするノードセレクターラベルを指定します。
    6
    エッジコンピュートマシンのコンピュートマシンセット内の key および effects taint に一致する toleration を指定します。この例のように valueoperator の toleration を設定します。
  2. 次のコマンドを実行して、Deployment リソースを作成します。

    $ oc create -f <application_deployment>.yaml
  3. ターゲットのエッジコンピュートノードからエッジネットワーク内で実行されるサービスに Pod を公開する Service オブジェクトを設定します。

    Service マニフェストの例

    apiVersion: v1
    kind: Service 1
    metadata:
      name:  <application_name>
      namespace: <application_namespace>
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector: 2
        app: <application_name>

    1
    service リソースを定義します。
    2
    管理対象の Pod に適用するラベルのタイプを指定します。
  4. 次のコマンドを実行して Service CR を作成します。

    $ oc create -f <application_service>.yaml

3.13.6. エッジおよびクラウドベースの AWS コンピューティングリソースでワークロードをスケジュールする

AWS VPC クラスターを Outpost に拡張すると、Outpost はエッジコンピュートノードを使用し、VPC はクラウドベースのコンピュートノードを使用します。Outpost に拡張された AWS VPC クラスターには、ロードバランサーに関する次の考慮事項が適用されます。

  • Outpost は AWS Network Load Balancer または AWS Classic Load Balancer を実行できませんが、Outpost に拡張された VPC クラスターの Classic Load Balancer は Outpost エッジコンピュートノードに接続できます。詳細は、Outpost に拡張された AWS VPC クラスターでの AWS Classic Load Balancer の使用 を参照してください。
  • Outpost インスタンスでロードバランサーを実行するには、AWS Application Load Balancer を使用する必要があります。AWS Load Balancer Operator を使用すると、AWS Load Balancer コントローラーのインスタンスをデプロイできます。このコントローラーは、Kubernetes Ingress リソース用の AWS Application Load Balancer をプロビジョニングします。詳細は、Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用 を参照してください。
3.13.6.1. Outpost に拡張された AWS VPC クラスターでの AWS Classic Load Balancer の使用

AWS Outposts インフラストラクチャーは、AWS Classic Load Balancer を実行できませんが、AWS VPC クラスターの Classic Load Balancer は、エッジおよびクラウドベースのサブネットが同じアベイラビリティーゾーンにある場合、Outpost のエッジコンピュートノードをターゲットにすることができます。そのため、VPC クラスター上の Classic Load Balancer は、これらのノードタイプのどちらかに Pod をスケジュールする可能性があります。

エッジコンピュートノードおよびクラウドベースのコンピュートノードでワークロードをスケジュールすると、遅延が発生する可能性があります。VPC クラスター内の Classic Load Balancer が Outpost のエッジコンピュートノードをターゲットにするのを防ぐ場合は、クラウドベースのコンピュートノードにラベルを適用し、適用されたラベルを持つノードにのみスケジュールするように Classic Load Balancer を設定できます。

注記

VPC クラスター内の Classic Load Balancer が Outpost エッジコンピュートノードをターゲットにしても問題ない場合、これらの手順を完了する必要はありません。

前提条件

  • AWS VPC クラスターを Outpost に拡張した。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • エッジコンピュートマシンの taint に一致する toleration を持つユーザーワークロードを Outpost に作成している。

手順

  1. オプション: 次のコマンドを実行し、出力に Outpost 内のエッジコンピュートノードのみが含まれていることを確認して、エッジコンピュートノードに location=outposts ラベルがあることを確認します。

    $ oc get nodes -l location=outposts
  2. 次のコマンドを実行して、VPC クラスター内のクラウドベースのコンピュートノードにキーと値のペアのラベルを付けます。

    $ for NODE in $(oc get node -l node-role.kubernetes.io/worker --no-headers | grep -v outposts | awk '{print$1}'); do oc label node $NODE <key_name>=<value>; done

    <key_name>=<value> は、クラウドベースのコンピュートノードを識別するために使用するラベルです。

    出力例

    node1.example.com labeled
    node2.example.com labeled
    node3.example.com labeled

  3. オプション: 次のコマンドを実行し、出力に VPC クラスター内のすべてのクラウドベースのコンピュートノードが含まれていることを確認して、クラウドベースのコンピュートノードに指定したラベルがあることを確認します。

    $ oc get nodes -l <key_name>=<value>

    出力例

    NAME                   STATUS    ROLES     AGE       VERSION
    node1.example.com      Ready     worker    7h        v1.30.3
    node2.example.com      Ready     worker    7h        v1.30.3
    node3.example.com      Ready     worker    7h        v1.30.3

  4. クラウドベースのサブネットの情報を Service マニフェストの annotations フィールドに追加して、Classic Load Balancer サービスを設定します。

    サービス設定の例

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: <application_name>
      name: <application_name>
      namespace: <application_namespace>
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-subnets: <aws_subnet> 1
        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: <key_name>=<value> 2
    spec:
      ports:
      - name: http
        port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        app: <application_name>
      type: LoadBalancer

    1
    AWS VPC クラスターのサブネット ID を指定します。
    2
    ノードラベルのペアと一致するキーと値のペアを指定します。
  5. 次のコマンドを実行して Service CR を作成します。

    $ oc create -f <file_name>.yaml

検証

  1. 次のコマンドを実行して、service リソースのステータスを確認して、プロビジョニングされた Classic Load Balancer のホストを表示します。

    $ HOST=$(oc get service <application_name> -n <application_namespace> --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
  2. 次のコマンドを実行して、プロビジョニングされた Classic Load Balancer ホストのステータスを確認します。

    $ curl $HOST
  3. AWS コンソールで、ラベル付きインスタンスのみがロードバランサーのターゲットインスタンスとして表示されることを確認します。
3.13.6.2. Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用

Outpost に拡張された AWS VPC クラスター内で AWS Application Load Balancer をプロビジョニングするように AWS Load Balancer Operator を設定できます。AWS Outposts は AWS Network Load Balancer をサポートしていません。そのため、AWS Load Balancer Operator は Outpost に Network Load Balancer をプロビジョニングできません。

AWS Application Load Balancer は、クラウドサブネットか Outpost サブネットのどちらかに作成できます。クラウドの Application Load Balancer はクラウドベースのコンピュートノードに接続でき、Outpost の Application Load Balancer はエッジコンピュートノードに接続できます。Ingress リソースには Outpost サブネットまたは VPC サブネットのアノテーションを付ける必要がありますが、両方を付けることはできません。

前提条件

  • AWS VPC クラスターを Outpost に拡張した。
  • OpenShift CLI (oc) がインストールされている。
  • AWS Load Balancer Operator をインストールし、AWS Load Balancer Controller を作成した。

手順

  • 指定のサブネットを使用するように Ingress リソースを設定します。

    Ingress リソース設定の例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <application_name>
      annotations:
        alb.ingress.kubernetes.io/subnets: <subnet_id> 1
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <application_name>
                    port:
                      number: 80

    1
    使用するサブネットを指定します。
    • Outpost で Application Load Balancer を使用するには、Outpost のサブネット ID を指定します。
    • クラウドで Application Load Balancer を使用するには、別々のアベイラビリティーゾーンに少なくとも 2 つのサブネットを指定する必要があります。

3.13.7. 関連情報

3.14. マルチアーキテクチャーコンピュートマシンの設定をサポートするクラスターのインストール

マルチアーキテクチャーコンピュートマシンを備えた OpenShift Container Platform クラスターは、さまざまなアーキテクチャーのコンピュートマシンをサポートします。

注記

クラスター内に複数のアーキテクチャーを持つノードがある場合、イメージのアーキテクチャーはノードのアーキテクチャーと一致している必要があります。Pod が適切なアーキテクチャーを持つノードに割り当てられていること、およびそれがイメージアーキテクチャーと一致していることを確認する必要があります。Pod をノードに割り当てる方法の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターでのワークロードのスケジュール設定 を参照してください。

マルチアーキテクチャーコンピュートマシンの設定をサポートする Amazon Web Services (AWS) クラスターをインストールできます。クラスターをインストールした後、次の方法でマルチアーキテクチャーコンピュートマシンをクラスターに追加できます。

  • 64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに 64 ビット x86 コンピュートマシンを追加します。この場合、64 ビット x86 がセカンダリーアーキテクチャーと見なされます。
  • 64 ビット x86 コントロールプレーンマシンを使用し、すでに 64 ビット x86 コンピュートマシンが含まれているクラスターに 64 ビット ARM コンピュートマシンを追加します。この場合、64 ビット ARM がセカンダリーアーキテクチャーと見なされます。
注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig カスタムリソースをデプロイすることを推奨します。詳細は、「Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する」を参照してください。

3.14.1. マルチアーキテクチャーをサポートするクラスターのインストール

マルチアーキテクチャーコンピュートマシンの設定をサポートするクラスターをインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • OpenShift Container Platform インストールプログラムがある。
  • クラスターのプルシークレットをダウンロードしている。

手順

  1. 次のコマンドを実行して、openshift-install バイナリーがmulti ペイロードを使用していることを確認します。

    $ ./openshift-install version

    出力例

    ./openshift-install 4.17.0
    built from commit abc123etc
    release image quay.io/openshift-release-dev/ocp-release@sha256:abc123wxyzetc
    release architecture multi
    default architecture amd64

    openshift-install バイナリーが multi ペイロードを使用していることを示すには、出力に release architecture multi を含める必要があります。

  2. install-config.yaml ファイルを更新して、ノードのアーキテクチャーを設定します。

    マルチアーキテクチャー設定の install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.openshift.com
    compute:
    - architecture: amd64 1
      hyperthreading: Enabled
      name: worker
      platform: {}
      replicas: 3
    controlPlane:
      architecture: arm64 2
      name: master
      platform: {}
      replicas: 3
    # ...

    1
    ワーカーノードのアーキテクチャーを指定します。このフィールドは arm64 または amd64 のいずれかに設定できます。
    2
    コントロールプレーンノードのアーキテクチャーを指定します。このフィールドは arm64 または amd64 のいずれかに設定できます。

次のステップ

第4章 user-provisioned infrastructure

4.1. AWS にクラスターをインストールする準備

以下の手順を実行して、AWS に OpenShift Container Platform クラスターをインストールする準備をします。

4.1.1. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.17 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしないと、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

4.1.2. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

4.1.3. OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.17 のすべてのコマンドを実行することはできません。新しいバージョンの oc をダウンロードしてインストールしてください。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.17 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

4.1.4. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

4.1.5. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.17 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

4.2. AWS 上の user-provisioned infrastructure のインストール要件

プロビジョニングしたインフラストラクチャーへのインストールを開始する前に、AWS 環境が次のインストール要件を満たしていることを確認してください。

user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。

4.2.1. クラスターのインストールに必要なマシン

最小の OpenShift Container Platform クラスターでは以下のホストが必要です。

表4.1 最低限必要なホスト
ホスト説明

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) 8.6 から選択できます。

RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。

4.2.1.1. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表4.2 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHCOS

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 以降 [3]

2

8 GB

100 GB

300

  1. 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
  2. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  3. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

4.2.1.2. AWS のテスト済みインスタンスタイプ

以下の Amazon Web Services (AWS) インスタンスタイプは OpenShift Container Platform でテストされています。

注記

AWS インスタンスには、次の表に記載されているマシンタイプを使用してください。表に記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」セクションに記載されている最小リソース要件と一致していることを確認してください。

例4.1 64 ビット x86 アーキテクチャーに基づくマシンタイプ

  • c4.*
  • c5.*
  • c5a.*
  • i3.*
  • m4.*
  • m5.*
  • m5a.*
  • m6a.*
  • m6i.*
  • r4.*
  • r5.*
  • r5a.*
  • r6i.*
  • t3.*
  • t3a.*
4.2.1.3. 64 ビット ARM インフラストラクチャー上の AWS のテスト済みインスタンスタイプ

次の Amazon Web Services (AWS) 64 ビット ARM インスタンスタイプは、OpenShift Container Platform でテストされています。

注記

AWS ARM インスタンスには、次のチャートに含まれるマシンタイプを使用してください。チャートに記載されていないインスタンスタイプを使用する場合は、使用するインスタンスサイズが、「クラスターインストールの最小リソース要件」に記載されている最小リソース要件と一致していることを確認してください。

例4.2 64 ビット ARM アーキテクチャーに基づくマシンタイプ

  • c6g.*
  • c7g.*
  • m6g.*
  • m7g.*
  • r8g.*

4.2.2. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

4.2.3. 必要な AWS インフラストラクチャーコンポーネント

OpenShift Container Platform を Amazon Web Services (AWS) の user-provisioned infrastructure にインストールするには、マシンとサポートするインフラストラクチャーの両方を手動で作成する必要があります。

各種プラットフォームの統合テストに関する詳細は、OpenShift Container Platform 4.x のテスト済みインテグレーション のページを参照してください。

提供される CloudFormation テンプレートを使用すると、以下のコンポーネントを表す AWS リソースのスタックを作成できます。

  • AWS Virtual Private Cloud (VPC)
  • ネットワークおよび負荷分散コンポーネント
  • セキュリティーグループおよびロール
  • OpenShift Container Platform ブートストラップノード
  • OpenShift Container Platform コントロールプレーンノード
  • OpenShift Container Platform コンピュートノード

または、コンポーネントを手動で作成するか、クラスターの要件を満たす既存のインフラストラクチャーを再利用できます。コンポーネントの相互関係の詳細は、CloudFormation テンプレートを参照してください。

4.2.3.1. 他のインフラストラクチャーコンポーネント
  • 1 つの VPC
  • DNS エントリー
  • ロードバランサー (classic または network) およびリスナー
  • パブリックおよびプライベート Route 53 ゾーン
  • セキュリティーグループ
  • IAM ロール
  • S3 バケット

非接続環境で作業している場合、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 アベイラビリティーゾーンのプライベートサブネットを作成できます。プライベートサブネットを使用できる場合は、それらの適切なルートおよびテーブルを指定する必要があります。

必要な DNS および負荷分散コンポーネント

DNS およびロードバランサー設定では、パブリックホストゾーンを使用する必要があり、クラスターのインフラストラクチャーをプロビジョニングする場合にインストールプログラムが使用するものと同様のプライベートホストゾーンを使用できます。ロードバランサーに解決する DNS エントリーを作成する必要があります。api.<cluster_name>.<domain> のエントリーは外部ロードバランサーを参照し、api-int.<cluster_name>.<domain> のエントリーは内部ロードバランサーを参照する必要があります。

またクラスターには、Kubernetes API とその拡張に必要なポート 6443、および新規マシンの Ignition 設定ファイルに必要なポート 22623 のロードバランサーおよびリスナーが必要です。ターゲットはコントロールプレーンノードになります。ポート 6443 はクラスター外のクライアントとクラスター内のノードからもアクセスできる必要があります。ポート 22623 はクラスター内のノードからアクセスできる必要があります。

コンポーネントAWS タイプ説明

DNS

AWS::Route53::HostedZone

内部 DNS のホストゾーン。

パブリックロードバランサー

AWS::ElasticLoadBalancingV2::LoadBalancer

パブリックサブネットのロードバランサー。

外部 API サーバーレコード

AWS::Route53::RecordSetGroup

外部 API サーバーのエイリアスレコード。

外部リスナー

AWS::ElasticLoadBalancingV2::Listener

外部ロードバランサー用のポート 6443 のリスナー。

外部ターゲットグループ

AWS::ElasticLoadBalancingV2::TargetGroup

外部ロードバランサーのターゲットグループ。

プライベートロードバランサー

AWS::ElasticLoadBalancingV2::LoadBalancer

プライベートサブネットのロードバランサー。

内部 API サーバーレコード

AWS::Route53::RecordSetGroup

内部 API サーバーのエイリアスレコード。

内部リスナー

AWS::ElasticLoadBalancingV2::Listener

内部ロードバランサー用のポート 22623 のリスナー。

内部ターゲットグループ

AWS::ElasticLoadBalancingV2::TargetGroup

内部ロードバランサーのターゲットグループ。

内部リスナー

AWS::ElasticLoadBalancingV2::Listener

内部ロードバランサーのポート 6443 のリスナー。

内部ターゲットグループ

AWS::ElasticLoadBalancingV2::TargetGroup

内部ロードバランサーのターゲットグループ。

セキュリティーグループ

コントロールプレーンおよびワーカーマシンには、以下のポートへのアクセスが必要です。

グループIP プロトコルポート範囲

MasterSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

tcp

6443

tcp

22623

WorkerSecurityGroup

AWS::EC2::SecurityGroup

icmp

0

tcp

22

BootstrapSecurityGroup

AWS::EC2::SecurityGroup

tcp

22

tcp

19531

コントロールプレーンの Ingress

コントロールプレーンマシンには、以下の Ingress グループが必要です。それぞれの Ingress グループは AWS::EC2::SecurityGroupIngress リソースになります。

Ingress グループ説明IP プロトコルポート範囲

MasterIngressEtcd

etcd

tcp

2379- 2380

MasterIngressVxlan

Vxlan パケット

udp

4789

MasterIngressWorkerVxlan

Vxlan パケット

udp

4789

MasterIngressInternal

内部クラスター通信および Kubernetes プロキシーメトリック

tcp

9000 - 9999

MasterIngressWorkerInternal

内部クラスター通信

tcp

9000 - 9999

MasterIngressKube

Kubernetes kubelet、スケジューラーおよびコントローラーマネージャー

tcp

10250 - 10259

MasterIngressWorkerKube

Kubernetes kubelet、スケジューラーおよびコントローラーマネージャー

tcp

10250 - 10259

MasterIngressIngressServices

Kubernetes Ingress サービス

tcp

30000 - 32767

MasterIngressWorkerIngressServices

Kubernetes Ingress サービス

tcp

30000 - 32767

MasterIngressGeneve

Geneve パケット

udp

6081

MasterIngressWorkerGeneve

Geneve パケット

udp

6081

MasterIngressIpsecIke

IPsec IKE パケット

udp

500

MasterIngressWorkerIpsecIke

IPsec IKE パケット

udp

500

MasterIngressIpsecNat

IPsec NAT-T パケット

udp

4500

MasterIngressWorkerIpsecNat

IPsec NAT-T パケット

udp

4500

MasterIngressIpsecEsp

IPsec ESP パケット

50

All

MasterIngressWorkerIpsecEsp

IPsec ESP パケット

50

All

MasterIngressInternalUDP

内部クラスター通信

udp

9000 - 9999

MasterIngressWorkerInternalUDP

内部クラスター通信

udp

9000 - 9999

MasterIngressIngressServicesUDP

Kubernetes Ingress サービス

udp

30000 - 32767

MasterIngressWorkerIngressServicesUDP

Kubernetes Ingress サービス

udp

30000 - 32767

ワーカーの Ingress

ワーカーマシンには、以下の Ingress グループが必要です。それぞれの Ingress グループは AWS::EC2::SecurityGroupIngress リソースになります。

Ingress グループ説明IP プロトコルポート範囲

WorkerIngressVxlan

Vxlan パケット

udp

4789

WorkerIngressWorkerVxlan

Vxlan パケット

udp

4789

WorkerIngressInternal

内部クラスター通信

tcp

9000 - 9999

WorkerIngressWorkerInternal

内部クラスター通信

tcp

9000 - 9999

WorkerIngressKube

Kubernetes kubelet、スケジューラーおよびコントローラーマネージャー

tcp

10250

WorkerIngressWorkerKube

Kubernetes kubelet、スケジューラーおよびコントローラーマネージャー

tcp

10250

WorkerIngressIngressServices

Kubernetes Ingress サービス

tcp

30000 - 32767

WorkerIngressWorkerIngressServices

Kubernetes Ingress サービス

tcp

30000 - 32767

WorkerIngressGeneve

Geneve パケット

udp

6081

WorkerIngressMasterGeneve

Geneve パケット

udp

6081

WorkerIngressIpsecIke

IPsec IKE パケット

udp

500

WorkerIngressMasterIpsecIke

IPsec IKE パケット

udp

500

WorkerIngressIpsecNat

IPsec NAT-T パケット

udp

4500

WorkerIngressMasterIpsecNat

IPsec NAT-T パケット

udp

4500

WorkerIngressIpsecEsp

IPsec ESP パケット

50

All

WorkerIngressMasterIpsecEsp

IPsec ESP パケット

50

All

WorkerIngressInternalUDP

内部クラスター通信

udp

9000 - 9999

WorkerIngressMasterInternalUDP

内部クラスター通信

udp

9000 - 9999

WorkerIngressIngressServicesUDP

Kubernetes Ingress サービス

udp

30000 - 32767

WorkerIngressMasterIngressServicesUDP

Kubernetes Ingress サービス

udp

30000 - 32767

ロールおよびインスタンスプロファイル

マシンには、AWS でのパーミッションを付与する必要があります。提供される CloudFormation テンプレートはマシンに対し、以下の AWS::IAM::Role オブジェクトに関するマシンの Allow パーミッションを付与し、それぞれのロールセットに AWS::IAM::InstanceProfile を指定します。テンプレートを使用しない場合、マシンには以下の広範囲のパーミッションまたは個別のパーミッションを付与することができます。

ロール結果アクションリソース

マスター

Allow

ec2:*

*

Allow

elasticloadbalancing:*

*

Allow

iam:PassRole

*

Allow

s3:GetObject

*

ワーカー

Allow

ec2:Describe*

*

ブートストラップ

Allow

ec2:Describe*

*

Allow

ec2:AttachVolume

*

Allow

ec2:DetachVolume

*

4.2.3.2. クラスターマシン

以下のマシンには AWS::EC2::Instance オブジェクトが必要になります。

  • ブートストラップマシン。このマシンはインストール時に必要ですが、クラスターのデプロイ後に除去することができます。
  • 3 つのコントロールプレーンマシンコントロールプレーンマシンは、コントロールプレーンマシンセットによって管理されません。
  • コンピュートマシン。インストール時に 2 つ以上のコンピュートマシン (ワーカーマシンとしても知られる) を作成する必要があります。これらのマシンは、コンピュートマシンセットによって管理されません。

4.2.4. IAM ユーザーに必要な AWS パーミッション

注記

ベースクラスターリソースを削除するには、IAM ユーザーが領域 us-east-1 にアクセス許可 tag:GetResources を持っている必要があります。AWS API 要件の一部として、OpenShift Container Platform インストールプログラムはこのリージョンでさまざまなアクションを実行します。

AdministratorAccess ポリシーを、Amazon Web Services (AWS) で作成する IAM ユーザーに割り当てる場合、そのユーザーには必要なパーミッションすべてを付与します。OpenShift Container Platform クラスターのすべてのコンポーネントをデプロイするために、IAM ユーザーに以下のパーミッションが必要になります。

例4.3 インストールに必要な EC2 パーミッション

  • ec2:AttachNetworkInterface
  • ec2:AuthorizeSecurityGroupEgress
  • ec2:AuthorizeSecurityGroupIngress
  • ec2:CopyImage
  • ec2:CreateNetworkInterface
  • ec2:CreateSecurityGroup
  • ec2:CreateTags
  • ec2:CreateVolume
  • ec2:DeleteSecurityGroup
  • ec2:DeleteSnapshot
  • ec2:DeleteTags
  • ec2:DeregisterImage
  • ec2:DescribeAccountAttributes
  • ec2:DescribeAddresses
  • ec2:DescribeAvailabilityZones
  • ec2:DescribeDhcpOptions
  • ec2:DescribeImages
  • ec2:DescribeInstanceAttribute
  • ec2:DescribeInstanceCreditSpecifications
  • ec2:DescribeInstances
  • ec2:DescribeInstanceTypes
  • ec2:DescribeInternetGateways
  • ec2:DescribeKeyPairs
  • ec2:DescribeNatGateways
  • ec2:DescribeNetworkAcls
  • ec2:DescribeNetworkInterfaces
  • ec2:DescribePrefixLists
  • ec2:DescribePublicIpv4Pools (install-config.yamlpublicIpv4Pool が指定されている場合にのみ必要)
  • ec2:DescribeRegions
  • ec2:DescribeRouteTables
  • ec2:DescribeSecurityGroupRules
  • ec2:DescribeSecurityGroups
  • ec2:DescribeSubnets
  • ec2:DescribeTags
  • ec2:DescribeVolumes
  • ec2:DescribeVpcAttribute
  • ec2:DescribeVpcClassicLink
  • ec2:DescribeVpcClassicLinkDnsSupport
  • ec2:DescribeVpcEndpoints
  • ec2:DescribeVpcs
  • ec2:DisassociateAddress (install-config.yamlpublicIpv4Pool が指定されている場合にのみ必要)
  • ec2:GetEbsDefaultKmsKeyId
  • ec2:ModifyInstanceAttribute
  • ec2:ModifyNetworkInterfaceAttribute
  • ec2:RevokeSecurityGroupEgress
  • ec2:RevokeSecurityGroupIngress
  • ec2:RunInstances
  • ec2:TerminateInstances

例4.4 インストール時のネットワークリソースの作成に必要なパーミッション

  • ec2:AllocateAddress
  • ec2:AssociateAddress
  • ec2:AssociateDhcpOptions
  • ec2:AssociateRouteTable
  • ec2:AttachInternetGateway
  • ec2:CreateDhcpOptions
  • ec2:CreateInternetGateway
  • ec2:CreateNatGateway
  • ec2:CreateRoute
  • ec2:CreateRouteTable
  • ec2:CreateSubnet
  • ec2:CreateVpc
  • ec2:CreateVpcEndpoint
  • ec2:ModifySubnetAttribute
  • ec2:ModifyVpcAttribute
注記

既存の Virtual Private Cloud (VPC) を使用する場合、アカウントではネットワークリソースの作成にこれらのパーミッションを必要としません。

例4.5 インストールに必要な Elastic Load Balancing (ELB) のパーミッション

  • elasticloadbalancing:AddTags
  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer
  • elasticloadbalancing:AttachLoadBalancerToSubnets
  • elasticloadbalancing:ConfigureHealthCheck
  • elasticloadbalancing:CreateListener
  • elasticloadbalancing:CreateLoadBalancer
  • elasticloadbalancing:CreateLoadBalancerListeners
  • elasticloadbalancing:CreateTargetGroup
  • elasticloadbalancing:DeleteLoadBalancer
  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer
  • elasticloadbalancing:DeregisterTargets
  • elasticloadbalancing:DescribeInstanceHealth
  • elasticloadbalancing:DescribeListeners
  • elasticloadbalancing:DescribeLoadBalancerAttributes
  • elasticloadbalancing:DescribeLoadBalancers
  • elasticloadbalancing:DescribeTags
  • elasticloadbalancing:DescribeTargetGroupAttributes
  • elasticloadbalancing:DescribeTargetHealth
  • elasticloadbalancing:ModifyLoadBalancerAttributes
  • elasticloadbalancing:ModifyTargetGroup
  • elasticloadbalancing:ModifyTargetGroupAttributes
  • elasticloadbalancing:RegisterInstancesWithLoadBalancer
  • elasticloadbalancing:RegisterTargets
  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener
  • elasticloadbalancing:SetSecurityGroups
重要

OpenShift Container Platform は、ELB と ELBv2 API サービスの両方を使用してロードバランサーをプロビジョニングします。パーミッションリストには、両方のサービスに必要なパーミッションが表示されます。AWS Web コンソールには、両方のサービスが同じ elasticloadbalancing アクション接頭辞を使用しているにもかかわらず、同じアクションを認識しないという既知の問題が存在します。サービスが特定の elasticloadbalancing アクションを認識しないという警告は無視できます。

例4.6 インストールに必要な IAM パーミッション

  • iam:AddRoleToInstanceProfile
  • iam:CreateInstanceProfile
  • iam:CreateRole
  • iam:DeleteInstanceProfile
  • iam:DeleteRole
  • iam:DeleteRolePolicy
  • iam:GetInstanceProfile
  • iam:GetRole
  • iam:GetRolePolicy
  • iam:GetUser
  • iam:ListInstanceProfilesForRole
  • iam:ListRoles
  • iam:ListUsers
  • iam:PassRole
  • iam:PutRolePolicy
  • iam:RemoveRoleFromInstanceProfile
  • iam:SimulatePrincipalPolicy
  • iam:TagInstanceProfile
  • iam:TagRole
注記
  • install-config.yaml ファイルで既存の IAM ロールを指定する場合、iam:CreateRoleiam:DeleteRoleiam:DeleteRolePolicy、および iam:PutRolePolicy の IAM 権限は必要ありません。
  • AWS アカウントにロードバランサーを作成していない場合、IAM ユーザーには iam:CreateServiceLinkedRole パーミッションも必要です。

例4.7 インストールに必要な Route 53 パーミッション

  • route53:ChangeResourceRecordSets
  • route53:ChangeTagsForResource
  • route53:CreateHostedZone
  • route53:DeleteHostedZone
  • route53:GetChange
  • route53:GetHostedZone
  • route53:ListHostedZones
  • route53:ListHostedZonesByName
  • route53:ListResourceRecordSets
  • route53:ListTagsForResource
  • route53:UpdateHostedZoneComment

例4.8 インストールに必要な Amazon Simple Storage Service (S3) パーミッション

  • s3:CreateBucket
  • s3:DeleteBucket
  • s3:GetAccelerateConfiguration
  • s3:GetBucketAcl
  • s3:GetBucketCors
  • s3:GetBucketLocation
  • s3:GetBucketLogging
  • s3:GetBucketObjectLockConfiguration
  • s3:GetBucketPolicy
  • s3:GetBucketRequestPayment
  • s3:GetBucketTagging
  • s3:GetBucketVersioning
  • s3:GetBucketWebsite
  • s3:GetEncryptionConfiguration
  • s3:GetLifecycleConfiguration
  • s3:GetReplicationConfiguration
  • s3:ListBucket
  • s3:PutBucketAcl
  • s3:PutBucketPolicy
  • s3:PutBucketTagging
  • s3:PutEncryptionConfiguration

例4.9 クラスター Operator が必要とする S3 パーミッション

  • s3:DeleteObject
  • s3:GetObject
  • s3:GetObjectAcl
  • s3:GetObjectTagging
  • s3:GetObjectVersion
  • s3:PutObject
  • s3:PutObjectAcl
  • s3:PutObjectTagging

例4.10 ベースクラスターリソースの削除に必要なパーミッション

  • autoscaling:DescribeAutoScalingGroups
  • ec2:DeleteNetworkInterface
  • ec2:DeletePlacementGroup
  • ec2:DeleteVolume
  • elasticloadbalancing:DeleteTargetGroup
  • elasticloadbalancing:DescribeTargetGroups
  • iam:DeleteAccessKey
  • iam:DeleteUser
  • iam:DeleteUserPolicy
  • iam:ListAttachedRolePolicies
  • iam:ListInstanceProfiles
  • iam:ListRolePolicies
  • iam:ListUserPolicies
  • s3:DeleteObject
  • s3:ListBucketVersions
  • tag:GetResources

例4.11 ネットワークリソースの削除に必要なパーミッション

  • ec2:DeleteDhcpOptions
  • ec2:DeleteInternetGateway
  • ec2:DeleteNatGateway
  • ec2:DeleteRoute
  • ec2:DeleteRouteTable
  • ec2:DeleteSubnet
  • ec2:DeleteVpc
  • ec2:DeleteVpcEndpoints
  • ec2:DetachInternetGateway
  • ec2:DisassociateRouteTable
  • ec2:ReleaseAddress
  • ec2:ReplaceRouteTableAssociation
注記

既存の VPC を使用する場合、アカウントではネットワークリソースの削除にこれらのパーミッションを必要としません。代わりに、アカウントではネットワークリソースの削除に tag:UntagResources パーミッションのみが必要になります。

例4.12 カスタムキー管理サービス (KMS) キーを使用してクラスターをインストールするためのオプションの権限

  • kms:CreateGrant
  • kms:Decrypt
  • kms:DescribeKey
  • kms:Encrypt
  • kms:GenerateDataKey
  • kms:GenerateDataKeyWithoutPlainText
  • kms:ListGrants
  • kms:RevokeGrant

例4.13 共有インスタンスロールが割り当てられたクラスターを削除するために必要なパーミッション

  • iam:UntagRole

例4.14 マニフェストの作成に必要な追加の IAM および S3 パーミッション

  • iam:GetUserPolicy
  • iam:ListAccessKeys
  • iam:PutUserPolicy
  • iam:TagUser
  • s3:AbortMultipartUpload
  • s3:GetBucketPublicAccessBlock
  • s3:ListBucket
  • s3:ListBucketMultipartUploads
  • s3:PutBucketPublicAccessBlock
  • s3:PutLifecycleConfiguration
注記

クラウドプロバイダーのクレデンシャルをミントモードで管理している場合に、IAM ユーザーには iam:CreateAccessKeyiam:CreateUser 権限も必要です。

例4.15 インスタンスのオプションのパーミッションおよびインストールのクォータチェック

  • ec2:DescribeInstanceTypeOfferings
  • servicequotas:ListAWSDefaultServiceQuotas

例4.16 共有 VPC にクラスターをインストールする場合のクラスター所有者アカウントのオプションの権限

  • sts:AssumeRole

例4.17 インストール時に Bring your own public IPv4 アドレス (BYOIP) 機能を有効にするために必要な権限

  • ec2:DescribePublicIpv4Pools
  • ec2:DisassociateAddress

4.2.5. AWS Marketplace イメージの取得

AWS Marketplace イメージを使用して OpenShift Container Platform クラスターをデプロイする場合は、最初に AWS を通じてサブスクライブする必要があります。オファーにサブスクライブすると、インストールプログラムがコンピュートノードのデプロイに使用する AMI ID が提供されます。

前提条件

  • オファーを購入するための AWS アカウントを持っている。このアカウントは、クラスターのインストールに使用されるアカウントと同じである必要はありません。

手順

  1. AWS Marketplace で OpenShift Container Platform サブスクリプションを完了します。

4.3. CloudFormation テンプレートの使用による、AWS での user-provisioned infrastructure へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、独自に提供するインフラストラクチャーを使用する Amazon Web Services (AWS) にクラスターをインストールできます。

このインフラストラクチャーを作成する 1 つの方法として、提供される CloudFormation テンプレートを使用できます。テンプレートを変更してインフラストラクチャーをカスタマイズしたり、それらに含まれる情報を使用し、所属する会社のポリシーに基づいて AWS オブジェクトを作成したりできます。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の CloudFormation テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。

4.3.1. 前提条件

4.3.2. AWS のインストールファイルの作成

user-provisioned infrastructure を使用して OpenShift Container Platform を Amazon Web Services (AWS) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。

4.3.2.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 設定ファイルを再び作成する必要はありません。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. 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

  3. オプション: インストールプログラムで 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
    ...

  4. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    variant: openshift
    version: 4.17.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 1
        partitions:
        - label: var
          start_mib: <partition_start_offset> 2
          size_mib: <partition_size> 3
          number: 5
      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 パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  5. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  6. 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) システムをインストールするためにインストール手順への入力として使用できます。

4.3.2.2. インストール設定ファイルの作成

インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。

前提条件

  • user-provisioned infrastructure 用の OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、install-config.yaml ファイルを手動で作成する必要があります。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
      重要

      空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして aws を選択します。
      3. AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

        注記

        AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. 3 ノードクラスターをインストールする場合は、compute.replicas パラメーターを 0 に設定して、install-config.yaml ファイルを変更します。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「AWS に 3 ノードクラスターをインストールする」を参照してください。
  3. オプション: install-config.yaml ファイルをバックアップします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

関連情報

4.3.2.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: 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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

4.3.2.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 インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
  2. コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml

    これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

  3. コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml
  4. ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
    重要

    user-provisioned infrastructure にクラスターをインストールするときに MachineAPI 機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。

    ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。

    警告

    3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。

    重要

    コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。

  5. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  6. オプション: 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: {}
    1 2
    このセクションを完全に削除します。

    これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。

  7. 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

4.3.3. インフラストラクチャー名の抽出

Ignition 設定ファイルには、Amazon Web Services (AWS) でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な AWS リソースを見つけるためにも使用されます。提供される CloudFormation テンプレートにはこのインフラストラクチャー名の参照が含まれるため、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

4.3.4. AWS での VPC の作成

OpenShift Container Platform クラスターで使用する Virtual Private Cloud (VPC) を Amazon Web Services (AWS) で作成する必要があります。VPN およびルートテーブルを含む、各種要件を満たすように VPC をカスタマイズできます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "VpcCidr", 1
        "ParameterValue": "10.0.0.0/16" 2
      },
      {
        "ParameterKey": "AvailabilityZoneCount", 3
        "ParameterValue": "1" 4
      },
      {
        "ParameterKey": "SubnetBits", 5
        "ParameterValue": "12" 6
      }
    ]
    1
    VPC の CIDR ブロック。
    2
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    3
    VPC をデプロイするアベイラビリティーゾーンの数。
    4
    1 から 3 の間の整数を指定します。
    5
    各アベイラビリティーゾーン内の各サブネットのサイズ。
    6
    5 から 13 の間の整数を指定します。ここで、5/27 であり、13/19 です。
  2. このトピックのVPC の CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  3. CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-vpc などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f

  4. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    VpcId

    VPC の ID。

    PublicSubnetIds

    新規パブリックサブネットの ID。

    PrivateSubnetIds

    新規プライベートサブネットの ID。

4.3.4.1. VPC の CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。

例4.18 VPC の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable
  PrivateRouteTableIds:
    Description: Private Route table IDs
    Value:
      !Join [
        ",",
        [
          !Join ["=", [
            !Select [0, "Fn::GetAZs": !Ref "AWS::Region"],
            !Ref PrivateRouteTable
          ]],
          !If [DoAz2,
               !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]],
               !Ref "AWS::NoValue"
          ],
          !If [DoAz3,
               !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]],
               !Ref "AWS::NoValue"
          ]
        ]
      ]

関連情報

4.3.5. AWS でのネットワークおよび負荷分散コンポーネントの作成

OpenShift Container Platform クラスターで使用できるネットワークおよび負荷分散 (classic または network) を Amazon Web Services (AWS) で設定する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform クラスターに必要なネットワークおよび負荷分散コンポーネントを表します。テンプレートは、ホストゾーンおよびサブネットタグも作成します。

単一 Virtual Private Cloud 内でテンプレートを複数回実行することができます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。

手順

  1. クラスターの install-config.yaml ファイルに指定した Route 53 ベースドメインのホストゾーン ID を取得します。以下のコマンドを実行して、ホストゾーンの詳細を取得できます。

    $ aws route53 list-hosted-zones-by-name --dns-name <route53_domain> 1
    1
    <route53_domain> に、クラスターの install-config.yaml ファイルを生成した時に作成した Route 53 ベースドメインを指定します。

    出力例

    mycluster.example.com.	False	100
    HOSTEDZONES	65F8F38E-2268-B835-E15C-AB55336FCBFA	/hostedzone/Z21IXYZABCZ2A4	mycluster.example.com.	10

    この出力例では、ホストゾーン ID は Z21IXYZ3-2Z2A4 です。

  2. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "ClusterName", 1
        "ParameterValue": "mycluster" 2
      },
      {
        "ParameterKey": "InfrastructureName", 3
        "ParameterValue": "mycluster-<random_string>" 4
      },
      {
        "ParameterKey": "HostedZoneId", 5
        "ParameterValue": "<random_string>" 6
      },
      {
        "ParameterKey": "HostedZoneName", 7
        "ParameterValue": "example.com" 8
      },
      {
        "ParameterKey": "PublicSubnets", 9
        "ParameterValue": "subnet-<random_string>" 10
      },
      {
        "ParameterKey": "PrivateSubnets", 11
        "ParameterValue": "subnet-<random_string>" 12
      },
      {
        "ParameterKey": "VpcId", 13
        "ParameterValue": "vpc-<random_string>" 14
      }
    ]
    1
    ホスト名などに使用する短いクラスター名。
    2
    クラスターの install-config.yaml ファイルを生成した時に使用したクラスター名を指定します。
    3
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    4
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    5
    ターゲットの登録に使用する Route 53 パブリックトゾーン ID。
    6
    Z21IXYZABCZ2A4 に類する形式の Route 53 パブリックゾーン ID を指定します。この値は AWS コンソールから取得できます。
    7
    ターゲットの登録に使用する Route 53 ゾーン。
    8
    クラスターの install-config.yaml ファイルを生成した時に使用した Route 53 ベースドメインを指定します。AWS コンソールに表示される末尾のピリド (.) は含めないでください。
    9
    VPC 用に作成したパブリックサブネット。
    10
    VPC の CloudFormation テンプレートの出力から PublicSubnetIds 値を指定します。
    11
    VPC 用に作成したプライベートサブネット。
    12
    VPC の CloudFormation テンプレートの出力から PrivateSubnetIds 値を指定します。
    13
    クラスター用に作成した VPC。
    14
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
  3. このトピックのネットワークおよびロードバランサーの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なネットワークおよび負荷分散オブジェクトを記述しています。

    重要

    AWS government またはシークレットリージョンにクラスターをデプロイする場合は、CloudFormation テンプレートの InternalApiServerRecord を更新して、CNAME レコードを使用する必要があります。ALIAS タイプのレコードは、AWS 政府リージョンではサポートされません。

  4. CloudFormation テンプレートを起動し、ネットワークおよび負荷分散コンポーネントを提供する AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-dns などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-dns/cd3e5de0-2fd4-11eb-5cf0-12be5c33a183

  5. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    PrivateHostedZoneId

    プライベート DNS のホストゾーン ID。

    ExternalApiLoadBalancerName

    外部 API ロードバランサーのフルネーム。

    InternalApiLoadBalancerName

    内部 API ロードバランサーのフルネーム。

    ApiServerDnsName

    API サーバーの完全ホスト名。

    RegisterNlbIpTargetsLambda

    これらのロードバランサーの登録/登録解除に役立つ Lambda ARN。

    ExternalApiTargetGroupArn

    外部 API ターゲットグループの ARN。

    InternalApiTargetGroupArn

    内部 API ターゲットグループの ARN。

    InternalServiceTargetGroupArn

    内部サービスターゲットグループの ARN。

4.3.5.1. ネットワークおよびロードバランサーの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なネットワークオブジェクトおよびロードバランサーをデプロイすることができます。

例4.19 ネットワークおよびロードバランサーの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Network Elements (Route53 & LBs)

Parameters:
  ClusterName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Cluster name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, representative cluster name to use for host names and other identifying names.
    Type: String
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  HostedZoneId:
    Description: The Route53 public zone ID to register the targets with, such as Z21IXYZABCZ2A4.
    Type: String
  HostedZoneName:
    Description: The Route53 zone to register the targets with, such as example.com. Omit the trailing period.
    Type: String
    Default: "example.com"
  PublicSubnets:
    Description: The internet-facing subnets.
    Type: List<AWS::EC2::Subnet::Id>
  PrivateSubnets:
    Description: The internal subnets.
    Type: List<AWS::EC2::Subnet::Id>
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - ClusterName
      - InfrastructureName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - PublicSubnets
      - PrivateSubnets
    - Label:
        default: "DNS"
      Parameters:
      - HostedZoneName
      - HostedZoneId
    ParameterLabels:
      ClusterName:
        default: "Cluster Name"
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      PublicSubnets:
        default: "Public Subnets"
      PrivateSubnets:
        default: "Private Subnets"
      HostedZoneName:
        default: "Public Hosted Zone Name"
      HostedZoneId:
        default: "Public Hosted Zone ID"

Resources:
  ExtApiElb:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Join ["-", [!Ref InfrastructureName, "ext"]]
      IpAddressType: ipv4
      Subnets: !Ref PublicSubnets
      Type: network

  IntApiElb:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Join ["-", [!Ref InfrastructureName, "int"]]
      Scheme: internal
      IpAddressType: ipv4
      Subnets: !Ref PrivateSubnets
      Type: network

  IntDns:
    Type: "AWS::Route53::HostedZone"
    Properties:
      HostedZoneConfig:
        Comment: "Managed by CloudFormation"
      Name: !Join [".", [!Ref ClusterName, !Ref HostedZoneName]]
      HostedZoneTags:
      - Key: Name
        Value: !Join ["-", [!Ref InfrastructureName, "int"]]
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "owned"
      VPCs:
      - VPCId: !Ref VpcId
        VPCRegion: !Ref "AWS::Region"

  ExternalApiServerRecord:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      Comment: Alias record for the API server
      HostedZoneId: !Ref HostedZoneId
      RecordSets:
      - Name:
          !Join [
            ".",
            ["api", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt ExtApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt ExtApiElb.DNSName

  InternalApiServerRecord:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      Comment: Alias record for the API server
      HostedZoneId: !Ref IntDns
      RecordSets:
      - Name:
          !Join [
            ".",
            ["api", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt IntApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt IntApiElb.DNSName
      - Name:
          !Join [
            ".",
            ["api-int", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt IntApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt IntApiElb.DNSName

  ExternalApiListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: ExternalApiTargetGroup
      LoadBalancerArn:
        Ref: ExtApiElb
      Port: 6443
      Protocol: TCP

  ExternalApiTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/readyz"
      HealthCheckPort: 6443
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 6443
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  InternalApiListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: InternalApiTargetGroup
      LoadBalancerArn:
        Ref: IntApiElb
      Port: 6443
      Protocol: TCP

  InternalApiTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/readyz"
      HealthCheckPort: 6443
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 6443
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  InternalServiceInternalListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: InternalServiceTargetGroup
      LoadBalancerArn:
        Ref: IntApiElb
      Port: 22623
      Protocol: TCP

  InternalServiceTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/healthz"
      HealthCheckPort: 22623
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 22623
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  RegisterTargetLambdaIamRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Join ["-", [!Ref InfrastructureName, "nlb", "lambda", "role"]]
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "lambda.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "master", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref InternalApiTargetGroup
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref InternalServiceTargetGroup
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref ExternalApiTargetGroup

  RegisterNlbIpTargets:
    Type: "AWS::Lambda::Function"
    Properties:
      Handler: "index.handler"
      Role:
        Fn::GetAtt:
        - "RegisterTargetLambdaIamRole"
        - "Arn"
      Code:
        ZipFile: |
          import json
          import boto3
          import cfnresponse
          def handler(event, context):
            elb = boto3.client('elbv2')
            if event['RequestType'] == 'Delete':
              elb.deregister_targets(TargetGroupArn=event['ResourceProperties']['TargetArn'],Targets=[{'Id': event['ResourceProperties']['TargetIp']}])
            elif event['RequestType'] == 'Create':
              elb.register_targets(TargetGroupArn=event['ResourceProperties']['TargetArn'],Targets=[{'Id': event['ResourceProperties']['TargetIp']}])
            responseData = {}
            cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, event['ResourceProperties']['TargetArn']+event['ResourceProperties']['TargetIp'])
      Runtime: "python3.11"
      Timeout: 120

  RegisterSubnetTagsLambdaIamRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Join ["-", [!Ref InfrastructureName, "subnet-tags-lambda-role"]]
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "lambda.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "subnet-tagging-policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
              [
                "ec2:DeleteTags",
                "ec2:CreateTags"
              ]
            Resource: "arn:aws:ec2:*:*:subnet/*"
          - Effect: "Allow"
            Action:
              [
                "ec2:DescribeSubnets",
                "ec2:DescribeTags"
              ]
            Resource: "*"

  RegisterSubnetTags:
    Type: "AWS::Lambda::Function"
    Properties:
      Handler: "index.handler"
      Role:
        Fn::GetAtt:
        - "RegisterSubnetTagsLambdaIamRole"
        - "Arn"
      Code:
        ZipFile: |
          import json
          import boto3
          import cfnresponse
          def handler(event, context):
            ec2_client = boto3.client('ec2')
            if event['RequestType'] == 'Delete':
              for subnet_id in event['ResourceProperties']['Subnets']:
                ec2_client.delete_tags(Resources=[subnet_id], Tags=[{'Key': 'kubernetes.io/cluster/' + event['ResourceProperties']['InfrastructureName']}]);
            elif event['RequestType'] == 'Create':
              for subnet_id in event['ResourceProperties']['Subnets']:
                ec2_client.create_tags(Resources=[subnet_id], Tags=[{'Key': 'kubernetes.io/cluster/' + event['ResourceProperties']['InfrastructureName'], 'Value': 'shared'}]);
            responseData = {}
            cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, event['ResourceProperties']['InfrastructureName']+event['ResourceProperties']['Subnets'][0])
      Runtime: "python3.11"
      Timeout: 120

  RegisterPublicSubnetTags:
    Type: Custom::SubnetRegister
    Properties:
      ServiceToken: !GetAtt RegisterSubnetTags.Arn
      InfrastructureName: !Ref InfrastructureName
      Subnets: !Ref PublicSubnets

  RegisterPrivateSubnetTags:
    Type: Custom::SubnetRegister
    Properties:
      ServiceToken: !GetAtt RegisterSubnetTags.Arn
      InfrastructureName: !Ref InfrastructureName
      Subnets: !Ref PrivateSubnets

Outputs:
  PrivateHostedZoneId:
    Description: Hosted zone ID for the private DNS, which is required for private records.
    Value: !Ref IntDns
  ExternalApiLoadBalancerName:
    Description: Full name of the external API load balancer.
    Value: !GetAtt ExtApiElb.LoadBalancerFullName
  InternalApiLoadBalancerName:
    Description: Full name of the internal API load balancer.
    Value: !GetAtt IntApiElb.LoadBalancerFullName
  ApiServerDnsName:
    Description: Full hostname of the API server, which is required for the Ignition config files.
    Value: !Join [".", ["api-int", !Ref ClusterName, !Ref HostedZoneName]]
  RegisterNlbIpTargetsLambda:
    Description: Lambda ARN useful to help register or deregister IP targets for these load balancers.
    Value: !GetAtt RegisterNlbIpTargets.Arn
  ExternalApiTargetGroupArn:
    Description: ARN of the external API target group.
    Value: !Ref ExternalApiTargetGroup
  InternalApiTargetGroupArn:
    Description: ARN of the internal API target group.
    Value: !Ref InternalApiTargetGroup
  InternalServiceTargetGroupArn:
    Description: ARN of the internal service target group.
    Value: !Ref InternalServiceTargetGroup
重要

クラスターを AWS government またはシークレットリージョンにデプロイする場合は、InternalApiServerRecord を更新し、CNAME レコードを使用する必要があります。ALIAS タイプのレコードは、AWS 政府リージョンではサポートされません。以下に例を示します。

Type: CNAME
TTL: 10
ResourceRecords:
- !GetAtt IntApiElb.DNSName

関連情報

4.3.6. AWS でのセキュリティーグループおよびロールの作成

OpenShift Container Platform クラスターで使用するセキュリティーグループおよびロールを Amazon Web Services (AWS) で作成する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform クラスターに必要なセキュリティーグループおよびロールを表します。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "VpcCidr", 3
        "ParameterValue": "10.0.0.0/16" 4
      },
      {
        "ParameterKey": "PrivateSubnets", 5
        "ParameterValue": "subnet-<random_string>" 6
      },
      {
        "ParameterKey": "VpcId", 7
        "ParameterValue": "vpc-<random_string>" 8
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    VPC の CIDR ブロック。
    4
    x.x.x.x/16-24 の形式で定義した VPC に使用した CIDR ブロックパラメーターを指定します。
    5
    VPC 用に作成したプライベートサブネット。
    6
    VPC の CloudFormation テンプレートの出力から PrivateSubnetIds 値を指定します。
    7
    クラスター用に作成した VPC。
    8
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
  2. このトピックのセキュリティーオブジェクトの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なセキュリティーグループおよびロールを記述しています。
  3. CloudFormation テンプレートを起動し、セキュリティーグループおよびロールを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-sec などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role および AWS::IAM::InstanceProfile リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-sec/03bd4210-2ed7-11eb-6d7a-13fc0b61e9db

  4. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    MasterSecurityGroupId

    マスターセキュリティーグループ ID

    WorkerSecurityGroupId

    ワーカーセキュリティーグループ ID

    MasterInstanceProfile

    マスター IAM インスタンスプロファイル

    WorkerInstanceProfile

    ワーカー IAM インスタンスプロファイル

4.3.6.1. セキュリティーオブジェクトの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なセキュリティーオブジェクトをデプロイすることができます。

例4.20 セキュリティーオブジェクトの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Security Elements (Security Groups & IAM)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id
  PrivateSubnets:
    Description: The internal subnets.
    Type: List<AWS::EC2::Subnet::Id>

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - VpcCidr
      - PrivateSubnets
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      VpcCidr:
        default: "VPC CIDR"
      PrivateSubnets:
        default: "Private Subnets"

Resources:
  MasterSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Master Security Group
      SecurityGroupIngress:
      - IpProtocol: icmp
        FromPort: 0
        ToPort: 0
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        ToPort: 6443
        FromPort: 6443
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22623
        ToPort: 22623
        CidrIp: !Ref VpcCidr
      VpcId: !Ref VpcId

  WorkerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Worker Security Group
      SecurityGroupIngress:
      - IpProtocol: icmp
        FromPort: 0
        ToPort: 0
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref VpcCidr
      VpcId: !Ref VpcId

  MasterIngressEtcd:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: etcd
      FromPort: 2379
      ToPort: 2380
      IpProtocol: tcp

  MasterIngressVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  MasterIngressWorkerVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  MasterIngressGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  MasterIngressWorkerGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  MasterIngressIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  MasterIngressIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  MasterIngressIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  MasterIngressWorkerIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  MasterIngressWorkerIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  MasterIngressWorkerIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  MasterIngressInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  MasterIngressWorkerInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  MasterIngressInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  MasterIngressWorkerInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  MasterIngressKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes kubelet, scheduler and controller manager
      FromPort: 10250
      ToPort: 10259
      IpProtocol: tcp

  MasterIngressWorkerKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes kubelet, scheduler and controller manager
      FromPort: 10250
      ToPort: 10259
      IpProtocol: tcp

  MasterIngressIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  MasterIngressWorkerIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  MasterIngressIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  MasterIngressWorkerIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  WorkerIngressVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  WorkerIngressMasterVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  WorkerIngressGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  WorkerIngressMasterGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  WorkerIngressIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  WorkerIngressIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  WorkerIngressIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  WorkerIngressMasterIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  WorkerIngressMasterIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  WorkerIngressMasterIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  WorkerIngressInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  WorkerIngressMasterInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  WorkerIngressInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  WorkerIngressMasterInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  WorkerIngressKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes secure kubelet port
      FromPort: 10250
      ToPort: 10250
      IpProtocol: tcp

  WorkerIngressWorkerKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal Kubernetes communication
      FromPort: 10250
      ToPort: 10250
      IpProtocol: tcp

  WorkerIngressIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  WorkerIngressMasterIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  WorkerIngressIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  WorkerIngressMasterIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  MasterIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "master", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
            - "ec2:AttachVolume"
            - "ec2:AuthorizeSecurityGroupIngress"
            - "ec2:CreateSecurityGroup"
            - "ec2:CreateTags"
            - "ec2:CreateVolume"
            - "ec2:DeleteSecurityGroup"
            - "ec2:DeleteVolume"
            - "ec2:Describe*"
            - "ec2:DetachVolume"
            - "ec2:ModifyInstanceAttribute"
            - "ec2:ModifyVolume"
            - "ec2:RevokeSecurityGroupIngress"
            - "elasticloadbalancing:AddTags"
            - "elasticloadbalancing:AttachLoadBalancerToSubnets"
            - "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer"
            - "elasticloadbalancing:CreateListener"
            - "elasticloadbalancing:CreateLoadBalancer"
            - "elasticloadbalancing:CreateLoadBalancerPolicy"
            - "elasticloadbalancing:CreateLoadBalancerListeners"
            - "elasticloadbalancing:CreateTargetGroup"
            - "elasticloadbalancing:ConfigureHealthCheck"
            - "elasticloadbalancing:DeleteListener"
            - "elasticloadbalancing:DeleteLoadBalancer"
            - "elasticloadbalancing:DeleteLoadBalancerListeners"
            - "elasticloadbalancing:DeleteTargetGroup"
            - "elasticloadbalancing:DeregisterInstancesFromLoadBalancer"
            - "elasticloadbalancing:DeregisterTargets"
            - "elasticloadbalancing:Describe*"
            - "elasticloadbalancing:DetachLoadBalancerFromSubnets"
            - "elasticloadbalancing:ModifyListener"
            - "elasticloadbalancing:ModifyLoadBalancerAttributes"
            - "elasticloadbalancing:ModifyTargetGroup"
            - "elasticloadbalancing:ModifyTargetGroupAttributes"
            - "elasticloadbalancing:RegisterInstancesWithLoadBalancer"
            - "elasticloadbalancing:RegisterTargets"
            - "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer"
            - "elasticloadbalancing:SetLoadBalancerPoliciesOfListener"
            - "kms:DescribeKey"
            Resource: "*"

  MasterInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Roles:
      - Ref: "MasterIamRole"

  WorkerIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "worker", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
            - "ec2:DescribeInstances"
            - "ec2:DescribeRegions"
            Resource: "*"

  WorkerInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Roles:
      - Ref: "WorkerIamRole"

Outputs:
  MasterSecurityGroupId:
    Description: Master Security Group ID
    Value: !GetAtt MasterSecurityGroup.GroupId

  WorkerSecurityGroupId:
    Description: Worker Security Group ID
    Value: !GetAtt WorkerSecurityGroup.GroupId

  MasterInstanceProfile:
    Description: Master IAM Instance Profile
    Value: !Ref MasterInstanceProfile

  WorkerInstanceProfile:
    Description: Worker IAM Instance Profile
    Value: !Ref WorkerInstanceProfile

関連情報

4.3.7. ストリームメタデータを使用した RHCOS AMI へのアクセス

OpenShift Container Platform では、ストリームメタデータ は、JSON 形式で RHCOS に関する標準化されたメタデータを提供し、メタデータをクラスターに挿入します。ストリームメタデータは、複数のアーキテクチャーをサポートする安定した形式で、自動化を維持するための自己文書化が意図されています。

openshift-installcoreos print-stream-json サブコマンドを使用して、ストリームメタデータ形式のブートイメージに関する情報にアクセスできます。このコマンドは、スクリプト可能でマシン読み取り可能な形式でストリームメタデータを出力する方法を提供します。

user-provisioned installation の場合、openshift-install バイナリーには、AWS AMI などの OpenShift Container Platform での使用がテストされている RHCOS ブートイメージのバージョンへの参照が含まれます。

手順

ストリームメタデータを解析するには、以下のいずれかの方法を使用します。

  • Go プログラムから、https://github.com/coreos/stream-metadata-go の公式の stream-metadata-go ライブラリーを使用します。ライブラリーでサンプルコードを確認することもできます。
  • Python や Ruby などの別のプログラミング言語から、お好みのプログラミング言語の JSON ライブラリーを使用します。
  • jq などの JSON データを処理するコマンドラインユーティリティーから、以下のコマンドを実行します。

    • us-west-1 などの AWS リージョンの現在の x86_64 または aarch64 AMI を出力します。

      x86_64 の場合

      $ openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.images.aws.regions["us-west-1"].image'

      出力例

      ami-0d3e625f84626bbda

      aarch64 の場合

      $ openshift-install coreos print-stream-json | jq -r '.architectures.aarch64.images.aws.regions["us-west-1"].image'

      出力例

      ami-0af1d3b7fa5be2131

      このコマンドの出力は、指定されたアーキテクチャーと us-west-1 リージョンの AWS AMI ID です。AMI はクラスターと同じリージョンに属する必要があります。

4.3.8. AWS インフラストラクチャーの RHCOS AMI

Red Hat は、OpenShift Container Platform ノードに手動で指定できる、さまざまな AWS リージョンおよびインスタンスアーキテクチャーに有効な Red Hat Enterprise Linux CoreOS(RHCOS) AMI を提供します。

注記

また、独自の AMI をインポートすることで、RHCOS AMI がパブリッシュされていないリージョンにインストールすることもできます。

表4.3 x86_64 RHCOS AMIs
AWS ゾーンAWS AMI

af-south-1

ami-019b3e090bb062842

ap-east-1

ami-0cb76d97f77cda0a1

ap-northeast-1

ami-0d7d4b329e5403cfb

ap-northeast-2

ami-02d3789d532feb517

ap-northeast-3

ami-08b82c4899109b707

ap-south-1

ami-0c184f8b5ad8af69d

ap-south-2

ami-0b0525037b9a20e9a

ap-southeast-1

ami-0dbee0006375139a7

ap-southeast-2

ami-043072b1af91be72f

ap-southeast-3

ami-09d8bbf16b228139e

ap-southeast-4

ami-01c6b29e9c57b434b

ca-central-1

ami-06fda1fa0b65b864b

ca-west-1

ami-0141eea486b5e2c43

eu-central-1

ami-0f407de515454fdd0

eu-central-2

ami-062cfad83bc7b71b8

eu-north-1

ami-0af77aba6aebb5086

eu-south-1

ami-04d9da83bc9f854fc

eu-south-2

ami-035d487abf54f0af7

eu-west-1

ami-043dd3b788dbaeb1c

eu-west-2

ami-0c7d0f90a4401b723

eu-west-3

ami-039baa878e1def55f

il-central-1

ami-07d305bf03b2148de

me-central-1

ami-0fc457e8897ccb41a

me-south-1

ami-0af99a751cf682b90

sa-east-1

ami-04a7300f64ee01d68

us-east-1

ami-01b53f2824bf6d426

us-east-2

ami-0565349610e27bd41

us-gov-east-1

ami-0020504fa043fe41d

us-gov-west-1

ami-036798bce4722d3c2

us-west-1

ami-0147c634ad692da52

us-west-2

ami-0c65d71e89d43aa90

表4.4 aarch64 RHCOS AMI
AWS ゾーンAWS AMI

af-south-1

ami-0e585ef53405bebf5

ap-east-1

ami-05f32f1715bb51bda

ap-northeast-1

ami-05ecb62bab0c50e52

ap-northeast-2

ami-0a3ffb2c07c9e4a8d

ap-northeast-3

ami-0ae6746ea17d1042c

ap-south-1

ami-00deb5b08c86060b8

ap-south-2

ami-047a47d5049781e03

ap-southeast-1

ami-09cb598f0d36fde4c

ap-southeast-2

ami-01fe8a7538500f24c

ap-southeast-3

ami-051b3f67dd787d5e9

ap-southeast-4

ami-04d2e14a9eef40143

ca-central-1

ami-0f66973ff12d09356

ca-west-1

ami-0c9f3e2f0470d6d0b

eu-central-1

ami-0a79af8849b425a8a

eu-central-2

ami-0f9f66951c9709471

eu-north-1

ami-0670362aa7eb9032d

eu-south-1

ami-031b24b970eae750b

eu-south-2

ami-0734d2ed55c00a46c

eu-west-1

ami-0a9af75c2649471c0

eu-west-2

ami-0b84155a3672ac44e

eu-west-3

ami-02b51442c612818d4

il-central-1

ami-0d2c47a297d483ce4

me-central-1

ami-0ef3005246bd83b07

me-south-1

ami-0321ca1ee89015eda

sa-east-1

ami-0e63f1103dc71d8ae

us-east-1

ami-0404da96615c73bec

us-east-2

ami-04c3bd7be936f728f

us-gov-east-1

ami-0d30bc0b99b153247

us-gov-west-1

ami-0ee006f84d6aa5045

us-west-1

ami-061bfd61d5cfd7aa6

us-west-2

ami-05ffb8f6f18b8e3f8

4.3.8.1. 公開済み RHCOS AMI のない AWS リージョン

Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) または AWS software development kit (SDK) のネイティブサポートなしに、OpenShift Container Platform クラスターを Amazon Web Services (AWS) リージョンにデプロイできます。パブリッシュ済みの AMI が AWS リージョンで利用できない場合は、クラスターをインストールする前にカスタム AMI をアップロードできます。

AWS SDK によってサポートされないリージョンにデプロイしている場合で、カスタム AMI を指定しない場合、インストールプログラムは us-east-1 AMI をユーザーアカウントに自動的にコピーします。次にインストールプログラムは、デフォルトまたはユーザー指定の Key Management Service (KMS) キーを使用して、暗号化された EBS ボリュームでコントロールプレーンマシンを作成します。これにより、AMI は、パブリッシュ済みの RHCOS AMI と同じプロセスワークフローを実施することができます。

RHCOS AMI のネイティブサポートのないリージョンはパブリッシュされないため、クラスターの作成時にターミナルから選択することはできません。ただし、install-config.yaml ファイルでカスタム AMI を設定して、このリージョンにインストールすることができます。

4.3.8.2. AWS でのカスタム RHCOS AMI のアップロード

カスタム Amazon Web Services (AWS) リージョンにデプロイする場合、そのリージョンに属するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) をアップロードする必要があります。

前提条件

  • AWS アカウントを設定している。
  • 必要な IAM サービスロール で、Amazon S3 バケットを作成している。
  • RHCOS VMDK ファイルを Amazon S3 にアップロードしている。RHCOS VMDK ファイルは、インストールする OpenShift Container Platform のバージョンと同じか、それ以下のバージョンである必要があります。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer を参照してください。

手順

  1. AWS プロファイルを環境変数としてエクスポートします。

    $ export AWS_PROFILE=<aws_profile> 1
  2. カスタム AMI に関連付けるリージョンを環境変数としてエクスポートします。

    $ export AWS_DEFAULT_REGION=<aws_region> 1
  3. 環境変数として Amazon S3 にアップロードした RHCOS のバージョンをエクスポートします。

    $ export RHCOS_VERSION=<version> 1
    1 1 1
    4.17.0 などの RHCOS VMDK バージョン。
  4. Amazon S3 バケット名を環境変数としてエクスポートします。

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. containers.json ファイルを作成し、RHCOS VMDK ファイルを定義します。

    $ cat <<EOF > containers.json
    {
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
       }
    }
    EOF
  6. RHCOS ディスクを Amazon EBS スナップショットとしてインポートします。

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ 1
         --disk-container "file://<file_path>/containers.json" 2
    1
    rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64 などの RHCOS ディスクがインポートされていることの説明。
    2
    RHCOS ディスクを説明する JSON ファイルへのファイルパス。JSON ファイルには、Amazon S3 バケット名とキーが含まれている必要があります。
  7. イメージインポートのステータスを確認します。

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}

    出力例

    {
        "ImportSnapshotTasks": [
            {
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"
                    }
                }
            }
        ]
    }

    SnapshotId をコピーして、イメージを登録します。

  8. RHCOS スナップショットからカスタム RHCOS AMI を作成します。

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ 1
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 2
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ 3
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' 4
    1
    x86_64aarch64s390x、または ppc64le などの RHCOS VMDK アーキテクチャータイプ。
    2
    インポートされたスナップショットの Description
    3
    RHCOS AMI の名前。
    4
    インポートされたスナップショットからの SnapshotID

これらの API の詳細は、AWS ドキュメントの importing snapshots および creating EBS-backed AMIs を参照してください。

4.3.9. AWS でのブートストラップノードの作成

OpenShift Container Platform クラスターの初期化で使用するブートストラップノードを Amazon Web Services (AWS) で作成する必要があります。これは、以下の方法で行います。

  • bootstrap.ign Ignition 設定ファイルをクラスターに送るための場所を指定。このファイルはインストールディレクトリーに置かれます。提供される CloudFormation テンプレートでは、クラスターの Ignition 設定ファイルは S3 バケットから送られることを前提としています。このファイルを別の場所から送ることを選択する場合は、テンプレートを変更する必要があります。
  • 提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform インストールに必要なブートストラップノードを表します。
注記

提供される CloudFormation テンプレートを使用してブートストラップノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。

手順

  1. 以下のコマンドを実行してバケットを作成します。

    $ aws s3 mb s3://<cluster-name>-infra 1
    1
    <cluster-name>-infra はバケット名です。install-config.yaml ファイルを作成する際に、<cluster-name> をクラスターに指定された名前に置き換えます。

    以下の場合は、s3:// スキーマではなく、S3 バケットに事前に署名された URL を使用する必要があります。

    • AWS SDK とは異なるエンドポイントを持つリージョンへのデプロイ。
    • プロキシーをデプロイする。
    • カスタムエンドポイントを指定します。
  2. 以下のコマンドを実行して bootstrap.ign Ignition 設定ファイルをバケットにアップロードします。

    $ aws s3 cp <installation_directory>/bootstrap.ign s3://<cluster-name>-infra/bootstrap.ign 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  3. 以下のコマンドを実行して、ファイルがアップロードされていることを確認します。

    $ aws s3 ls s3://<cluster-name>-infra/

    出力例

    2019-04-03 16:15:16     314878 bootstrap.ign

    注記

    ブートストラップ Ignition 設定ファイルには、X.509 キーのようなシークレットが含まれません。以下の手順では、S3 バケットの基本的なセキュリティーを提供します。追加のセキュリティーを提供するには、OpenShift IAM ユーザーなどの特定のユーザーのみがバケットに含まれるオブジェクトにアクセスできるように S3 バケットポリシーを有効にできます。S3 を完全に回避し、ブートストラップマシンが到達できるアドレスからブートストラップ Ignition 設定ファイルを送ることができます。

  4. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "AllowedBootstrapSshCidr", 5
        "ParameterValue": "0.0.0.0/0" 6
      },
      {
        "ParameterKey": "PublicSubnet", 7
        "ParameterValue": "subnet-<random_string>" 8
      },
      {
        "ParameterKey": "MasterSecurityGroupId", 9
        "ParameterValue": "sg-<random_string>" 10
      },
      {
        "ParameterKey": "VpcId", 11
        "ParameterValue": "vpc-<random_string>" 12
      },
      {
        "ParameterKey": "BootstrapIgnitionLocation", 13
        "ParameterValue": "s3://<bucket_name>/bootstrap.ign" 14
      },
      {
        "ParameterKey": "AutoRegisterELB", 15
        "ParameterValue": "yes" 16
      },
      {
        "ParameterKey": "RegisterNlbIpTargetsLambdaArn", 17
        "ParameterValue": "arn:aws:lambda:<aws_region>:<account_number>:function:<dns_stack_name>-RegisterNlbIpTargets-<random_string>" 18
      },
      {
        "ParameterKey": "ExternalApiTargetGroupArn", 19
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Exter-<random_string>" 20
      },
      {
        "ParameterKey": "InternalApiTargetGroupArn", 21
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 22
      },
      {
        "ParameterKey": "InternalServiceTargetGroupArn", 23
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 24
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてブートストラップノードに使用する最新の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    有効な AWS::EC2::Image::Id 値を指定します。
    5
    ブートストラップノードへの SSH アクセスを許可する CIDR ブロック。
    6
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    7
    ブートストラップを起動するために VPC に関連付けられるパブリックサブネット。
    8
    VPC の CloudFormation テンプレートの出力から PublicSubnetIds 値を指定します。
    9
    マスターセキュリティーグループ ID (一時ルールの登録用)。
    10
    セキュリティーグループおよびロールの CloudFormation テンプレートから MasterSecurityGroupId 値を指定します。
    11
    作成されたリソースが属する VPC。
    12
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
    13
    ブートストラップの Ignition 設定ファイルをフェッチする場所。
    14
    s3://<bucket_name>/bootstrap.ign の形式で S3 バケットおよびファイル名を指定します。
    15
    ネットワークロードバランサー (NLB) を登録するかどうか。
    16
    yes または no を指定します。yes を指定する場合、Lambda Amazon Resource Name (ARN) の値を指定する必要があります。
    17
    NLB IP ターゲット登録 lambda グループの ARN。
    18
    DNS および負荷分散の CloudFormation テンプレートの出力から RegisterNlbIpTargetsLambda 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    19
    外部 API ロードバランサーのターゲットグループの ARN。
    20
    DNS および負荷分散の CloudFormation テンプレートの出力から ExternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    21
    内部 API ロードバランサーのターゲットグループの ARN。
    22
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    23
    内部サービスバランサーのターゲットグループの ARN。
    24
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalServiceTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
  5. このトピックのブートストラップマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。
  6. オプション: プロキシーを使用してクラスターをデプロイする場合は、テンプレートの ignition を更新して ignition.config.proxy フィールドを追加する必要があります。さらに、Amazon EC2、Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加している場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
  7. CloudFormation テンプレートを起動し、ブートストラップノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-bootstrap などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role および AWS::IAM::InstanceProfile リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-bootstrap/12944486-2add-11eb-9dee-12dace8e3a83

  8. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    BootstrapInstanceId

    ブートストラップインスタンス ID。

    BootstrapPublicIp

    ブートストラップノードのパブリック IP アドレス。

    BootstrapPrivateIp

    ブートストラップノードのプライベート IP アドレス。

4.3.9.1. ブートストラップマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイできます。

例4.21 ブートストラップマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Bootstrap (EC2 Instance, Security Groups and IAM)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  AllowedBootstrapSshCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|1[0-9]|2[0-9]|3[0-2]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/0-32.
    Default: 0.0.0.0/0
    Description: CIDR block to allow SSH access to the bootstrap node.
    Type: String
  PublicSubnet:
    Description: The public subnet to launch the bootstrap node into.
    Type: AWS::EC2::Subnet::Id
  MasterSecurityGroupId:
    Description: The master security group ID for registering temporary rules.
    Type: AWS::EC2::SecurityGroup::Id
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id
  BootstrapIgnitionLocation:
    Default: s3://my-s3-bucket/bootstrap.ign
    Description: Ignition config file location.
    Type: String
  AutoRegisterELB:
    Default: "yes"
    AllowedValues:
    - "yes"
    - "no"
    Description: Do you want to invoke NLB registration, which requires a Lambda ARN parameter?
    Type: String
  RegisterNlbIpTargetsLambdaArn:
    Description: ARN for NLB IP target registration lambda.
    Type: String
  ExternalApiTargetGroupArn:
    Description: ARN for external API load balancer target group.
    Type: String
  InternalApiTargetGroupArn:
    Description: ARN for internal API load balancer target group.
    Type: String
  InternalServiceTargetGroupArn:
    Description: ARN for internal service load balancer target group.
    Type: String
  BootstrapInstanceType:
    Description: Instance type for the bootstrap EC2 instance
    Default: "i3.large"
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - RhcosAmi
      - BootstrapIgnitionLocation
      - MasterSecurityGroupId
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - AllowedBootstrapSshCidr
      - PublicSubnet
    - Label:
        default: "Load Balancer Automation"
      Parameters:
      - AutoRegisterELB
      - RegisterNlbIpTargetsLambdaArn
      - ExternalApiTargetGroupArn
      - InternalApiTargetGroupArn
      - InternalServiceTargetGroupArn
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      AllowedBootstrapSshCidr:
        default: "Allowed SSH Source"
      PublicSubnet:
        default: "Public Subnet"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      BootstrapIgnitionLocation:
        default: "Bootstrap Ignition Source"
      MasterSecurityGroupId:
        default: "Master Security Group ID"
      AutoRegisterELB:
        default: "Use Provided ELB Automation"

Conditions:
  DoRegistration: !Equals ["yes", !Ref AutoRegisterELB]

Resources:
  BootstrapIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "bootstrap", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action: "ec2:Describe*"
            Resource: "*"
          - Effect: "Allow"
            Action: "ec2:AttachVolume"
            Resource: "*"
          - Effect: "Allow"
            Action: "ec2:DetachVolume"
            Resource: "*"
          - Effect: "Allow"
            Action: "s3:GetObject"
            Resource: "*"

  BootstrapInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Path: "/"
      Roles:
      - Ref: "BootstrapIamRole"

  BootstrapSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Bootstrap Security Group
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref AllowedBootstrapSshCidr
      - IpProtocol: tcp
        ToPort: 19531
        FromPort: 19531
        CidrIp: 0.0.0.0/0
      VpcId: !Ref VpcId

  BootstrapInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      IamInstanceProfile: !Ref BootstrapInstanceProfile
      InstanceType: !Ref BootstrapInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "true"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "BootstrapSecurityGroup"
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "PublicSubnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"replace":{"source":"${S3Loc}"}},"version":"3.1.0"}}'
        - {
          S3Loc: !Ref BootstrapIgnitionLocation
        }

  RegisterBootstrapApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

  RegisterBootstrapInternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

  RegisterBootstrapInternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

Outputs:
  BootstrapInstanceId:
    Description: Bootstrap Instance ID.
    Value: !Ref BootstrapInstance

  BootstrapPublicIp:
    Description: The bootstrap node public IP address.
    Value: !GetAtt BootstrapInstance.PublicIp

  BootstrapPrivateIp:
    Description: The bootstrap node private IP address.
    Value: !GetAtt BootstrapInstance.PrivateIp

関連情報

4.3.10. AWS でのコントロールプレーンの作成

クラスターで使用するコントロールプレーンマシンを Amazon Web Services (AWS) で作成する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、コントロールプレーンノードを表す AWS リソースのスタックを作成できます。

重要

CloudFormation テンプレートは、3 つのコントロールプレーンノードを表すスタックを作成します。

注記

提供される CloudFormation テンプレートを使用してコントロールプレーンノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "AutoRegisterDNS", 5
        "ParameterValue": "yes" 6
      },
      {
        "ParameterKey": "PrivateHostedZoneId", 7
        "ParameterValue": "<random_string>" 8
      },
      {
        "ParameterKey": "PrivateHostedZoneName", 9
        "ParameterValue": "mycluster.example.com" 10
      },
      {
        "ParameterKey": "Master0Subnet", 11
        "ParameterValue": "subnet-<random_string>" 12
      },
      {
        "ParameterKey": "Master1Subnet", 13
        "ParameterValue": "subnet-<random_string>" 14
      },
      {
        "ParameterKey": "Master2Subnet", 15
        "ParameterValue": "subnet-<random_string>" 16
      },
      {
        "ParameterKey": "MasterSecurityGroupId", 17
        "ParameterValue": "sg-<random_string>" 18
      },
      {
        "ParameterKey": "IgnitionLocation", 19
        "ParameterValue": "https://api-int.<cluster_name>.<domain_name>:22623/config/master" 20
      },
      {
        "ParameterKey": "CertificateAuthorities", 21
        "ParameterValue": "data:text/plain;charset=utf-8;base64,ABC...xYz==" 22
      },
      {
        "ParameterKey": "MasterInstanceProfileName", 23
        "ParameterValue": "<roles_stack>-MasterInstanceProfile-<random_string>" 24
      },
      {
        "ParameterKey": "MasterInstanceType", 25
        "ParameterValue": "" 26
      },
      {
        "ParameterKey": "AutoRegisterELB", 27
        "ParameterValue": "yes" 28
      },
      {
        "ParameterKey": "RegisterNlbIpTargetsLambdaArn", 29
        "ParameterValue": "arn:aws:lambda:<aws_region>:<account_number>:function:<dns_stack_name>-RegisterNlbIpTargets-<random_string>" 30
      },
      {
        "ParameterKey": "ExternalApiTargetGroupArn", 31
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Exter-<random_string>" 32
      },
      {
        "ParameterKey": "InternalApiTargetGroupArn", 33
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 34
      },
      {
        "ParameterKey": "InternalServiceTargetGroupArn", 35
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 36
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてコントロールプレーンマシンに使用する最新の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    AWS::EC2::Image::Id 値を指定します。
    5
    DNS etcd 登録を実行するかどうか。
    6
    yes または no を指定します。yes を指定する場合、ホストゾーンの情報を指定する必要があります。
    7
    etcd ターゲットの登録に使用する Route 53 プライベートゾーン ID。
    8
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateHostedZoneId 値を指定します。
    9
    ターゲットの登録に使用する Route 53 ゾーン。
    10
    <cluster_name>.<domain_name> を指定します。ここで、<domain_name> はクラスターの install-config.yaml ファイルの生成時に使用した Route 53 ベースドメインです。AWS コンソールに表示される末尾のピリド (.) は含めないでください。
    11 13 15
    コントロールプレーンマシンの起動に使用するサブネット (プライベートが望ましい)。
    12 14 16
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateSubnets 値のサブネットを指定します。
    17
    コントロールプレーンノードに関連付けるマスターセキュリティーグループ ID。
    18
    セキュリティーグループおよびロールの CloudFormation テンプレートから MasterSecurityGroupId 値を指定します。
    19
    コントロールプレーンの Ignition 設定ファイルをフェッチする場所。
    20
    生成される Ignition 設定ファイルの場所を指定します (https://api-int.<cluster_name>.<domain_name>:22623/config/master)。
    21
    使用する base64 でエンコードされた認証局の文字列。
    22
    インストールディレクトリーにある master.ign ファイルから値を指定します。この値は、data:text/plain;charset=utf-8;base64,ABC…​xYz== 形式の長い文字列です。
    23
    コントロールプレーンノードに関連付ける IAM プロファイル。
    24
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から MasterInstanceProfile パラメーターの値を指定します。
    25
    選択したアーキテクチャーに基づいてコントロールプレーンマシンに使用する AWS インスタンスのタイプ。
    26
    インスタンスタイプの値は、コントロールプレーンマシンの最小リソース要件に対応します。たとえば、m6i.xlarge は AMD64 のタイプであり、m6g.xlarge は、ARM64 のタイプです。
    27
    ネットワークロードバランサー (NLB) を登録するかどうか。
    28
    yes または no を指定します。yes を指定する場合、Lambda Amazon Resource Name (ARN) の値を指定する必要があります。
    29
    NLB IP ターゲット登録 lambda グループの ARN。
    30
    DNS および負荷分散の CloudFormation テンプレートの出力から RegisterNlbIpTargetsLambda 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    31
    外部 API ロードバランサーのターゲットグループの ARN。
    32
    DNS および負荷分散の CloudFormation テンプレートの出力から ExternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    33
    内部 API ロードバランサーのターゲットグループの ARN。
    34
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    35
    内部サービスバランサーのターゲットグループの ARN。
    36
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalServiceTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
  2. このトピックのコントロールプレーンマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。
  3. m5 インスタンスタイプを MasterInstanceType の値として指定している場合、そのインスタンスタイプを CloudFormation テンプレートの MasterInstanceType.AllowedValues パラメーターに追加します。
  4. CloudFormation テンプレートを起動し、コントロールプレーンノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-control-plane などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-control-plane/21c7e2b0-2ee2-11eb-c6f6-0aa34627df4b

    注記

    CloudFormation テンプレートは、3 つのコントロールプレーンノードを表すスタックを作成します。

  5. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>
4.3.10.1. コントロールプレーンマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。

例4.22 コントロールプレーンマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Node Launch (EC2 master instances)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag nodes for the kubelet cloud provider.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  AutoRegisterDNS:
    Default: ""
    Description: unused
    Type: String
  PrivateHostedZoneId:
    Default: ""
    Description: unused
    Type: String
  PrivateHostedZoneName:
    Default: ""
    Description: unused
    Type: String
  Master0Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  Master1Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  Master2Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  MasterSecurityGroupId:
    Description: The master security group ID to associate with master nodes.
    Type: AWS::EC2::SecurityGroup::Id
  IgnitionLocation:
    Default: https://api-int.$CLUSTER_NAME.$DOMAIN:22623/config/master
    Description: Ignition config file location.
    Type: String
  CertificateAuthorities:
    Default: data:text/plain;charset=utf-8;base64,ABC...xYz==
    Description: Base64 encoded certificate authority string to use.
    Type: String
  MasterInstanceProfileName:
    Description: IAM profile to associate with master nodes.
    Type: String
  MasterInstanceType:
    Default: m5.xlarge
    Type: String

  AutoRegisterELB:
    Default: "yes"
    AllowedValues:
    - "yes"
    - "no"
    Description: Do you want to invoke NLB registration, which requires a Lambda ARN parameter?
    Type: String
  RegisterNlbIpTargetsLambdaArn:
    Description: ARN for NLB IP target registration lambda. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  ExternalApiTargetGroupArn:
    Description: ARN for external API load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  InternalApiTargetGroupArn:
    Description: ARN for internal API load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  InternalServiceTargetGroupArn:
    Description: ARN for internal service load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - MasterInstanceType
      - RhcosAmi
      - IgnitionLocation
      - CertificateAuthorities
      - MasterSecurityGroupId
      - MasterInstanceProfileName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - AllowedBootstrapSshCidr
      - Master0Subnet
      - Master1Subnet
      - Master2Subnet
    - Label:
        default: "Load Balancer Automation"
      Parameters:
      - AutoRegisterELB
      - RegisterNlbIpTargetsLambdaArn
      - ExternalApiTargetGroupArn
      - InternalApiTargetGroupArn
      - InternalServiceTargetGroupArn
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      Master0Subnet:
        default: "Master-0 Subnet"
      Master1Subnet:
        default: "Master-1 Subnet"
      Master2Subnet:
        default: "Master-2 Subnet"
      MasterInstanceType:
        default: "Master Instance Type"
      MasterInstanceProfileName:
        default: "Master Instance Profile Name"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      BootstrapIgnitionLocation:
        default: "Master Ignition Source"
      CertificateAuthorities:
        default: "Ignition CA String"
      MasterSecurityGroupId:
        default: "Master Security Group ID"
      AutoRegisterELB:
        default: "Use Provided ELB Automation"

Conditions:
  DoRegistration: !Equals ["yes", !Ref AutoRegisterELB]

Resources:
  Master0:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master0Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster0:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  RegisterMaster0InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  RegisterMaster0InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  Master1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master1Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster1:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  RegisterMaster1InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  RegisterMaster1InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  Master2:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master2Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster2:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

  RegisterMaster2InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

  RegisterMaster2InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

Outputs:
  PrivateIPs:
    Description: The control-plane node private IP addresses.
    Value:
      !Join [
        ",",
        [!GetAtt Master0.PrivateIp, !GetAtt Master1.PrivateIp, !GetAtt Master2.PrivateIp]
      ]

関連情報

4.3.11. AWS でのワーカーノードの作成

クラスターで使用するワーカーノードを Amazon Web Services (AWS) で作成できます。

注記

3 ノードクラスターをインストールする場合は、この手順をスキップしてください。3 ノードクラスターは、コンピュートマシンとしても機能する 3 つのコントロールプレーンマシンで構成されます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、ワーカーノードを表す AWS リソースのスタックを作成できます。

重要

CloudFormation テンプレートは、1 つのワーカーノードを表すスタックを作成します。それぞれのワーカーノードにスタックを作成する必要があります。

注記

提供される CloudFormation テンプレートを使用してワーカーノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。
  • コントロールプレーンマシンを作成している。

手順

  1. CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "Subnet", 5
        "ParameterValue": "subnet-<random_string>" 6
      },
      {
        "ParameterKey": "WorkerSecurityGroupId", 7
        "ParameterValue": "sg-<random_string>" 8
      },
      {
        "ParameterKey": "IgnitionLocation", 9
        "ParameterValue": "https://api-int.<cluster_name>.<domain_name>:22623/config/worker" 10
      },
      {
        "ParameterKey": "CertificateAuthorities", 11
        "ParameterValue": "" 12
      },
      {
        "ParameterKey": "WorkerInstanceProfileName", 13
        "ParameterValue": "" 14
      },
      {
        "ParameterKey": "WorkerInstanceType", 15
        "ParameterValue": "" 16
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてワーカーノードに使用する現在の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    AWS::EC2::Image::Id 値を指定します。
    5
    ワーカーノードを起動するためのサブネット (プライベートであることが望ましい)。
    6
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateSubnets 値のサブネットを指定します。
    7
    ワーカーノードに関連付けるワーカーセキュリティーグループ ID。
    8
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から WorkerSecurityGroupId 値を指定します。
    9
    ブートストラップ Ignition 設定ファイルを取得する場所。
    10
    生成される Ignition 設定の場所を指定します。 https://api-int.<cluster_name>.<domain_name>:22623/config/worker
    11
    使用する base64 でエンコードされた認証局の文字列。
    12
    インストールディレクトリーにある worker.ign ファイルから値を指定します。この値は、data:text/plain;charset=utf-8;base64,ABC…​xYz== 形式の長い文字列です。
    13
    ワーカーロールに関連付ける IAM プロファイル。
    14
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から WorkerInstanceProfile パラメーターの値を指定します。
    15
    選択したアーキテクチャーに基づいてコンピュートマシンに使用する AWS インスタンスのタイプ。
    16
    インスタンスタイプの値は、コンピュートマシンの最小リソース要件に対応します。たとえば、m6i.large は AMD64 のタイプであり、m6g.large は ARM64 のタイプです。
  2. このトピックのワーカーマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なネットワークオブジェクトおよびロードバランサーを記述しています。
  3. オプション: m5 インスタンスタイプを WorkerInstanceType の値として指定した場合は、そのインスタンスタイプを CloudFormation テンプレートの WorkerInstanceType.AllowedValues パラメーターに追加します。
  4. オプション: AWS Marketplace イメージを使用してデプロイする場合は、サブスクリプションから取得した AMI ID で Worker0.type.properties.ImageID パラメーターを更新します。
  5. CloudFormation テンプレートを使用して、ワーカーノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml \ 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-worker-1 などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-worker-1/729ee301-1c2a-11eb-348f-sd9888c65b59

    注記

    CloudFormation テンプレートは、1 つのワーカーノードを表すスタックを作成します。

  6. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>
  7. クラスターに作成するワーカーマシンが十分な数に達するまでワーカースタックの作成を継続します。同じテンプレートおよびパラメーターファイルを参照し、異なるスタック名を指定してワーカースタックをさらに作成することができます。

    重要

    2 つ以上のワーカーマシンを作成する必要があるため、この CloudFormation テンプレートを使用する 2 つ以上のスタックを作成する必要があります。

4.3.11.1. ワーカーマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。

例4.23 ワーカーマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Node Launch (EC2 worker instance)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag nodes for the kubelet cloud provider.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  Subnet:
    Description: The subnets, recommend private, to launch the worker nodes into.
    Type: AWS::EC2::Subnet::Id
  WorkerSecurityGroupId:
    Description: The worker security group ID to associate with worker nodes.
    Type: AWS::EC2::SecurityGroup::Id
  IgnitionLocation:
    Default: https://api-int.$CLUSTER_NAME.$DOMAIN:22623/config/worker
    Description: Ignition config file location.
    Type: String
  CertificateAuthorities:
    Default: data:text/plain;charset=utf-8;base64,ABC...xYz==
    Description: Base64 encoded certificate authority string to use.
    Type: String
  WorkerInstanceProfileName:
    Description: IAM profile to associate with worker nodes.
    Type: String
  WorkerInstanceType:
    Default: m5.large
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - WorkerInstanceType
      - RhcosAmi
      - IgnitionLocation
      - CertificateAuthorities
      - WorkerSecurityGroupId
      - WorkerInstanceProfileName
    - Label:
        default: "Network Configuration"
      Parameters:
      - Subnet
    ParameterLabels:
      Subnet:
        default: "Subnet"
      InfrastructureName:
        default: "Infrastructure Name"
      WorkerInstanceType:
        default: "Worker Instance Type"
      WorkerInstanceProfileName:
        default: "Worker Instance Profile Name"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      IgnitionLocation:
        default: "Worker Ignition Source"
      CertificateAuthorities:
        default: "Ignition CA String"
      WorkerSecurityGroupId:
        default: "Worker Security Group ID"

Resources:
  Worker0:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref WorkerInstanceProfileName
      InstanceType: !Ref WorkerInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "WorkerSecurityGroupId"
        SubnetId: !Ref "Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

Outputs:
  PrivateIP:
    Description: The compute node private IP address.
    Value: !GetAtt Worker0.PrivateIp

関連情報

4.3.12. user-provisioned infrastructure を使用した AWS でのブートストラップシーケンスの初期化

Amazon Web Services (AWS) ですべての必要なインフラストラクチャーを作成した後に、OpenShift Container Platform コントロールプレーンを初期化するブートストラップシーケンスを開始できます。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。
  • コントロールプレーンマシンを作成している。
  • ワーカーノードを作成している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、OpenShift Container Platform コントロールプレーンを初期化するブートストラッププロセスを開始します。

    $ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 20m0s for the Kubernetes API at https://api.mycluster.example.com:6443...
    INFO API v1.30.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    INFO Time elapsed: 1s

    コマンドが FATAL 警告を出さずに終了する場合、OpenShift Container Platform コントロールプレーンは初期化されています。

    注記

    コントロールプレーンの初期化後に、コンピュートノードを設定し、Operator の形式で追加のサービスをインストールします。

関連情報

  • OpenShift Container Platform のインストールの進行中にインストール、ブートストラップ、コントロールプレーンのログを監視する方法の詳細は、インストールの進捗の監視 を参照してください。
  • ブートストラッププロセスに関する問題のトラブルシューティングの詳細は、ブートストラップノードの診断データの収集 を参照してください。
  • AWS EC2 コンソールを使用して、作成される実行中のインスタンスの詳細を表示できます。

4.3.13. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

4.3.14. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.30.3
    master-1  Ready     master  63m  v1.30.3
    master-2  Ready     master  64m  v1.30.3

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (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 が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc 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 が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ 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
    ...

  5. 残りの 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
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.30.3
    master-1  Ready     master  73m  v1.30.3
    master-2  Ready     master  74m  v1.30.3
    worker-0  Ready     worker  11m  v1.30.3
    worker-1  Ready     worker  11m  v1.30.3

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

4.3.15. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.17.0    True        False         False      19m
    baremetal                                  4.17.0    True        False         False      37m
    cloud-credential                           4.17.0    True        False         False      40m
    cluster-autoscaler                         4.17.0    True        False         False      37m
    config-operator                            4.17.0    True        False         False      38m
    console                                    4.17.0    True        False         False      26m
    csi-snapshot-controller                    4.17.0    True        False         False      37m
    dns                                        4.17.0    True        False         False      37m
    etcd                                       4.17.0    True        False         False      36m
    image-registry                             4.17.0    True        False         False      31m
    ingress                                    4.17.0    True        False         False      30m
    insights                                   4.17.0    True        False         False      31m
    kube-apiserver                             4.17.0    True        False         False      26m
    kube-controller-manager                    4.17.0    True        False         False      36m
    kube-scheduler                             4.17.0    True        False         False      36m
    kube-storage-version-migrator              4.17.0    True        False         False      37m
    machine-api                                4.17.0    True        False         False      29m
    machine-approver                           4.17.0    True        False         False      37m
    machine-config                             4.17.0    True        False         False      36m
    marketplace                                4.17.0    True        False         False      37m
    monitoring                                 4.17.0    True        False         False      29m
    network                                    4.17.0    True        False         False      38m
    node-tuning                                4.17.0    True        False         False      37m
    openshift-apiserver                        4.17.0    True        False         False      32m
    openshift-controller-manager               4.17.0    True        False         False      30m
    openshift-samples                          4.17.0    True        False         False      32m
    operator-lifecycle-manager                 4.17.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
    service-ca                                 4.17.0    True        False         False      38m
    storage                                    4.17.0    True        False         False      37m

  2. 利用不可の Operator を設定します。
4.3.15.1. イメージレジストリーストレージの設定

Amazon Web Services はデフォルトのストレージを提供します。つまり、Image Registry Operator はインストール後に利用可能になります。ただし、レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合は、レジストリーストレージを手動で設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

AWS の user-provisioned infrastructure のレジストリーストレージを設定し、OpenShift Container Platform を非表示のリージョンにデプロイできます。詳細は、AWS user-provisioned infrastructure のレジストリー設定 を参照してください。

4.3.15.1.1. user-provisioned infrastructure を使用した AWS のレジストリーストレージの設定

インストール時に、Amazon S3 バケットを作成するにはクラウド認証情報を使用でき、レジストリー Operator がストレージを自動的に設定します。

レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合、以下の手順により S3 バケットを作成し、ストレージを設定することができます。

前提条件

  • user-provisioned infrastructure を使用した AWS 上にクラスターがある。
  • Amazon S3 ストレージの場合、シークレットには以下のキーが含まれることが予想されます。

    • REGISTRY_STORAGE_S3_ACCESSKEY
    • REGISTRY_STORAGE_S3_SECRETKEY

手順

レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合は、以下の手順を使用してください。

  1. バケットライフサイクルポリシー を設定し、1 日以上経過している未完了のマルチパートアップロードを中止します。
  2. configs.imageregistry.operator.openshift.io/cluster にストレージ設定を入力します。

    $ oc edit configs.imageregistry.operator.openshift.io/cluster

    設定例

    storage:
      s3:
        bucket: <bucket-name>
        region: <region-name>

警告

AWS でレジストリーイメージのセキュリティーを保護するには、S3 バケットに対して パブリックアクセスのブロック を実行します。

4.3.15.1.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

4.3.16. ブートストラップリソースの削除

クラスターの初期 Operator 設定の完了後に、Amazon Web Services (AWS) からブートストラップリソースを削除します。

前提条件

  • クラスターの初期 Operator 設定が完了済みです。

手順

  1. ブートストラップリソースを削除します。CloudFormation テンプレートを使用した場合は、そのスタックを削除 します。

    • AWS CLI を使用してスタックを削除します。

      $ aws cloudformation delete-stack --stack-name <name> 1
      1
      <name> は、ブートストラップスタックの名前です。
    • AWS CloudFormation コンソール を使用してスタックを削除します。

4.3.17. Ingress DNS レコードの作成

DNS ゾーン設定を削除した場合には、Ingress ロードバランサーを参照する DNS レコードを手動で作成します。ワイルドカードレコードまたは特定のレコードのいずれかを作成できます。以下の手順では A レコードを使用しますが、CNAME やエイリアスなどの必要な他のレコードタイプを使用できます。

前提条件

  • 独自にプロビジョニングしたインフラストラクチャーを使用する OpenShift Container Platform クラスターを Amazon Web Services (AWS) にデプロイしています。
  • OpenShift CLI (oc) がインストールされている。
  • jq パッケージをインストールしている。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer (Linux, macOS, or Unix) を参照してください。

手順

  1. 作成するルートを決定します。

    • ワイルドカードレコードを作成するには、*.apps.<cluster_name>.<domain_name> を使用します。ここで、<cluster_name> はクラスター名で、<domain_name> は OpenShift Container Platform クラスターの Route 53 ベースドメインです。
    • 特定のレコードを作成するには、以下のコマンドの出力にあるように、クラスターが使用する各ルートにレコードを作成する必要があります。

      $ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes

      出力例

      oauth-openshift.apps.<cluster_name>.<domain_name>
      console-openshift-console.apps.<cluster_name>.<domain_name>
      downloads-openshift-console.apps.<cluster_name>.<domain_name>
      alertmanager-main-openshift-monitoring.apps.<cluster_name>.<domain_name>
      prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<domain_name>

  2. Ingress Operator ロードバランサーのステータスを取得し、使用する外部 IP アドレスの値をメモします。これは EXTERNAL-IP 列に表示されます。

    $ oc -n openshift-ingress get service router-default

    出力例

    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)                      AGE
    router-default   LoadBalancer   172.30.62.215   ab3...28.us-east-2.elb.amazonaws.com   80:31499/TCP,443:30693/TCP   5m

  3. ロードバランサーのホストゾーン ID を見つけます。

    $ aws elb describe-load-balancers | jq -r '.LoadBalancerDescriptions[] | select(.DNSName == "<external_ip>").CanonicalHostedZoneNameID' 1
    1
    <external_ip> には、取得した Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。

    出力例

    Z3AADJGX6KTTL2

    このコマンドの出力は、ロードバランサーのホストゾーン ID です。

  4. クラスターのドメインのパブリックホストゾーン ID を取得します。

    $ aws route53 list-hosted-zones-by-name \
                --dns-name "<domain_name>" \ 1
                --query 'HostedZones[? Config.PrivateZone != `true` && Name == `<domain_name>.`].Id' 2
                --output text
    1 2
    <domain_name> には、OpenShift Container Platform クラスターの Route 53 ベースドメインを指定します。

    出力例

    /hostedzone/Z3URY6TWQ91KVV

    ドメインのパブリックホストゾーン ID がコマンド出力に表示されます。この例では、これは Z3URY6TWQ91KVV になります。

  5. プライベートゾーンにエイリアスレコードを追加します。

    $ aws route53 change-resource-record-sets --hosted-zone-id "<private_hosted_zone_id>" --change-batch '{ 1
    >   "Changes": [
    >     {
    >       "Action": "CREATE",
    >       "ResourceRecordSet": {
    >         "Name": "\\052.apps.<cluster_domain>", 2
    >         "Type": "A",
    >         "AliasTarget":{
    >           "HostedZoneId": "<hosted_zone_id>", 3
    >           "DNSName": "<external_ip>.", 4
    >           "EvaluateTargetHealth": false
    >         }
    >       }
    >     }
    >   ]
    > }'
    1
    <private_hosted_zone_id> には、DNS および負荷分散の CloudFormation テンプレートの出力から値を指定します。
    2
    <cluster_domain> には、OpenShift Container Platform クラスターで使用するドメインまたはサブドメインを指定します。
    3
    <hosted_zone_id> には、取得したロードバランサーのパブリックホストゾーン ID を指定します。
    4
    <external_ip> には、Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。このパラメーターの値に末尾のピリオド (.) が含まれていることを確認します。
  6. パブリックゾーンにレコードを追加します。

    $ aws route53 change-resource-record-sets --hosted-zone-id "<public_hosted_zone_id>"" --change-batch '{ 1
    >   "Changes": [
    >     {
    >       "Action": "CREATE",
    >       "ResourceRecordSet": {
    >         "Name": "\\052.apps.<cluster_domain>", 2
    >         "Type": "A",
    >         "AliasTarget":{
    >           "HostedZoneId": "<hosted_zone_id>", 3
    >           "DNSName": "<external_ip>.", 4
    >           "EvaluateTargetHealth": false
    >         }
    >       }
    >     }
    >   ]
    > }'
    1
    <public_hosted_zone_id> には、ドメインのパブリックホストゾーンを指定します。
    2
    <cluster_domain> には、OpenShift Container Platform クラスターで使用するドメインまたはサブドメインを指定します。
    3
    <hosted_zone_id> には、取得したロードバランサーのパブリックホストゾーン ID を指定します。
    4
    <external_ip> には、Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。このパラメーターの値に末尾のピリオド (.) が含まれていることを確認します。

4.3.18. user-provisioned infrastructure での AWS インストールの実行

Amazon Web Service (AWS) の user-provisioned infrastructure で OpenShift Container Platform のインストールを開始した後に、デプロイメントを完了するまでモニターします。

前提条件

  • OpenShift Container Platform クラスターのブートストラップノードを、user-provisioned AWS インフラストラクチャーで削除している。
  • oc CLI をインストールしていること。

手順

  • インストールプログラムが含まれるディレクトリーから、クラスターのインストールを完了します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 40m0s for the cluster at https://api.mycluster.example.com:6443 to initialize...
    INFO Waiting up to 10m0s for the openshift-console route to be created...
    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: 1s

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

4.3.19. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

4.3.20. 関連情報

  • AWS CloudFormation スタックの詳細は、Working with stacks を参照してください。

4.3.21. 次のステップ

4.4. user-provisioned infrastructure のネットワークが制限された環境での AWS へのクラスターのインストール

OpenShift Container Platform バージョン 4.17 では、独自に提供するインフラストラクチャーとインストールリリースコンテンツの内部ミラーを使用して、Amazon Web Services (AWS) にクラスターをインストールできます。

重要

ミラーリングされたインストールリリースのコンテンツを使用して OpenShift Container Platform クラスターをインストールすることは可能ですが、クラスターが AWS API を使用するにはインターネットへのアクセスが必要になります。

このインフラストラクチャーを作成する 1 つの方法として、提供される CloudFormation テンプレートを使用できます。テンプレートを変更してインフラストラクチャーをカスタマイズしたり、それらに含まれる情報を使用し、所属する会社のポリシーに基づいて AWS オブジェクトを作成したりできます。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の CloudFormation テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。

4.4.1. 前提条件

4.4.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.17 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、installer-provisioned infrastructure または user-provisioned infrastructure を使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

重要

user-provisioned installation の設定は複雑であるため、user-provisioned infrastructure を使用してネットワークが制限されたインストールを試行する前に、標準的な user-provisioned infrastructure を実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。

4.4.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

4.4.3. AWS のインストールファイルの作成

user-provisioned infrastructure を使用して OpenShift Container Platform を Amazon Web Services (AWS) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。

4.4.3.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 設定ファイルを再び作成する必要はありません。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. 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

  3. オプション: インストールプログラムで 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
    ...

  4. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    variant: openshift
    version: 4.17.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 1
        partitions:
        - label: var
          start_mib: <partition_start_offset> 2
          size_mib: <partition_size> 3
          number: 5
      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 パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  5. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  6. 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) システムをインストールするためにインストール手順への入力として使用できます。

4.4.3.2. インストール設定ファイルの作成

インストールプログラムがクラスターをデプロイするために必要なインストール設定ファイルを生成し、カスタマイズします。

前提条件

  • user-provisioned infrastructure 用の OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • Red Hat が公開している付属の Red Hat Enterprise Linux CoreOS (RHCOS) AMI のある AWS リージョンにクラスターをデプロイしようとしている。カスタム AMI が必要な AWS リージョン (AWS GovCloud リージョンなど) にデプロイする場合は、install-config.yaml ファイルを手動で作成する必要があります。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
      重要

      空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして aws を選択します。
      3. AWS プロファイルをコンピューターに保存していない場合、インストールプログラムを実行するように設定したユーザーの AWS アクセスキー ID およびシークレットアクセスキーを入力します。

        注記

        AWS アクセスキー ID およびシークレットアクセスキーは、インストールホストの現行ユーザーのホームディレクトリーの ~/.aws/credentials に保存されます。エクスポートされたプロファイルの認証情報がファイルにない場合は、インストールプログラムにより認証情報の入力が求めるプロンプトが出されます。インストールプログラムに指定する認証情報は、ファイルに保存されます。

      4. クラスターのデプロイ先とする AWS リージョンを選択します。
      5. クラスターに設定した Route 53 サービスのベースドメインを選択します。
      6. クラスターの記述名を入力します。
      7. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
  2. install-config.yaml ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。

      pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}'

      <local_registry> には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----
    3. イメージコンテンツリソースを追加します。

      imageContentSources:
      - mirrors:
        - <local_registry>/<local_repository_name>/release
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - <local_registry>/<local_repository_name>/release
        source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

      コマンドの出力の imageContentSources セクションを使用して、リポジトリー、またはネットワークが制限されたネットワークに取り込んだメディアからのコンテンツをミラーリングする際に使用した値をミラーリングします。

    4. オプション: パブリッシュストラテジーを Internal に設定します。

      publish: Internal

      このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。

  3. オプション: install-config.yaml ファイルをバックアップします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

関連情報

4.4.3.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: 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 コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

4.4.3.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 インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
  2. コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml

    これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

  3. コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml
  4. ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
    重要

    user-provisioned infrastructure にクラスターをインストールするときに MachineAPI 機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。

    ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。

  5. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  6. オプション: 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: {}
    1 2
    このセクションを完全に削除します。

    これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。

  7. 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

4.4.4. インフラストラクチャー名の抽出

Ignition 設定ファイルには、Amazon Web Services (AWS) でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な AWS リソースを見つけるためにも使用されます。提供される CloudFormation テンプレートにはこのインフラストラクチャー名の参照が含まれるため、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

4.4.5. AWS での VPC の作成

OpenShift Container Platform クラスターで使用する Virtual Private Cloud (VPC) を Amazon Web Services (AWS) で作成する必要があります。VPN およびルートテーブルを含む、各種要件を満たすように VPC をカスタマイズできます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、VPC を表す AWS リソースのスタックを作成できます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "VpcCidr", 1
        "ParameterValue": "10.0.0.0/16" 2
      },
      {
        "ParameterKey": "AvailabilityZoneCount", 3
        "ParameterValue": "1" 4
      },
      {
        "ParameterKey": "SubnetBits", 5
        "ParameterValue": "12" 6
      }
    ]
    1
    VPC の CIDR ブロック。
    2
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    3
    VPC をデプロイするアベイラビリティーゾーンの数。
    4
    1 から 3 の間の整数を指定します。
    5
    各アベイラビリティーゾーン内の各サブネットのサイズ。
    6
    5 から 13 の間の整数を指定します。ここで、5/27 であり、13/19 です。
  2. このトピックのVPC の CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  3. CloudFormation テンプレートを起動し、VPC を表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-vpc などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f

  4. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    VpcId

    VPC の ID。

    PublicSubnetIds

    新規パブリックサブネットの ID。

    PrivateSubnetIds

    新規プライベートサブネットの ID。

4.4.5.1. VPC の CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。

例4.24 VPC の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable
  PrivateRouteTableIds:
    Description: Private Route table IDs
    Value:
      !Join [
        ",",
        [
          !Join ["=", [
            !Select [0, "Fn::GetAZs": !Ref "AWS::Region"],
            !Ref PrivateRouteTable
          ]],
          !If [DoAz2,
               !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]],
               !Ref "AWS::NoValue"
          ],
          !If [DoAz3,
               !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]],
               !Ref "AWS::NoValue"
          ]
        ]
      ]

4.4.6. AWS でのネットワークおよび負荷分散コンポーネントの作成

OpenShift Container Platform クラスターで使用できるネットワークおよび負荷分散 (classic または network) を Amazon Web Services (AWS) で設定する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform クラスターに必要なネットワークおよび負荷分散コンポーネントを表します。テンプレートは、ホストゾーンおよびサブネットタグも作成します。

単一 Virtual Private Cloud 内でテンプレートを複数回実行することができます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。

手順

  1. クラスターの install-config.yaml ファイルに指定した Route 53 ベースドメインのホストゾーン ID を取得します。以下のコマンドを実行して、ホストゾーンの詳細を取得できます。

    $ aws route53 list-hosted-zones-by-name --dns-name <route53_domain> 1
    1
    <route53_domain> に、クラスターの install-config.yaml ファイルを生成した時に作成した Route 53 ベースドメインを指定します。

    出力例

    mycluster.example.com.	False	100
    HOSTEDZONES	65F8F38E-2268-B835-E15C-AB55336FCBFA	/hostedzone/Z21IXYZABCZ2A4	mycluster.example.com.	10

    この出力例では、ホストゾーン ID は Z21IXYZ3-2Z2A4 です。

  2. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "ClusterName", 1
        "ParameterValue": "mycluster" 2
      },
      {
        "ParameterKey": "InfrastructureName", 3
        "ParameterValue": "mycluster-<random_string>" 4
      },
      {
        "ParameterKey": "HostedZoneId", 5
        "ParameterValue": "<random_string>" 6
      },
      {
        "ParameterKey": "HostedZoneName", 7
        "ParameterValue": "example.com" 8
      },
      {
        "ParameterKey": "PublicSubnets", 9
        "ParameterValue": "subnet-<random_string>" 10
      },
      {
        "ParameterKey": "PrivateSubnets", 11
        "ParameterValue": "subnet-<random_string>" 12
      },
      {
        "ParameterKey": "VpcId", 13
        "ParameterValue": "vpc-<random_string>" 14
      }
    ]
    1
    ホスト名などに使用する短いクラスター名。
    2
    クラスターの install-config.yaml ファイルを生成した時に使用したクラスター名を指定します。
    3
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    4
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    5
    ターゲットの登録に使用する Route 53 パブリックトゾーン ID。
    6
    Z21IXYZABCZ2A4 に類する形式の Route 53 パブリックゾーン ID を指定します。この値は AWS コンソールから取得できます。
    7
    ターゲットの登録に使用する Route 53 ゾーン。
    8
    クラスターの install-config.yaml ファイルを生成した時に使用した Route 53 ベースドメインを指定します。AWS コンソールに表示される末尾のピリド (.) は含めないでください。
    9
    VPC 用に作成したパブリックサブネット。
    10
    VPC の CloudFormation テンプレートの出力から PublicSubnetIds 値を指定します。
    11
    VPC 用に作成したプライベートサブネット。
    12
    VPC の CloudFormation テンプレートの出力から PrivateSubnetIds 値を指定します。
    13
    クラスター用に作成した VPC。
    14
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
  3. このトピックのネットワークおよびロードバランサーの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なネットワークおよび負荷分散オブジェクトを記述しています。

    重要

    AWS government またはシークレットリージョンにクラスターをデプロイする場合は、CloudFormation テンプレートの InternalApiServerRecord を更新して、CNAME レコードを使用する必要があります。ALIAS タイプのレコードは、AWS 政府リージョンではサポートされません。

  4. CloudFormation テンプレートを起動し、ネットワークおよび負荷分散コンポーネントを提供する AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-dns などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-dns/cd3e5de0-2fd4-11eb-5cf0-12be5c33a183

  5. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    PrivateHostedZoneId

    プライベート DNS のホストゾーン ID。

    ExternalApiLoadBalancerName

    外部 API ロードバランサーのフルネーム。

    InternalApiLoadBalancerName

    内部 API ロードバランサーのフルネーム。

    ApiServerDnsName

    API サーバーの完全ホスト名。

    RegisterNlbIpTargetsLambda

    これらのロードバランサーの登録/登録解除に役立つ Lambda ARN。

    ExternalApiTargetGroupArn

    外部 API ターゲットグループの ARN。

    InternalApiTargetGroupArn

    内部 API ターゲットグループの ARN。

    InternalServiceTargetGroupArn

    内部サービスターゲットグループの ARN。

4.4.6.1. ネットワークおよびロードバランサーの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なネットワークオブジェクトおよびロードバランサーをデプロイすることができます。

例4.25 ネットワークおよびロードバランサーの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Network Elements (Route53 & LBs)

Parameters:
  ClusterName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Cluster name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, representative cluster name to use for host names and other identifying names.
    Type: String
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  HostedZoneId:
    Description: The Route53 public zone ID to register the targets with, such as Z21IXYZABCZ2A4.
    Type: String
  HostedZoneName:
    Description: The Route53 zone to register the targets with, such as example.com. Omit the trailing period.
    Type: String
    Default: "example.com"
  PublicSubnets:
    Description: The internet-facing subnets.
    Type: List<AWS::EC2::Subnet::Id>
  PrivateSubnets:
    Description: The internal subnets.
    Type: List<AWS::EC2::Subnet::Id>
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - ClusterName
      - InfrastructureName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - PublicSubnets
      - PrivateSubnets
    - Label:
        default: "DNS"
      Parameters:
      - HostedZoneName
      - HostedZoneId
    ParameterLabels:
      ClusterName:
        default: "Cluster Name"
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      PublicSubnets:
        default: "Public Subnets"
      PrivateSubnets:
        default: "Private Subnets"
      HostedZoneName:
        default: "Public Hosted Zone Name"
      HostedZoneId:
        default: "Public Hosted Zone ID"

Resources:
  ExtApiElb:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Join ["-", [!Ref InfrastructureName, "ext"]]
      IpAddressType: ipv4
      Subnets: !Ref PublicSubnets
      Type: network

  IntApiElb:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Join ["-", [!Ref InfrastructureName, "int"]]
      Scheme: internal
      IpAddressType: ipv4
      Subnets: !Ref PrivateSubnets
      Type: network

  IntDns:
    Type: "AWS::Route53::HostedZone"
    Properties:
      HostedZoneConfig:
        Comment: "Managed by CloudFormation"
      Name: !Join [".", [!Ref ClusterName, !Ref HostedZoneName]]
      HostedZoneTags:
      - Key: Name
        Value: !Join ["-", [!Ref InfrastructureName, "int"]]
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "owned"
      VPCs:
      - VPCId: !Ref VpcId
        VPCRegion: !Ref "AWS::Region"

  ExternalApiServerRecord:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      Comment: Alias record for the API server
      HostedZoneId: !Ref HostedZoneId
      RecordSets:
      - Name:
          !Join [
            ".",
            ["api", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt ExtApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt ExtApiElb.DNSName

  InternalApiServerRecord:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      Comment: Alias record for the API server
      HostedZoneId: !Ref IntDns
      RecordSets:
      - Name:
          !Join [
            ".",
            ["api", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt IntApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt IntApiElb.DNSName
      - Name:
          !Join [
            ".",
            ["api-int", !Ref ClusterName, !Join ["", [!Ref HostedZoneName, "."]]],
          ]
        Type: A
        AliasTarget:
          HostedZoneId: !GetAtt IntApiElb.CanonicalHostedZoneID
          DNSName: !GetAtt IntApiElb.DNSName

  ExternalApiListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: ExternalApiTargetGroup
      LoadBalancerArn:
        Ref: ExtApiElb
      Port: 6443
      Protocol: TCP

  ExternalApiTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/readyz"
      HealthCheckPort: 6443
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 6443
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  InternalApiListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: InternalApiTargetGroup
      LoadBalancerArn:
        Ref: IntApiElb
      Port: 6443
      Protocol: TCP

  InternalApiTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/readyz"
      HealthCheckPort: 6443
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 6443
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  InternalServiceInternalListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
      - Type: forward
        TargetGroupArn:
          Ref: InternalServiceTargetGroup
      LoadBalancerArn:
        Ref: IntApiElb
      Port: 22623
      Protocol: TCP

  InternalServiceTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      HealthCheckIntervalSeconds: 10
      HealthCheckPath: "/healthz"
      HealthCheckPort: 22623
      HealthCheckProtocol: HTTPS
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 2
      Port: 22623
      Protocol: TCP
      TargetType: ip
      VpcId:
        Ref: VpcId
      TargetGroupAttributes:
      - Key: deregistration_delay.timeout_seconds
        Value: 60

  RegisterTargetLambdaIamRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Join ["-", [!Ref InfrastructureName, "nlb", "lambda", "role"]]
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "lambda.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "master", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref InternalApiTargetGroup
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref InternalServiceTargetGroup
          - Effect: "Allow"
            Action:
              [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets",
              ]
            Resource: !Ref ExternalApiTargetGroup

  RegisterNlbIpTargets:
    Type: "AWS::Lambda::Function"
    Properties:
      Handler: "index.handler"
      Role:
        Fn::GetAtt:
        - "RegisterTargetLambdaIamRole"
        - "Arn"
      Code:
        ZipFile: |
          import json
          import boto3
          import cfnresponse
          def handler(event, context):
            elb = boto3.client('elbv2')
            if event['RequestType'] == 'Delete':
              elb.deregister_targets(TargetGroupArn=event['ResourceProperties']['TargetArn'],Targets=[{'Id': event['ResourceProperties']['TargetIp']}])
            elif event['RequestType'] == 'Create':
              elb.register_targets(TargetGroupArn=event['ResourceProperties']['TargetArn'],Targets=[{'Id': event['ResourceProperties']['TargetIp']}])
            responseData = {}
            cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, event['ResourceProperties']['TargetArn']+event['ResourceProperties']['TargetIp'])
      Runtime: "python3.11"
      Timeout: 120

  RegisterSubnetTagsLambdaIamRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Join ["-", [!Ref InfrastructureName, "subnet-tags-lambda-role"]]
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "lambda.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "subnet-tagging-policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
              [
                "ec2:DeleteTags",
                "ec2:CreateTags"
              ]
            Resource: "arn:aws:ec2:*:*:subnet/*"
          - Effect: "Allow"
            Action:
              [
                "ec2:DescribeSubnets",
                "ec2:DescribeTags"
              ]
            Resource: "*"

  RegisterSubnetTags:
    Type: "AWS::Lambda::Function"
    Properties:
      Handler: "index.handler"
      Role:
        Fn::GetAtt:
        - "RegisterSubnetTagsLambdaIamRole"
        - "Arn"
      Code:
        ZipFile: |
          import json
          import boto3
          import cfnresponse
          def handler(event, context):
            ec2_client = boto3.client('ec2')
            if event['RequestType'] == 'Delete':
              for subnet_id in event['ResourceProperties']['Subnets']:
                ec2_client.delete_tags(Resources=[subnet_id], Tags=[{'Key': 'kubernetes.io/cluster/' + event['ResourceProperties']['InfrastructureName']}]);
            elif event['RequestType'] == 'Create':
              for subnet_id in event['ResourceProperties']['Subnets']:
                ec2_client.create_tags(Resources=[subnet_id], Tags=[{'Key': 'kubernetes.io/cluster/' + event['ResourceProperties']['InfrastructureName'], 'Value': 'shared'}]);
            responseData = {}
            cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, event['ResourceProperties']['InfrastructureName']+event['ResourceProperties']['Subnets'][0])
      Runtime: "python3.11"
      Timeout: 120

  RegisterPublicSubnetTags:
    Type: Custom::SubnetRegister
    Properties:
      ServiceToken: !GetAtt RegisterSubnetTags.Arn
      InfrastructureName: !Ref InfrastructureName
      Subnets: !Ref PublicSubnets

  RegisterPrivateSubnetTags:
    Type: Custom::SubnetRegister
    Properties:
      ServiceToken: !GetAtt RegisterSubnetTags.Arn
      InfrastructureName: !Ref InfrastructureName
      Subnets: !Ref PrivateSubnets

Outputs:
  PrivateHostedZoneId:
    Description: Hosted zone ID for the private DNS, which is required for private records.
    Value: !Ref IntDns
  ExternalApiLoadBalancerName:
    Description: Full name of the external API load balancer.
    Value: !GetAtt ExtApiElb.LoadBalancerFullName
  InternalApiLoadBalancerName:
    Description: Full name of the internal API load balancer.
    Value: !GetAtt IntApiElb.LoadBalancerFullName
  ApiServerDnsName:
    Description: Full hostname of the API server, which is required for the Ignition config files.
    Value: !Join [".", ["api-int", !Ref ClusterName, !Ref HostedZoneName]]
  RegisterNlbIpTargetsLambda:
    Description: Lambda ARN useful to help register or deregister IP targets for these load balancers.
    Value: !GetAtt RegisterNlbIpTargets.Arn
  ExternalApiTargetGroupArn:
    Description: ARN of the external API target group.
    Value: !Ref ExternalApiTargetGroup
  InternalApiTargetGroupArn:
    Description: ARN of the internal API target group.
    Value: !Ref InternalApiTargetGroup
  InternalServiceTargetGroupArn:
    Description: ARN of the internal service target group.
    Value: !Ref InternalServiceTargetGroup
重要

クラスターを AWS government またはシークレットリージョンにデプロイする場合は、InternalApiServerRecord を更新し、CNAME レコードを使用する必要があります。ALIAS タイプのレコードは、AWS 政府リージョンではサポートされません。以下に例を示します。

Type: CNAME
TTL: 10
ResourceRecords:
- !GetAtt IntApiElb.DNSName

関連情報

  • パブリックホストゾーンのリスト表示の詳細は、AWS ドキュメントの Listing public hosted zones を参照してください。

4.4.7. AWS でのセキュリティーグループおよびロールの作成

OpenShift Container Platform クラスターで使用するセキュリティーグループおよびロールを Amazon Web Services (AWS) で作成する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform クラスターに必要なセキュリティーグループおよびロールを表します。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "VpcCidr", 3
        "ParameterValue": "10.0.0.0/16" 4
      },
      {
        "ParameterKey": "PrivateSubnets", 5
        "ParameterValue": "subnet-<random_string>" 6
      },
      {
        "ParameterKey": "VpcId", 7
        "ParameterValue": "vpc-<random_string>" 8
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    VPC の CIDR ブロック。
    4
    x.x.x.x/16-24 の形式で定義した VPC に使用した CIDR ブロックパラメーターを指定します。
    5
    VPC 用に作成したプライベートサブネット。
    6
    VPC の CloudFormation テンプレートの出力から PrivateSubnetIds 値を指定します。
    7
    クラスター用に作成した VPC。
    8
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
  2. このトピックのセキュリティーオブジェクトの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なセキュリティーグループおよびロールを記述しています。
  3. CloudFormation テンプレートを起動し、セキュリティーグループおよびロールを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-sec などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role および AWS::IAM::InstanceProfile リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-sec/03bd4210-2ed7-11eb-6d7a-13fc0b61e9db

  4. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    MasterSecurityGroupId

    マスターセキュリティーグループ ID

    WorkerSecurityGroupId

    ワーカーセキュリティーグループ ID

    MasterInstanceProfile

    マスター IAM インスタンスプロファイル

    WorkerInstanceProfile

    ワーカー IAM インスタンスプロファイル

4.4.7.1. セキュリティーオブジェクトの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なセキュリティーオブジェクトをデプロイすることができます。

例4.26 セキュリティーオブジェクトの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Security Elements (Security Groups & IAM)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  VpcCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.0.0/16
    Description: CIDR block for VPC.
    Type: String
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id
  PrivateSubnets:
    Description: The internal subnets.
    Type: List<AWS::EC2::Subnet::Id>

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - VpcCidr
      - PrivateSubnets
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      VpcCidr:
        default: "VPC CIDR"
      PrivateSubnets:
        default: "Private Subnets"

Resources:
  MasterSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Master Security Group
      SecurityGroupIngress:
      - IpProtocol: icmp
        FromPort: 0
        ToPort: 0
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        ToPort: 6443
        FromPort: 6443
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22623
        ToPort: 22623
        CidrIp: !Ref VpcCidr
      VpcId: !Ref VpcId

  WorkerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Worker Security Group
      SecurityGroupIngress:
      - IpProtocol: icmp
        FromPort: 0
        ToPort: 0
        CidrIp: !Ref VpcCidr
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref VpcCidr
      VpcId: !Ref VpcId

  MasterIngressEtcd:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: etcd
      FromPort: 2379
      ToPort: 2380
      IpProtocol: tcp

  MasterIngressVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  MasterIngressWorkerVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  MasterIngressGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  MasterIngressWorkerGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  MasterIngressIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  MasterIngressIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  MasterIngressIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  MasterIngressWorkerIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  MasterIngressWorkerIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  MasterIngressWorkerIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  MasterIngressInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  MasterIngressWorkerInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  MasterIngressInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  MasterIngressWorkerInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  MasterIngressKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes kubelet, scheduler and controller manager
      FromPort: 10250
      ToPort: 10259
      IpProtocol: tcp

  MasterIngressWorkerKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes kubelet, scheduler and controller manager
      FromPort: 10250
      ToPort: 10259
      IpProtocol: tcp

  MasterIngressIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  MasterIngressWorkerIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  MasterIngressIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  MasterIngressWorkerIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt MasterSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  WorkerIngressVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  WorkerIngressMasterVxlan:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Vxlan packets
      FromPort: 4789
      ToPort: 4789
      IpProtocol: udp

  WorkerIngressGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  WorkerIngressMasterGeneve:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Geneve packets
      FromPort: 6081
      ToPort: 6081
      IpProtocol: udp

  WorkerIngressIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  WorkerIngressIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  WorkerIngressIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  WorkerIngressMasterIpsecIke:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec IKE packets
      FromPort: 500
      ToPort: 500
      IpProtocol: udp

  WorkerIngressMasterIpsecNat:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec NAT-T packets
      FromPort: 4500
      ToPort: 4500
      IpProtocol: udp

  WorkerIngressMasterIpsecEsp:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: IPsec ESP packets
      IpProtocol: 50

  WorkerIngressInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  WorkerIngressMasterInternal:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: tcp

  WorkerIngressInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  WorkerIngressMasterInternalUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal cluster communication
      FromPort: 9000
      ToPort: 9999
      IpProtocol: udp

  WorkerIngressKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes secure kubelet port
      FromPort: 10250
      ToPort: 10250
      IpProtocol: tcp

  WorkerIngressWorkerKube:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Internal Kubernetes communication
      FromPort: 10250
      ToPort: 10250
      IpProtocol: tcp

  WorkerIngressIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  WorkerIngressMasterIngressServices:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: tcp

  WorkerIngressIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt WorkerSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  WorkerIngressMasterIngressServicesUDP:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !GetAtt WorkerSecurityGroup.GroupId
      SourceSecurityGroupId: !GetAtt MasterSecurityGroup.GroupId
      Description: Kubernetes ingress services
      FromPort: 30000
      ToPort: 32767
      IpProtocol: udp

  MasterIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "master", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
            - "ec2:AttachVolume"
            - "ec2:AuthorizeSecurityGroupIngress"
            - "ec2:CreateSecurityGroup"
            - "ec2:CreateTags"
            - "ec2:CreateVolume"
            - "ec2:DeleteSecurityGroup"
            - "ec2:DeleteVolume"
            - "ec2:Describe*"
            - "ec2:DetachVolume"
            - "ec2:ModifyInstanceAttribute"
            - "ec2:ModifyVolume"
            - "ec2:RevokeSecurityGroupIngress"
            - "elasticloadbalancing:AddTags"
            - "elasticloadbalancing:AttachLoadBalancerToSubnets"
            - "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer"
            - "elasticloadbalancing:CreateListener"
            - "elasticloadbalancing:CreateLoadBalancer"
            - "elasticloadbalancing:CreateLoadBalancerPolicy"
            - "elasticloadbalancing:CreateLoadBalancerListeners"
            - "elasticloadbalancing:CreateTargetGroup"
            - "elasticloadbalancing:ConfigureHealthCheck"
            - "elasticloadbalancing:DeleteListener"
            - "elasticloadbalancing:DeleteLoadBalancer"
            - "elasticloadbalancing:DeleteLoadBalancerListeners"
            - "elasticloadbalancing:DeleteTargetGroup"
            - "elasticloadbalancing:DeregisterInstancesFromLoadBalancer"
            - "elasticloadbalancing:DeregisterTargets"
            - "elasticloadbalancing:Describe*"
            - "elasticloadbalancing:DetachLoadBalancerFromSubnets"
            - "elasticloadbalancing:ModifyListener"
            - "elasticloadbalancing:ModifyLoadBalancerAttributes"
            - "elasticloadbalancing:ModifyTargetGroup"
            - "elasticloadbalancing:ModifyTargetGroupAttributes"
            - "elasticloadbalancing:RegisterInstancesWithLoadBalancer"
            - "elasticloadbalancing:RegisterTargets"
            - "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer"
            - "elasticloadbalancing:SetLoadBalancerPoliciesOfListener"
            - "kms:DescribeKey"
            Resource: "*"

  MasterInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Roles:
      - Ref: "MasterIamRole"

  WorkerIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "worker", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action:
            - "ec2:DescribeInstances"
            - "ec2:DescribeRegions"
            Resource: "*"

  WorkerInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Roles:
      - Ref: "WorkerIamRole"

Outputs:
  MasterSecurityGroupId:
    Description: Master Security Group ID
    Value: !GetAtt MasterSecurityGroup.GroupId

  WorkerSecurityGroupId:
    Description: Worker Security Group ID
    Value: !GetAtt WorkerSecurityGroup.GroupId

  MasterInstanceProfile:
    Description: Master IAM Instance Profile
    Value: !Ref MasterInstanceProfile

  WorkerInstanceProfile:
    Description: Worker IAM Instance Profile
    Value: !Ref WorkerInstanceProfile

4.4.8. ストリームメタデータを使用した RHCOS AMI へのアクセス

OpenShift Container Platform では、ストリームメタデータ は、JSON 形式で RHCOS に関する標準化されたメタデータを提供し、メタデータをクラスターに挿入します。ストリームメタデータは、複数のアーキテクチャーをサポートする安定した形式で、自動化を維持するための自己文書化が意図されています。

openshift-installcoreos print-stream-json サブコマンドを使用して、ストリームメタデータ形式のブートイメージに関する情報にアクセスできます。このコマンドは、スクリプト可能でマシン読み取り可能な形式でストリームメタデータを出力する方法を提供します。

user-provisioned installation の場合、openshift-install バイナリーには、AWS AMI などの OpenShift Container Platform での使用がテストされている RHCOS ブートイメージのバージョンへの参照が含まれます。

手順

ストリームメタデータを解析するには、以下のいずれかの方法を使用します。

  • Go プログラムから、https://github.com/coreos/stream-metadata-go の公式の stream-metadata-go ライブラリーを使用します。ライブラリーでサンプルコードを確認することもできます。
  • Python や Ruby などの別のプログラミング言語から、お好みのプログラミング言語の JSON ライブラリーを使用します。
  • jq などの JSON データを処理するコマンドラインユーティリティーから、以下のコマンドを実行します。

    • us-west-1 などの AWS リージョンの現在の x86_64 または aarch64 AMI を出力します。

      x86_64 の場合

      $ openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.images.aws.regions["us-west-1"].image'

      出力例

      ami-0d3e625f84626bbda

      aarch64 の場合

      $ openshift-install coreos print-stream-json | jq -r '.architectures.aarch64.images.aws.regions["us-west-1"].image'

      出力例

      ami-0af1d3b7fa5be2131

      このコマンドの出力は、指定されたアーキテクチャーと us-west-1 リージョンの AWS AMI ID です。AMI はクラスターと同じリージョンに属する必要があります。

4.4.9. AWS インフラストラクチャーの RHCOS AMI

Red Hat は、OpenShift Container Platform ノードに手動で指定できる、さまざまな AWS リージョンおよびインスタンスアーキテクチャーに有効な Red Hat Enterprise Linux CoreOS(RHCOS) AMI を提供します。

注記

また、独自の AMI をインポートすることで、RHCOS AMI がパブリッシュされていないリージョンにインストールすることもできます。

表4.5 x86_64 RHCOS AMIs
AWS ゾーンAWS AMI

af-south-1

ami-019b3e090bb062842

ap-east-1

ami-0cb76d97f77cda0a1

ap-northeast-1

ami-0d7d4b329e5403cfb

ap-northeast-2

ami-02d3789d532feb517

ap-northeast-3

ami-08b82c4899109b707

ap-south-1

ami-0c184f8b5ad8af69d

ap-south-2

ami-0b0525037b9a20e9a

ap-southeast-1

ami-0dbee0006375139a7

ap-southeast-2

ami-043072b1af91be72f

ap-southeast-3

ami-09d8bbf16b228139e

ap-southeast-4

ami-01c6b29e9c57b434b

ca-central-1

ami-06fda1fa0b65b864b

ca-west-1

ami-0141eea486b5e2c43

eu-central-1

ami-0f407de515454fdd0

eu-central-2

ami-062cfad83bc7b71b8

eu-north-1

ami-0af77aba6aebb5086

eu-south-1

ami-04d9da83bc9f854fc

eu-south-2

ami-035d487abf54f0af7

eu-west-1

ami-043dd3b788dbaeb1c

eu-west-2

ami-0c7d0f90a4401b723

eu-west-3

ami-039baa878e1def55f

il-central-1

ami-07d305bf03b2148de

me-central-1

ami-0fc457e8897ccb41a

me-south-1

ami-0af99a751cf682b90

sa-east-1

ami-04a7300f64ee01d68

us-east-1

ami-01b53f2824bf6d426

us-east-2

ami-0565349610e27bd41

us-gov-east-1

ami-0020504fa043fe41d

us-gov-west-1

ami-036798bce4722d3c2

us-west-1

ami-0147c634ad692da52

us-west-2

ami-0c65d71e89d43aa90

表4.6 aarch64 RHCOS AMI
AWS ゾーンAWS AMI

af-south-1

ami-0e585ef53405bebf5

ap-east-1

ami-05f32f1715bb51bda

ap-northeast-1

ami-05ecb62bab0c50e52

ap-northeast-2

ami-0a3ffb2c07c9e4a8d

ap-northeast-3

ami-0ae6746ea17d1042c

ap-south-1

ami-00deb5b08c86060b8

ap-south-2

ami-047a47d5049781e03

ap-southeast-1

ami-09cb598f0d36fde4c

ap-southeast-2

ami-01fe8a7538500f24c

ap-southeast-3

ami-051b3f67dd787d5e9

ap-southeast-4

ami-04d2e14a9eef40143

ca-central-1

ami-0f66973ff12d09356

ca-west-1

ami-0c9f3e2f0470d6d0b

eu-central-1

ami-0a79af8849b425a8a

eu-central-2

ami-0f9f66951c9709471

eu-north-1

ami-0670362aa7eb9032d

eu-south-1

ami-031b24b970eae750b

eu-south-2

ami-0734d2ed55c00a46c

eu-west-1

ami-0a9af75c2649471c0

eu-west-2

ami-0b84155a3672ac44e

eu-west-3

ami-02b51442c612818d4

il-central-1

ami-0d2c47a297d483ce4

me-central-1

ami-0ef3005246bd83b07

me-south-1

ami-0321ca1ee89015eda

sa-east-1

ami-0e63f1103dc71d8ae

us-east-1

ami-0404da96615c73bec

us-east-2

ami-04c3bd7be936f728f

us-gov-east-1

ami-0d30bc0b99b153247

us-gov-west-1

ami-0ee006f84d6aa5045

us-west-1

ami-061bfd61d5cfd7aa6

us-west-2

ami-05ffb8f6f18b8e3f8

4.4.10. AWS でのブートストラップノードの作成

OpenShift Container Platform クラスターの初期化で使用するブートストラップノードを Amazon Web Services (AWS) で作成する必要があります。これは、以下の方法で行います。

  • bootstrap.ign Ignition 設定ファイルをクラスターに送るための場所を指定。このファイルはインストールディレクトリーに置かれます。提供される CloudFormation テンプレートでは、クラスターの Ignition 設定ファイルは S3 バケットから送られることを前提としています。このファイルを別の場所から送ることを選択する場合は、テンプレートを変更する必要があります。
  • 提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、AWS リソースのスタックを作成できます。スタックは、OpenShift Container Platform インストールに必要なブートストラップノードを表します。
注記

提供される CloudFormation テンプレートを使用してブートストラップノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。

手順

  1. 以下のコマンドを実行してバケットを作成します。

    $ aws s3 mb s3://<cluster-name>-infra 1
    1
    <cluster-name>-infra はバケット名です。install-config.yaml ファイルを作成する際に、<cluster-name> をクラスターに指定された名前に置き換えます。

    以下の場合は、s3:// スキーマではなく、S3 バケットに事前に署名された URL を使用する必要があります。

    • AWS SDK とは異なるエンドポイントを持つリージョンへのデプロイ。
    • プロキシーをデプロイする。
    • カスタムエンドポイントを指定します。
  2. 以下のコマンドを実行して bootstrap.ign Ignition 設定ファイルをバケットにアップロードします。

    $ aws s3 cp <installation_directory>/bootstrap.ign s3://<cluster-name>-infra/bootstrap.ign 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  3. 以下のコマンドを実行して、ファイルがアップロードされていることを確認します。

    $ aws s3 ls s3://<cluster-name>-infra/

    出力例

    2019-04-03 16:15:16     314878 bootstrap.ign

    注記

    ブートストラップ Ignition 設定ファイルには、X.509 キーのようなシークレットが含まれません。以下の手順では、S3 バケットの基本的なセキュリティーを提供します。追加のセキュリティーを提供するには、OpenShift IAM ユーザーなどの特定のユーザーのみがバケットに含まれるオブジェクトにアクセスできるように S3 バケットポリシーを有効にできます。S3 を完全に回避し、ブートストラップマシンが到達できるアドレスからブートストラップ Ignition 設定ファイルを送ることができます。

  4. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "AllowedBootstrapSshCidr", 5
        "ParameterValue": "0.0.0.0/0" 6
      },
      {
        "ParameterKey": "PublicSubnet", 7
        "ParameterValue": "subnet-<random_string>" 8
      },
      {
        "ParameterKey": "MasterSecurityGroupId", 9
        "ParameterValue": "sg-<random_string>" 10
      },
      {
        "ParameterKey": "VpcId", 11
        "ParameterValue": "vpc-<random_string>" 12
      },
      {
        "ParameterKey": "BootstrapIgnitionLocation", 13
        "ParameterValue": "s3://<bucket_name>/bootstrap.ign" 14
      },
      {
        "ParameterKey": "AutoRegisterELB", 15
        "ParameterValue": "yes" 16
      },
      {
        "ParameterKey": "RegisterNlbIpTargetsLambdaArn", 17
        "ParameterValue": "arn:aws:lambda:<aws_region>:<account_number>:function:<dns_stack_name>-RegisterNlbIpTargets-<random_string>" 18
      },
      {
        "ParameterKey": "ExternalApiTargetGroupArn", 19
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Exter-<random_string>" 20
      },
      {
        "ParameterKey": "InternalApiTargetGroupArn", 21
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 22
      },
      {
        "ParameterKey": "InternalServiceTargetGroupArn", 23
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 24
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてブートストラップノードに使用する最新の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    有効な AWS::EC2::Image::Id 値を指定します。
    5
    ブートストラップノードへの SSH アクセスを許可する CIDR ブロック。
    6
    x.x.x.x/16-24 形式で CIDR ブロックを指定します。
    7
    ブートストラップを起動するために VPC に関連付けられるパブリックサブネット。
    8
    VPC の CloudFormation テンプレートの出力から PublicSubnetIds 値を指定します。
    9
    マスターセキュリティーグループ ID (一時ルールの登録用)。
    10
    セキュリティーグループおよびロールの CloudFormation テンプレートから MasterSecurityGroupId 値を指定します。
    11
    作成されたリソースが属する VPC。
    12
    VPC の CloudFormation テンプレートの出力から VpcId 値を指定します。
    13
    ブートストラップの Ignition 設定ファイルをフェッチする場所。
    14
    s3://<bucket_name>/bootstrap.ign の形式で S3 バケットおよびファイル名を指定します。
    15
    ネットワークロードバランサー (NLB) を登録するかどうか。
    16
    yes または no を指定します。yes を指定する場合、Lambda Amazon Resource Name (ARN) の値を指定する必要があります。
    17
    NLB IP ターゲット登録 lambda グループの ARN。
    18
    DNS および負荷分散の CloudFormation テンプレートの出力から RegisterNlbIpTargetsLambda 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    19
    外部 API ロードバランサーのターゲットグループの ARN。
    20
    DNS および負荷分散の CloudFormation テンプレートの出力から ExternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    21
    内部 API ロードバランサーのターゲットグループの ARN。
    22
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    23
    内部サービスバランサーのターゲットグループの ARN。
    24
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalServiceTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
  5. このトピックのブートストラップマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。
  6. オプション: プロキシーを使用してクラスターをデプロイする場合は、テンプレートの ignition を更新して ignition.config.proxy フィールドを追加する必要があります。さらに、Amazon EC2、Elastic Load Balancing、および S3 VPC エンドポイントを VPC に追加している場合は、これらのエンドポイントを noProxy フィールドに追加する必要があります。
  7. CloudFormation テンプレートを起動し、ブートストラップノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
         --capabilities CAPABILITY_NAMED_IAM 4
    1
    <name>cluster-bootstrap などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。
    4
    提供されるテンプレートは一部の AWS::IAM::Role および AWS::IAM::InstanceProfile リソースを作成するため、CAPABILITY_NAMED_IAM 機能を明示的に宣言する必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-bootstrap/12944486-2add-11eb-9dee-12dace8e3a83

  8. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>

    StackStatusCREATE_COMPLETE を表示した後に、出力には以下のパラメーターの値が表示されます。これらのパラメーターの値をクラスターを作成するために実行する他の CloudFormation テンプレートに指定する必要があります。

    BootstrapInstanceId

    ブートストラップインスタンス ID。

    BootstrapPublicIp

    ブートストラップノードのパブリック IP アドレス。

    BootstrapPrivateIp

    ブートストラップノードのプライベート IP アドレス。

4.4.10.1. ブートストラップマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイできます。

例4.27 ブートストラップマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Bootstrap (EC2 Instance, Security Groups and IAM)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag cloud resources and identify items owned or used by the cluster.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  AllowedBootstrapSshCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/([0-9]|1[0-9]|2[0-9]|3[0-2]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/0-32.
    Default: 0.0.0.0/0
    Description: CIDR block to allow SSH access to the bootstrap node.
    Type: String
  PublicSubnet:
    Description: The public subnet to launch the bootstrap node into.
    Type: AWS::EC2::Subnet::Id
  MasterSecurityGroupId:
    Description: The master security group ID for registering temporary rules.
    Type: AWS::EC2::SecurityGroup::Id
  VpcId:
    Description: The VPC-scoped resources will belong to this VPC.
    Type: AWS::EC2::VPC::Id
  BootstrapIgnitionLocation:
    Default: s3://my-s3-bucket/bootstrap.ign
    Description: Ignition config file location.
    Type: String
  AutoRegisterELB:
    Default: "yes"
    AllowedValues:
    - "yes"
    - "no"
    Description: Do you want to invoke NLB registration, which requires a Lambda ARN parameter?
    Type: String
  RegisterNlbIpTargetsLambdaArn:
    Description: ARN for NLB IP target registration lambda.
    Type: String
  ExternalApiTargetGroupArn:
    Description: ARN for external API load balancer target group.
    Type: String
  InternalApiTargetGroupArn:
    Description: ARN for internal API load balancer target group.
    Type: String
  InternalServiceTargetGroupArn:
    Description: ARN for internal service load balancer target group.
    Type: String
  BootstrapInstanceType:
    Description: Instance type for the bootstrap EC2 instance
    Default: "i3.large"
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - RhcosAmi
      - BootstrapIgnitionLocation
      - MasterSecurityGroupId
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - AllowedBootstrapSshCidr
      - PublicSubnet
    - Label:
        default: "Load Balancer Automation"
      Parameters:
      - AutoRegisterELB
      - RegisterNlbIpTargetsLambdaArn
      - ExternalApiTargetGroupArn
      - InternalApiTargetGroupArn
      - InternalServiceTargetGroupArn
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      AllowedBootstrapSshCidr:
        default: "Allowed SSH Source"
      PublicSubnet:
        default: "Public Subnet"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      BootstrapIgnitionLocation:
        default: "Bootstrap Ignition Source"
      MasterSecurityGroupId:
        default: "Master Security Group ID"
      AutoRegisterELB:
        default: "Use Provided ELB Automation"

Conditions:
  DoRegistration: !Equals ["yes", !Ref AutoRegisterELB]

Resources:
  BootstrapIamRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Effect: "Allow"
          Principal:
            Service:
            - "ec2.amazonaws.com"
          Action:
          - "sts:AssumeRole"
      Path: "/"
      Policies:
      - PolicyName: !Join ["-", [!Ref InfrastructureName, "bootstrap", "policy"]]
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
          - Effect: "Allow"
            Action: "ec2:Describe*"
            Resource: "*"
          - Effect: "Allow"
            Action: "ec2:AttachVolume"
            Resource: "*"
          - Effect: "Allow"
            Action: "ec2:DetachVolume"
            Resource: "*"
          - Effect: "Allow"
            Action: "s3:GetObject"
            Resource: "*"

  BootstrapInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Path: "/"
      Roles:
      - Ref: "BootstrapIamRole"

  BootstrapSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster Bootstrap Security Group
      SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: 22
        ToPort: 22
        CidrIp: !Ref AllowedBootstrapSshCidr
      - IpProtocol: tcp
        ToPort: 19531
        FromPort: 19531
        CidrIp: 0.0.0.0/0
      VpcId: !Ref VpcId

  BootstrapInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      IamInstanceProfile: !Ref BootstrapInstanceProfile
      InstanceType: !Ref BootstrapInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "true"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "BootstrapSecurityGroup"
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "PublicSubnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"replace":{"source":"${S3Loc}"}},"version":"3.1.0"}}'
        - {
          S3Loc: !Ref BootstrapIgnitionLocation
        }

  RegisterBootstrapApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

  RegisterBootstrapInternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

  RegisterBootstrapInternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt BootstrapInstance.PrivateIp

Outputs:
  BootstrapInstanceId:
    Description: Bootstrap Instance ID.
    Value: !Ref BootstrapInstance

  BootstrapPublicIp:
    Description: The bootstrap node public IP address.
    Value: !GetAtt BootstrapInstance.PublicIp

  BootstrapPrivateIp:
    Description: The bootstrap node private IP address.
    Value: !GetAtt BootstrapInstance.PrivateIp

関連情報

4.4.11. AWS でのコントロールプレーンの作成

クラスターで使用するコントロールプレーンマシンを Amazon Web Services (AWS) で作成する必要があります。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、コントロールプレーンノードを表す AWS リソースのスタックを作成できます。

重要

CloudFormation テンプレートは、3 つのコントロールプレーンノードを表すスタックを作成します。

注記

提供される CloudFormation テンプレートを使用してコントロールプレーンノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。

手順

  1. テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "AutoRegisterDNS", 5
        "ParameterValue": "yes" 6
      },
      {
        "ParameterKey": "PrivateHostedZoneId", 7
        "ParameterValue": "<random_string>" 8
      },
      {
        "ParameterKey": "PrivateHostedZoneName", 9
        "ParameterValue": "mycluster.example.com" 10
      },
      {
        "ParameterKey": "Master0Subnet", 11
        "ParameterValue": "subnet-<random_string>" 12
      },
      {
        "ParameterKey": "Master1Subnet", 13
        "ParameterValue": "subnet-<random_string>" 14
      },
      {
        "ParameterKey": "Master2Subnet", 15
        "ParameterValue": "subnet-<random_string>" 16
      },
      {
        "ParameterKey": "MasterSecurityGroupId", 17
        "ParameterValue": "sg-<random_string>" 18
      },
      {
        "ParameterKey": "IgnitionLocation", 19
        "ParameterValue": "https://api-int.<cluster_name>.<domain_name>:22623/config/master" 20
      },
      {
        "ParameterKey": "CertificateAuthorities", 21
        "ParameterValue": "data:text/plain;charset=utf-8;base64,ABC...xYz==" 22
      },
      {
        "ParameterKey": "MasterInstanceProfileName", 23
        "ParameterValue": "<roles_stack>-MasterInstanceProfile-<random_string>" 24
      },
      {
        "ParameterKey": "MasterInstanceType", 25
        "ParameterValue": "" 26
      },
      {
        "ParameterKey": "AutoRegisterELB", 27
        "ParameterValue": "yes" 28
      },
      {
        "ParameterKey": "RegisterNlbIpTargetsLambdaArn", 29
        "ParameterValue": "arn:aws:lambda:<aws_region>:<account_number>:function:<dns_stack_name>-RegisterNlbIpTargets-<random_string>" 30
      },
      {
        "ParameterKey": "ExternalApiTargetGroupArn", 31
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Exter-<random_string>" 32
      },
      {
        "ParameterKey": "InternalApiTargetGroupArn", 33
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 34
      },
      {
        "ParameterKey": "InternalServiceTargetGroupArn", 35
        "ParameterValue": "arn:aws:elasticloadbalancing:<aws_region>:<account_number>:targetgroup/<dns_stack_name>-Inter-<random_string>" 36
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてコントロールプレーンマシンに使用する最新の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    AWS::EC2::Image::Id 値を指定します。
    5
    DNS etcd 登録を実行するかどうか。
    6
    yes または no を指定します。yes を指定する場合、ホストゾーンの情報を指定する必要があります。
    7
    etcd ターゲットの登録に使用する Route 53 プライベートゾーン ID。
    8
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateHostedZoneId 値を指定します。
    9
    ターゲットの登録に使用する Route 53 ゾーン。
    10
    <cluster_name>.<domain_name> を指定します。ここで、<domain_name> はクラスターの install-config.yaml ファイルの生成時に使用した Route 53 ベースドメインです。AWS コンソールに表示される末尾のピリド (.) は含めないでください。
    11 13 15
    コントロールプレーンマシンの起動に使用するサブネット (プライベートが望ましい)。
    12 14 16
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateSubnets 値のサブネットを指定します。
    17
    コントロールプレーンノードに関連付けるマスターセキュリティーグループ ID。
    18
    セキュリティーグループおよびロールの CloudFormation テンプレートから MasterSecurityGroupId 値を指定します。
    19
    コントロールプレーンの Ignition 設定ファイルをフェッチする場所。
    20
    生成される Ignition 設定ファイルの場所を指定します (https://api-int.<cluster_name>.<domain_name>:22623/config/master)。
    21
    使用する base64 でエンコードされた認証局の文字列。
    22
    インストールディレクトリーにある master.ign ファイルから値を指定します。この値は、data:text/plain;charset=utf-8;base64,ABC…​xYz== 形式の長い文字列です。
    23
    コントロールプレーンノードに関連付ける IAM プロファイル。
    24
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から MasterInstanceProfile パラメーターの値を指定します。
    25
    選択したアーキテクチャーに基づいてコントロールプレーンマシンに使用する AWS インスタンスのタイプ。
    26
    インスタンスタイプの値は、コントロールプレーンマシンの最小リソース要件に対応します。たとえば、m6i.xlarge は AMD64 のタイプであり、m6g.xlarge は、ARM64 のタイプです。
    27
    ネットワークロードバランサー (NLB) を登録するかどうか。
    28
    yes または no を指定します。yes を指定する場合、Lambda Amazon Resource Name (ARN) の値を指定する必要があります。
    29
    NLB IP ターゲット登録 lambda グループの ARN。
    30
    DNS および負荷分散の CloudFormation テンプレートの出力から RegisterNlbIpTargetsLambda 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    31
    外部 API ロードバランサーのターゲットグループの ARN。
    32
    DNS および負荷分散の CloudFormation テンプレートの出力から ExternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    33
    内部 API ロードバランサーのターゲットグループの ARN。
    34
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalApiTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
    35
    内部サービスバランサーのターゲットグループの ARN。
    36
    DNS および負荷分散の CloudFormation テンプレートの出力から InternalServiceTargetGroupArn 値を指定します。クラスターを AWS GovCloud リージョンにデプロイする場合は、arn:aws-us-gov を使用します。
  2. このトピックのコントロールプレーンマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。
  3. m5 インスタンスタイプを MasterInstanceType の値として指定している場合、そのインスタンスタイプを CloudFormation テンプレートの MasterInstanceType.AllowedValues パラメーターに追加します。
  4. CloudFormation テンプレートを起動し、コントロールプレーンノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-control-plane などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-control-plane/21c7e2b0-2ee2-11eb-c6f6-0aa34627df4b

    注記

    CloudFormation テンプレートは、3 つのコントロールプレーンノードを表すスタックを作成します。

  5. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>
4.4.11.1. コントロールプレーンマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。

例4.28 コントロールプレーンマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Node Launch (EC2 master instances)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag nodes for the kubelet cloud provider.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  AutoRegisterDNS:
    Default: ""
    Description: unused
    Type: String
  PrivateHostedZoneId:
    Default: ""
    Description: unused
    Type: String
  PrivateHostedZoneName:
    Default: ""
    Description: unused
    Type: String
  Master0Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  Master1Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  Master2Subnet:
    Description: The subnets, recommend private, to launch the master nodes into.
    Type: AWS::EC2::Subnet::Id
  MasterSecurityGroupId:
    Description: The master security group ID to associate with master nodes.
    Type: AWS::EC2::SecurityGroup::Id
  IgnitionLocation:
    Default: https://api-int.$CLUSTER_NAME.$DOMAIN:22623/config/master
    Description: Ignition config file location.
    Type: String
  CertificateAuthorities:
    Default: data:text/plain;charset=utf-8;base64,ABC...xYz==
    Description: Base64 encoded certificate authority string to use.
    Type: String
  MasterInstanceProfileName:
    Description: IAM profile to associate with master nodes.
    Type: String
  MasterInstanceType:
    Default: m5.xlarge
    Type: String

  AutoRegisterELB:
    Default: "yes"
    AllowedValues:
    - "yes"
    - "no"
    Description: Do you want to invoke NLB registration, which requires a Lambda ARN parameter?
    Type: String
  RegisterNlbIpTargetsLambdaArn:
    Description: ARN for NLB IP target registration lambda. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  ExternalApiTargetGroupArn:
    Description: ARN for external API load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  InternalApiTargetGroupArn:
    Description: ARN for internal API load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String
  InternalServiceTargetGroupArn:
    Description: ARN for internal service load balancer target group. Supply the value from the cluster infrastructure or select "no" for AutoRegisterELB.
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - MasterInstanceType
      - RhcosAmi
      - IgnitionLocation
      - CertificateAuthorities
      - MasterSecurityGroupId
      - MasterInstanceProfileName
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcId
      - AllowedBootstrapSshCidr
      - Master0Subnet
      - Master1Subnet
      - Master2Subnet
    - Label:
        default: "Load Balancer Automation"
      Parameters:
      - AutoRegisterELB
      - RegisterNlbIpTargetsLambdaArn
      - ExternalApiTargetGroupArn
      - InternalApiTargetGroupArn
      - InternalServiceTargetGroupArn
    ParameterLabels:
      InfrastructureName:
        default: "Infrastructure Name"
      VpcId:
        default: "VPC ID"
      Master0Subnet:
        default: "Master-0 Subnet"
      Master1Subnet:
        default: "Master-1 Subnet"
      Master2Subnet:
        default: "Master-2 Subnet"
      MasterInstanceType:
        default: "Master Instance Type"
      MasterInstanceProfileName:
        default: "Master Instance Profile Name"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      BootstrapIgnitionLocation:
        default: "Master Ignition Source"
      CertificateAuthorities:
        default: "Ignition CA String"
      MasterSecurityGroupId:
        default: "Master Security Group ID"
      AutoRegisterELB:
        default: "Use Provided ELB Automation"

Conditions:
  DoRegistration: !Equals ["yes", !Ref AutoRegisterELB]

Resources:
  Master0:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master0Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster0:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  RegisterMaster0InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  RegisterMaster0InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master0.PrivateIp

  Master1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master1Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster1:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  RegisterMaster1InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  RegisterMaster1InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master1.PrivateIp

  Master2:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref MasterInstanceProfileName
      InstanceType: !Ref MasterInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "MasterSecurityGroupId"
        SubnetId: !Ref "Master2Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

  RegisterMaster2:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref ExternalApiTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

  RegisterMaster2InternalApiTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalApiTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

  RegisterMaster2InternalServiceTarget:
    Condition: DoRegistration
    Type: Custom::NLBRegister
    Properties:
      ServiceToken: !Ref RegisterNlbIpTargetsLambdaArn
      TargetArn: !Ref InternalServiceTargetGroupArn
      TargetIp: !GetAtt Master2.PrivateIp

Outputs:
  PrivateIPs:
    Description: The control-plane node private IP addresses.
    Value:
      !Join [
        ",",
        [!GetAtt Master0.PrivateIp, !GetAtt Master1.PrivateIp, !GetAtt Master2.PrivateIp]
      ]

4.4.12. AWS でのワーカーノードの作成

クラスターで使用するワーカーノードを Amazon Web Services (AWS) で作成できます。

提供される CloudFormation テンプレートおよびカスタムパラメーターファイルを使用して、ワーカーノードを表す AWS リソースのスタックを作成できます。

重要

CloudFormation テンプレートは、1 つのワーカーノードを表すスタックを作成します。それぞれのワーカーノードにスタックを作成する必要があります。

注記

提供される CloudFormation テンプレートを使用してワーカーノードを作成しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。
  • コントロールプレーンマシンを作成している。

手順

  1. CloudFormation テンプレートが必要とするパラメーター値が含まれる JSON ファイルを作成します。

    [
      {
        "ParameterKey": "InfrastructureName", 1
        "ParameterValue": "mycluster-<random_string>" 2
      },
      {
        "ParameterKey": "RhcosAmi", 3
        "ParameterValue": "ami-<random_string>" 4
      },
      {
        "ParameterKey": "Subnet", 5
        "ParameterValue": "subnet-<random_string>" 6
      },
      {
        "ParameterKey": "WorkerSecurityGroupId", 7
        "ParameterValue": "sg-<random_string>" 8
      },
      {
        "ParameterKey": "IgnitionLocation", 9
        "ParameterValue": "https://api-int.<cluster_name>.<domain_name>:22623/config/worker" 10
      },
      {
        "ParameterKey": "CertificateAuthorities", 11
        "ParameterValue": "" 12
      },
      {
        "ParameterKey": "WorkerInstanceProfileName", 13
        "ParameterValue": "" 14
      },
      {
        "ParameterKey": "WorkerInstanceType", 15
        "ParameterValue": "" 16
      }
    ]
    1
    クラスターの Ignition 設定ファイルでエンコードされるクラスターインフラストラクチャーの名前。
    2
    形式が <cluster-name>-<random-string> の Ignition 設定ファイルから抽出したインフラストラクチャー名を指定します。
    3
    選択したアーキテクチャーに基づいてワーカーノードに使用する現在の Red Hat Enterprise Linux CoreOS (RHCOS) AMI。
    4
    AWS::EC2::Image::Id 値を指定します。
    5
    ワーカーノードを起動するためのサブネット (プライベートであることが望ましい)。
    6
    DNS および負荷分散の CloudFormation テンプレートの出力から PrivateSubnets 値のサブネットを指定します。
    7
    ワーカーノードに関連付けるワーカーセキュリティーグループ ID。
    8
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から WorkerSecurityGroupId 値を指定します。
    9
    ブートストラップ Ignition 設定ファイルを取得する場所。
    10
    生成される Ignition 設定の場所を指定します。 https://api-int.<cluster_name>.<domain_name>:22623/config/worker
    11
    使用する base64 でエンコードされた認証局の文字列。
    12
    インストールディレクトリーにある worker.ign ファイルから値を指定します。この値は、data:text/plain;charset=utf-8;base64,ABC…​xYz== 形式の長い文字列です。
    13
    ワーカーロールに関連付ける IAM プロファイル。
    14
    セキュリティーグループおよびロールの CloudFormation テンプレートの出力から WorkerInstanceProfile パラメーターの値を指定します。
    15
    選択したアーキテクチャーに基づいてコンピュートマシンに使用する AWS インスタンスのタイプ。
    16
    インスタンスタイプの値は、コンピュートマシンの最小リソース要件に対応します。たとえば、m6i.large は AMD64 のタイプであり、m6g.large は ARM64 のタイプです。
  2. このトピックのワーカーマシンの CloudFormation テンプレートセクションからテンプレートをコピーし、これをコンピューター上に YAML ファイルとして保存します。このテンプレートは、クラスターに必要なネットワークオブジェクトおよびロードバランサーを記述しています。
  3. オプション: m5 インスタンスタイプを WorkerInstanceType の値として指定した場合は、そのインスタンスタイプを CloudFormation テンプレートの WorkerInstanceType.AllowedValues パラメーターに追加します。
  4. オプション: AWS Marketplace イメージを使用してデプロイする場合は、サブスクリプションから取得した AMI ID で Worker0.type.properties.ImageID パラメーターを更新します。
  5. CloudFormation テンプレートを使用して、ワーカーノードを表す AWS リソースのスタックを作成します。

    重要

    単一行にコマンドを入力してください。

    $ aws cloudformation create-stack --stack-name <name> 1
         --template-body file://<template>.yaml \ 2
         --parameters file://<parameters>.json 3
    1
    <name>cluster-worker-1 などの CloudFormation スタックの名前です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルへの相対パスまたはその名前です。
    3
    <parameters> は、CloudFormation パラメーター JSON ファイルへの相対パスまたは名前です。

    出力例

    arn:aws:cloudformation:us-east-1:269333783861:stack/cluster-worker-1/729ee301-1c2a-11eb-348f-sd9888c65b59

    注記

    CloudFormation テンプレートは、1 つのワーカーノードを表すスタックを作成します。

  6. テンプレートのコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <name>
  7. クラスターに作成するワーカーマシンが十分な数に達するまでワーカースタックの作成を継続します。同じテンプレートおよびパラメーターファイルを参照し、異なるスタック名を指定してワーカースタックをさらに作成することができます。

    重要

    2 つ以上のワーカーマシンを作成する必要があるため、この CloudFormation テンプレートを使用する 2 つ以上のスタックを作成する必要があります。

4.4.12.1. ワーカーマシンの CloudFormation テンプレート

以下の CloudFormation テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。

例4.29 ワーカーマシンの CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for OpenShift Cluster Node Launch (EC2 worker instance)

Parameters:
  InfrastructureName:
    AllowedPattern: ^([a-zA-Z][a-zA-Z0-9\-]{0,26})$
    MaxLength: 27
    MinLength: 1
    ConstraintDescription: Infrastructure name must be alphanumeric, start with a letter, and have a maximum of 27 characters.
    Description: A short, unique cluster ID used to tag nodes for the kubelet cloud provider.
    Type: String
  RhcosAmi:
    Description: Current Red Hat Enterprise Linux CoreOS AMI to use for bootstrap.
    Type: AWS::EC2::Image::Id
  Subnet:
    Description: The subnets, recommend private, to launch the worker nodes into.
    Type: AWS::EC2::Subnet::Id
  WorkerSecurityGroupId:
    Description: The worker security group ID to associate with worker nodes.
    Type: AWS::EC2::SecurityGroup::Id
  IgnitionLocation:
    Default: https://api-int.$CLUSTER_NAME.$DOMAIN:22623/config/worker
    Description: Ignition config file location.
    Type: String
  CertificateAuthorities:
    Default: data:text/plain;charset=utf-8;base64,ABC...xYz==
    Description: Base64 encoded certificate authority string to use.
    Type: String
  WorkerInstanceProfileName:
    Description: IAM profile to associate with worker nodes.
    Type: String
  WorkerInstanceType:
    Default: m5.large
    Type: String

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Cluster Information"
      Parameters:
      - InfrastructureName
    - Label:
        default: "Host Information"
      Parameters:
      - WorkerInstanceType
      - RhcosAmi
      - IgnitionLocation
      - CertificateAuthorities
      - WorkerSecurityGroupId
      - WorkerInstanceProfileName
    - Label:
        default: "Network Configuration"
      Parameters:
      - Subnet
    ParameterLabels:
      Subnet:
        default: "Subnet"
      InfrastructureName:
        default: "Infrastructure Name"
      WorkerInstanceType:
        default: "Worker Instance Type"
      WorkerInstanceProfileName:
        default: "Worker Instance Profile Name"
      RhcosAmi:
        default: "Red Hat Enterprise Linux CoreOS AMI ID"
      IgnitionLocation:
        default: "Worker Ignition Source"
      CertificateAuthorities:
        default: "Ignition CA String"
      WorkerSecurityGroupId:
        default: "Worker Security Group ID"

Resources:
  Worker0:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref RhcosAmi
      BlockDeviceMappings:
      - DeviceName: /dev/xvda
        Ebs:
          VolumeSize: "120"
          VolumeType: "gp2"
      IamInstanceProfile: !Ref WorkerInstanceProfileName
      InstanceType: !Ref WorkerInstanceType
      NetworkInterfaces:
      - AssociatePublicIpAddress: "false"
        DeviceIndex: "0"
        GroupSet:
        - !Ref "WorkerSecurityGroupId"
        SubnetId: !Ref "Subnet"
      UserData:
        Fn::Base64: !Sub
        - '{"ignition":{"config":{"merge":[{"source":"${SOURCE}"}]},"security":{"tls":{"certificateAuthorities":[{"source":"${CA_BUNDLE}"}]}},"version":"3.1.0"}}'
        - {
          SOURCE: !Ref IgnitionLocation,
          CA_BUNDLE: !Ref CertificateAuthorities,
        }
      Tags:
      - Key: !Join ["", ["kubernetes.io/cluster/", !Ref InfrastructureName]]
        Value: "shared"

Outputs:
  PrivateIP:
    Description: The compute node private IP address.
    Value: !GetAtt Worker0.PrivateIp

4.4.13. user-provisioned infrastructure を使用した AWS でのブートストラップシーケンスの初期化

Amazon Web Services (AWS) ですべての必要なインフラストラクチャーを作成した後に、OpenShift Container Platform コントロールプレーンを初期化するブートストラップシーケンスを開始できます。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • クラスターの Ignition 設定ファイルを生成している。
  • AWS で VPC および関連するサブネットを作成し、設定している。
  • AWS で DNS、ロードバランサー、およびリスナーを作成し、設定している。
  • AWS でクラスターに必要なセキュリティーグループおよびロールを作成している。
  • ブートストラップマシンを作成している。
  • コントロールプレーンマシンを作成している。
  • ワーカーノードを作成している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、OpenShift Container Platform コントロールプレーンを初期化するブートストラッププロセスを開始します。

    $ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 20m0s for the Kubernetes API at https://api.mycluster.example.com:6443...
    INFO API v1.30.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    INFO Time elapsed: 1s

    コマンドが FATAL 警告を出さずに終了する場合、OpenShift Container Platform コントロールプレーンは初期化されています。

    注記

    コントロールプレーンの初期化後に、コンピュートノードを設定し、Operator の形式で追加のサービスをインストールします。

関連情報

4.4.14. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.30.3
    master-1  Ready     master  63m  v1.30.3
    master-2  Ready     master  64m  v1.30.3

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (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 が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc 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 が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ 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
    ...

  5. 残りの 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
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.30.3
    master-1  Ready     master  73m  v1.30.3
    master-2  Ready     master  74m  v1.30.3
    worker-0  Ready     worker  11m  v1.30.3
    worker-1  Ready     worker  11m  v1.30.3

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

4.4.15. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.17.0    True        False         False      19m
    baremetal                                  4.17.0    True        False         False      37m
    cloud-credential                           4.17.0    True        False         False      40m
    cluster-autoscaler                         4.17.0    True        False         False      37m
    config-operator                            4.17.0    True        False         False      38m
    console                                    4.17.0    True        False         False      26m
    csi-snapshot-controller                    4.17.0    True        False         False      37m
    dns                                        4.17.0    True        False         False      37m
    etcd                                       4.17.0    True        False         False      36m
    image-registry                             4.17.0    True        False         False      31m
    ingress                                    4.17.0    True        False         False      30m
    insights                                   4.17.0    True        False         False      31m
    kube-apiserver                             4.17.0    True        False         False      26m
    kube-controller-manager                    4.17.0    True        False         False      36m
    kube-scheduler                             4.17.0    True        False         False      36m
    kube-storage-version-migrator              4.17.0    True        False         False      37m
    machine-api                                4.17.0    True        False         False      29m
    machine-approver                           4.17.0    True        False         False      37m
    machine-config                             4.17.0    True        False         False      36m
    marketplace                                4.17.0    True        False         False      37m
    monitoring                                 4.17.0    True        False         False      29m
    network                                    4.17.0    True        False         False      38m
    node-tuning                                4.17.0    True        False         False      37m
    openshift-apiserver                        4.17.0    True        False         False      32m
    openshift-controller-manager               4.17.0    True        False         False      30m
    openshift-samples                          4.17.0    True        False         False      32m
    operator-lifecycle-manager                 4.17.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
    service-ca                                 4.17.0    True        False         False      38m
    storage                                    4.17.0    True        False         False      37m

  2. 利用不可の Operator を設定します。
4.4.15.1. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

4.4.15.2. イメージレジストリーストレージの設定

Amazon Web Services はデフォルトのストレージを提供します。つまり、Image Registry Operator はインストール後に利用可能になります。ただし、レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合は、レジストリーストレージを手動で設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

4.4.15.2.1. user-provisioned infrastructure を使用した AWS のレジストリーストレージの設定

インストール時に、Amazon S3 バケットを作成するにはクラウド認証情報を使用でき、レジストリー Operator がストレージを自動的に設定します。

レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合、以下の手順により S3 バケットを作成し、ストレージを設定することができます。

前提条件

  • user-provisioned infrastructure を使用した AWS 上にクラスターがある。
  • Amazon S3 ストレージの場合、シークレットには以下のキーが含まれることが予想されます。

    • REGISTRY_STORAGE_S3_ACCESSKEY
    • REGISTRY_STORAGE_S3_SECRETKEY

手順

レジストリー Operator が S3 バケットを作成できず、ストレージを自動的に設定する場合は、以下の手順を使用してください。

  1. バケットライフサイクルポリシー を設定し、1 日以上経過している未完了のマルチパートアップロードを中止します。
  2. configs.imageregistry.operator.openshift.io/cluster にストレージ設定を入力します。

    $ oc edit configs.imageregistry.operator.openshift.io/cluster

    設定例

    storage:
      s3:
        bucket: <bucket-name>
        region: <region-name>

警告

AWS でレジストリーイメージのセキュリティーを保護するには、S3 バケットに対して パブリックアクセスのブロック を実行します。

4.4.15.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

4.4.16. ブートストラップリソースの削除

クラスターの初期 Operator 設定の完了後に、Amazon Web Services (AWS) からブートストラップリソースを削除します。

前提条件

  • クラスターの初期 Operator 設定が完了済みです。

手順

  1. ブートストラップリソースを削除します。CloudFormation テンプレートを使用した場合は、そのスタックを削除 します。

    • AWS CLI を使用してスタックを削除します。

      $ aws cloudformation delete-stack --stack-name <name> 1
      1
      <name> は、ブートストラップスタックの名前です。
    • AWS CloudFormation コンソール を使用してスタックを削除します。

4.4.17. Ingress DNS レコードの作成

DNS ゾーン設定を削除した場合には、Ingress ロードバランサーを参照する DNS レコードを手動で作成します。ワイルドカードレコードまたは特定のレコードのいずれかを作成できます。以下の手順では A レコードを使用しますが、CNAME やエイリアスなどの必要な他のレコードタイプを使用できます。

前提条件

  • 独自にプロビジョニングしたインフラストラクチャーを使用する OpenShift Container Platform クラスターを Amazon Web Services (AWS) にデプロイしています。
  • OpenShift CLI (oc) がインストールされている。
  • jq パッケージをインストールしている。
  • AWS CLI をダウンロードし、これをコンピューターにインストールしている。Install the AWS CLI Using the Bundled Installer (Linux, macOS, or Unix) を参照してください。

手順

  1. 作成するルートを決定します。

    • ワイルドカードレコードを作成するには、*.apps.<cluster_name>.<domain_name> を使用します。ここで、<cluster_name> はクラスター名で、<domain_name> は OpenShift Container Platform クラスターの Route 53 ベースドメインです。
    • 特定のレコードを作成するには、以下のコマンドの出力にあるように、クラスターが使用する各ルートにレコードを作成する必要があります。

      $ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes

      出力例

      oauth-openshift.apps.<cluster_name>.<domain_name>
      console-openshift-console.apps.<cluster_name>.<domain_name>
      downloads-openshift-console.apps.<cluster_name>.<domain_name>
      alertmanager-main-openshift-monitoring.apps.<cluster_name>.<domain_name>
      prometheus-k8s-openshift-monitoring.apps.<cluster_name>.<domain_name>

  2. Ingress Operator ロードバランサーのステータスを取得し、使用する外部 IP アドレスの値をメモします。これは EXTERNAL-IP 列に表示されます。

    $ oc -n openshift-ingress get service router-default

    出力例

    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)                      AGE
    router-default   LoadBalancer   172.30.62.215   ab3...28.us-east-2.elb.amazonaws.com   80:31499/TCP,443:30693/TCP   5m

  3. ロードバランサーのホストゾーン ID を見つけます。

    $ aws elb describe-load-balancers | jq -r '.LoadBalancerDescriptions[] | select(.DNSName == "<external_ip>").CanonicalHostedZoneNameID' 1
    1
    <external_ip> には、取得した Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。

    出力例

    Z3AADJGX6KTTL2

    このコマンドの出力は、ロードバランサーのホストゾーン ID です。

  4. クラスターのドメインのパブリックホストゾーン ID を取得します。

    $ aws route53 list-hosted-zones-by-name \
                --dns-name "<domain_name>" \ 1
                --query 'HostedZones[? Config.PrivateZone != `true` && Name == `<domain_name>.`].Id' 2
                --output text
    1 2
    <domain_name> には、OpenShift Container Platform クラスターの Route 53 ベースドメインを指定します。

    出力例

    /hostedzone/Z3URY6TWQ91KVV

    ドメインのパブリックホストゾーン ID がコマンド出力に表示されます。この例では、これは Z3URY6TWQ91KVV になります。

  5. プライベートゾーンにエイリアスレコードを追加します。

    $ aws route53 change-resource-record-sets --hosted-zone-id "<private_hosted_zone_id>" --change-batch '{ 1
    >   "Changes": [
    >     {
    >       "Action": "CREATE",
    >       "ResourceRecordSet": {
    >         "Name": "\\052.apps.<cluster_domain>", 2
    >         "Type": "A",
    >         "AliasTarget":{
    >           "HostedZoneId": "<hosted_zone_id>", 3
    >           "DNSName": "<external_ip>.", 4
    >           "EvaluateTargetHealth": false
    >         }
    >       }
    >     }
    >   ]
    > }'
    1
    <private_hosted_zone_id> には、DNS および負荷分散の CloudFormation テンプレートの出力から値を指定します。
    2
    <cluster_domain> には、OpenShift Container Platform クラスターで使用するドメインまたはサブドメインを指定します。
    3
    <hosted_zone_id> には、取得したロードバランサーのパブリックホストゾーン ID を指定します。
    4
    <external_ip> には、Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。このパラメーターの値に末尾のピリオド (.) が含まれていることを確認します。
  6. パブリックゾーンにレコードを追加します。

    $ aws route53 change-resource-record-sets --hosted-zone-id "<public_hosted_zone_id>"" --change-batch '{ 1
    >   "Changes": [
    >     {
    >       "Action": "CREATE",
    >       "ResourceRecordSet": {
    >         "Name": "\\052.apps.<cluster_domain>", 2
    >         "Type": "A",
    >         "AliasTarget":{
    >           "HostedZoneId": "<hosted_zone_id>", 3
    >           "DNSName": "<external_ip>.", 4
    >           "EvaluateTargetHealth": false
    >         }
    >       }
    >     }
    >   ]
    > }'
    1
    <public_hosted_zone_id> には、ドメインのパブリックホストゾーンを指定します。
    2
    <cluster_domain> には、OpenShift Container Platform クラスターで使用するドメインまたはサブドメインを指定します。
    3
    <hosted_zone_id> には、取得したロードバランサーのパブリックホストゾーン ID を指定します。
    4
    <external_ip> には、Ingress Operator ロードバランサーの外部 IP アドレスの値を指定します。このパラメーターの値に末尾のピリオド (.) が含まれていることを確認します。

4.4.18. user-provisioned infrastructure での AWS インストールの実行

Amazon Web Service (AWS) の user-provisioned infrastructure で OpenShift Container Platform のインストールを開始した後に、デプロイメントを完了するまでモニターします。

前提条件

  • OpenShift Container Platform クラスターのブートストラップノードを、user-provisioned AWS インフラストラクチャーで削除している。
  • oc CLI をインストールしていること。

手順

  1. インストールプログラムが含まれるディレクトリーから、クラスターのインストールを完了します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 40m0s for the cluster at https://api.mycluster.example.com:6443 to initialize...
    INFO Waiting up to 10m0s for the openshift-console route to be created...
    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: 1s

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
  2. Cluster registration ページでクラスターを登録します。

4.4.19. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

4.4.20. Web コンソールを使用したクラスターへのログイン

kubeadmin ユーザーは、OpenShift Container Platform のインストール後はデフォルトで存在します。OpenShift Container Platform Web コンソールを使用し、kubeadmin ユーザーとしてクラスターにログインできます。

前提条件

  • インストールホストにアクセスできる。
  • クラスターのインストールを完了しており、すべてのクラスター Operator が利用可能である。

手順

  1. インストールホストで kubeadmin-password ファイルから kubeadmin ユーザーのパスワードを取得します。

    $ cat <installation_directory>/auth/kubeadmin-password
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルから kubeadmin パスワードを取得できます。

  2. OpenShift Container Platform Web コンソールルートをリスト表示します。

    $ oc get routes -n openshift-console | grep 'console-openshift'
    注記

    または、インストールホストで <installation_directory>/.openshift_install.log ログファイルからで OpenShift Container Platform ルートを取得できます。

    出力例

    console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

  3. Web ブラウザーで前述のコマンドの出力で詳細に説明されたルートに移動し、kubeadmin ユーザーとしてログインします。

関連情報

関連情報

4.4.21. 関連情報

  • AWS CloudFormation スタックの詳細は、Working with stacks を参照してください。

4.4.22. 次のステップ

4.5. マルチアーキテクチャーコンピュートマシンの設定をサポートするクラスターのインストール

マルチアーキテクチャーコンピュートマシンを備えた OpenShift Container Platform クラスターは、さまざまなアーキテクチャーのコンピュートマシンをサポートします。

注記

クラスター内に複数のアーキテクチャーを持つノードがある場合、イメージのアーキテクチャーはノードのアーキテクチャーと一致している必要があります。Pod が適切なアーキテクチャーを持つノードに割り当てられていること、およびそれがイメージアーキテクチャーと一致していることを確認する必要があります。Pod をノードに割り当てる方法の詳細は、マルチアーキテクチャーコンピュートマシンを使用したクラスターでのワークロードのスケジュール設定 を参照してください。

マルチアーキテクチャーコンピュートマシンの設定をサポートする AWS クラスターをインストールできます。AWS クラスターをインストールした後、次の方法でマルチアーキテクチャーコンピュートマシンをクラスターに追加できます。

  • 64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに 64 ビット x86 コンピュートマシンを追加します。この場合、64 ビット x86 がセカンダリーアーキテクチャーと見なされます。
  • 64 ビット x86 コントロールプレーンマシンを使用し、すでに 64 ビット x86 コンピュートマシンが含まれているクラスターに 64 ビット ARM コンピュートマシンを追加します。この場合、64 ビット ARM がセカンダリーアーキテクチャーと見なされます。
注記

セカンダリーアーキテクチャーノードをクラスターに追加する前に、Multiarch Tuning Operator をインストールし、ClusterPodPlacementConfig カスタムリソースをデプロイすることを推奨します。詳細は、「Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する」を参照してください。

4.5.1. マルチアーキテクチャーをサポートするクラスターのインストール

マルチアーキテクチャーコンピュートマシンの設定をサポートするクラスターをインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • OpenShift Container Platform インストールプログラムがある。
  • クラスターのプルシークレットをダウンロードしている。

手順

  1. 次のコマンドを実行して、openshift-install バイナリーがmulti ペイロードを使用していることを確認します。

    $ ./openshift-install version

    出力例

    ./openshift-install 4.17.0
    built from commit abc123etc
    release image quay.io/openshift-release-dev/ocp-release@sha256:abc123wxyzetc
    release architecture multi
    default architecture amd64

    openshift-install バイナリーが multi ペイロードを使用していることを示すには、出力に release architecture multi を含める必要があります。

  2. install-config.yaml ファイルを更新して、ノードのアーキテクチャーを設定します。

    マルチアーキテクチャー設定の install-config.yaml ファイルのサンプル

    apiVersion: v1
    baseDomain: example.openshift.com
    compute:
    - architecture: amd64 1
      hyperthreading: Enabled
      name: worker
      platform: {}
      replicas: 3
    controlPlane:
      architecture: arm64 2
      name: master
      platform: {}
      replicas: 3
    # ...

    1
    ワーカーノードのアーキテクチャーを指定します。このフィールドは arm64 または amd64 のいずれかに設定できます。
    2
    コントロールプレーンノードのアーキテクチャーを指定します。このフィールドは arm64 または amd64 のいずれかに設定できます。

次のステップ

第5章 AWS に 3 ノードクラスターをインストールする

OpenShift Container Platform バージョン 4.17 では、Amazon Web Services (AWS) に 3 ノードのクラスターをインストールできます。3 ノードクラスターは、コンピュートマシンとしても機能する 3 つのコントロールプレーンマシンで構成されます。このタイプのクラスターは、クラスター管理者および開発者がテスト、開発、および実稼働に使用するためのより小さくリソース効率の高いクラスターを提供します。

installer-provisioned infrastructure または user-provisioned infrastructure のいずれかを使用して、3 ノードクラスターをインストールできます。

注記

AWS Marketplace イメージを使用した 3 ノードクラスターのデプロイはサポートされていません。

5.1. 3 ノードクラスターの設定

クラスターをデプロイする前に、install-config.yaml ファイルでワーカーノードの数を 0 に設定して、3 ノードクラスターを設定します。ワーカーノードの数を 0 に設定すると、コントロールプレーンマシンがスケジュール可能になります。これにより、アプリケーションワークロードをコントロールプレーンノードから実行するようにスケジュールできます。

注記

アプリケーションワークロードはコントロールプレーンノードから実行され、コントロールプレーンノードはコンピュートノードと見なされるため、追加のサブスクリプションが必要です。

前提条件

  • 既存の install-config.yaml ファイルがある。

手順

  1. 次の compute スタンザに示すように、install-config.yaml ファイルでコンピューティングレプリカの数を 0 に設定します。

    3 ノードクラスターの install-config.yaml ファイルの例

    apiVersion: v1
    baseDomain: example.com
    compute:
    - name: worker
      platform: {}
      replicas: 0
    # ...

  2. user-provisioned infrastructure を使用して、クラスターをデプロイする場合:

    • Kubernetes マニフェストファイルを作成したら、cluster-scheduler-02-config.yml ファイルで spec.mastersSchedulable パラメーターが true に設定されていることを確認します。このファイルは、<installation_directory>/manifests にあります。詳細は、「CloudFormation テンプレートを使用して、AWS で user-provisioned infrastructure にクラスターをインストールする」の「Kubernetes マニフェストと Ignition 設定ファイルの作成」を参照してください。
    • 追加のワーカーノードを作成しないでください。

3 ノードクラスターの cluster-scheduler-02-config.yml ファイルの例

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: null
  name: cluster
spec:
  mastersSchedulable: true
  policy:
    name: ""
status: {}

5.2. 次のステップ

第6章 AWS でのクラスターのアンインストール

Amazon Web Services (AWS) にデプロイしたクラスターは削除することができます。

6.1. installer-provisioned infrastructure を使用するクラスターの削除

installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。

注記

アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。

    $ ./openshift-install destroy cluster \
    --dir <installation_directory> --log-level info 1 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <installation_directory> ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。

6.2. Cloud Credential Operator ユーティリティーを使用した Amazon Web Services リソースの削除

クラスターの外部で管理される短期認証情報を使用する OpenShift Container Platform クラスターをアンインストールした後、CCO ユーティリティー (ccoctl) を使用して、インストール中に ccoctl が作成した Amazon Web Services (AWS) リソースを削除できます。

前提条件

  • ccoctl バイナリーを展開して準備しておく。
  • 短期認証情報を使用する AWS 上の OpenShift Container Platform クラスターをアンインストールします。

手順

  • 次のコマンドを実行して、ccoctl が作成した AWS リソースを削除します。

    $ ccoctl aws delete \
      --name=<name> \1
      --region=<aws_region> 2
    1
    <name> は、クラウドリソースを最初に作成してタグ付けするために使用された名前と一致します。
    2
    <aws_region> は、クラウドリソースが削除される AWS リージョンです。

    出力例

    2021/04/08 17:50:41 Identity Provider object .well-known/openid-configuration deleted from the bucket <name>-oidc
    2021/04/08 17:50:42 Identity Provider object keys.json deleted from the bucket <name>-oidc
    2021/04/08 17:50:43 Identity Provider bucket <name>-oidc deleted
    2021/04/08 17:51:05 Policy <name>-openshift-cloud-credential-operator-cloud-credential-o associated with IAM Role <name>-openshift-cloud-credential-operator-cloud-credential-o deleted
    2021/04/08 17:51:05 IAM Role <name>-openshift-cloud-credential-operator-cloud-credential-o deleted
    2021/04/08 17:51:07 Policy <name>-openshift-cluster-csi-drivers-ebs-cloud-credentials associated with IAM Role <name>-openshift-cluster-csi-drivers-ebs-cloud-credentials deleted
    2021/04/08 17:51:07 IAM Role <name>-openshift-cluster-csi-drivers-ebs-cloud-credentials deleted
    2021/04/08 17:51:08 Policy <name>-openshift-image-registry-installer-cloud-credentials associated with IAM Role <name>-openshift-image-registry-installer-cloud-credentials deleted
    2021/04/08 17:51:08 IAM Role <name>-openshift-image-registry-installer-cloud-credentials deleted
    2021/04/08 17:51:09 Policy <name>-openshift-ingress-operator-cloud-credentials associated with IAM Role <name>-openshift-ingress-operator-cloud-credentials deleted
    2021/04/08 17:51:10 IAM Role <name>-openshift-ingress-operator-cloud-credentials deleted
    2021/04/08 17:51:11 Policy <name>-openshift-machine-api-aws-cloud-credentials associated with IAM Role <name>-openshift-machine-api-aws-cloud-credentials deleted
    2021/04/08 17:51:11 IAM Role <name>-openshift-machine-api-aws-cloud-credentials deleted
    2021/04/08 17:51:39 Identity Provider with ARN arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com deleted

検証

  • リソースが削除されたことを確認するには、AWS にクエリーを実行します。詳細は AWS ドキュメントを参照してください。

6.3. 設定された AWS Local Zone インフラストラクチャーを使用したクラスターの削除

Amazon Web Services (AWS) のクラスターを既存の Virtual Private Cloud (VPC) にインストールし、ローカルゾーンの場所ごとにサブネットを設定したら、クラスターとそれに関連付けられている AWS リソースを削除できます。

この手順の例では、CloudFormation テンプレートを使用して VPC とそのサブネットを作成したことを前提としています。

前提条件

  • ネットワークの作成中に使用された CloudFormation スタックの名前 <local_zone_stack_name><vpc_stack_name> を知っています。クラスターを削除するには、スタックの名前が必要です。
  • インストールプログラムによって作成されたインストールファイルを含むディレクトリーへのアクセス権があります。
  • アカウントには、CloudFormation スタックを削除するためのアクセス許可を提供するポリシーが含まれています。

手順

  1. インストールプログラムが保存されているディレクトリーに移動し、destroy cluster コマンドを使用してクラスターを削除します。

    $ ./openshift-install destroy cluster --dir <installation_directory> \1
       --log-level=debug 2
    1
    <installation_directory> には、インストールプログラムによって作成されたファイルを保存したディレクトリーを指定します。
    2
    別のログの詳細を表示するには、debug の代わりに errorinfo、または warn を指定します。
  2. Local Zone サブネットの CloudFormation スタックを削除します。

    $ aws cloudformation delete-stack --stack-name <local_zone_stack_name>
  3. VPC を表すリソースのスタックを削除します。

    $ aws cloudformation delete-stack --stack-name <vpc_stack_name>

検証

  • AWS CLI で次のコマンドを発行して、スタックリソースを削除したことを確認します。AWS CLI は、テンプレートコンポーネントが存在しないことを出力します。

    $ aws cloudformation describe-stacks --stack-name <local_zone_stack_name>
    $ aws cloudformation describe-stacks --stack-name <vpc_stack_name>

関連情報

第7章 AWS のインストール設定パラメーター

OpenShift Container Platform クラスターを AWS にデプロイする前に、クラスターとそれをホストするプラットフォームをカスタマイズするためのパラメーターを指定します。install-config.yaml ファイルを作成するときは、コマンドラインを使用して必要なパラメーターの値を指定します。その後、install-config.yaml ファイルを変更して、クラスターをさらにカスタマイズできます。

7.1. AWS で使用可能なインストール設定パラメーター

次の表では、インストールプロセスの一部として設定できる、必須、オプション、および AWS 固有のインストール設定パラメーターを示します。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

7.1.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表7.1 必須パラメーター
パラメーター説明
apiVersion:

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain:

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata:

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata:
  name:

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。

platform:

インストールを実行する特定のプラットフォームの設定: awsbaremetalazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret:

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

7.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

表7.2 ネットワークパラメーター
パラメーター説明
networking:

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking:
  networkType:

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OVNKubernetesOVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNKubernetes です。

networking:
  clusterNetwork:

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
networking:
  clusterNetwork:
    cidr:

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking:
  clusterNetwork:
    hostPrefix:

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking:
  serviceNetwork:

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。

networking:
  serviceNetwork:
   - 172.30.0.0/16
networking:
  machineNetwork:

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16
networking:
  machineNetwork:
    cidr:

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt と IBM Power® Virtual Server を除くすべてのプラットフォームのデフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。IBM Power® Virtual Server の場合、デフォルト値は 192.168.0.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

7.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表7.3 オプションのパラメーター
パラメーター説明
additionalTrustBundle:

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities:

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities:
  baselineCapabilitySet:

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11v4.12vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities:
  additionalEnabledCapabilities:

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

cpuPartitioningMode:

ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。

None または AllNodes。デフォルト値は None です。

compute:

コンピュートノードを構成するマシンの設定。

MachinePool オブジェクトの配列。

compute:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は、amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

compute:
  hyperthreading:

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute:
  name:

compute を使用する場合に必須です。マシンプールの名前。

worker

compute:
  platform:

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

awsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

compute:
  replicas:

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet:

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane:

コントロールプレーンを構成するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は、amd64arm64 です。すべてのインストールオプションが 64 ビット ARM アーキテクチャーをサポートしているわけではありません。使用するインストールオプションがプラットフォームでサポートされているか確認するには、クラスターインストール方法の選択およびそのユーザー向けの準備各種プラットフォームでサポートされているインストール方法 参照してください。

文字列

controlPlane:
  hyperthreading:

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane:
  name:

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane:
  platform:

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

awsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

controlPlane:
  replicas:

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3、シングルノード OpenShift をデプロイする場合は 1 です。

credentialsMode:

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。

MintPassthroughManual、または空の文字列 ("")。

fips:

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources:

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources:
  source:

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources:
  mirrors:

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

platform:
  aws:
    lbType:

AWS で NLB ロードバランサータイプを設定するために必要です。有効な値は Classic または NLB です。値が指定されていない場合、インストールプログラムはデフォルトで Classic になります。インストールプログラムは、ここで指定された値をイングレスクラスター設定オブジェクトに設定します。他の Ingress コントローラーのロードバランサータイプを指定しない場合、それらはこのパラメーターに設定されたタイプを使用します。

Classic または NLBデフォルト値は Classic です。

publish:

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。プライベートクラスターをデプロイするには、publishInternal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。

sshKey:

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

+

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

+

重要

このパラメーターを Manual に設定すると、管理者レベルのシークレットを kube-system プロジェクトに保存する代替手段が有効になりますが、追加の設定手順が必要になります。詳細は、「管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法」を参照してください。

7.1.4. オプションの AWS 設定パラメーター

オプションの AWS 設定パラメーターは、以下の表で説明されています。

表7.4 オプションの AWS パラメーター
パラメーター説明
compute:
  platform:
    aws:
      amiID:

クラスターのコンピュートマシンの起動に使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID は、AWS インフラストラクチャーの RHCOS AMI を参照してください。

compute:
  platform:
    aws:
      iamProfile:

マシンに使用する IAM インスタンスプロファイルの名前。インストールプログラムで IAM インスタンスプロファイルを作成する場合は、iamProfile パラメーターを使用しないでください。iamProfile パラメーターまたは iamRole パラメーターのいずれかを指定できますが、両方を指定することはできません。

文字列

compute:
  platform:
    aws:
      iamRole:

マシンに使用する IAM インスタンスロールの名前。IAM ロールを指定すると、インストールプログラムによってインスタンスプロファイルが作成されます。インストールプログラムで IAM インスタンスロールを作成する場合は、iamRole パラメーターを選択しないでください。iamRole または iamProfile パラメーターのいずれかを指定できますが、両方を指定することはできません。

文字列

compute:
  platform:
    aws:
      rootVolume:
        iops:

ルートボリュームに予約される 1 秒あたりの入出力操作 (IOPS)。

整数 (例: 4000)。

compute:
  platform:
    aws:
      rootVolume:
        size:

ルートボリュームのサイズ (GiB)。

整数 (例: 500)。

compute:
  platform:
    aws:
      rootVolume:
        type:

root ボリュームのタイプです。

有効な AWS EBS ボリュームタイプ (例: io1)。

compute:
  platform:
    aws:
      rootVolume:
        kmsKeyARN:

KMS キーの Amazon リソース名 (キー ARN)。これは、ワーカーノードのオペレーティングシステムボリュームを特定の KMS キーで暗号化するために必要です。

有効な キー ID またはキー ARN

compute:
  platform:
    aws:
      type:

コンピュートマシンの EC2 インスタンスタイプ。

有効な AWS インスタンスタイプ (例: m4.2xlarge)。次の サポートされている AWS マシンタイプ の表を参照してください。

compute:
  platform:
    aws:
      zones:

インストールプログラムがコンピュートマシンプールのマシンを作成するアベイラビリティーゾーン。独自の VPC を指定する場合は、そのアベイラビリティーゾーンにサブネットを指定する必要があります。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

compute:
  aws:
    region:

インストールプログラムがコンピュートリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。AWS CLI を使用して、選択したインスタンスタイプに基づいて利用可能なリージョンにアクセスできます。以下に例を示します。

aws ec2 describe-instance-type-offerings --filters Name=instance-type,Values=c7g.xlarge
重要

ARM ベースの AWS インスタンスで実行する場合は、AWS Graviton プロセッサーが利用可能なリージョンを入力するようにしてください。AWS ドキュメントの グローバルアベイラビリティー マップを参照してください。現在、AWS Graviton3 プロセッサーは一部のリージョンでのみ利用できます。

controlPlane:
  platform:
    aws:
      amiID:

クラスターのコントロールプレーンマシンを起動するために使用される AWS AMI。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID は、AWS インフラストラクチャーの RHCOS AMI を参照してください。

controlPlane:
  platform:
    aws:
      iamProfile:

マシンに使用する IAM インスタンスプロファイルの名前。インストールプログラムで IAM インスタンスプロファイルを作成する場合は、iamProfile パラメーターを使用しないでください。iamProfile パラメーターまたは iamRole パラメーターのいずれかを指定できますが、両方を指定することはできません。

文字列

controlPlane:
  platform:
    aws:
      iamRole:

マシンに使用する IAM インスタンスロールの名前。IAM ロールを指定すると、インストールプログラムによってインスタンスプロファイルが作成されます。インストールプログラムで IAM インスタンスロールを作成する場合は、iamRole パラメーターを使用しないでください。iamRole または iamProfile パラメーターのいずれかを指定できますが、両方を指定することはできません。

文字列

controlPlane:
  platform:
    aws:
      rootVolume:
        iops:

コントロールプレーンマシン上のルートボリューム用に予約されている 1 秒あたりの入出力操作数 (IOPS)。

整数 (例: 4000)。

controlPlane:
  platform:
    aws:
      rootVolume:
        size:

コントロールプレーンマシンのルートボリュームのサイズ (GiB)。

整数 (例: 500)。

controlPlane:
  platform:
    aws:
      rootVolume:
        type:

コントロールプレーンマシンのルートボリュームのタイプ。

有効な AWS EBS ボリュームタイプ (例: io1)。

controlPlane:
  platform:
    aws:
      rootVolume:
        kmsKeyARN:

KMS キーの Amazon リソース名 (キー ARN)。これは、特定の KMS キーでコントロールプレーンノードのオペレーティングシステムボリュームを暗号化するために必要です。

有効な キー ID とキー ARN

controlPlane:
  platform:
    aws:
      type:

コントロールプレーンマシンの EC2 インスタンスタイプ。

m6i.xlarge などの有効な AWS インスタンスタイプ。次の サポートされている AWS マシンタイプ の表を参照してください。

controlPlane:
  platform:
    aws:
      zones:

インストールプログラムがコントロールプレーンマシンプールのマシンを作成するアベイラビリティーゾーン。

YAML シーケンスus-east-1c などの有効な AWS アベイラビリティーゾーンのリスト。

controlPlane:
  aws:
    region:

インストールプログラムがコントロールプレーンのリソースを作成する AWS リージョン。

有効な AWS リージョン (例: us-east-1)。

platform:
  aws:
    amiID:

クラスターのすべてのマシンを起動するために使用される AWS AMI。これが設定されている場合、AMI はクラスターと同じリージョンに属する必要があります。これは、カスタム RHCOS AMI を必要とするリージョンに必要です。

設定した AWS リージョンに属するパブリッシュ済みまたはカスタムの RHCOS AMI。利用可能な AMI ID は、AWS インフラストラクチャーの RHCOS AMI を参照してください。

platform:
  aws:
    hostedZone:

クラスターの既存の Route 53 プライベートホストゾーン。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。ホストゾーンは、インストール前にユーザーによって提供される VPC に関連付けられている必要があります。また、ホストゾーンのドメインはクラスタードメインまたはクラスタードメインの親である必要があります。定義されていない場合は、インストールプログラムは新規のホストゾーンを作成します。

文字列 (例: Z3URY6TWQ91KVV)

platform:
  aws:
    hostedZoneRole:

指定されたホストゾーンを含むアカウントの既存の IAM ロールの Amazon Resource Name (ARN)。インストールプログラムとクラスターオペレーターは、ホストゾーンで操作を実行するときにこのロールを引き受けます。このパラメーターは、クラスターを共有 VPC にインストールする場合にのみ使用してください。

文字列 (例 arn:aws:iam::1234567890:role/shared-vpc-role)。

platform:
  aws:
    serviceEndpoints:
      - name:
        url:

AWS サービスのエンドポイント名と URL。カスタムエンドポイントは、FIPS などの AWS の代替エンドポイントを使用しなければならない場合にのみ必要です。カスタム API エンドポイントは、EC2、S3、IAM、Elastic Load Balancing、Tagging、Route 53、および STS AWS サービスに指定できます。

有効な AWS サービスエンドポイント 名と有効な AWS サービスエンドポイント URL。

platform:
  aws:
    userTags:

インストールプログラムが、作成するすべてのリソースに対するタグとして追加するキーと値のマップ。

<key>: <value> 形式のキー値ペアなどの有効な YAML マップ。AWS タグの詳細は、AWS ドキュメントの Tagging Your Amazon EC2 Resources を参照してください。

注記

インストール時に、最大 25 個のユーザー定義タグを追加できます。残りの 25 個のタグは、OpenShift Container Platform 用に予約されています。

platform:
  aws:
    propagateUserTags:

クラスター内 Operator に対し、Operator が作成する AWS リソースのタグに指定されたユーザータグを組み込むフラグ。

ブール値( true または false など)。

platform:
  aws:
    subnets:

インストールプログラムによる VPC の作成を許可する代わりに VPC を指定する場合は、使用するクラスターのサブネットを指定します。サブネットは、指定する同じ machineNetwork[].cidr 範囲の一部である必要があります。

標準クラスターの場合は、各アベイラビリティーゾーンのパブリックおよびプライベートサブネットを指定します。

プライベートクラスターには、各アベイラビリティーゾーンのプライベートサブネットを指定します。

AWS Local Zone を使用するクラスターの場合、エッジマシンプールが確実に作成されるように、AWS Local Zone のサブネットをこのリストに追加する必要があります。

有効なサブネット ID。

platform:
  aws:
    publicIpv4Pool:

publishExternal に設定されている場合に、Elastic IP (EIP) を割り当てるために使用されるパブリック IPv4 プール ID。プールは、クラスターと同じ AWS アカウントとリージョンでプロビジョニングおよびアドバタイズする必要があります。プール内に、使用可能な IPv4 が 2n + 1 個あることを確認する必要があります。この場合の n は、API、NAT ゲートウェイ、およびブートストラップノードの Network Load Balancer ー (NLB) をデプロイするために使用される AWS ゾーンの合計数です。AWS での独自の持ち込み IP アドレス (BYOIP) の詳細は、Onboard your BYOIP を参照してください。

有効な public IPv4 pool id

注記

BYOIP は、ネットワーク制限のないカスタマイズされたインストールでのみ有効にできます。

platform:
  aws:
    preserveBootstrapIgnition:

ブートストラップの完了後に S3 バケットが削除されないようにします。

true または false。デフォルト値は false で、S3 バケットが削除されます。

第8章 AWS Local Zone または Wavelength Zone 関連のタスク

OpenShift Container Platform を Amazon Web Services (AWS) にインストールした後、AWS Local Zones または Wavelength Zones とエッジコンピュートプールをさらに設定できます。

8.1. 既存のクラスターを拡張して AWS Local Zones または Wavelength Zones を使用する

インストール後のタスクとして、Amazon Web Services (AWS) 上の既存の OpenShift Container Platform クラスターを拡張して、AWS Local Zones または Wavelength Zones を使用できます。

ノードを Local Zones または Wavelength Zones の場所に拡張するには、次の手順を実行します。

  • クラスターネットワークの最大伝送単位 (MTU) を調整します。
  • Local Zones または Wavelength Zones グループを AWS Local Zones または Wavelength Zones にオプトインします。
  • Local Zones または Wavelength Zones の場所の既存 VPC にサブネットを作成します。

    重要

    AWS 上の既存の OpenShift Container Platform クラスターを拡張して Local Zones または Wavelength Zones を使用する前に、既存の VPC に使用可能な Classless Inter-Domain Routing (CIDR) ブロックが含まれていることを確認してください。これらのブロックはサブネットの作成に必要です。

  • マシンセットマニフェストを作成し、Local Zone または Wavelength Zone の各場所にノードを作成します。
  • Local Zones のみ: ec2:ModifyAvailabilityZoneGroup 権限を Identity and Access Management (IAM) ユーザーまたはロールに追加して、必要なネットワークリソースを作成できるようにします。以下に例を示します。

    AWS Local Zones デプロイメントの追加 IAM ポリシーの例

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Action": [
            "ec2:ModifyAvailabilityZoneGroup"
          ],
          "Effect": "Allow",
          "Resource": "*"
        }
      ]
    }

  • Wavelength Zone のみ: ec2:ModifyAvailabilityZoneGroupec2:CreateCarrierGateway、および ec2:DeleteCarrierGateway 権限を Identity and Access Management (IAM) ユーザーまたはロールに追加して、必要なネットワークリソースを作成できるようにします。以下に例を示します。

    AWS Wavelength Zones デプロイメント用の追加 IAM ポリシーの例

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "ec2:DeleteCarrierGateway",
            "ec2:CreateCarrierGateway"
          ],
          "Resource": "*"
        },
        {
          "Action": [
            "ec2:ModifyAvailabilityZoneGroup"
          ],
          "Effect": "Allow",
          "Resource": "*"
        }
      ]
    }

関連情報

  • AWS Local Zones、サポートされているインスタンスタイプ、およびサービスの詳細は、AWS ドキュメントの AWS Local Zones features を参照してください。
  • AWS Local Zones、サポートされているインスタンスタイプ、およびサービスの詳細は、AWS ドキュメントの AWS Wavelength features を参照してください。

8.1.1. エッジコンピュートプールについて

エッジコンピュートノードは、AWS Local Zones または Wavelength Zone の場所で実行される taint されたコンピュートノードです。

Local Zones または Wavelength Zones を使用するクラスターをデプロイする場合は、次の点を考慮してください。

  • Local Zones または Wavelength Zones 内の Amazon EC2 インスタンスは、アベイラビリティーゾーン内の Amazon EC2 インスタンスよりも高コストです。
  • AWS Local Zones または Wavelength Zones で実行されているアプリケーションとエンドユーザーの間の遅延は低くなります。一部のワークロードでは、遅延の影響が発生します。たとえば、Local Zones または Wavelength Zones とアベイラビリティーゾーンの間で Ingress トラフィックが混在している場合などです。
重要

通常、Local Zones または Wavelength Zones 内の Amazon EC2 インスタンスとリージョン内の Amazon EC2 インスタンス間の最大伝送単位 (MTU) は 1300 です。クラスターネットワークの MTU は、オーバーヘッドを考慮して、常に EC2 の MTU よりも小さくする必要があります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。たとえば、OVN-Kubernetes のオーバーヘッドは 100 bytes です。

ネットワークプラグインは、IPsec などの追加機能を提供できます。MTU のサイズには、このような追加機能も影響します。

それぞれのゾーンタイプの詳細は、次のリソースにアクセスしてください。

OpenShift Container Platform 4.12 で、リモートゾーンで使用するために設計された新しいコンピュートプールの エッジ が導入されました。エッジコンピュートプールの設定は、AWS Local Zones または Wavelength Zones の場所間で共通です。Local Zones または Wavelength Zones リソース上の EC2 や EBS などのリソースのタイプとサイズの制限により、デフォルトのインスタンスタイプが従来のコンピュートプールと異なる場合があります。

Local Zones または Wavelength Zone の場所のデフォルト Elastic Block Store (EBS) は gp2 であり、非エッジコンピュートプールとは異なります。各 Local Zones または Wavelength Zones に使用される、エッジコンピュートプールのインスタンスタイプも、ゾーンのインスタンスオファリングに応じて、他のコンピュートプールと異なる場合があります。

エッジコンピュートプールは、開発者が AWS Local Zones または Wavelength Zones ノードにアプリケーションをデプロイするために使用できる新しいラベルを作成します。新しいラベルは次のとおりです。

  • node-role.kubernetes.io/edge=''
  • Local Zones のみ: machine.openshift.io/zone-type=local-zone
  • Wavelength Zones のみ: machine.openshift.io/zone-type=wavelength-zone
  • machine.openshift.io/zone-group=$ZONE_GROUP_NAME

デフォルトでは、エッジコンピュートプールのマシンセットは NoSchedule taint を定義して、Local Zones または Wavelength Zones のインスタンスに他のワークロードが拡散するのを防ぎます。ユーザーは、Pod 仕様で toleration を定義している場合にのみユーザーワークロードを実行できます。

8.2. Local Zones または Wavelength Zones をサポートするためのクラスターネットワーク MTU の変更

場合によっては、クラスターインフラストラクチャーが Local Zones または Wavelength Zones のサブネットをサポートできるように、クラスターネットワークの最大伝送単位 (MTU) 値を変更する必要があります。

8.2.1. クラスター MTU について

インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。

以下のような理由でクラスターネットワークの MTU を変更する場合があります。

  • クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
  • クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。

OVN-Kubernetes クラスターネットワークプラグインのみが MTU 値の変更をサポートしています。

8.2.1.1. サービス中断に関する考慮事項

クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。

  • 新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
  • 特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。
8.2.1.2. MTU 値の選択

MTU の移行を計画するときは、関連しているが異なる MTU 値を 2 つ考慮する必要があります。

  • ハードウェア MTU: この MTU 値は、ネットワークインフラストラクチャーの詳細に基づいて設定されます。
  • クラスターネットワーク MTU: この MTU 値は、クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。OVN-Kubernetes の場合、オーバーヘッドは 100 バイトです。

クラスターがノードごとに異なる MTU 値を必要とする場合は、クラスター内の任意のノードで使用される最小の MTU 値から、ネットワークプラグインのオーバーヘッド値を差し引く必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

重要

ノードが受け入れられない MTU 値の選択を回避するには、ip -d link コマンドを使用して、ネットワークインターフェイスが受け入れる最大 MTU 値 (maxmtu) を確認します。

8.2.1.3. 移行プロセスの仕組み

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

表8.1 クラスター MTU のライブマイグレーション
ユーザーが開始する手順OpenShift Container Platform アクティビティー

Cluster Network Operator 設定で次の値を指定します。

  • spec.migration.mtu.machine.to
  • spec.migration.mtu.network.from
  • spec.migration.mtu.network.to

Cluster Network Operator (CNO): 各フィールドが有効な値に設定されていることを確認します。

  • mtu.machine.toは、新しいハードウェア MTU、またはハードウェアの MTU が変更されていない場合は、現在のハードウェア MTU のいずれかに設定する必要があります。この値は一時的なものであり、移行プロセスの一部として使用されます。これとは別に、既存のハードウェア MTU 値とは異なるハードウェア MTU を指定する場合は、マシン設定、DHCP 設定、Linux カーネルコマンドラインなどの他の方法で永続化するように MTU を手動で設定する必要があります。
  • mtu.network.from フィールドは、クラスターネットワークの現在の MTU である network.status.clusterNetworkMTU フィールドと同じである必要があります。
  • mtu.network.toフィールドは、ターゲットクラスターネットワーク MTU に設定する必要があり、ネットワークプラグインのオーバーレイオーバーヘッドを考慮して、ハードウェア MTU よりも低くする必要があります。OVN-Kubernetes の場合、オーバーヘッドは 100 バイトです。

指定の値が有効な場合に、CNO は、クラスターネットワークの MTU がmtu.network.toフィールドの値に設定された新しい一時設定を書き出します。

Machine Config Operator (MCO): クラスター内の各ノードのローリングリブートを実行します。

クラスター上のノードのプライマリーネットワークインターフェイスの MTU を再設定します。これを実現するには、次のようなさまざまな方法を使用できます。

  • MTU を変更した新しい NetworkManager 接続プロファイルのデプロイ
  • DHCP サーバー設定による MTU の変更
  • ブートパラメーターによる MTU の変更

該当なし

ネットワークプラグインの CNO 設定で mtu 値を設定し、spec.migrationnull に設定します。

Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。

8.2.1.4. クラスターネットワーク MTU の変更

クラスター管理者は、クラスターの最大伝送単位 (MTU) を増減できます。

重要

移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
  • クラスターのターゲット MTU を特定している。OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から 100 を引いた値に設定する必要があります。

手順

  1. クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

    $ oc describe network.config cluster

    出力例

    ...
    Status:
      Cluster Network:
        Cidr:               10.217.0.0/22
        Host Prefix:        23
      Cluster Network MTU:  1400
      Network Type:         OVNKubernetes
      Service Network:
        10.217.4.0/23
    ...

  2. MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'

    ここでは、以下のようになります。

    <overlay_from>
    現在のクラスターネットワークの MTU 値を指定します。
    <overlay_to>
    クラスターネットワークのターゲット MTU を指定します。この値は、<machine_to> の値を基準にして設定します。OVN-Kubernetes の場合、この値は <machine_to> の値から 100 を引いた値である必要があります。
    <machine_to>
    基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。

    クラスター MTU を増やす例

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'

  3. Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get machineconfigpools

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

    注記

    Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。

  4. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

    2. 以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    3. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      ここで、<config_name>machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。

      マシン設定には、systemd 設定に以下の更新を含める必要があります。

      ExecStart=/usr/local/bin/mtu-migration.sh
  5. MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
      '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

    ここでは、以下のようになります。

    <mtu>
    <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。
  6. MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get machineconfigpools

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

検証

  • 次のコマンドを入力して、クラスター内のノードが指定した MTU を使用していることを確認します。

    $ oc describe network.config cluster

8.2.2. AWS Local Zones または Wavelength Zones へのオプトイン

AWS Local Zones または Wavelength Zones にサブネットを作成する予定がある場合は、各ゾーングループに個別にオプトインする必要があります。

前提条件

  • AWS CLI をインストールしている。
  • OpenShift Container Platform クラスターをデプロイする AWS リージョンを決定しました。
  • ゾーングループにオプトインするユーザーまたはロールアカウントに、寛容な IAM ポリシーをアタッチしました。

手順

  1. 次のコマンドを実行して、AWS リージョンで利用可能なゾーンをリスト表示します。

    AWS リージョンで利用可能な AWS Local Zones をリスト表示するコマンドの例

    $ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
        --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
        --filters Name=zone-type,Values=local-zone \
        --all-availability-zones

    AWS リージョンで利用可能な AWS Wavelength Zones をリストするコマンドの例

    $ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
        --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
        --filters Name=zone-type,Values=wavelength-zone \
        --all-availability-zones

    AWS リージョンによっては、利用可能なゾーンのリストが長くなる場合があります。このコマンドは次のフィールドを返します。

    ZoneName
    Local Zones または Wavelength Zones の名前。
    GroupName
    ゾーンで構成されるグループ。リージョンにオプトインするには、この名前を保存しておきます。
    Status
    Local Zones または Wavelength Zones グループのステータス。ステータスが not-opted-in の場合は、次の手順で説明するように GroupName をオプトインする必要があります。
  2. 次のコマンドを実行して、AWS アカウントのゾーングループにオプトインします。

    $ aws ec2 modify-availability-zone-group \
        --group-name "<value_of_GroupName>" \1
        --opt-in-status opted-in
    1
    <value_of_GroupName> は、サブネットを作成する Local Zones または Wavelength Zones のグループの名前に置き換えます。

8.2.3. AWS Local Zones または Wavelength Zones を使用する既存の VPC にネットワーク要件を作成する

Machine API でリモートゾーンの場所に Amazon EC2 インスタンスを作成する場合は、Local Zones または Wavelength Zones の場所にサブネットを作成する必要があります。Ansible や Terraform などのプロビジョニングツールを使用して、既存の Virtual Private Cloud (VPC) にサブネットを作成できます。

要件を満たすように CloudFormation テンプレートを設定できます。次のサブセクションでは、CloudFormation テンプレートを使用して、AWS Local Zones または Wavelength Zones を使用するように既存の VPC を拡張するネットワーク要件を作成する手順を説明します。

ノードを Local Zones に拡張するには、次のリソースを作成する必要があります。

  • 2 つの VPC サブネット: パブリックとプライベート。パブリックサブネットは、リージョン内の通常のアベイラビリティーゾーンのパブリックルートテーブルに関連付けます。プライベートサブネットは、指定のルートテーブル ID に関連付けます。

ノードを Wavelength Zones に拡張するには、次のリソースを作成する必要があります。

  • 指定の VPC ID に関連付けられた 1 つの VPC キャリアーゲートウェイ。
  • VPC キャリアーゲートウェイへのデフォルトルートエントリーを含む、Wavelength Zones の 1 つの VPC ルートテーブル。
  • 2 つの VPC サブネット: パブリックとプライベート。パブリックサブネットは、AWS Wavelength Zone のパブリックルートテーブルに関連付けます。プライベートサブネットは、指定のルートテーブル ID に関連付けます。
重要

このドキュメントの CloudFormation テンプレートは、Wavelength Zones の NAT ゲートウェイの制限を考慮して、プライベートサブネットと指定のルートテーブル ID の関連付けのみをサポートしています。ルートテーブル ID は、AWS リージョン内の有効な NAT ゲートウェイに割り当てられます。

8.2.4. Wavelength Zones のみ: VPC キャリアーゲートウェイの作成

Wavelength Zones で実行される OpenShift Container Platform クラスターでパブリックサブネットを使用するには、キャリアーゲートウェイを作成し、キャリアーゲートウェイを VPC に関連付ける必要があります。サブネットは、ロードバランサーまたはエッジコンピュートノードをデプロイするのに役立ちます。

OpenShift Container Platform クラスター用の Wavelength Zones の場所に、エッジノードやインターネットに接続されたロードバランサーを作成するには、以下の必要なネットワークコンポーネントを作成する必要があります。

  • 既存の VPC に関連付けるキャリアーゲートウェイ
  • ルートエントリーをリストするキャリールートテーブル
  • キャリアールートテーブルに関連付けるサブネット

キャリアーゲートウェイは、Wavelength Zone 内のサブネットのみを含む VPC に存在します。

以下では、AWS Wavelength Zones の場所に関連するキャリアーゲートウェイの機能を説明します。

  • Wavelength Zone とキャリアーネットワーク (キャリアーネットワークから利用可能なデバイスを含む) の間の接続を提供します。
  • ネットワークボーダーグループに格納されているパブリック IP アドレスである IP アドレスを Wavelength Zones からキャリアー IP アドレスに変換するなど、ネットワークアドレス変換 (NAT) 機能を実行します。このような変換機能は、受信トラフィックと送信トラフィックに適用されます。
  • 特定の場所にあるキャリアーネットワークからの受信トラフィックを許可します。
  • キャリアーネットワークとインターネットへの送信トラフィックを許可します。
注記

インターネットからキャリアーゲートウェイを経由した Wavelength Zone への受信接続設定は存在しません。

このドキュメントの CloudFormation テンプレートを使用して、次の AWS リソースのスタックを作成できます。

  • テンプレート内の VPC ID に関連付ける 1 つのキャリアーゲートウェイ
  • <ClusterName>-public-carrier という名前の Wavelength Zone の 1 つのパブリックルートテーブル
  • キャリアーゲートウェイをターゲットとする新しいルートテーブルのデフォルトの IPv4 ルートエントリー
  • AWS Simple Storage Service (S3) の VPC ゲートウェイエンドポイント
注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。

手順

  1. ドキュメントの次のセクション「VPC キャリアーゲートウェイ用の CloudFormation テンプレート」に移動し、VPC キャリアーゲートウェイ用の CloudFormation テンプレート から構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \2
      --parameters \//
        ParameterKey=VpcId,ParameterValue="${VpcId}" \3
        ParameterKey=ClusterName,ParameterValue="${ClusterName}" 4
    1
    <stack_name> は CloudFormation スタックの名前です (例: clusterName-vpc-carrier-gw)。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    <VpcId> は、「AWS での VPC の作成」セクションで作成した CloudFormation スタックの出力から抽出した VPC ID です。
    4
    <ClusterName> は、CloudFormation スタックによって作成されるリソースに接頭辞として付加するカスタム値です。install-config.yaml 設定ファイルの metadata.name セクションで定義されているのと同じ名前を使用できます。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f

検証

  • 次のコマンドを実行して、CloudFormation テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。このパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

    PublicRouteTableId

    キャリアーインフラストラクチャーのルートテーブルの ID。

8.2.5. Wavelength Zone のみ: VPC キャリアーゲートウェイ用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、AWS Wavelength インフラストラクチャーにキャリアーゲートウェイをデプロイできます。

例8.1 VPC キャリアーゲートウェイ用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Creating Wavelength Zone Gateway (Carrier Gateway).

Parameters:
  VpcId:
    Description: VPC ID to associate the Carrier Gateway.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster Name or Prefix name to prepend the tag Name for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.

Resources:
  CarrierGateway:
    Type: "AWS::EC2::CarrierGateway"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "cagw"]]

  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public-carrier"]]

  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: CarrierGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      CarrierGatewayId: !Ref CarrierGateway

  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VpcId

Outputs:
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable

8.2.6. AWS エッジコンピュートサービス用のサブネットの作成

OpenShift Container Platform クラスターのエッジコンピュートノードのマシンセットを設定する前に、Local Zones または Wavelength Zones にサブネットを作成する必要があります。コンピュートノードをデプロイする Wavelength Zone ごとに次の手順を実行してください。

このドキュメントの CloudFormation テンプレートを使用して、CloudFormation スタックを作成できます。その後、このスタックを使用してサブネットをカスタムプロビジョニングできます。

注記

このドキュメントの CloudFormation テンプレートを使用して AWS インフラストラクチャーを作成しない場合は、記載されている情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。

前提条件

  • AWS アカウントを設定している。
  • aws configure を実行して、AWS キーおよびリージョンをローカルの AWS プロファイルに追加している。
  • Local Zones または Wavelength Zones グループにオプトインしている。

手順

  1. このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
  2. 次のコマンドを実行して CloudFormation テンプレートをデプロイします。これにより、VPC を表す AWS リソースのスタックが作成されます。

    $ aws cloudformation create-stack --stack-name <stack_name> \1
      --region ${CLUSTER_REGION} \
      --template-body file://<template>.yaml \2
      --parameters \
        ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3
        ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4
        ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5
        ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6
        ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7
        ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8
        ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
    1
    <stack_name> は、CloudFormation スタックの名前です。たとえば、Local Zones の場合は cluster-wl-<local_zone_shortname>、Wavelength Zones の場合は cluster-wl-<wavelength_zone_shortname> です。クラスターを削除する場合に、このスタックの名前が必要になります。
    2
    <template> は、保存した CloudFormation テンプレート YAML ファイルの相対パスと名前です。
    3
    ${VPC_ID} は VPC ID であり、VPC 用の CloudFormation テンプレートの出力に含まれる値 VpcID です。
    4
    ${CLUSTER_NAME} は、新しい AWS リソース名の接頭辞として使用する ClusterName の値です。
    5
    ${ZONE_NAME} は、サブネットを作成する Local Zones または Wavelength Zones 名の値です。
    6
    ${ROUTE_TABLE_PUB} は、CloudFormation テンプレートから抽出したパブリックルートテーブル ID です。Local Zones の場合、パブリックルートテーブルは VPC の CloudFormation スタックから抽出します。Wavelength Zones の場合、VPC のキャリアーゲートウェイ CloudFormation スタックの出力から値を抽出する必要があります。
    7
    ${SUBNET_CIDR_PUB} は、パブリックサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。
    8
    ${ROUTE_TABLE_PVT} は、VPC の CloudFormation スタックの出力から抽出した PrivateRouteTableId です。
    9
    ${SUBNET_CIDR_PVT} は、プライベートサブネットの作成に使用する有効な CIDR ブロックです。このブロックは、VPC CIDR ブロック VpcCidr の一部である必要があります。

    出力例

    arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f

検証

  • 次のコマンドを実行して、テンプレートコンポーネントが存在することを確認します。

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatusCREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。

    PublicSubnetId

    CloudFormation スタックによって作成されたパブリックサブネットの ID。

    PrivateSubnetId

    CloudFormation スタックによって作成されたプライベートサブネットの ID。

    これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

8.2.7. VPC サブネット用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、Local Zones または Wavelength Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。

例8.2 VPC サブネット用の CloudFormation テンプレート

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice Subnets (Public and Private)

Parameters:
  VpcId:
    Description: VPC ID that comprises all the target subnets.
    Type: String
    AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
    ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
  ClusterName:
    Description: Cluster name or prefix name to prepend the Name tag for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.
  ZoneName:
    Description: Zone Name to create the subnets, such as us-west-2-lax-1a.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ZoneName parameter must be specified.
  PublicRouteTableId:
    Description: Public Route Table ID to associate the public subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PublicRouteTableId parameter must be specified.
  PublicSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for public subnet.
    Type: String
  PrivateRouteTableId:
    Description: Private Route Table ID to associate the private subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: PrivateRouteTableId parameter must be specified.
  PrivateSubnetCidr:
    AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
    Default: 10.0.128.0/20
    Description: CIDR block for private subnet.
    Type: String


Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]]

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PrivateSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]]

  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTableId

Outputs:
  PublicSubnetId:
    Description: Subnet ID of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

  PrivateSubnetId:
    Description: Subnet ID of the private subnets.
    Value:
      !Join ["", [!Ref PrivateSubnet]]

8.2.8. AWS Local Zones または Wavelength Zones ノードのマシンセットマニフェストの作成

AWS Local Zones または Wavelength Zones にサブネットを作成した後、マシンセットマニフェストを作成できます。

インストールプログラムは、クラスターのインストール時に edge マシンプールに次のラベルを設定します。

  • machine.openshift.io/parent-zone-name: <value_of_ParentZoneName>
  • machine.openshift.io/zone-group: <value_of_ZoneGroup>
  • machine.openshift.io/zone-type: <value_of_ZoneType>

次の手順では、edgeコンピュートプール設定に一致するマシンセット設定を作成する方法を詳しく説明します。

前提条件

  • AWS Local Zones または Wavelength Zones にサブネットを作成している。

手順

  • AWS API を収集してマシンセットマニフェストを作成するときに、edge マシンプールのラベルを手動で保存します。このアクションを完了するには、コマンドラインインターフェイス (CLI) で次のコマンドを入力します。

    $ aws ec2 describe-availability-zones --region <value_of_Region> \1
        --query 'AvailabilityZones[].{
    	ZoneName: ZoneName,
    	ParentZoneName: ParentZoneName,
    	GroupName: GroupName,
    	ZoneType: ZoneType}' \
        --filters Name=zone-name,Values=<value_of_ZoneName> \2
        --all-availability-zones
    1
    <value_of_Region> には、ゾーンのリージョンの名前を指定します。
    2
    <value_of_ZoneName> には、Local Zones または Wavelength Zones の名前を指定します。

    Local Zone us-east-1-nyc-1a の出力例

    [
        {
            "ZoneName": "us-east-1-nyc-1a",
            "ParentZoneName": "us-east-1f",
            "GroupName": "us-east-1-nyc-1",
            "ZoneType": "local-zone"
        }
    ]

    Wavelength Zone us-east-1-wl1 の出力例

    [
        {
            "ZoneName": "us-east-1-wl1-bos-wlz-1",
            "ParentZoneName": "us-east-1a",
            "GroupName": "us-east-1-wl1",
            "ZoneType": "wavelength-zone"
        }
    ]

8.2.8.1. AWS 上のコンピュートマシンセットカスタムリソースのサンプル YAML

このサンプル YAML は us-east-1-nyc-1a Amazon Web Services (AWS) ゾーンで実行し、node-role.kubernetes.io/edge: "" というラベルが付けられたノードを作成するコンピュートマシンセットを定義します。

注記

Wavelength Zone との関連でサンプル YAML ファイルを参照する場合は、必ず AWS リージョンとゾーンの情報をサポートされている Wavelength Zone の値に置き換えてください。

このサンプルでは、<infrastructure_id> はクラスターのプロビジョニング時に設定したクラスター ID に基づくインフラストラクチャー ID であり、<edge> は追加するノードラベルです。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
  name: <infrastructure_id>-edge-<zone> 2
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-edge-<zone>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id> 4
        machine.openshift.io/cluster-api-machine-role: edge 5
        machine.openshift.io/cluster-api-machine-type: edge 6
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-edge-<zone> 7
    spec:
      metadata:
        labels:
          machine.openshift.io/parent-zone-name: <value_of_ParentZoneName>
          machine.openshift.io/zone-group: <value_of_GroupName>
          machine.openshift.io/zone-type: <value_of_ZoneType>
          node-role.kubernetes.io/edge: "" 8
      providerSpec:
        value:
          ami:
            id: ami-046fe691f52a953f9 9
          apiVersion: machine.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile 10
          instanceType: m6i.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone> 11
            region: <region> 12
          securityGroups:
            - filters:
                - name: tag:Name
                  values:
                    - <infrastructure_id>-worker-sg 13
          subnet:
              id: <value_of_PublicSubnetIds> 14
          publicIp: true
          tags:
            - name: kubernetes.io/cluster/<infrastructure_id> 15
              value: owned
            - name: <custom_tag_name> 16
              value: <custom_tag_value> 17
          userDataSecret:
            name: worker-user-data
      taints: 18
        - key: node-role.kubernetes.io/edge
          effect: NoSchedule
1 3 4 10 13 15
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。OpenShift CLI がインストールされている場合は、以下のコマンドを実行してインフラストラクチャー ID を取得できます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 7
インフラストラクチャー ID、edge ロールノードラベル、およびゾーン名を指定します。
5 6 8
edge ロールノードラベルを指定します。
9
OpenShift Container Platform ノードの AWS ゾーンに有効な Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を指定します。AWS Marketplace イメージを使用する場合は、AWS Marketplace から OpenShift Container Platform サブスクリプションを完了して、リージョンの AMI ID を取得する必要があります。
$ oc -n openshift-machine-api \
    -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \
    get machineset/<infrastructure_id>-<role>-<zone>
16 17
オプション: クラスターのカスタムタグデータを指定します。たとえば、name:value のペアである Email:admin-email@example.com を指定して、管理者の連絡先電子メールアドレスを追加できます。
注記

カスタムタグは、インストール中に install-config.yml ファイルで指定することもできます。install-config.yml ファイルとマシンセットに同じ 名前 のデータを持つタグが含まれている場合、マシンセットのタグの値が install-config.yml ファイルのタグの値よりも優先されます。

11
ゾーン名を指定します (例: us-east-1-nyc-1a)。
12
リージョン (例: us-east-1) を指定します。
14
AWS Local Zones または Wavelength Zones に作成したパブリックサブネットの ID。このパブリックサブネット ID は、「AWS ゾーンでのサブネットの作成」手順を完了したときに作成したものです。
18
ユーザーのワークロードが edge ノードにスケジュールされないように taint を指定します。
注記

インフラストラクチャーノードに NoSchedule taint を追加すると、そのノードで実行されている既存の DNS Pod は misscheduled としてマークされます。misscheduled DNS Pod に対する toleration の追加 または削除を行う必要があります。

8.2.8.2. コンピュートマシンセットの作成

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。

      $ oc get machineset <machineset_name> \
        -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
          spec:
            providerSpec: 3
              ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。
  3. 次のコマンドを実行して MachineSet CR を作成します。

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
    agl030519-vplxk-edge-us-east-1-nyc-1a      1         1         1       1           11m
    agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
    agl030519-vplxk-worker-us-east-1d          0         0                             55m
    agl030519-vplxk-worker-us-east-1e          0         0                             55m
    agl030519-vplxk-worker-us-east-1f          0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIREDCURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

  • オプション: エッジマシンによって作成されたノードを確認するには、次のコマンドを実行します。

    $ oc get nodes -l node-role.kubernetes.io/edge

    出力例

    NAME                           STATUS   ROLES         AGE    VERSION
    ip-10-0-207-188.ec2.internal   Ready    edge,worker   172m   v1.25.2+d2e245f

8.3. AWS Local Zones または Wavelength Zones でのユーザーワークロードの作成

Amazon Web Service (AWS) の Local Zones または Wavelength Zone インフラストラクチャーを作成し、クラスターをデプロイした後、エッジコンピュートノードを使用して Local Zones または Wavelength Zones のサブネットにユーザーワークロードを作成できます。

インストールプログラムを使用してクラスターを作成すると、インストールプログラムは各エッジコンピュートノードに NoSchedule taint effect を自動的に指定します。これは、Pod が taint に対して指定された許容範囲に一致しない場合、スケジューラーは新しい Pod またはデプロイメントをノードに追加しないことを意味します。taint を変更することで、Local Zones または Wavelength Zones の各サブネットにノードがワークロードを作成する方法をより適切に制御できます。

インストールプログラムは、node-role.kubernetes.io/edge ラベルと node-role.kubernetes.io/worker ラベルを含むコンピュートマシンセットのマニフェストファイルを作成します。これらのラベルは、Local Zones または Wavelength Zones のサブネット内にある各エッジコンピュートノードに適用されます。

注記

この手順の例は、Local Zones インフラストラクチャーを対象としています。Wavelength Zone インフラストラクチャーを使用している場合は、Wavelength Zone インフラストラクチャーでサポートされている機能に合わせて例を変更してください。

前提条件

  • OpenShift CLI (oc) にアクセスできる。
  • Local Zones または Wavelength Zones のサブネットが定義された Virtual Private Cloud (VPC) にクラスターをデプロイしている。
  • Local Zones または Wavelength Zones のサブネット上のエッジコンピュートノードのコンピュートマシンセットが、node-role.kubernetes.io/edge の taint を指定していることを確認している。

手順

  1. Local Zones のサブネットで動作するエッジコンピュートノードにデプロイするサンプルアプリケーションの deployment リソース YAML ファイルを作成します。エッジコンピュートノードの taint に合った正しい toleration を指定していることを確認してください。

    Local Zone のサブネットで動作するエッジコンピュートノード用に設定された deployment リソースの例

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <local_zone_application_namespace>
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: <pvc_name>
      namespace: <local_zone_application_namespace>
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: gp2-csi 1
      volumeMode: Filesystem
    ---
    apiVersion: apps/v1
    kind: Deployment 2
    metadata:
      name: <local_zone_application> 3
      namespace: <local_zone_application_namespace> 4
    spec:
      selector:
        matchLabels:
          app: <local_zone_application>
      replicas: 1
      template:
        metadata:
          labels:
            app: <local_zone_application>
            zone-group: ${ZONE_GROUP_NAME} 5
        spec:
          securityContext:
            seccompProfile:
              type: RuntimeDefault
          nodeSelector: 6
            machine.openshift.io/zone-group: ${ZONE_GROUP_NAME}
          tolerations: 7
          - key: "node-role.kubernetes.io/edge"
            operator: "Equal"
            value: ""
            effect: "NoSchedule"
          containers:
            - image: openshift/origin-node
              command:
               - "/bin/socat"
              args:
                - TCP4-LISTEN:8080,reuseaddr,fork
                - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
              imagePullPolicy: Always
              name: echoserver
              ports:
                - containerPort: 8080
              volumeMounts:
                - mountPath: "/mnt/storage"
                  name: data
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: <pvc_name>

    1
    storageClassName: Local Zone 設定の場合、gp2-csi を指定する必要があります。
    2
    kind: deployment リソースを定義します。
    3
    name: Local Zone アプリケーションの名前を指定します。たとえば、local-zone-demo-app-nyc-1 です。
    4
    namespace: ユーザーワークロードを実行する AWS Local Zone 用の namespace を定義します。例: local-zone-app-nyc-1a
    5
    zone-group: ゾーンが属するグループを定義します。たとえば、us-east-1-iah-1
    6
    nodeSelector: 指定のラベルに一致するエッジコンピュートノードをターゲットとします。
    7
    tolerations: Local Zone ノードの MachineSet マニフェストで定義された taints と一致する値を設定します。
  2. ノードの service リソース YAML ファイルを作成します。このリソースは、ターゲットのエッジコンピュートノードから Local Zone ネットワーク内で実行されるサービスに Pod を公開します。

    Local Zone サブネットで動作するエッジコンピュートノード用に設定された service リソースの例

    apiVersion: v1
    kind: Service 1
    metadata:
      name:  <local_zone_application>
      namespace: <local_zone_application_namespace>
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector: 2
        app: <local_zone_application>

    1
    kind: service リソースを定義します。
    2
    selector: マネージド Pod に適用されるラベルタイプを指定します。

8.4. 次のステップ

  • オプション: AWS Load Balancer (ALB) Operator を使用して、ターゲットのエッジコンピュートノードからパブリックネットワークの Local Zones または Wavelength Zones のサブネット内で実行されるサービスに Pod を公開します。AWS Load Balancer Operator のインストール を参照してください。

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.