コンテナーネットワークログを設定する

このガイドでは、Azure Kubernetes Service (AKS)の Advanced Container Networking Services でコンテナーネットワークログを構成する手順について説明します。保存 されたログ は、永続的なストレージを使用した継続的な収集用に設定することも、リアルタイムのトラブルシューティングのために オンデマンドログ を設定することもできます。

コンテナーネットワークログキャプチャの概要と各モードを使用するタイミングについては、「コンテナーネットワークログとは」を参照してください。

Important

コンテナーネットワークログは ACNS 自体によって生成されるため、ログの生成にはAzure Monitorに対するハード依存関係はありません。 ACNS が有効になり、 ContainerNetworkLog CRD を適用すると、フローログが /var/log/acns/hubble/events.logの各ノードに書き込まれます。

完全な実稼働グレードの監視エクスペリエンスを実現するには、Azure Monitor アドオンを有効にすることをお勧めします。ホストローカルログをLog Analyticsワークスペースに収集し、長期間のデータ保持を可能にします。そして、KQL、Azureポータルの組み込みダッシュボード、および管理されたGrafanaダッシュボードを活用可能にします。

Azure Monitorを有効にしない場合でも、ホストローカルログを直接使用することも、OpenTelemetry 互換のコレクターまたはログサービスに転送することもできます。

[前提条件]

アクティブなサブスクリプションを持つAzure アカウント。アカウントをお持ちでない場合は、開始する前に無料アカウントを作成してください。

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Get started with Azure Cloud Shell」を参照してください。
CLI 参照コマンドをローカルで実行する場合は、Azure CLIinstallします。 Windowsまたは macOS で実行している場合は、Docker コンテナーでAzure CLIを実行することを検討してください。詳細については、「 Docker コンテナーでAzure CLIを実行する方法を参照してください。
- ローカルインストールを使用している場合は、az login コマンドを使用してAzure CLIにサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、「Azure CLI を使用して Azure に認証する」を参照してください。
- メッセージが表示されたら、最初に使用するときにAzure CLI拡張機能をインストールします。拡張機能の詳細については、「Azure CLIを参照してください。
- az version を実行して、インストールされているバージョンと依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

Azure CLI バージョン 2.85.0 以降。 az --version を実行して確認します。インストールまたはアップグレードするには、「Install Azure CLIを参照してください。

aks-preview Azure CLI 拡張機能バージョン 20.0.0b4 以降:

# Install the aks-preview extension
az extension add --name aks-preview
# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

保存されたログモードには Cilium データプレーンが必要です。
オンデマンドログモードは、Cilium データプレーンと非 Cilium データプレーンの両方で動作します。
クラスターで Kubernetes バージョン 1.33 以降が実行されている必要があります。
レイヤー 7 のフローデータは、レイヤー 7 ポリシーのサポートが有効になっている場合にのみキャプチャされます。詳細については、「レイヤ 7 ポリシーを設定する」を参照してください。
DNS フローとメトリックは、Cilium FQDN ネットワークポリシーが適用されている場合にのみキャプチャされます。詳細については、「 FQDN ポリシーの構成」を参照してください。

保存されたログモードを構成する

保存されたログモードを使用すると、ACNS は各ノードのネットワークフローログを継続的にキャプチャできます。ログのフローを開始するには、次の 2 つのことが必要です。

クラスターで ACNS を有効にする必要があります。 これにより、フローをキャプチャする Cilium エージェントコンポーネントがプロビジョニングされます。
少なくとも 1 つの ContainerNetworkLog CRD を適用する必要があります。 これにより、キャプチャされるトラフィックが定義されます。 CRD がないと、ログは生成されません。

両方を配置すると、フローログが各ノードの /var/log/acns/hubble/events.log に書き込まれます。同様のフローは、フローログの集計を通じて集計されたレコードに自動的にグループ化されます。これにより、必要なパターンを維持しながらデータ量が削減されます。

Azure Monitor アドオンの有効化は、Log Analytics ワークスペースにログを発送する別の省略可能な手順です。ログの生成には影響しません。

これは、新しいクラスターで設定することも、既存のクラスターで有効にすることもできます。

