Network Connectivity Gateway を構成する

このドキュメントでは、GKE on Bare Metal のクラスタに Network Connectivity Gateway を構成する方法について説明します。

Virtual Private Cloud（VPC）で実行されているワークロードと通信する必要があるクラスタで Pod が実行されることがあります。この通信は安全である必要があります。また、プロキシサーバーを使用せずにフラットなネットワーク上でこの通信を行う必要がある場合もあります。Network Connectivity Gateway により、このような通信が可能になります。

Network Connectivity Gateway は、クラスタの Pod として実行されます。次の図に示すように、このソリューションでは、クラスタ内の Pod から VPC の VM へのトラフィックに IPsec トンネルが提供されています。ゲートウェイ Pod は、Border Gateway Protocol（BGP）セッションで VPC サブネットの接頭辞を受信すると、Dataplane V2 を使用して転送を設定します。他の Pod がその接頭辞を持つアドレスにトラフィックを送信すると、トラフィックはゲートウェイ Pod に転送されます。次に、ゲートウェイ Pod はそのトラフィックを IPsec トンネル経由で Google Cloud に転送します。

GKE on Bare Metal の Network Connectivity Gateway の図

Network Connectivity Gateway は、次の機能をサポートしていません。

HA VPN（および BGP）の IPv6
BGP の MD5
BGP の Bidirectional Forwarding Detection（BFD）

Google Cloud リソースを作成する

クラスタで Network Connectivity Gateway を有効にする前に、次の Google Cloud リソースが必要です。

Cloud Router
HA VPN ゲートウェイ
ピア VPN ゲートウェイ: 1 つのインターフェース
2 つの VPN トンネル
2 つの BGP セッション: VPN トンネルごとに 1 つずつ

これらのリソースを作成して構成する方法については、ピア VPN ゲートウェイへの HA VPN ゲートウェイの作成をご覧ください。

これらのリソースを作成する際は、次の情報を収集して後で使用できるようにしておきます。

Google Cloud が HA VPN ゲートウェイに割り振った 2 つの外部 IP アドレス。
組織を離れる IPsec / VPN トラフィックのパブリック IP アドレス。このアドレスは、ネットワークアドレス変換（NAT）の結果である可能性があります。
事前共有キー。
BGP セッションで Cloud Router に割り当てた自律システム番号（ASN）。
BGP セッションにオンプレミスクラスタで使用するように選択した ASN。
BGP セッションごとに、Cloud Router で使用される 169.254.1.1 などのリンクローカルアドレスと、オンプレミスクラスタで使用されるリンクローカルアドレス。

BGP セッション構成の詳細を確認する方法については、BGP セッション構成を表示するをご覧ください。

クラスタ要件

Network Connectivity Gateway のコマンドラインツール ncgctl-v1.12.0-linux-amd64.tar.gz のダウンロードは、GKE on Bare Metal のバージョン 1.12 とのみ互換性があります。新しいバージョン 1.12.0 クラスタを作成する場合は、クラスタ構成ファイルでアノテーションを使用して Network Connectivity Gateway を有効にします。

クラスタの作成時に Network Connectivity Gateway を有効にするには:

クラスタ構成ファイルで、baremetal.cluster.gke.io/enable-gng: "true" アノテーションを追加します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-gng: "true"
  name: my-cluster
  namespace: cluster-my-cluster
spec:
...
  anthosBareMetalVersion: 1.12.0
  ...

bmctl create を使用してクラスタを作成します。
```
bmctl create cluster -c CLUSTER_NAME
```
CLUSTER_NAME は、クラスタ構成ファイルの作成時に指定した名前に置き換えます。クラスタの作成の詳細については、クラスタの作成の概要をご覧ください。

ダウンロード

Network Connectivity Gateway のコマンドラインツールである ncgctl をダウンロードする手順は次のとおりです。

Network Connectivity Gateway のコンポーネントとカスタムリソース定義をダウンロードします。
```
gsutil cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
```

アーカイブを解凍します。

tar -xvzf ncgctl-v1.12.0-linux-amd64.tar.gz

インストール

ncgctl をインストールする方法は次のとおりです。

