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.16 における回避策です。詳細は、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
) がインストールされている。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー ID をリスト表示します。この値を保存しておきます。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructures.config.openshift.io cluster
次のコマンドを実行して、インストールプログラムが作成したコンピュートマシンセットに関する詳細を取得します。
クラスター上のコンピュートマシンセットをリスト表示します。
$ 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
リストされたコンピュートマシンセットのいずれかの 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}'
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 アカウントにアクセスできる。
手順
次のコマンドを実行して、AWS アカウントに接続されている Outpost をリスト表示します。
$ aws outposts list-outposts
aws outposts list-outposts
コマンドの出力の次の値を保存しておきます。- Outpost ID
- Outpost の Amazon Resource Name (ARN)
Outpost のアベイラビリティーゾーン
注記aws outposts list-outposts
コマンドの出力には、アベイラビリティーゾーンに関連する 2 つの値、AvailabilityZone
とAvailabilityZoneId
が含まれています。Outpost 内にコンピュートマシンを作成するコンピュートマシンセットを設定するには、AvailablilityZone
値を使用します。
Outpost ID の値を使用して次のコマンドを実行し、Outpost で利用可能なインスタンスタイプを表示します。利用可能なインスタンスタイプの値を保存しておきます。
$ aws outposts get-outpost-instance-types \ --outpost-id <outpost_id_value>
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
を引いた値に設定する必要があります。
手順
クラスターネットワークの現在の 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 ...
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} } } } }'
Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
$ oc get machineconfigpools
正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 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
以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/state
フィールドの値はDone
です。 -
machineconfiguration.openshift.io/currentConfig
フィールドの値は、machineconfiguration.openshift.io/desiredConfig
フィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
ここで、
<config_name>
はmachineconfiguration.openshift.io/currentConfig
フィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/mtu-migration.sh
MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
ここでは、以下のようになります。
<mtu>
-
<overlay_to>
で指定した新しいクラスターネットワーク MTU を指定します。
MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
$ oc get machineconfigpools
正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=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 アカウントから環境に関する必要な情報を取得している。
手順
- このドキュメントの「VPC サブネット用の CloudFormation テンプレート」セクションに移動し、テンプレートから構文をコピーします。コピーしたテンプレートの構文を YAML ファイルとしてローカルシステムに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。
次のコマンドを実行して 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>
StackStatus
にCREATE_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]]
3.13.4. Outpost にエッジコンピュートマシンをデプロイするコンピュートマシンセットの作成
AWS Outposts でエッジコンピュートマシンを作成するには、互換性のある設定を使用して新しいコンピュートマシンセットを作成する必要があります。
前提条件
- AWS Outposts サイトがある。
- OpenShift Container Platform クラスターを AWS のカスタム VPC にインストールしている。
-
cluster-admin
権限を持つアカウントを使用してクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ 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
- 既存のコンピュートマシンセットの名前を記録します。
次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (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 # ...
<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 を指定する必要があります。
- 変更を保存します。
次のコマンドを実行して、コンピュートマシンセット 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 環境と互換性のあるエッジコンピュートマシンをデプロイするコンピュートマシンセットを作成している。
手順
エッジサブネットのエッジコンピュートノードにデプロイするアプリケーションの
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 を指定します。この例のようにvalue
とoperator
の toleration を設定します。
次のコマンドを実行して、
Deployment
リソースを作成します。$ oc create -f <application_deployment>.yaml
ターゲットのエッジコンピュートノードからエッジネットワーク内で実行されるサービスに 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>
次のコマンドを実行して
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 に作成している。
手順
オプション: 次のコマンドを実行し、出力に Outpost 内のエッジコンピュートノードのみが含まれていることを確認して、エッジコンピュートノードに
location=outposts
ラベルがあることを確認します。$ oc get nodes -l location=outposts
次のコマンドを実行して、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
オプション: 次のコマンドを実行し、出力に VPC クラスター内のすべてのクラウドベースのコンピュートノードが含まれていることを確認して、クラウドベースのコンピュートノードに指定したラベルがあることを確認します。
$ oc get nodes -l <key_name>=<value>
出力例
NAME STATUS ROLES AGE VERSION node1.example.com Ready worker 7h v1.29.4 node2.example.com Ready worker 7h v1.29.4 node3.example.com Ready worker 7h v1.29.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
次のコマンドを実行して
Service
CR を作成します。$ oc create -f <file_name>.yaml
検証
次のコマンドを実行して、
service
リソースのステータスを確認して、プロビジョニングされた Classic Load Balancer のホストを表示します。$ HOST=$(oc get service <application_name> -n <application_namespace> --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
次のコマンドを実行して、プロビジョニングされた Classic Load Balancer ホストのステータスを確認します。
$ curl $HOST
- 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 つのサブネットを指定する必要があります。