格納されたログの流れを最初から最後まで示す方法

                    ┌─────────────────────────────────────────────┐
                    │                AKS node                     │
                    │                                             │
   Pod traffic ───▶ │  Cilium agent (ACNS)                        │
                    │       │                                     │
                    │       ▼                                     │
                    │  ContainerNetworkLog CRD ── filters flows   │
                    │       │                                     │
                    │       ▼                                     │
                    │  /var/log/acns/hubble/events.log            │
                    │  (50 MB rotating, host-local)               │
                    └───────┬─────────────────────────────────────┘
                            │
              ┌─────────────┴──────────────┐
              ▼                            ▼
   Azure Monitor add-on        OpenTelemetry collector
   (optional)                  or logging service (optional)
              │                            │
              ▼                            ▼
   ContainerNetworkLogs        Your SIEM / observability
   table in Log Analytics      backend
              │
              ▼
   Azure portal / Grafana
   dashboards, KQL

展開オプション

以下のエンドツーエンドのセットアップに従います。同じ 3 つの手順は、新規クラスターと既存のクラスターの両方で機能します。

エンドツーエンドのセットアップ

次の手順を順番に実行します。手順 1 と 2 が必要です。手順 3 は省略可能であり、ログをAzure Monitorに転送する場合にのみ必要です。

Step	あなたの活動内容	必須ですか？
1	クラスターで ACNS が有効になっていることを確認します (新規または既存)	イエス
2	`ContainerNetworkLog` CRD を適用してログ収集を開始する	イエス
3	永続的ストレージのAzure Monitorにログを転送する	Optional

環境変数を 1 回設定し、全体で再利用します。

# Replace placeholders with your own values
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"
export LOCATION="<location>"

手順 1: クラスターで ACNS が有効になっていることを確認する

状況に合ったオプションを使用します。

オプション A: ACNS を使用して新しいクラスターを作成する

# Create the resource group if it doesn't already exist
az group create --name $RESOURCE_GROUP --location $LOCATION

# Create an AKS cluster with ACNS
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --acns-advanced-networkpolicies L7

ヒント

既定の VM サイズがサブスクリプションで使用できない場合は、 --node-vm-size Standard_D4ads_v5追加します。

ログをAzure Monitorに転送することが既にわかっている場合は、1 つのコマンドですべてを実行できます。「ショートカット：最初からログアナリティクスでクラスターを作成する」を参照してください。

kubectlコマンドを実行できるように、クラスターの資格情報を取得します。

az aks get-credentials --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

オプション B: 既存のクラスターを使用する

クラスターで既に ACNS が有効になっている場合は、手順 2 に進むことができます。それ以外の場合は、 kubectl コマンドを実行できるように資格情報を取得します。

az aks get-credentials --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

手順 2: ContainerNetworkLog CRD を適用してログ収集を開始する

保存されたログモードでは、カスタムリソース ContainerNetworkLog 少なくとも 1 つを適用するまで、何も収集されません。このリソースは、キャプチャするトラフィックを、名前空間、ポッド、サービス、プロトコル、または判定ごとに指定します。

CRD が適用されると、一致するフローが各ノードの /var/log/acns/hubble/events.log に書き込まれます。

kubectl apply -f <crd.yaml>

使用可能なすべてのフィールドについては、以下の完全な ContainerNetworkLog CRD テンプレートを参照してください。

ヒント

実際の例については、 AKS Labs ドキュメントのサンプル CRD を参照してください。

注

ホストノードのログは一時的なものです。ファイルは 50 MB で自動的にローテーションされ、古いエントリは上書きされます。永続ストレージの場合は、手順 3. を完了します。また、Azure Monitorの代わりに、または一緒に、OpenTelemetry と互換性のあるコレクターまたはログサービスを使用して、SIEM または監視バックエンドにログを転送することもできます。

この時点で、すべてのノードには JSON 形式の /var/log/acns/hubble/events.log フローレコードがあります。必要なものがそれだけなら、これで完了です。

手順 3 (省略可能): 永続的ストレージのログをAzure Monitorに転送する

長期的なリテンション期間、KQL クエリ、組み込みのAzure ポータルと Grafana ダッシュボードのためにログを Log Analytics ワークスペースに転送する場合は、この手順を完了します。ホストローカルログを直接使用する場合や、独自の OpenTelemetry コレクターまたはログサービスを介して転送する場合はスキップします。

3a。 Azure Monitor アドオン (Log Analytics) を有効にします。

