検索

4.8. AWS Local Zone または Wavelength Zone 関連のタスク

download PDF

OpenShift Container Platform を Amazon Web Services (AWS) にインストールした後、AWS Local Zones または Wavelength Zones とエッジコンピュートプールをさらに設定できます。

4.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 を参照してください。

4.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 を定義している場合にのみユーザーワークロードを実行できます。

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

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

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

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

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

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

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

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

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

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

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

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

表4.31 クラスター 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 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。

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

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

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

4.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。

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

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

例4.85 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

4.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 テンプレートに必ず指定してください。

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

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

例4.86 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]]

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

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

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

4.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 に適用されるラベルタイプを指定します。

4.8.4. 次のステップ

  • オプション: AWS Load Balancer (ALB) Operator を使用して、ターゲットのエッジコンピュートノードからパブリックネットワークの Local Zones または Wavelength Zones のサブネット内で実行されるサービスに Pod を公開します。AWS Load Balancer Operator のインストール を参照してください。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.