ノード内の可視化の設定

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

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

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

Google Kubernetes Engine に移動
[作成] をクリックします。
クラスタの名前を [名前] に入力します。
[クラスタの構成] ダイアログで、[GKE Standard] の横にある [構成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーションパネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[ノード内の可視化の有効化] チェックボックスを選択します。
[作成] をクリックします。

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

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

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

gcloud

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

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

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

Console

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

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

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] で [ノード内の可視化の編集] をクリックします。
[ノード内の可視化の有効化] チェックボックスを選択します。
[変更を保存] をクリックします。

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

クラスタのノード内の可視化を無効にするには、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

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

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

Google Kubernetes Engine に移動
クラスタのリストで、変更するクラスタの名前をクリックします。
[ネットワーキング] で [ノード内の可視化の編集] をクリックします。
[ノード内の可視化の有効化] チェックボックスをオフにします。
[変更を保存] をクリックします。

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

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

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

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

フローログを有効にする

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

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

デフォルトサブネットでフローログが有効になっていることを確認します。
```
gcloud compute networks subnets describe default \
    --region=us-central1
```
フローログが有効になったかどうかは、次のような出力で確認できます。
```
...
enableFlowLogs: true
...
```

クラスタを作成する

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

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

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

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

2 つの Pod を作成する

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

マニフェストをクラスタに適用します。
```
kubectl apply -f pod-1.yaml
```

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

マニフェストをクラスタに適用します。
```
kubectl apply -f pod-2.yaml
```

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 アドレスをメモします。

リクエストを送信する

pod-1 のコンテナへのシェルを取得します。
```
kubectl exec -it pod-1 -- sh
```
シェルで、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
```
「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
...

クリーンアップ

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

クラスタを削除します。

gcloud container clusters delete -q flow-log-test

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

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

次のステップ

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

ノード内の可視化の設定

アーキテクチャ

利点

要件と制限事項

ファイアウォール ルール

始める前に

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

gcloud

Console

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

gcloud

Console

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

gcloud

Console

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

フローログを有効にする

クラスタを作成する

2 つの Pod を作成する

リクエストを送信する

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

クリーンアップ

次のステップ

ファイアウォールルール

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