# To use the default Log Analytics workspace
az aks enable-addons -a monitoring -g $RESOURCE_GROUP -n $CLUSTER_NAME

# To use an existing Log Analytics workspace
az aks enable-addons -a monitoring -g $RESOURCE_GROUP -n $CLUSTER_NAME --workspace-resource-id <workspace-resource-id>

3b。コンテナーネットワークログフラグを有効にします。

az aks update --enable-acns \
  --enable-container-network-logs \
  -g $RESOURCE_GROUP \
  -n $CLUSTER_NAME

特定のAzure Monitor ワークスペースにログを送信するには、--azure-monitor-workspace-resource-id フラグを追加します。

az aks update --enable-acns \
  --enable-container-network-logs \
  --azure-monitor-workspace-resource-id $AZURE_MONITOR_ID \
  -g $RESOURCE_GROUP \
  -n $CLUSTER_NAME

注

ContainerNetworkLog CRD が適用されると、フローログがホストに書き込まれます。後でLog Analytics統合を有効にすると、Azure Monitor エージェントはその時点から収集を開始します。 2 分より前のログは取り込まれません。

ショートカット: 最初からLog Analyticsを使用してクラスターを作成する

新しいクラスターを作成していて、Log Analytics ワークスペースにログを送信することが既にわかっている場合は、手順 1 と手順 3 を 1 つの作成コマンドに組み合わせることができます。

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --enable-addons monitoring \
  --enable-container-network-logs \
  --acns-advanced-networkpolicies L7

特定のワークスペースにログを送信するには、 --azure-monitor-workspace-resource-id フラグを追加します。

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --enable-addons monitoring \
  --enable-container-network-logs \
  --azure-monitor-workspace-resource-id $AZURE_MONITOR_ID \
  --acns-advanced-networkpolicies L7

キャプチャするトラフィックを定義するには、手順 2 ( ContainerNetworkLog CRD の適用) を完了する必要があります。 Log Analytics統合は既に行われているため、一致したフローが収集され、ワークスペースに自動的に送信されます。

ContainerNetworkLog CRD テンプレート

ContainerNetworkLogカスタムリソースは、キャプチャするネットワークフローを定義します。 1 つのクラスターに複数のカスタムリソースを作成でき、それぞれが異なる名前空間、ポッド、またはプロトコルを対象にすることができます。

apiVersion: acn.azure.com/v1alpha1
kind: ContainerNetworkLog
metadata:
  name: sample-containernetworklog # Cluster scoped
spec:
  includefilters: # At least one filter is required
    - name: sample-filter
      from:
        namespacedPod: # Format: namespace/pod
          - sample-namespace/sample-pod
        labelSelector:
          matchLabels:
            app: frontend
            k8s.io/namespace: sample-namespace
          matchExpressions:
            - key: environment
              operator: In
              values:
                - production
                - staging
        ip: # Single IP or CIDR
          - "192.168.1.10"
          - "10.0.0.1"
      to:
        namespacedPod:
          - sample-namespace2/sample-pod2
        labelSelector:
          matchLabels:
            app: backend
            k8s.io/namespace: sample-namespace2
          matchExpressions:
            - key: tier
              operator: NotIn
              values:
                - dev
        ip:
          - "192.168.1.20"
          - "10.0.1.1"
      protocol: # tcp, udp, dns
        - tcp
        - udp
        - dns
      verdict: # forwarded, dropped
        - forwarded
        - dropped

上記のテンプレートを使用して YAML ファイルを作成し、必要に応じてフィルターをカスタマイズし、 kubectl apply -f <crd.yaml>で適用するだけです。

CRD フィールドリファレンス

フィールド	タイプ	説明	必須
`includefilters`	[]フィルター	キャプチャするネットワークフローを定義するフィルター。少なくとも 1 つのフィルターを含む必要があります。	イエス
`filters.name`	糸	フィルターの名前。	No
`filters.protocol`	[]string	照合するプロトコル: `tcp`、 `udp`、 `dns`。省略すると、すべてのプロトコルが含まれます。	No
`filters.verdict`	[]string	一致するフロー判定: `forwarded`、`dropped`。省略すると、すべての判定が含まれます。	No
`filters.from`	エンドポイント	ネットワークフローのソース。 IP、ラベルセレクター、名前空間とポッドのペアを含めることができます。	No
`filters.to`	エンドポイント	ネットワークフローの宛先。 `from`と同じオプション。	No
`Endpoint.ip`	[]string	単一の IP アドレスまたは CIDR 範囲。	No
`Endpoint.labelSelector`	オブジェクト	`matchLabels`と`matchExpressions`を含む Standard Kubernetes ラベルセレクター。条件は AND と組み合わされます。空の場合は、すべてのリソースと一致します。	No
`Endpoint.namespacedPod`	[]string	`namespace/pod` 形式の名前空間とポッドのペア。	No

