マルチゾーン相互接続を構成する

このページでは、新しいゾーンがデプロイに参加するときに、マルチゾーンデプロイの既存のゾーンで行う必要がある構成について説明します。この構成により、新しいゾーンへの接続を確立できます。

1. 始める前に

Google Distributed Cloud（GDC）エアギャップでマルチゾーン相互接続を構成するには、次のものが必要です。

生成された kubeconfig ファイルと環境変数。詳細については、IAM-R0004 ランブックをご覧ください。
ルート管理クラスタに一時的にアクセスできるインフラストラクチャオペレーター（IO）。詳細については、IAM-R0005 ランブックをご覧ください。

2. マルチゾーン相互接続を構成する

マルチゾーンデプロイの各ゾーンで MultiZoneNetworkConfig リソースを構成します。
1. 操作する正しいクラスタを見つけます。ルート管理クラスタが実行されている場合は、ルート管理クラスタの kubeconfig を使用します。それ以外の場合は、ブートストラップ種類のクラスタに kubeconfig を使用します。詳細については、IAM-R0004 ランブックをご覧ください。ここに kubeconfig パスを入力します。
```
KUBECONFIG=KUBECONFIG_PATH
```
2. multizone_network_config.yaml という名前の YAML ファイルを作成します。
3. 次の内容をファイルに追加します。
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: CARRIER_TYPE
  zones:
    - zoneID: ZONE_1_ID
      asn: ZONE_1_ASN
      externalSubnets:
        - METERING_SUBNET_1
    - zoneID: ZONE_2_ID
      asn: ZONE_2_ASN
      externalSubnets:
        - METERING_SUBNET_2
  ports:
    - port: PORT_1
    - port: PORT_2
  portSetting:
    mtu: MTU
```
  次のように置き換えます。
  - CARRIER_TYPE: マルチゾーンバックボーンのキャリアタイプ。L2 または L3 にする必要があります。
    
    重要: L2 運送業者のタイプの場合、ゾーンの数は 3 つを超えないことを強くおすすめします。
  - ZONE_1_ID: GDC リージョンの最初のゾーンの ID。
  - ZONE_1_ASN: GDC リージョンの最初のゾーンのデータネットワークの BGP 自律システム番号（ASN）。
  - METERING_SUBNET_1: このゾーンの従量課金制サブネット。このフィールドには、関連付けられたゾーンのルート管理クラスタにある zone-infra-cidr CIDRClaim リソースのサブネットを入力する必要があります。このフィールドは測定のみを目的としており、サブネットの広告の制御には影響しません。このフィールドは、アドバタイズされる実際のサブネットと同期させる必要があります。このフィールドが指定されていない場合、このゾーンのトラフィックは測定されません。
  - ZONE_2_ID: GDC リージョンの 2 番目のゾーンの ID。
  - ZONE_2_ASN: GDC リージョンの 2 番目のゾーンのデータネットワークの BGP ASN。
  - METERING_SUBNET_2: このゾーンの従量課金制サブネット。このフィールドには、関連付けられたゾーンのルート管理クラスタにある zone-infra-cidr CIDRClaim リソースのサブネットを入力する必要があります。このフィールドは測定のみを目的としており、サブネットの広告の制御には影響しません。このフィールドは、アドバタイズされる実際のサブネットと同期させる必要があります。このフィールドが指定されていない場合、このゾーンのトラフィックは測定されません。
  - PORT_1: マルチゾーン相互接続に参加する最初のポート。詳細については、ポートを構成するをご覧ください。
  - PORT_2: マルチゾーン相互接続に参加している 2 番目のポート。詳細については、ポートを構成するをご覧ください。
  - MTU: すべてのポートに適用される MTU 値。指定しない場合、デフォルト値は 9216 です。
  注意: 現在のゾーンを含むすべてのゾーンが zones フィールドに含まれている必要があります。
  注: ゾーン ASN は、関連付けられたゾーンの dataASN と同じである必要があります。
  一般的なデプロイ例については、マルチゾーン構成の例をご覧ください。
4. multizone_network_config.yaml ファイルをクラスタに適用します。
```
kubectl apply -f multizone_network_config.yaml --kubeconfig=KUBECONFIG_PATH
```
5. MultiZonetNetworkConfig リソースの作成が成功したことを確認します。
```
kubectl get multizonenetworkconfig -n gpc-system --kubeconfig=KUBECONFIG_PATH
```
  次の例は、相互接続リンクを含む出力を示しています。
```
NAME                       AGE   READY
multizone-network-config   26h   True
```
6. 省略可: 相互接続の BGP 構成とステータスについて MultiZoneNetworkPeeringConfig リソースを確認します。
  
  実際の BGP 構成はネットワーク Reconciler によって設定され、MultiZoneNetworkPeeringConfig リソースに保存されます。各 MultiZoneNetworkPeeringConfig リソースは、あるゾーンから別のゾーンへのすべての BGP 構成を表します。次に例を示します。
  - zone-1-zone-2-peering-config という名前の MultiZoneNetworkPeeringConfig リソースは次のようになります。
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-zone-2-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    evpnBGPSessions:
    - bgpSessionConfig:
        addressFamily: EVPN
        bfdConfig:
          bfdMode: MultiHopBFD
        localASN: 65501
        localIP: 192.168.201.65/32
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-evpn-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.202.65
        sourceInterface: loopback2
      bgpSessionStatus:
        prefixCounters:
          received: 4
          sent: 23
        sessionStatus: Up
        uptime: P6DT20H26M59S
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-zone-2-blsw-1-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6
```
  この例のステータスには、ゾーン 1 からゾーン 2 までのすべての BGP セッション構成と BGP セッションのステータスが含まれています。
  - L3 キャリアモードの場合、1 つのゾーンから L3 キャリアへのすべての IPv4 BGP セッションを表す zone-1-ipv4-peering-config という名前の MultiZoneNetworkPeeringConfig リソースは次のようになります。
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
spec: ...
status:
  borderLeafSwitches:
  - blswID: 1
    blswName: aa-aa-blsw01
    ipv4BGPSessions:
    - bgpSessionConfig:
        addressFamily: IPv4
        bfdConfig:
          bfdMode: PlainBFD
        localASN: 65501
        localIP: 192.168.208.0/31
        md5SecretRef:
          name: zone-1-blsw-1-port-6-ipv4-bgp-password
          namespace: gpc-system
        peerASN: 65502
        peerIP: 192.168.208.1
      bgpSessionStatus:
        prefixCounters:
          received: 11
          sent: 11
        sessionStatus: Up
        uptime: P6DT20H27M1S
      port:
        port: 6
