サポートコンソール開発者トライアルの開始お問い合わせ

17.2. Local Zones または Wavelength Zones をサポートするためのクラスターネットワーク MTU の変更

場合によっては、クラスターインフラストラクチャーが Local Zones または Wavelength Zones のサブネットをサポートできるように、クラスターネットワークの最大伝送単位 (MTU) 値を変更する必要があります。

17.2.1. クラスター MTU について

インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。

以下のような理由でクラスターネットワークの MTU を変更する場合があります。

  • クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
  • クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。

OVN-Kubernetes クラスターネットワークプラグインのみが MTU 値の変更をサポートしています。

17.2.1.1. サービス中断に関する考慮事項

クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。

  • 新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
  • 特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。

17.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) を確認します。

17.2.1.3. 移行プロセスの仕組み

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

表17.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.migration を null に設定します。

Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。

17.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=true、UPDATING=false、DEGRADED=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=true、UPDATING=false、DEGRADED=false のステータスがあります。

検証

  • 次のコマンドを入力して、クラスター内のノードが指定した MTU を使用していることを確認します。 

    $ oc describe network.config cluster

17.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 のグループの名前に置き換えます。

17.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 ゲートウェイに割り当てられます。

17.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>

    StackStatus に CREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。このパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

    PublicRouteTableId

    キャリアーインフラストラクチャーのルートテーブルの ID。

17.2.5. Wavelength Zone のみ: VPC キャリアーゲートウェイ用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、AWS Wavelength インフラストラクチャーにキャリアーゲートウェイをデプロイできます。

例17.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

17.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>

    StackStatus に CREATE_COMPLETE が表示されると、出力に次のパラメーターの値が表示されます。

    PublicSubnetId

    CloudFormation スタックによって作成されたパブリックサブネットの ID。

    PrivateSubnetId

    CloudFormation スタックによって作成されたプライベートサブネットの ID。

    これらのパラメーター値を、クラスターを作成するために実行する他の CloudFormation テンプレートに必ず指定してください。

17.2.7. VPC サブネット用の CloudFormation テンプレート

次の CloudFormation テンプレートを使用して、Local Zones または Wavelength Zones インフラストラクチャー上のゾーンにプライベートサブネットとパブリックサブネットをデプロイできます。

例17.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]]

17.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"
    }
]

17.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 の追加 または削除を行う必要があります。

17.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

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

  • オプション: エッジマシンによって作成されたノードを確認するには、次のコマンドを実行します。 

    $ 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

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.