レイヤー 7 と DNS フローをキャプチャする

ContainerNetworkLog CRD は、includeFiltersで選択したトラフィックのレイヤー 3 とレイヤー 4 のフローをキャプチャします。レイヤー 7 (HTTP、gRPC、Kafka) と DNS レコードは、一致するトラフィックが、L7 検査または DNS 可視性を選択する Cilium ネットワークポリシーによってもカバーされている場合にのみ表示されます。このポリシーがない場合、フローログでは L7 フィールドと DNS フィールドは空のままです。

両方の部分が必要です。

クラスターレベルの L7 サポート。 クラスターで L7 ポリシーのサポートを有効にする必要があります。詳細については、レイヤー 7 ポリシーの構成を参照してください。
L7 または DNS ルールをスコープとする Cilium ネットワークポリシー。 検査対象のトラフィックを持つワークロードにCiliumNetworkPolicy、rules.http、またはrules.kafkaを適用してください。 DNS 対応のエグレスの場合は、 rules.dns と toFQDNsを組み合わせます。詳細については、「 FQDN ポリシーの構成」を参照してください。

次の例では、kube-dns 参照の DNS 検査と、 *.example.comへのエグレスの L7 HTTP 検査を有効にします。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-dns-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchPattern: "*.example.com"
    - toFQDNs:
        - matchPattern: "*.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/1"

適用します。

kubectl apply -f l7-dns-policy.yaml

ポリシーが適用されると、 ContainerNetworkLogs 内の一致するフローが Layer7 フィールドに入力され、DNS 参照に dns.rcode および関連するメタデータが表示されます。

セットアップを確認する

これらの手順は、新規と既存の両方のクラスターセットアップに適用されます。

クラスターの資格情報を取得する

az aks get-credentials --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

コンテナーネットワークログが有効になっていることを確認する

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

出力で次のセクションを探します。

"networkProfile": {
  "advancedNetworking": {
    "enabled": true,
    "observability": {
      "enabled": true
    }
  }
}

"osmagent": {
  "config": {
    "enableContainerNetworkLogs": "True"
  }
}

カスタムリソースの状態を確認する

クラスター内のすべての ContainerNetworkLog リソースを一覧表示します。

kubectl get containernetworklog

作成した containernetworklog リソースの名前が表示されます。次のコマンドでその名前を使用して、その状態を確認します。

特定のリソースの状態を確認します。

kubectl describe containernetworklog <cr-name>

[ Status>State ] フィールドに CONFIGUREDが表示されます。 FAILEDが表示されている場合は、フィルタースペックが有効であることを確認します。

Spec:
  Includefilters:
    From:
      Namespaced Pod:
        namespace/pod-
    Name:  sample-filter
    Protocol:
      tcp
    To:
      Namespaced Pod:
        namespace/pod-
    Verdict:
      dropped
Status:
  State:      CONFIGURED
  Timestamp:  2025-05-01T11:24:48Z

複数の ContainerNetworkLog カスタムリソースを適用できます。それぞれに独自の状態があります。

Log Analytics でログを照会する

Log Analyticsが構成されている場合は、Log Analytics ワークスペースの ContainerNetworkLogs テーブルを使用して、フローログの履歴を照会できます。 Kusto クエリ言語 (KQL) を使用して、ネットワークパターンの分析、セキュリティインシデントの特定、接続のトラブルシューティング、根本原因分析の実行を行います。

サンプルクエリについては、AKS Labs ドキュメントのフローログを使用したプログレッシブ診断を参照してください。

Grafana ダッシュボードを使用して視覚化する

Azure ポータルから事前構築済みの Grafana ダッシュボードにアクセスできます。 Azure Monitorのログポッドが実行されていることを確認してから、開始してください。

kubectl get pods -o wide -n kube-system | grep ama-logs

予想される出力:

