このドキュメントでは、Anthos clusters 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 にトラフィックをルーティングします。
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
のダウンロードは、Anthos clusters 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 を使用している場合、次の
ncgctl
コマンドを使用して Network Connectivity Gateway を有効にできます。./bin/ncgctl --enable-ncg-on-existing-cluster
ncgctl
コマンドは、有効化フラグの短縮バージョンとして-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 のトラブルシューティングをご覧ください。