ノード内の可視化の設定

このガイドでは、Google Kubernetes Engine（GKE）クラスタにノード内の可視化を設定する方法について説明します。

ノード内の可視化では、クラスタ内の各ノードでネットワーキングを構成して、Pod が同じノードにある場合でも、ある Pod から別の Pod に送信されたトラフィックが、クラスタの Virtual Private Cloud（VPC）ネットワークによって処理されるようにします。

ノード内の可視化は、Standard クラスタではデフォルトで無効になっており、Autopilot クラスタではデフォルトで有効になっています。

アーキテクチャ

ノード内の可視化により、Pod 間で送信されたパケットは常に VPC ネットワークによって処理されます。これによって、ファイアウォール ルール、ルート、フローログ、パケット ミラーリング構成がパケットに適用されます。

Pod から同じノードの別の Pod にパケットを送信すると、パケットはノードを離れて Google Cloud ネットワークで処理されます。その後、パケットはすぐに同じノードに戻され、宛先 Pod に転送されます。

ノード内の可視化によって、netd DaemonSet がデプロイされます。

利点

ノード内の可視化には、次の利点があります。

• 同じノード上の Pod 間のトラフィックなど、Pod 間のすべてのトラフィックのフローログを確認する。
• 同じノードの Pod 間トラフィックも含め、Pod 間のすべてのトラフィックに適用されるファイアウォール ルールを作成する。
• パケット ミラーリングを使用して、同じノード上にある Pod 間のトラフィックを含めて、トラフィックのクローンを作成し、検査用として転送します。

要件と制限事項

ノード内の可視化には次の要件と制限があります。

• クラスタには GKE バージョン 1.15 以降が必要です。
• ノード内の可視化は、Windows Server ノードプールではサポートされていません。
• ノード内の可視化を有効にして、nonMasqueradeCIDRs パラメータで構成された ip-masq-agent を使用する場合は、ノード内の接続で問題が発生しないように、nonMasqueradeCIDRs に Pod CIDR 範囲を含める必要があります。

ファイアウォール ルール

ノード内の可視化を有効にすると、VPC ネットワークは、Pod（同じノード上の Pod 間で送信されたパケットを含む）間で送信されたすべてのパケットを処理します。つまり、Pod のロケーションに関係なく、VPC ファイアウォール ルールと階層型ファイアウォール ポリシーは Pod 間の通信に一貫して適用されます。

クラスタ内の通信にカスタム ファイアウォール ルールを構成する場合は、クラスタのネットワーク要件を慎重に確認して、下り（外向き）と上り（内向き）許可ルールのセットを決める必要があります。接続テストを使用して、正当なトラフィックに支障がないことを確認します。たとえば、ネットワーク ポリシーが機能するには Pod 間の通信が必要です。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

新しいクラスタでノード内の可視化を有効にする

ノード内の可視化が有効になっているクラスタを作成するには、gcloud CLI または Google Cloud コンソールを使用します。

gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --enable-intra-node-visibility

既存のクラスタでノード内の可視化を有効にする

既存のクラスタでノード内の可視化を有効にするには、gcloud CLI または Google Cloud コンソールを使用します。

既存のクラスタに対してノード内の可視化を有効にすると、GKE でコントロール プレーンとワーカーノードの両方のコンポーネントが再起動されます。

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、ノードのアップグレード戦略を使用してノードを再作成し、メンテナンス ポリシーに準拠する手動変更の表で対応する行を確認してください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

ノード内の可視化を無効にする

クラスタのノード内の可視化を無効にするには、gcloud CLI または Google Cloud コンソールを使用します。

既存のクラスタに対してノード内の可視化を無効にすると、GKE でコントロール プレーンとワーカーノードの両方のコンポーネントが再起動されます。

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

この変更を行うにはノードを再作成する必要があります。これにより、実行中のワークロードが中断する可能性があります。この特定の変更について詳しくは、ノードのアップグレード戦略を使用してノードを再作成し、メンテナンス ポリシーに準拠する手動変更の表で対応する行を確認してください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

演習: ノード内の可視化を確認する

この演習では、ノード内の可視化を有効にして、それがクラスタで機能していることを確認するために必要な手順を示します。

この演習では、次の手順を行います。

1. us-central1 リージョンのデフォルト サブネットのフローログを有効にします。
2. us-central1-a ゾーンで、ノード内の可視化を有効にして単一ノードクラスタを作成します。
3. クラスタに Pod を 2 つ作成します。
4. ある Pod から別の Pod に HTTP リクエストを送信します。
5. Pod から Pod へのリクエストのフロー ログエントリを表示します。

フローログを有効にする

1. デフォルト サブネットのフローログを有効にします。

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. デフォルト サブネットでフローログが有効になっていることを確認します。

   gcloud compute networks subnets describe default \
       --region=us-central1
   

   フローログが有効になったことは、次のような出力からわかります。

   ...
   enableFlowLogs: true
   ...
   

クラスタの作成

1. ノード内の可視化を有効にして単一ノードクラスタを作成します。

   gcloud container clusters create flow-log-test \
       --zone=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

2. クラスタの認証情報を取得します。

   gcloud container clusters get-credentials flow-log-test \
       --zone=us-central1-a
   

2 つの Pod を作成する

1. Pod を作成します。

   次のマニフェストを pod-1.yaml という名前のファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

2. マニフェストをクラスタに適用します。

   kubectl apply -f pod-1.yaml
   

3. 2 つ目の Pod を作成します。

   次のマニフェストを pod-2.yaml という名前のファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

4. マニフェストをクラスタに適用します。

   kubectl apply -f pod-2.yaml
   

5. Pod を確認します。

   kubectl get pod pod-1 pod-2 --output wide
   

   出力で、Pod の IP アドレスが次のように表示されます。

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   pod-1 と pod-2 の IP アドレスをメモします。

リクエストを送信する

1. pod-1 のコンテナへのシェルを取得します。

   kubectl exec -it pod-1 -- sh
   

2. シェルで、pod-2 にリクエストを送信します。

   curl -s POD_2_IP_ADDRESS:8080
   

   POD_2_IP_ADDRESS は、pod-2 の IP アドレスに置き換えます。

   出力には pod-2 内で実行中のコンテナからのレスポンスが表示されます。

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. 「exit」を入力してシェルを終了し、メインのコマンドライン環境に戻ります。

フローログ エントリを表示する

フローログ エントリを表示するには、次のコマンドを使用します。

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

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

• PROJECT_ID: プロジェクト ID。
• POD_1_IP_ADDRESS: pod-1 の IP アドレスです。
• POD_2_IP_ADDRESS: pod-2 の IP アドレスです。

出力は、pod-1 から pod-2 へのリクエストのフローログ エントリを示しています。この例では、pod-1 の IP アドレスは 10.56.0.13、pod-2 の IP アドレスは 10.56.0.14 です。

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

クリーンアップ

アカウントに不要な料金が発生しないように、作成したリソースを削除するには、次の手順を行います。

1. クラスタを削除します。

   gcloud container clusters delete -q flow-log-test
   

2. デフォルト サブネットのフローログを無効にします。

   gcloud compute networks subnets update default --no-enable-flow-logs
   

次のステップ

• クラスタ ネットワーク ポリシーを作成して、クラスタの Pod と Service 間の通信を制御する方法を学ぶ。
• VPC ネイティブ クラスタのメリットを確認する。