ama-logs-9bxc6                                   3/3     Running   1 (39m ago)   44m
ama-logs-fd568                                   3/3     Running   1 (40m ago)   44m
ama-logs-rs-65bdd98f75-hqnd2                     2/2     Running   1 (43m ago)   22h

監視データへのアクセス権を Grafana に付与する

Managed Grafana ワークスペースには、Log Analytics ワークスペースを含むサブスクリプションの Monitoring Reader ロールが必要です。

サブスクリプション所有者またはユーザーアクセス管理者の場合、Managed Grafana ワークスペースは作成時にこのロールを自動的に取得します。

そうでない場合 (または、Log Analyticsワークスペースと Grafana ワークスペースが異なるサブスクリプションにある場合)、ロールを手動で付与します。

Managed Grafana ワークスペースで、[>] に移動します。
[Azure ロールの割り当て]>[ロールの割り当てを追加] を選択します。
[スコープ] を [サブスクリプション] に設定し、サブスクリプションを選択し、[ロール] を [監視閲覧者] に設定して、[保存] を選択します。
Managed Grafana インスタンスの [ データソース ] タブでデータソースを確認します。

ダッシュボードにアクセスする

Azure ポータルからダッシュボードを開くには:

Azure portal で、AKS クラスターに移動します。
Grafana を活用したダッシュボード (プレビュー)を選択します。
Azure MonitorまたはAzureマネージドプロメテウスで利用可能なダッシュボードを参照します。

Azure Monitor>Insights>Containers>Networking の下にあるダッシュボードを探します。 Log Analyticsの ContainerNetworkLogs テーブルに対して選択したレベルに応じて、次の 2 つのオプションがあります。

ダッシュボード	経路	テーブル階層	グラファナID
フローログ - 基本層	Azure>Insights>Containers>Networking>フローログ - ベーシックティア	Basic	23155
フローログ - 分析レベル	Azure>Insights>Containers>Networking>Flow Logs - Analytics Tier	分析 (デフォルト)	23156

どちらのダッシュボードにも、要求、応答、ドロップ、エラーなど、相互に通信する AKS ワークロードが表示されます。 ContainerNetworkLogs テーブル用に構成されているレベルと一致するものを使用します。

ダッシュボードコンポーネントの詳細については、コンテナーネットワークログの概要を参照してください。

ヒント

ContainerNetworkLogs テーブルの既定値は Analytics レベルです。インジェストとリテンション期間のコストを削減する場合は、 Basic レベルに切り替えて、対応するダッシュボードを使用できます。詳細については、「Log Analytics テーブルプランを参照してください。

オンデマンドログモードを構成する

オンデマンドログを使用すると、永続ストレージなしでフローデータをリアルタイムでキャプチャできます。このモードは、Cilium データプレーンと非 Cilium データプレーンの両方で動作します。

クラスターで Advanced Container Networking Services を有効にする必要があります。 ACNS 対応クラスターがまだない場合は、次のクラスターを作成します。

Cilium
非 Cilium

export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --generate-ssh-keys \
    --location eastus \
    --max-pods 250 \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --node-count 2 \
    --pod-cidr 192.168.0.0/16 \
    --kubernetes-version 1.33 \
    --enable-acns

注

コンテナーネットワークセキュリティは、Cilium 以外のクラスターでは使用できません。

export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --generate-ssh-keys \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

既存のクラスターで ACNS を有効にする

すでにあるクラスターで ACNS を有効にするには、次の手順を実施してください。

az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --enable-acns

注

Container Network Security の機能には、Cilium データプレーンが必要です。

クラスターの資格情報を取得します。

az aks get-credentials --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Hubble CLI をインストールする

export HUBBLE_VERSION=v1.16.3
export HUBBLE_ARCH=amd64

if [ "$(uname -m)" = "aarch64" ]; then HUBBLE_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}
sha256sum --check hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum
sudo tar xzvfC hubble-linux-${HUBBLE_ARCH}.tar.gz /usr/local/bin
rm hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}

Hubble CLI を使用する

Hubble Relay ポッドが実行中であることを確認してください。

kubectl get pods -o wide -n kube-system -l k8s-app=hubble-relay

予想される出力:

hubble-relay-7ddd887cdb-h6khj     1/1  Running     0       23h

Hubble Relay をポート転送します。