プリフライトチェックを実行して、クラスタが前提条件を満たしていることを確認します。たとえば、Dataplane V2 が有効になっていることを確認します。
```
./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
```
CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。
Network Connectivity Gateway をインストールします。
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
注: 新しいバージョン 1.12.0 クラスタを作成する場合は、次の手順をスキップできます。クラスタを作成するときに、クラスタ構成ファイルに baremetal.cluster.gke.io/enable-gng: "true" アノテーションを追加して、ネットワーク接続ゲートウェイを有効にすることをおすすめします}。詳しくは、クラスタの要件をご覧ください。
既存のバージョン 1.12.0 を使用している場合、次の ncgctl コマンドを使用して Network Connectivity Gateway を有効にできます。
```
./bin/ncgctl --enable-ncg-on-existing-cluster
```
ncgctl コマンドでは、enable フラグの短縮版として -e を認めます。
その他のショートカットやコマンドのヘルプを表示するには、次のコマンドを使用します。
```
./bin/ncgctl --help
```

事前共有キーの Secret を作成する

IPsec トンネルの一方の端のゲートウェイでは、認証に事前共有キーを含む Secret が使用されます。

Secret の作成手順は次のとおりです。

以下の Secret マニフェストの詳細を含む psk-secret.yaml という名前のファイルを作成します。
```
apiVersion: v1
kind: Secret
metadata:
  name: "ike-key"
  namespace: "kube-system"
data:
  psk: PRE_SHARED_KEY
```
PRE_SHARED_KEY は、base64 でエンコードされた事前共有キーに置き換えます。平文の鍵がある場合は、この Secret を作成する前に、鍵を Base64 形式にエンコードします。たとえば、Google Cloud コンソールで生成した鍵は平文であるため、エンコードする必要があります。鍵を Base64 でエンコードするには次のようにします。
```
echo -n PLAINTEXT_KEY | base64
```

Secret を作成します。

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f psk-secret.yaml

2 つの `OverlayVPNTunnel` カスタムリソースを作成する

2 つの IPsec セッションを開始するには、2 つの OverlayVPNTunnel カスタムリソースを作成します。

次の OverlayVPNTunnel マニフェストの詳細を含む overlay-vpn-tunnels.yaml という名前のファイルを作成します。
```
apiVersion: networking.gke.io/v1alpha1
kind: OverlayVPNTunnel
metadata:
  namespace: "kube-system"
  name: TUNNEL_1_NAME
spec:
  ikeKey:
    name: "ike-key"
    namespace: "kube-system"
  peer:
    publicIP: PEER_PUBLIC_IP_1
  self:
    publicIP: SELF_PUBLIC_IP
  localTunnelIP: SELF_LOCAL_TUNNEL_IP_1
---
apiVersion: networking.gke.io/v1alpha1
kind: OverlayVPNTunnel
metadata:
  namespace: "kube-system"
  name: TUNNEL_2_NAME
spec:
  ikeKey:
    name: "ike-key"
    namespace: "kube-system"
  peer:
    publicIP: PEER_PUBLIC_IP_2
  self:
    publicIP: SELF_PUBLIC_IP
  localTunnelIP: SELF_LOCAL_TUNNEL_IP_2
```
次のように置き換えます。
- TUNNEL_NAME_1: 最初の OverlayVPNTunnel に付ける名前。
- TUNNEL_NAME_2: 2 番目の OverlayVPNTunnel に付ける名前。
- PEER_PUBLIC_IP_1: VPN ゲートウェイの 1 つのインターフェースのパブリック IP アドレス。このインターフェースは、最初の VPN トンネルの作成時に指定したものです。
- PEER_PUBLIC_IP_2: HA VPN ゲートウェイのもう一方のインターフェースのパブリック IP アドレス。このインターフェースは、2 番目の VPN トンネルの作成時に指定したものです。
- SELF_LOCAL_TUNNEL_IP_1: 最初のトンネルを介した BGP セッションのクラスタで使用するリンクローカルアドレス。
- SELF_LOCAL_TUNNEL_IP_2: 2 番目のトンネルを介した BGP セッションのクラスタで使用するリンクローカルアドレス。
- SELF_PUBLIC_IP: 組織を離れる IPsec / VPN トラフィックのパブリック IP アドレス。このアドレスは、ネットワークアドレス変換（NAT）の結果である可能性があります。

