AKS の kube-proxy 設定でまず押さえるべき結論は、iptables、IPVS、nftables の3つのモードをクラスター単位で選べるようになっており、特に nftables は大規模な Service 数を持つクラスターや、将来的に IPVS 依存を減らしたい環境で検証候補になる、という点です。一方で、AKS ではこの機能はプレビュー扱いのため、本番環境へすぐ適用するのではなく、非本番クラスターで通信影響、NodePort、Network Policy、監視メトリックを確認してから判断するのが安全です。Microsoft Learn の該当ページでは、AKS の kube-proxy はクラスター内 Service 宛てのトラフィックルーティングを扱い、バックエンドとして IPTABLES、IPVS、NFTABLES を指定できると説明されています。なお、参照した公式ページ上の最終更新日は 2026年1月29日と表示されています。(Microsoft Learn)
Azure の新機能・変更点：「Configure kube-proxy」で何を確認すべきか
Azure Kubernetes Service の「Configure kube-proxy」は、AKS クラスターで kube-proxy の動作モードを指定するためのプレビュー機能です。kube-proxy は、Kubernetes Service の仮想 IP とバックエンド Pod の通信を各ノード上で成立させる重要なコンポーネントです。普段は意識しにくい領域ですが、Service 数が増えたクラスター、NodePort を使う構成、Network Policy を使う構成では、モード変更が通信品質や運用手順に影響します。(Microsoft Learn)
今回の確認ポイントは、単に「nftables が使える」という話ではありません。実務では、既定値の IPTABLES を維持するのか、既存の IPVS 利用を見直すのか、NFTABLES を検証対象にするのかを、クラスター規模・ネットワークポリシー・NodePort 利用・メンテナンス許容時間で判断する必要があります。
| 確認項目 | 公式情報上のポイント | 管理者への影響 |
|---|---|---|
| 対象機能 | AKS の kube-proxy モード設定 | Service 通信の内部ルーティングに関わる |
| 選択できるモード | IPTABLES、IPVS、NFTABLES | 既定値は IPTABLES |
| 適用範囲 | クラスター全体 | Service マニフェスト自体の更新は不要 |
| 適用方法 | --kube-proxy-config を指定して az aks create または az aks update | 新規作成時・既存更新時の両方で設定可能 |
| 注意点 | 設定変更時に Service トラフィックが短時間影響を受ける可能性 | メンテナンス枠と事前検証が必要 |
| プレビュー条件 | aks-preview 拡張機能、機能フラグ登録、対応 API バージョン | 本番適用前に非本番で検証すべき |
kube-proxy の3モードをどう使い分けるか
kube-proxy のモード選びは、「新しいから NFTABLES」ではなく、現在のクラスターが抱えている課題から逆算するのが現実的です。小〜中規模の標準的な AKS クラスターで、Service 数や通信遅延に明確な問題がない場合は、既定の IPTABLES を維持する判断も十分に合理的です。
| モード | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
IPTABLES | 多くの Kubernetes クラスターで使われる既定のバックエンド | 互換性を重視する一般的な AKS クラスター | 大規模 Service 環境ではルール数増加による影響を確認 |
IPVS | Linux Virtual Server を使う L3/L4 ロードバランシング | 既に IPVS 前提で運用している環境 | AKS では Azure Network Policy をサポートしない点に注意 |
NFTABLES | iptables API の後継で、性能とスケーラビリティを意識したモード | Service 数が多いクラスター、IPVS からの将来移行検証 | AKS ではプレビュー。ネットワークプラグインや NodePort 挙動を検証する必要 |
Microsoft Learn では、IPVS は状態認識や接続追跡などの利点を持つ一方で、Azure Network Policy をサポートしないと明記されています。また、nftables は iptables API の後継であり、IPVS の代替として推奨される位置づけで説明されています。(Microsoft Learn)
Kubernetes upstream 側では、IPVS proxy mode は Kubernetes v1.35 で deprecated とされ、nftables proxy mode は Kubernetes v1.33 で stable とされています。ただし、AKS での機能提供状況やサポート範囲は Azure 側の公式ドキュメントを優先して確認する必要があります。(Kubernetes)
影響範囲：アプリよりも「クラスター運用」に効く変更
kube-proxy の設定はクラスター全体の設定です。Microsoft Learn では、Service を更新する必要はないと説明されています。つまり、通常の Deployment や Service マニフェストを直接書き換える変更ではありません。(Microsoft Learn)
ただし、影響が小さいという意味ではありません。Service 通信の実装方式を変えるため、次のような領域では事前確認が必要です。
| 影響を受ける領域 | 確認すべき内容 |
|---|---|
| ClusterIP 通信 | アプリ間通信、DNS 経由の Service 解決、内部 API 呼び出し |
| NodePort | 到達可能なノード IP、localhost 経由の利用有無、Firewall 設定 |
| LoadBalancer Service | Azure Load Balancer 自体ではなく、ノード内の Service 転送経路 |
| Network Policy | Azure Network Policy、Calico、Cilium など利用中のデータプレーンとの相性 |
| 監視 | kube-proxy メトリック、Service 通信エラー、TCP reset、レイテンシ |
| IaC | ARM、Bicep、Terraform AzAPI、Azure CLI のクラスター定義 |
特に nftables へ切り替える場合、Kubernetes 公式ドキュメントでは NodePort の挙動差が説明されています。iptables モードでは NodePort がローカルの全 IP アドレスで到達可能になるのに対し、nftables モードでは既定でノードのプライマリ IPv4/IPv6 アドレスに限定されます。また、127.0.0.1 経由の NodePort 到達や、ローカル Firewall との相互作用も iptables と完全には同じではありません。(Kubernetes)
設定変更に必要な前提条件
AKS で kube-proxy のカスタム設定を使うには、Azure CLI 利用時に aks-preview 拡張機能が必要です。さらに、KubeProxyConfigurationPreview 機能フラグの登録が必要です。ARM または REST API を使う場合、AKS API バージョンは 2022-08-02-preview 以降、nftables モードでは 2025-09-02-preview 以降が必要とされています。(Microsoft Learn)
実務では、以下の順に準備します。
az extension add --name aks-preview
az extension update --name aks-previewaz feature register \
--namespace "Microsoft.ContainerService" \
--name "KubeProxyConfigurationPreview"登録状態を確認します。
az feature show \
--namespace "Microsoft.ContainerService" \
--name "KubeProxyConfigurationPreview"状態が Registered になったら、リソースプロバイダーを再登録します。
az provider register --namespace Microsoft.ContainerServiceここで失敗しやすいのは、機能フラグを登録した直後にクラスター更新を実行してしまうことです。登録状態が反映されるまで数分かかるため、az feature show で Registered を確認してから進めるのが安全です。(Microsoft Learn)
kube-proxy 設定ファイルの具体例
kube-proxy の設定は JSON ファイルで指定します。AKS のスキーマでは、networkProfile.kubeProxyConfig に enabled、mode、ipvsConfig などの項目が含まれ、mode には IPTABLES、IPVS、NFTABLES を指定できます。(Microsoft Learn)
nftables を有効化する設定例
NFTABLES を検証する場合は、まず最小構成で始めるのが分かりやすいです。
{
"enabled": true,
"mode": "NFTABLES"
}このファイルを kube-proxy.json として保存し、新規クラスター作成または既存クラスター更新時に指定します。
az aks create \
--resource-group <resourceGroup> \
--name <clusterName> \
--kube-proxy-config kube-proxy.json \
--generate-ssh-keys既存クラスターに適用する場合は次のように実行します。
az aks update \
--resource-group <resourceGroup> \
--name <clusterName> \
--kube-proxy-config kube-proxy.jsonMicrosoft Learn では、kube-proxy 構成の変更によりクラスター Service のトラフィックフローが若干中断される可能性があると説明されています。そのため、既存クラスターでは業務時間中にいきなり適用せず、メンテナンス枠を設けるべきです。(Microsoft Learn)
IPVS を使う設定例
既存運用で IPVS の接続スケジューラを明示したい場合は、ipvsConfig を指定できます。
{
"enabled": true,
"mode": "IPVS",
"ipvsConfig": {
"scheduler": "LeastConnection",
"tcpTimeoutSeconds": 900,
"tcpFinTimeoutSeconds": 120,
"udpTimeoutSeconds": 300
}
}ただし、ipvsConfig は mode が IPVS の場合に使う設定です。NFTABLES に移行する際に、ipvsConfig の値がそのまま効くと考えるのは誤りです。AKS のスキーマでも、ipvsConfig は IPVS 用の構成として定義されています。(Microsoft Learn)
管理者が最初に確認すべきチェックリスト
既存クラスターで kube-proxy モード変更を検討する場合は、いきなり設定を変えず、現在の状態を棚卸しします。特に、Service 数が少ない環境では NFTABLES の性能メリットが体感しにくい可能性があり、変更リスクだけが残ることがあります。
| 確認項目 | コマンド例・見方 | 判断基準 | |
|---|---|---|---|
| 現在の kube-proxy 設定 | az aks show -g <rg> -n <cluster> --query "networkProfile.kubeProxyConfig" -o json | 未設定なら AKS 既定動作を利用している可能性 | |
| Service 数 | kubectl get svc -A --no-headers | wc -l | 数千〜数万規模なら性能検証の価値が上がる | |
| NodePort 利用 | kubectl get svc -A --field-selector spec.type=NodePort | nftables 移行前に到達元 IP と Firewall を確認 | |
| Azure Network Policy | クラスター作成設定、運用ドキュメント、az aks show | IPVS 利用時は非対応の注意点を確認 | |
| 長時間 TCP 接続 | DB 接続、gRPC、WebSocket、MQ など | 切替時の瞬断と conntrack 周りを重点確認 | |
| 監視メトリック | Prometheus、Container Insights、ログ | 切替前後でエラー率・レイテンシを比較 |
この棚卸しで重要なのは、「モード変更で何を解決したいのか」を明確にすることです。たとえば、Service 数が多く iptables ルール更新の遅延が疑われるなら NFTABLES 検証は意味があります。一方、単に新機能だから試すだけなら、プレビュー機能を本番に入れる理由としては弱いです。
移行期限はあるのか
AKS の該当 Microsoft Learn ページでは、既存 AKS クラスターに対して IPTABLES や IPVS から NFTABLES へ移行しなければならない明確な期限は示されていません。したがって、Azure 側の強制移行日があるかのように運用計画を立てるのは避けるべきです。(Microsoft Learn)
一方で、Kubernetes upstream では IPVS proxy mode が Kubernetes v1.35 で deprecated と示されています。これは「AKS でただちに使えなくなる」という意味ではありませんが、長期的には IPVS 前提の新規設計を避け、IPTABLES または NFTABLES への移行可能性を検証しておくべきサインです。(Kubernetes)
現実的な判断は次の通りです。
| 現在の状態 | 推奨アクション |
|---|---|
既定の IPTABLES で問題がない | 急いで変更せず、AKS の GA 化や追加情報を待つ |
IPVS を使っている | Azure Network Policy の利用有無と upstream deprecation を踏まえて移行検証を始める |
| Service 数が非常に多い | 非本番で NFTABLES の性能・互換性を検証する |
| NodePort や特殊な Firewall を多用 | NFTABLES 移行前に到達性テストを必ず実施する |
nftables を検証すべきケース、まだ待つべきケース
nftables は、Kubernetes upstream では iptables より効率的に Service/Endpoint の変更を処理し、特に数万 Service 規模で差が見えやすいと説明されています。また、Linux ノードで利用でき、カーネル 5.13 以降が必要です。(Kubernetes)
ただし、AKS ではプレビュー機能です。Microsoft Learn のプレビュー機能に関する注意書きでは、AKS プレビューはセルフサービスのオプトインで提供され、SLA や限定保証の対象外であり、本番利用を意図していないと説明されています。(Microsoft Learn)
| 判断 | 具体的な状況 |
|---|---|
| 検証すべき | Service 数が多い、IPVS 依存を減らしたい、将来の Kubernetes 変更に備えたい |
| 慎重に進めるべき | NodePort を外部連携で使っている、独自 Firewall がある、長時間 TCP 接続が多い |
| まだ待つべき | 本番 SLA が厳しい、非本番で検証できない、プレビュー機能を許容できない |
| 避けるべき | 「性能が上がりそう」という理由だけで本番へ直接適用する |
変更手順：安全に進めるための実務フロー
本番に近い AKS クラスターで kube-proxy モードを変更する場合は、次の順で進めると失敗を減らせます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 事前調査 | 現在の kubeProxyConfig、Service 数、NodePort、Network Policy を確認 | 既存の暗黙依存を見落とす |
| 非本番検証 | 同じ CNI、同じ Service パターンで NFTABLES または IPVS を検証 | 小さすぎる検証環境で判断してしまう |
| 監視基準作成 | 切替前のレイテンシ、5xx、TCP reset、CoreDNS、kube-proxy ログを記録 | 切替後の良し悪しを比較できない |
| メンテナンス計画 | 短時間の通信影響を許容できる時間帯を選ぶ | 業務ピークに実施して障害扱いになる |
| 適用 | az aks update --kube-proxy-config を実行 | feature flag や API バージョン不足で失敗 |
| 検証 | 代表 Service、NodePort、外部接続、内部 API 呼び出しを確認 | Pod 起動確認だけで通信確認を省略する |
| ロールバック方針 | 元のモードに戻す JSON を準備 | 切替後に元設定が分からなくなる |
実務でおすすめなのは、切替前に「戻すための IPTABLES 設定ファイル」も作っておくことです。
{
"enabled": true,
"mode": "IPTABLES"
}トラブル時にその場で JSON を作り直すと、誤字やパラメーター不足で復旧が遅れます。変更作業は、適用コマンドよりも「事前に戻し方を決めているか」が重要です。
よくある誤解と注意点
Azure Load Balancer の設定変更ではない
kube-proxy のモード変更は、Azure Load Balancer の SKU やフロントエンド IP 設定を変更する機能ではありません。対象は Kubernetes Service の仮想 IP からバックエンド Pod への転送経路です。LoadBalancer Service を使っている場合でも、Azure Load Balancer とノード内部の kube-proxy は役割が異なります。
すべての環境で nftables が速くなるとは限らない
nftables の利点は、大量の Service や Endpoint がある環境で見えやすいものです。Service 数が少ない一般的なクラスターでは、切替による性能差よりも、プレビュー機能利用や NodePort 挙動差のリスクの方が大きくなる場合があります。
IPVS の LeastConnection は常に均等ではない
AKS の公式ドキュメントでは、IPVS の LeastConnection は接続数が多い場合に負荷を均等にしやすい一方、接続数が少ない場合にはトラフィックが不均衡になる可能性があると説明されています。特にノード数が多く、接続数が少ないサービスでは、期待したほど均等化されないことがあります。(Microsoft Learn)
Network Policy の互換性を軽視しない
IPVS は Azure Network Policy をサポートしないと明記されています。Network Policy を使っている AKS クラスターで、性能目的だけで IPVS を選ぶと、セキュリティ設計に影響する可能性があります。(Microsoft Learn)
BYO CNI では kube-proxy 無効化も別論点になる
AKS マネージドの kube-proxy DaemonSet は、Bring Your Own CNI をサポートする目的で無効化できます。ただし、これは IPTABLES、IPVS、NFTABLES の選択とは別の設計判断です。CNI 側が Service 実装やロードバランシングをどう扱うかを理解せずに無効化すると、クラスター通信の責任範囲が曖昧になります。(Microsoft Learn)
導入判断の実務的な結論
AKS の Configure kube-proxy で確認すべきポイントは、NFTABLES をすぐ本番投入することではなく、kube-proxy のモード選択をクラスター設計の判断材料として扱えるようになったことです。既定の IPTABLES は引き続き安定重視の選択肢です。IPVS は既存利用がある場合に棚卸しが必要で、特に Azure Network Policy との非互換や upstream の deprecation を意識すべきです。NFTABLES は将来有望ですが、AKS ではプレビューであるため、非本番検証、NodePort 確認、Network Policy 確認、通信監視をセットで進めるのが現実的です。
次に取るべき行動は、既存 AKS クラスターの networkProfile.kubeProxyConfig を確認し、Service 数・NodePort・Network Policy・CNI を棚卸しすることです。そのうえで、IPVS を使っている環境や Service 数が多い環境から、非本番で NFTABLES の検証を始めるとよいでしょう。プレビュー機能である以上、移行は「設定できるか」ではなく「切替後の通信を観測し、戻せる状態を作ってから行うか」で判断することが重要です。
コメント