kubectl port-forward -n kube-system svc/hubble-relay --address 127.0.0.1 4245:443

Hubble クライアントの mTLS 証明書を構成します。

#!/usr/bin/env bash
set -euo pipefail
set -x

CERT_DIR="$(pwd)/.certs"
mkdir -p "$CERT_DIR"

declare -A CERT_FILES=(
  ["tls.crt"]="tls-client-cert-file"
  ["tls.key"]="tls-client-key-file"
  ["ca.crt"]="tls-ca-cert-files"
)

for FILE in "${!CERT_FILES[@]}"; do
  KEY="${CERT_FILES[$FILE]}"
  JSONPATH="{.data['${FILE//./\\.}']}"

  kubectl get secret hubble-relay-client-certs -n kube-system \
    -o jsonpath="${JSONPATH}" | \
    base64 -d > "$CERT_DIR/$FILE"

  hubble config set "$KEY" "$CERT_DIR/$FILE"
done

hubble config set tls true
hubble config set tls-server-name instance.hubble-relay.cilium.io

シークレットが存在するかどうかを確認します。

kubectl get secrets -n kube-system | grep hubble-

予想される出力:

kube-system     hubble-relay-client-certs     kubernetes.io/tls     3     9d
kube-system     hubble-relay-server-certs     kubernetes.io/tls     3     9d
kube-system     hubble-server-certs           kubernetes.io/tls     3     9d

特定のポッドからのフローを観察します。
```
hubble observe --pod hubble-relay-7ddd887cdb-h6khj
```

Hubble UI を設定する

次のマニフェストを hubble-ui.yamlとして保存します。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: hubble-ui
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: hubble-ui
  labels:
    app.kubernetes.io/part-of: retina
rules:
  - apiGroups:
      - networking.k8s.io
    resources:
      - networkpolicies
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - componentstatuses
      - endpoints
      - namespaces
      - nodes
      - pods
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - apiextensions.k8s.io
    resources:
      - customresourcedefinitions
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - cilium.io
    resources:
      - "*"
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: hubble-ui
  labels:
    app.kubernetes.io/part-of: retina
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: hubble-ui
subjects:
  - kind: ServiceAccount
    name: hubble-ui
    namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: hubble-ui-nginx
  namespace: kube-system
data:
  nginx.conf: |
    server {
        listen       8081;
        server_name  localhost;
        root /app;
        index index.html;
        client_max_body_size 1G;
        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            # CORS
            add_header Access-Control-Allow-Methods "GET, POST, PUT, HEAD, DELETE, OPTIONS";
            add_header Access-Control-Allow-Origin *;
            add_header Access-Control-Max-Age 1728000;
            add_header Access-Control-Expose-Headers content-length,grpc-status,grpc-message;
            add_header Access-Control-Allow-Headers range,keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout;
            if ($request_method = OPTIONS) {
                return 204;
            }
            # /CORS
            location /api {
                proxy_http_version 1.1;
                proxy_pass_request_headers on;
                proxy_hide_header Access-Control-Allow-Origin;
                proxy_pass http://127.0.0.1:8090;
            }
            location / {
                try_files $uri $uri/ /index.html /index.html;
            }
            # Liveness probe
            location /healthz {
                access_log off;
                add_header Content-Type text/plain;
                return 200 'ok';
            }
        }
    }
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: hubble-ui
  namespace: kube-system
  labels:
    k8s-app: hubble-ui
    app.kubernetes.io/name: hubble-ui
    app.kubernetes.io/part-of: retina
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: hubble-ui
  template:
    metadata:
      labels:
        k8s-app: hubble-ui
        app.kubernetes.io/name: hubble-ui
        app.kubernetes.io/part-of: retina
    spec:
      serviceAccountName: hubble-ui
      automountServiceAccountToken: true
      containers:
      - name: frontend
        image: mcr.microsoft.com/oss/cilium/hubble-ui:v0.12.2
        imagePullPolicy: Always
        ports:
        - name: http
          containerPort: 8081
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8081
        readinessProbe:
          httpGet:
            path: /
            port: 8081
        resources: {}
        volumeMounts:
        - name: hubble-ui-nginx-conf
          mountPath: /etc/nginx/conf.d/default.conf
          subPath: nginx.conf
        - name: tmp-dir
          mountPath: /tmp
        terminationMessagePolicy: FallbackToLogsOnError
        securityContext: {}
      - name: backend
        image: mcr.microsoft.com/oss/cilium/hubble-ui-backend:v0.12.2
        imagePullPolicy: Always
        env:
        - name: EVENTS_SERVER_PORT
          value: "8090"
        - name: FLOWS_API_ADDR
          value: "hubble-relay:443"
        - name: TLS_TO_RELAY_ENABLED
          value: "true"
        - name: TLS_RELAY_SERVER_NAME
          value: ui.hubble-relay.cilium.io
        - name: TLS_RELAY_CA_CERT_FILES
          value: /var/lib/hubble-ui/certs/hubble-relay-ca.crt
        - name: TLS_RELAY_CLIENT_CERT_FILE
          value: /var/lib/hubble-ui/certs/client.crt
        - name: TLS_RELAY_CLIENT_KEY_FILE
          value: /var/lib/hubble-ui/certs/client.key
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8090
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8090
        ports:
        - name: grpc
          containerPort: 8090
        resources: {}
        volumeMounts:
        - name: hubble-ui-client-certs
          mountPath: /var/lib/hubble-ui/certs
          readOnly: true
        terminationMessagePolicy: FallbackToLogsOnError
        securityContext: {}
      nodeSelector:
        kubernetes.io/os: linux
      volumes:
      - configMap:
          defaultMode: 420
          name: hubble-ui-nginx
        name: hubble-ui-nginx-conf
      - emptyDir: {}
        name: tmp-dir
      - name: hubble-ui-client-certs
        projected:
          defaultMode: 0400
          sources:
          - secret:
              name: hubble-relay-client-certs
              items:
                - key: tls.crt
                  path: client.crt
                - key: tls.key
                  path: client.key
                - key: ca.crt
                  path: hubble-relay-ca.crt
