ノード内の可視化の設定

Autopilot Standard

---

このガイドでは、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 間のすべてのトラフィックに適用されるファイアウォール ルールを作成する。
• Packet Mirroring を使用して、トラフィック（同じノード上にある 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 がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

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

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

gcloud

ノード内の可視化が有効になっている単一ノードクラスタを作成するには、--enable-intra-node-visibility フラグを使用します。

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

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

• CLUSTER_NAME: 新しいクラスタの名前。
• COMPUTE_REGION: クラスタの Compute Engine のリージョン。

Console

ノード内の可視化が有効になっている単一ノードクラスタを作成するには、次の手順を行います。

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [作成] をクリックします。

3. クラスタの名前を [名前] に入力します。

4. [クラスタの構成] ダイアログで、[GKE Standard] の横にある [構成] をクリックします。

5. 必要に応じてクラスタを構成します。

6. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

7. [ノード内の可視化の有効化] チェックボックスを選択します。

8. [作成] をクリックします。

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

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

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

gcloud

既存のクラスタでノード内の可視化を有効にするには、--enable-intra-node-visibility フラグを使用します。

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

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

Console

既存のクラスタでノード内の可視化を有効にするには、次の操作を行います。

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [ネットワーキング] で [ノード内の可視化の編集] をクリックします。

4. [ノード内の可視化の有効化] チェックボックスを選択します。

5. [変更を保存] をクリックします。

警告: ノード内の可視化を有効にすると、GKE はノードの再作成時に構成済みのメンテナンスの時間枠を使用します。つまり、次のメンテナンスの時間枠が発生するまで、クラスタでノード内の可視化は機能しません。この待機を回避するには、すでにコントロール プレーンが動作している GKE バージョンを --cluster-version フラグに設定して、ノードプールを手動でアップグレードします。この回避策を行う場合は、gcloud CLI を使用する必要があります。詳細については、メンテナンス時間枠の注意点をご覧ください。

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

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

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

gcloud

ノード内の可視化を無効にするには、--no-enable-intra-node-visibility フラグを使用します。

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

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

Console

ノード内の可視化を無効にするには、次の手順を行います。

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. クラスタのリストで、変更するクラスタの名前をクリックします。

3. [ネットワーキング] で [ノード内の可視化の編集] をクリックします。

4. [ノード内の可視化の有効化] チェックボックスをオフにします。

5. [変更を保存] をクリックします。

警告: ノード内の可視化を無効にすると、GKE はノードの再作成時に構成済みのメンテナンスの時間枠を使用します。つまり、次のメンテナンスの時間枠が発生するまで、ノード内の可視化は無効になりません。この待機を回避するには、すでにコントロール プレーンが動作している GKE バージョンを --cluster-version フラグに設定して、ノードプールを手動でアップグレードします。この回避策を行う場合は、gcloud CLI を使用する必要があります。詳細については、メンテナンス時間枠の注意点をご覧ください。

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

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

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

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: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

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 にリクエストを送信します。

   wget -qO- 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 ネイティブ クラスタのメリットを確認する。