2 つの OverlayVPNTunnels を作成します。

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml

トンネルのステータスを確認します。

kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \
    --namespace kube-system --output yaml

2 つの `OverlayBGPPeer` カスタムリソースを作成する

各トンネルで BGP セッションを開始するには、2 つの OverlayBGPPeer カスタムリソースを作成します。

次の OverlayBGPPeer マニフェストの詳細を含む overlay-bgp-peers.yaml という名前のファイルを作成します。
```
apiVersion: networking.gke.io/v1alpha1
kind: OverlayBGPPeer
metadata:
  namespace: "kube-system"
  name: BGP_PEER_1_NAME
spec:
  localASN: LOCAL_ASN
  localIP: LOCAL_IP
  peerIP: PEER_IP_1
  peerASN: PEER_ASN
  vpnTunnel: TUNNEL_1_NAME
---
apiVersion: networking.gke.io/v1alpha1
kind: OverlayBGPPeer
metadata:
  namespace: "kube-system"
  name: BGP_PEER_2_NAME
spec:
  localASN: LOCAL_ASN
  localIP: LOCAL_IP
  peerIP: PEER_IP_2
  peerASN: PEER_ASN
  vpnTunnel: TUNNEL_2_NAME
```
次のように置き換えます。
- BGP_PEER_1_NAME: 最初の OverlayBGPPeer に付ける名前。
- BGP_PEER_2_NAME: 2 番目の OverlayBGPPeer に付ける名前。
- LOCAL_ASN: BGP セッションのクラスタで使用される ASN。
- LOCAL_IP: 組織を離れる IPsec / VPN トラフィックのパブリック IP アドレス。このアドレスは、ネットワークアドレス変換（NAT）の結果である可能性があります。
- PEER_IP_1: VPN ゲートウェイの 1 つのインターフェースのパブリック IP アドレス。このインターフェースは、最初の VPN トンネルの作成時に指定したものです。
- PEER_IP_2: HA VPN ゲートウェイのもう一方のインターフェースのパブリック IP アドレス。このインターフェースは、2 番目の VPN トンネルの作成時に指定したものです。
- PEER_ASN: BGP セッションでルーターに割り当てられた ASN。
- TUNNEL_1_NAME: 前に作成した最初の OverlayVPNTunnel の名前。
- TUNNEL_2_NAME: 前に作成した 2 番目の OverlayVPNTunnel の名前。

OverlayBGPPeer カスタムリソースを作成します。

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yaml

BGP セッションのステータスを確認します。

kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayBGPPeer --namespace kube-system \
    --output yaml

Network Connectivity Gateway のステータスを確認する

インストールによって NetworkConnectivityGateway カスタムリソースが作成されました。

NetworkConnectivityGateway カスタムリソースを表示します。

kubectl --kubeconfig CLUSTER_KUBECONFIG get NetworkConnectivityGateway --namespace kube-system \
    --output yaml

出力は次のようになります。Status: Healthy が表示されていることを確認します。

apiVersion: networking.gke.io/v1alpha1
kind: NetworkConnectivityGateway
metadata:
  namespace: kube-system
  name: default
spec:
status:
    CurrNode: worker1-node
    CreatedTime: 2021-09-07T03:18:15Z
    LastReportTime: 2021-09-21T23:57:54Z
    Status:  Healthy

Network Connectivity Gateway のログを確認する

ゲートウェイ Pod は ncgd という名前の DaemonSet に属しているため、Pod 名は ncgd で始まります。

Network Connectivity Gateway のログを表示する手順は次のとおりです。

ゲートウェイ Pod の名前を確認します。

kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd

ゲートウェイ Pod のログを表示します。
```
kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD --namespace kube-system \
    --output yaml
```
GATEWAY_POD は、ゲートウェイの名前に置き換えます。

アンインストール

クラスタから Network Connectivity Gateway をアンインストールするには:

./bin/ncgctl –-uninstall --kubeconfig CLUSTER_KUBECONFIG

トラブルシューティング

Network Connectivity Gateway に関連するトラブルシューティングのヒントについては、Network Connectivity Gateway のトラブルシューティングをご覧ください。