---
kind: Service
apiVersion: v1
metadata:
  name: hubble-ui
  namespace: kube-system
  labels:
    k8s-app: hubble-ui
    app.kubernetes.io/name: hubble-ui
    app.kubernetes.io/part-of: retina
spec:
  type: ClusterIP
  selector:
    k8s-app: hubble-ui
  ports:
    - name: http
      port: 80
      targetPort: 8081

マニフェストを適用します。
```
kubectl apply -f hubble-ui.yaml
```

ポートフォワーディングを設定します。

kubectl -n kube-system port-forward svc/hubble-ui 12000:80

ブラウザーで http://localhost:12000/ を開き、Hubble UI にアクセスします。

トラブルシューティング

ACNS が有効になっていません。 ACNS を使用せずに --enable-container-network-logs を実行すると、次の結果が生成されます。

"フローログには '--enable-acns' が必要です。高度なネットワークを有効にする必要があります。
Kubernetes のバージョンが古すぎます。 1.33.0 より前のクラスターで --enable-container-network-logs を実行すると、次の結果が生成されます。

The specified orchestrator version %s is not valid. Advanced Networking Flow Logs is only supported on Kubernetes version 1.33.0 or later.
CRD が認識されません。 ACNS を使用せずにクラスターに ContainerNetworkLog を適用すると、次の結果が生成されます。

error: resource mapping not found for <....>": no matches for kind "ContainerNetworkLog" in version "acn.azure.com/v1alpha1"

クラスターで ACNS が有効になっていることを確認します。

保存されたログモードを無効にする

保存されたログには、ノードでのログ生成と、オプションのAzure Monitorへの転送という 2 つのレイヤーがあります。どちらのレイヤーも個別にオフにすることができます。

ログの生成を停止する

ログの生成は、カスタムリソース ContainerNetworkLog によって駆動されます。これらすべてを削除すると、新しいフローレコードが各ノードの /var/log/acns/hubble/events.log に書き込まれなくなります。

kubectl delete containernetworklog --all

すべてのリソースではなく特定のリソースを削除するには、 kubectl delete containernetworklog <cr-name>実行します。

Azure Monitorへのログの転送を停止する

Log Analytics ワークスペースへのログの送信のみを停止し、ノードでログを生成し続ける場合は、Azure Monitor統合を無効にします。

az aks update -n $CLUSTER_NAME -g $RESOURCE_GROUP --disable-container-network-logs

既存の ContainerNetworkLog リソースは引き続き有効であるため、それらのリソースを削除するまで、フローは /var/log/acns/hubble/events.log の各ノードに配置され続けます。