```

2.1. ポートを構成する

ports 構成は、携帯通信会社のタイプによって異なります。ports を設定する際は、次のルールに従ってください。

キャリアタイプが L2 の場合は、Spec.Ports で n ポートを指定する必要があります。ここで、n はゾーン数に 2 を掛けた値です。最初のポートは、最初のネイバーゾーン（ゾーン ID で並べ替え）の最初のボーダーリーフスイッチ（スイッチ名で並べ替え）に接続する必要があります。2 番目のポートは、最初のネイバーゾーンの 2 番目のボーダーリーフスイッチに接続する必要があります。3 番目のポートは、2 番目のネイバーゾーンの最初のボーダーリーフスイッチに接続します。以降の接続もこのパターンに従います。図については、L2 携帯通信会社のデプロイをご覧ください。

重要: L2 運送業者のタイプの場合、ゾーンの数は 3 つを超えないことを強くおすすめします。
キャリアタイプが L3 の場合は、Spec.Ports で 2 つのポートを指定する必要があります。現在のゾーンの両方のボーダーリーフスイッチは、最初のポートを使用して最初のプロバイダエッジデバイスに個別に接続し、2 番目のポートを使用して 2 番目のプロバイダエッジデバイスに個別に接続する必要があります。詳細については、L3 携帯通信会社のデプロイをご覧ください。

2.2. マルチゾーン構成の例

このセクションでは、一般的なデプロイ例を示します。

2.2.1. L2 キャリアのデプロイ

このデプロイには次の構成があります。

ASN 65501、65502、65503 の 3 つのゾーン
L2 搬送波
このデプロイの論理接続を次の図に示します。

重要: この例は、3 つのゾーンの L2 キャリアのデプロイを示しています。L2 タイプのキャリアでは、ゾーンを 3 つ以下にすることを強くおすすめします。

MultiZoneNetworkConfig YAML ファイルの例を次に示します。

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkConfig
metadata:
  name: multizone-network-config
  namespace: gpc-system
spec:
  carrierType: L2
  zones:
    - zoneID: 1
      asn: 65501
    - zoneID: 2
      asn: 65502
    - zoneID: 3
      asn: 65503
  ports:
    - port: 10
    - port: 11
    - port: 12
    - port: 13

2.2.2. L3 携帯通信会社のデプロイ

このデプロイには次の構成があります。

ASN 65501、65502、65503 の 3 つのゾーン
L3 運送業者
このデプロイの論理接続を次の図に示します。

MultiZoneNetworkConfig YAML ファイルの例を次に示します。

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: MultiZoneNetworkConfig
  metadata:
    name: multizone-network-config
    namespace: gpc-system
  spec:
    carrierType: L3
    zones:
      - zoneID: 1
        asn: 65501
        carrierASN: 60010
      - zoneID: 2
        asn: 65502
        carrierASN: 60010
      - zoneID: 3
        asn: 65503
        carrierASN: 60010
    ports:
      - port: 10
      - port: 11

2.3. 省略可: マルチゾーン BFD 認証を構成する

双方向転送検出（BFD）は、すべてのマルチゾーン IPv4 セッションと EVPN セッションで構成されています。デフォルトでは、シングルホップのプレーン BFD が構成されています。このセクションの手順に沿って、認証を使用してマルチホップ BFD をデプロイします。

マルチゾーン EVPN BGP セッションで Bidirectional Forwarding Detection（BFD）認証を有効にします。BFD セッションを確立して有効にするには、両方のゾーンのペア設定された BGP セッションが、同じ BFD 認証鍵 ID と鍵文字列で構成されていることを確認します。

キータイプを定義します。このコマンドはブートストラッパーマシンで実行することをおすすめします。セキュリティ上の理由から、キーには少なくとも SHA-1 を使用してください。必要に応じて、構成に安全性の高いキーを使用します。
```
export KEY_TYPE=SHA1
```
キー ID とキー文字列を設定します。キー ID は、ゾーン間のペア設定された相互接続セッション間で一意である必要があります。未使用の鍵 ID を特定して、変数に割り当てます。
```
export KEY_ID=1
```

chronyc keygen を使用して SHA-1 認証キーを生成します。

CHRONY_OUTPUT=$(chronyc keygen ${KEY_ID:?} ${KEY_TYPE:?})

出力例:

echo $CHRONY_OUTPUT
1 SHA1 HEX:887F1B88085BD0BDE4458EA7C2C4393C50A498EF

認証キーを抽出して検証します。

export KEY_STR=$(echo ${CHRONY_OUTPUT:?} | awk '{ split($3,key,":"); print key[2]}')

echo $KEY_STR
887F1B88085BD0BDE4458EA7C2C4393C50A498EF

選択した相互接続セッションに BFD 認証情報をパッチ適用します。

kubectl --kubeconfig=KUBECONFIG_PATH patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-bfd-auth-key -n gpc-system -p='{
  "stringData": {
    "bfdKeyID": "'"${KEY_ID}"'",
    "bfdKeyValue": "'"${KEY_STR}"'"
  }
}'

BFD セッションが実行されていることを確認します。
```
switch# show bfd neighbors vrf default
```

State フィールドの値が Up で、Type フィールドが SH または MH であることを確認します。

OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                              Type     BSID
192.168.208.31  192.168.208.30  1090519041/1090519042 Up              5237(3)           Up          Eth1/11               default                          SH       N/A
192.168.208.91  192.168.208.90  1090519042/1090519042 Up              5624(3)           Up          Eth1/12               default                          SH       N/A
192.168.202.66  192.168.201.65  1090519071/1090519060 Up              629(3)            Up          Lo2                   default                          MH       N/A
192.168.202.66  192.168.201.66  1090519072/1090519061 Up              545(3)            Up          Lo2                   default                          MH       N/A

2.4. 省略可: マルチゾーン BGP パスワードを構成する

Border Gateway Protocol（BGP）パスワードには、IPv4 BGP セッションパスワードと EVPN BGP セッションパスワードの 2 種類があります。

デフォルトでは、すべての BGP パスワードは空です。このセクションの手順に沿って、パスワードを更新します。

2.4.1. IPv4 BGP パスワードを更新する

L2 キャリアを使用する場合は、現在のゾーンの 1 つのボーダーリーフスイッチと別のゾーンの別のボーダーリーフスイッチ間の IPv4 BGP セッションに適用される IPv4 BGP パスワードを更新します。

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}'

次のように置き換えます。

LOCAL_ZONE_ID: 現在のゾーンの数値 ID。
LOCAL_BLSW_ID: 現在のゾーンのボーダーリーフスイッチの数値 ID。この値は 1 または 2 にする必要があります。
REMOTE_ZONE_ID: リモートゾーンの数値 ID。
REMOTE_BLSW_ID: リモートゾーンのボーダーリーフスイッチの数値 ID。この値は 1 または 2 にする必要があります。
PASSWORD: ローカルボーダーリーフスイッチとリモートボーダーリーフスイッチ間の IPv4 BGP セッションに適用される BGP パスワード。

L3 キャリアを使用する場合は、現在のゾーンの 1 つのボーダーリーフスイッチと L3 キャリアのプロバイダエッジデバイス間の IPv4 BGP セッションに適用される IPv4 BGP パスワードを更新します。

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-port-PORT_ID-ipv4-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

次のように置き換えます。

LOCAL_ZONE_ID: 現在のゾーンの数値 ID。
LOCAL_BLSW_ID: 現在のゾーンのボーダーリーフスイッチの数値 ID。この値は 1 または 2 にする必要があります。
PORT_ID: プロバイダエッジデバイスに接続するイーサネットポートのインデックス。
PASSWORD: ローカルボーダーリーフスイッチとプロバイダエッジデバイス間の IPv4 BGP セッションに適用される BGP パスワード。

2.4.2. EVPN BGP パスワードを更新する

現在のゾーンのボーダーリーフスイッチと別のゾーンのボーダーリーフスイッチ間の EVPN BGP セッションに適用される EVPN BGP パスワードを更新するには、次のコマンドを実行します。

kubectl patch secret zone-LOCAL_ZONE_ID-blsw-LOCAL_BLSW_ID-zone-REMOTE_ZONE_ID-blsw-REMOTE_BLSWID-evpn-bgp-password -p='{"stringData":{"password":"PASSWORD"}}' -n gpc-system --kubeconfig=KUBECONFIG_PATH

次のように置き換えます。

LOCAL_ZONE_ID: 現在のゾーンの数値 ID。
LOCAL_BLSW_ID: 現在のゾーンのボーダーリーフスイッチの数値 ID。この値は 1 または 2 にする必要があります。
REMOTE_ZONE_ID: リモートゾーンの数値 ID。
REMOTE_BLSW_ID: リモートゾーンのボーダーリーフスイッチの数値 ID。この値は 1 または 2 にする必要があります。
PASSWORD: ローカルボーダーリーフスイッチとリモートボーダーリーフスイッチ間の evpn bgp セッションに適用される BGP パスワード。

3. 高度な構成のオプション

このセクションでは、マルチゾーンネットワーク API によって提供される高度な構成オプションについて説明します。

3.1. 携帯通信会社の BGP 構成のオーバーライドを設定する

デフォルトでは、ボーダーリーフスイッチはデフォルトの IP アドレス割り当てを使用して、キャリア PE デバイスとの BGP ピアリング接続を確立します。使用中の特定の BGP ピアリング IP アドレスは、MultiZoneNetworkPeeringConfig リソースの zone-<ZONE_ID>-ipv4-peering-config を調べることで確認できます。次に例を示します。

   apiVersion: system.private.gdc.goog/v1alpha1
   kind: MultiZoneNetworkPeeringConfig
   metadata:
     name: zone-1-ipv4-peering-config
     namespace: gpc-system
   spec: ...
   status:
     borderLeafSwitches:
     - blswID: 1
       blswName: aa-aa-blsw01
       ipv4BGPSessions:
       - bgpSessionConfig:
           addressFamily: IPv4
           bfdConfig:
             bfdMode: PlainBFD
           localASN: 65501
           localIP: 192.168.208.0/31
           md5SecretRef:
             name: zone-1-blsw-1-port-6-ipv4-bgp-password
             namespace: gpc-system
           peerASN: 65502
           peerIP: 192.168.208.1
   ...

カスタム IP アドレスプランを使用するには、次の手順に沿ってデフォルトの携帯通信会社の BGP 構成をオーバーライドします。

kubectl edit MultiZoneNetworkPeeringConfig zone-<ZONE_ID>-ipv4-peering-config -n gpc-system を実行し、spec.Peerings の下に carrierBGPConfigOverride セクションを追加します。例:

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-1-ipv4-peering-config
  namespace: gpc-system
  ...
spec:
  peeringConfigType: L3-IPv4
  peerings:
  - carrierBGPConfigOverride:
      peeringIP:
        localIP: 192.168.78.5/31
        peerIP: 192.168.78.4
    peerA:
      blswID: 1
      port:
        port: 11
      zoneID: 1
    ...

この例では、carrierBGPConfigOverride.peeringIP を指定すると、ピアリングサブネットが 192.168.78.4/31 にオーバーライドされます。

3.2. ポートのオーバーライドを構成する

Google は、すべてのゾーンのすべてのボーダーリーフスイッチで同じポートセットを使用することをおすすめします。このポート構成は、ポートに対してきめ細かい制御が必要なシナリオで役立ちます。

ローカルゾーンは、デプロイするゾーンです。

リモートゾーンは、同じマルチゾーンユニバース内の他のゾーンです。

デフォルトでは、1 つのゾーンの 2 つのボーダーリーフスイッチで同じポートを使用して、別のゾーンまたはキャリアに接続する必要があります。ただし、ポートのオーバーライドオプションを有効にして、ゾーン間のこの接続に使用する別のポートを指定できます。

ポートのオーバーライド機能を構成する手順は次のとおりです。

portOverride 機能を有効にします。

kubectl patch MultiZoneNetworkConfig multizone-network-config -n gpc-system --type='merge' -p '{"spec":{"enablePortOverride":true}}' --kubeconfig=KUBECONFIG_PATH

ローカルゾーンの境界リーフスイッチとリモートゾーンの境界リーフスイッチを特定し、ローカル境界リーフスイッチポートを変更します。

kubectl edit MultiZoneNetworkPeeringConfig zone-ZONE_1_ID-zone-ZONE_2_ID -n gpc-system --kubeconfig=KUBECONFIG_PATH

次のように置き換えます。

ZONE_1_ID: ローカルゾーン ID とリモートゾーン ID のうち、小さい方のゾーン ID。たとえば、ローカルゾーン ID が 1 で、リモートゾーン ID が 2 の場合は、ここに値 1 を指定します。
ZONE_2_ID: ローカルゾーン ID とリモートゾーン ID のうち、大きい方のゾーン ID。

MultiZoneNetworkPeeringConfig リソースは次のようになります。

apiVersion: system.private.gdc.goog/v1alpha1
kind: MultiZoneNetworkPeeringConfig
metadata:
  name: zone-2-zone-3-peering-config
  namespace: gpc-system
spec:
  peeringConfigType: L2
  peerings:
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 1
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-1-zone-3-blsw-1-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key
  - peerA:
      blswID: 1
      port:
        port: 12
      zoneID: 2
    peerB:
      blswID: 2
      port:
        port: 12
      zoneID: 3
    secrets:
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-ipv4-bgp-password
        namespace: gpc-system
      type: ipv4-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-evpn-bgp-password
        namespace: gpc-system
      type: evpn-bgp-password
    - secretRef:
        name: zone-2-blsw-2-zone-3-blsw-2-bfd-auth-key
        namespace: gpc-system
      type: bfd-auth-key

ゾーン間のピアリングを構成するボーダーリーフスイッチのいずれかのポート値を更新する必要があります。Spec.peerings フィールドで、ゾーンにまたがるピアリングを探します。この例では、ゾーン 2 とゾーン 3 の間に次のピア接続があります。

peerA:
  blswID: 1
  port:
    port: 12
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

出力には、blswID: 1 と blswID: 2 で識別される 2 つのボーダーリーフスイッチが表示されます。blswID: 1 で識別される最初のボーダーリーフスイッチのポートを、20 の新しい値に更新します。

peerA:
  blswID: 1
  port:
    port: 20
  zoneID: 2
peerB:
  blswID: 2
  port:
    port: 12
  zoneID: 3

この例では、最初のボーダーリーフスイッチのポート値を port: 20 に更新します。

マルチゾーン相互接続を構成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

1. 始める前に

2. マルチゾーン相互接続を構成する

2.1. ポートを構成する

2.2. マルチゾーン構成の例

2.2.1. L2 キャリアのデプロイ

2.2.2. L3 携帯通信会社のデプロイ

2.3. 省略可: マルチゾーン BFD 認証を構成する

2.4. 省略可: マルチゾーン BGP パスワードを構成する

2.4.1. IPv4 BGP パスワードを更新する

2.4.2. EVPN BGP パスワードを更新する

3. 高度な構成のオプション

3.1. 携帯通信会社の BGP 構成のオーバーライドを設定する

3.2. ポートのオーバーライドを構成する

マルチゾーン相互接続を構成する