リソースをクリーンアップする

リソースが不要になった場合は、リソースグループを削除します。

az group delete --name $RESOURCE_GROUP

制限事項

データプレーンと Kubernetes バージョン

保存されたログモードには、Cilium データプレーンと Kubernetes 1.33 以降が必要です。
オンデマンドログ (Hubble CLI と Hubble UI) は、Cilium データプレーンと非 Cilium データプレーンの両方で機能します。

レイヤー 7 と DNS の可視性

レイヤー 7 のフローレコードは、クラスターで L7 ポリシーのサポートが有効になっていて、L7 ルールを持つ CiliumNetworkPolicy がトラフィックをカバーしている場合にのみ設定されます。詳細については、レイヤー 7 ポリシーの構成を参照してください。
DNS レコードは、Cilium FQDN ポリシー (rules.dns と toFQDNs) がトラフィックをカバーする場合にのみ設定されます。 FQDN ベースのポリシーは、AKS ローカル DNS を含むノードローカル DNS と互換性がありません。詳細については、「 FQDN ポリシーの構成」を参照してください。

ホストローカルストレージ

Azure Monitorまたは外部コレクターがない場合、フローログは各ノードの /var/log/acns/hubble/events.log に格納され、上限は 50 MB です。上限に達すると、古いエントリが上書きされます。
フローログはホストノードに書き込まれ、Azure Monitor エージェントによって収集されます。 ContainerNetworkLog CRD の適用後にLog Analytics統合を有効にした場合、その時点からの新しいログのみが取り込まれます。ホスト上の履歴ログは収集されません。

Log Analytics

コンテナーネットワークログを有効にした後で Log Analytics ワークスペースを切り替えると、ログが新しいワークスペースへのフローを停止する可能性があります。これは、既存のAzure Monitorデータ収集構成が自動的に更新されないために発生します。この問題を回避するには、最初にコンテナーネットワークログを有効にするときに目的のワークスペースを構成するか、ワークスペースを変更するときに関連付けられているデータ収集ルールを手動で更新します。 Container insights でのデータ収集の構成に関する説明を参照してください。
ContainerNetworkLogs テーブルでは、Analytics (既定) レベルと Basic レベルがサポートされています。補助層はサポートされていません。

集計のトレードオフ

フローログの集計では、個々のフロータイムスタンプ、ポッドごとの IP アドレス、または HTTP URL や DNS クエリ名などのカーディナリティの高いフィールドは保持されません。フローごとの調査には、オンデマンドログを使用します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-01

コンテナー ネットワーク ログを設定する

[前提条件]

保存されたログ モードを構成する

格納されたログの流れを最初から最後まで示す方法

展開オプション

エンド ツー エンドのセットアップ

手順 1: クラスターで ACNS が有効になっていることを確認する

オプション A: ACNS を使用して新しいクラスターを作成する

オプション B: 既存のクラスターを使用する

手順 2: ContainerNetworkLog CRD を適用してログ収集を開始する

手順 3 (省略可能): 永続的ストレージのログをAzure Monitorに転送する

ショートカット: 最初からLog Analyticsを使用してクラスターを作成する

ContainerNetworkLog CRD テンプレート

CRD フィールドリファレンス

レイヤー 7 と DNS フローをキャプチャする

セットアップを確認する

クラスターの資格情報を取得する

コンテナー ネットワーク ログが有効になっていることを確認する

カスタム リソースの状態を確認する

Log Analytics でログを照会する

Grafana ダッシュボードを使用して視覚化する

監視データへのアクセス権を Grafana に付与する

ダッシュボードにアクセスする

オンデマンド ログ モードを構成する

既存のクラスターで ACNS を有効にする

Hubble CLI をインストールする

Hubble CLI を使用する

Hubble UI を設定する

トラブルシューティング

保存されたログ モードを無効にする

ログの生成を停止する

Azure Monitorへのログの転送を停止する

リソースをクリーンアップする

制限事項

関連コンテンツ

フィードバック

その他のリソース

コンテナーネットワークログを設定する

保存されたログモードを構成する

エンドツーエンドのセットアップ

コンテナーネットワークログが有効になっていることを確認する

カスタムリソースの状態を確認する

オンデマンドログモードを構成する

保存されたログモードを無効にする