2026年8月26日にリリースされたKubernetes 1.37から、kube-proxyはプロキシモードを指定されないまま起動すると警告を出す[1][2]。ログにはエラーレベルで No kube-proxy mode specified: defaulting to 'iptables'. Note that in Kubernetes 1.40 the default mode will switch to 'nftables'. と記録され、ノードには reason が KubeProxyDefaultMode のWarningイベントが付く[3]。
1.37でも既定値はiptablesのままだ。既定をnftables（Linuxカーネルの新しいパケットフィルタリング機構）へ切り替える時期について、KEP-5343は1.40を予定している。ただしKEPのステータスはprovisional、つまり計画段階にある[4]。
警告の対象は、--proxy-mode も設定ファイルの mode: も書いていないkube-proxyに限られる。kubeadmは1.37から、kube-proxyの設定が渡されないときやmodeが空のときにmodeへiptablesを書き込むため、kubeadmで新しく作ったクラスタには警告が出ない[2][3]。一方、modeを空のまま1.40へ上げると、カーネル5.13未満のノードではkube-proxyがnftablesで起動しようとして失敗し、ノードが使えなくなるとKEPは書いている[4]。
予備知識
- kube-proxy: Kubernetes ServiceのIPアドレスへのアクセスを、実際のPodへ転送するための各ノード上のコンポーネント。
- プロキシモード: kube-proxyが転送ルールを書き込む仕組みの選択肢。Linuxではiptables・ipvs・nftablesの3つがあり、
--proxy-mode引数または設定ファイルのmode項目で指定する。 - iptables/nftables: どちらもLinuxカーネルのパケットフィルタリング機構。nftablesはiptablesの後継として設計された。
- KEP（Kubernetes Enhancement Proposal）: Kubernetesの機能追加・変更を提案・追跡する文書。
kube-proxyの背後で動くnftablesの文法・仕組みを直接学べ、移行後のトラブルシュート力につながる
なぜiptablesからnftablesへ移すのか
kube-proxyのiptablesモードは、Service数とエンドポイント数の合計に比例した数のルールを生成する。最上位のチェーンにはService IPとポートの組ごとに1本ずつルールが並び、届いたパケットをこれと順に照合するため、新しい接続の最初のパケットにかかる時間はService数に対してO(n)で伸びる[5]。公式ブログは、iptables APIは単純なファイアウォール向けに設計されたもので、数万のServiceを抱える大規模クラスタのServiceプロキシにはスケールしないと説明している[5]。
nftablesモードはverdict mapと呼ばれる対応表を使い、1本のルールで宛先ごとの振り分けを済ませる。検索はおおむねO(1)で、クラスタの規模によらず処理時間がほぼ一定になる[5]。公式ブログの計測では、5,000・10,000 Serviceのクラスタでnftablesのp50がiptablesのp01（ほぼ最良値）と同程度になり、30,000 Serviceではnftablesのp99がiptablesのp01を数マイクロ秒下回った[5]。
図の縦軸で読むと、30,000 Serviceのp99はiptablesが0.7ミリ秒を超えるのに対し、nftablesは0.05ミリ秒に届かない。差はルールの更新にも出る。iptablesモードは更新のたびにService数に比例した量の変更を送る必要があるが、nftablesモードは前回の同期から変わったServiceとエンドポイントの分だけを送ればよい。nftablesではコンポーネントごとに専用のテーブルを持てるため、iptablesのようなコンポーネント間のグローバルロック競合も起きない[5]。
nftablesモードは1.29でアルファとして入り[5]、1.33でGAになった[2]。IPVSモードの主な利点はiptablesより速いことだったが、nftablesモードはIPVSモードと同等か、わずかに上回る性能を出す[5]。そのIPVSモードは1.35で非推奨になった[2]。KEP-5343は1.40で既定をnftablesへ切り替え、あわせてIPVSモードを既定で無効にする段取りを示し[4]、1.37の公式ブログはIPVSモードを1.43で削除する見込みとしている[1]。
kube-proxyを含むKubernetesのネットワーク機構全体を体系的に押さえ直したい運用担当者向け
1.37の警告が出るクラスタ、出ないクラスタ
多くの利用者は、--proxy-mode も mode: も書かずにkube-proxyを動かしている。KEPは、こうした利用者を予告なしにiptablesからnftablesへ移すことは避けたいとして、1.37から既定値でiptablesになった場合に限ってログとイベントで警告し、十分な期間を置いてから既定を変える段取りを取った[4]。
警告文は、iptablesを使い続けるなら設定ファイルに mode: iptables、またはコマンドラインに --proxy-mode iptables を明示するよう求めている[3]。modeを明示したクラスタは、アップグレードでもダウングレードでも挙動が変わらない[4]。
kubeadmで構築したクラスタは事情が異なる。kubeadm 1.37は、KubeProxyConfigurationが渡されない場合やmodeが空の場合に、modeへiptablesを明示的に設定する[2]。kube-proxy側の変更を入れたプルリクエストも、kubeadmで新規作成したクラスタには影響しないはずだと説明している[3]。既存クラスタの設定は、1.37の公式ブログが示す次のコマンドで確かめられる[1]。
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
mode: "" のように値が空なら、警告の対象になる[3]。EKSではkube-proxyのConfigMap名が kube-proxy-config になる[6]。
Kubernetesクラスタを本番環境で運用する情報システム部門・SREチームが、2026年8月26日リリース予定のKubernetes 1.37で向き合うことになる変更がある[1]。長年使われてきたkube-proxyのIPVSモードが[…]
カーネル5.13という前提条件
nftablesモードはLinuxカーネル5.13以上を必要とする[5][4]。ホストのファイルシステムに1.0.0より古いnftコマンドがあるノードでは、kube-proxyのnftables利用がシステム上の他のnftables利用と干渉するおそれがあるため、nftablesモードを使わないよう公式ブログは求めている[5]。
KEP-5343は、主要ディストリビューションの標準カーネルを次のように整理している[4]。
| ディストリビューション | 標準カーネル | 5.13以上の要件 |
|---|---|---|
| Debian 12 | 6.1 | 満たす |
| Ubuntu 22.04 | 5.15 | 満たす |
| RHEL 9 | 5.14（名目上） | 満たす |
| RHEL 8 | 4.18（名目上） | KEPは、nftablesモードに必要なバックポートが足りない可能性が高いとみる |
| SLE15 SP4・SP5 | 5.14 | 満たす |
| SLE15 SP6・SLE16 | 6.x | 満たす |
AWSはAmazon Linux 2023と現行のUbuntuが要件を満たすとしている[6]。
問題になるのは、modeを明示しないまま古いカーネルのノードで1.40へ上げる場合だ。KEPは、このときkube-proxyがnftablesモードで起動しようとして失敗し、ノードが使えなくなると明記している。ホストのカーネルに応じて既定値を変える案にも触れているが、利用者に分かりにくく文書化もしにくいとして退けている[4]。
確認は、カーネル、Kubernetesのバージョンの順に進める。
数千人規模の従業員が使う基幹システムをAmazon EKS（Amazon Elastic Kubernetes Service、AWSのマネージドKubernetesサービス）上で本番稼働させ、年1回の内部監査を受ける情報システム部門のイ[…]
EKS・AKS・GKEでの扱い
マネージドサービスでは、kube-proxyのモードを変える経路がサービスごとに違う。
| サービス | モードの変更方法 | nftablesの扱い |
|---|---|---|
| Amazon EKS | kube-proxyアドオンの設定値 mode を変える（aws eks update-addon の --configuration-values '{"mode": "nftables"}'）。ConfigMapの mode は既定で iptables | Kubernetes 1.33以上で選べる。性能面から1.36以降での利用を推奨し、Amazon VPC CNIはv1.23.0以降が対応[6] |
| Azure AKS | az aks create / az aks update の --kube-proxy-config で IPTABLES・IPVS・NFTABLES から選ぶ。既定は IPTABLES | kube-proxyの設定機能そのものがプレビューで、KubeProxyConfigurationPreview の登録が必要。Microsoftはプレビュー機能を本番利用向けではないとしている[7] |
| Google GKE | Dataplane V2はkube-proxyではなくCiliumでServiceを実装する | 新規のAutopilotクラスタでは既定で有効。既存クラスタを後からDataplane V2へ移すことはできない[8] |
AWSは、nftablesモードへの切り替えを中断を伴う変更と位置づけ、業務時間外かクラスタ作成時に行うよう勧めている[6]。Microsoftも、kube-proxyの設定変更でServiceの通信が一時的に途切れることがあると書いている[7]。
nftablesへ切り替える前に確かめること
カーネル以外にも、公式ブログは移行前の確認点を挙げている[5]。
| 確認点 | 内容 |
|---|---|
| CNI・NetworkPolicy実装 | kube-proxyのnftablesモードに未対応のものがある。kube-proxyのiptablesルールを直接操作しない実装なら、多くは影響を受けない |
| 監視・可観測性ツール | 更新していないツールは、nftablesモードのkube-proxyについて報告するデータが少なくなることがある |
| NodePort | nftablesモードではノードの既定IPでしか到達できず、iptablesモードのように127.0.0.1では受け付けない |
| 切り替えと切り戻し | kube-proxyの設定を変えてPodを再起動すれば切り替わり、ノードの再起動は要らない。戻したときも前のモードのルールは削除される |
NodePortの差については、1.37でnftablesバックエンドにlocalhost経由のNodePortを扱うオプトインのユーザー空間プロキシが加わった[1]。KEP-5343は、この機能（KEP-6032）が1.38でベータ、1.40でGAになる見込みとしている[4]。
手順にすると、カーネルの棚卸しを先頭に置き、modeの明示で警告と1.40での自動切り替えを止めてから検証へ進む順になる。運用を外部に委託している場合は、検証作業が委託範囲に含まれるかを検証の前に確かめておく。
まとめ
1.37の警告は1.40の既定切り替えの予告で、1.37の時点で動作は変わらない。KEPの予定どおりなら、影響が出るのは1.40への更新時で、modeが空のkube-proxyはカーネル5.13未満のノードで起動に失敗する[4]。
最初の作業は、ConfigMapの mode が空かどうかと、KubeProxyDefaultMode イベントが出ているかの確認だ。空なら mode: iptables を書いて1.40での自動切り替えを止める。そのうえでノードのカーネルとnftのバージョン、CNIと監視ツールのnftables対応を棚卸しし、nftablesへ移る時期をクラスタごとに決める。
よくある質問（FAQ）
Q1. 警告が出たらすぐにnftablesへ切り替える必要があるか。
必要ない。1.37時点の既定値はiptablesのままだ[2]。警告を止めるだけなら、設定ファイルに mode: iptables を書くか、--proxy-mode iptables を付ければよい[3]。
Q2. nftablesモードに切り替えるには何が必要か。
ノードのカーネルが5.13以上であること、ホストにnftコマンドがあるなら1.0.0以上であることが条件になる[5]。CNIやNetworkPolicy実装がnftablesモードに対応しているかも確かめる[5]。
Q3. kubeadmで作ったクラスタにも警告は出るか。
kubeadm 1.37で新しく作ったクラスタには出ない[2][3]。既存クラスタは、ConfigMapの mode の値で確かめる[1]。
Q4. IPVSモードを使っている場合はどうなるか。
IPVSモードは1.35で非推奨になった[2]。1.37の公式ブログによると、1.40で既定では無効になり（KubeProxyIPVS feature gateで選択は可能）、1.43で削除される見込みだ[1][2]。公式ブログは、IPVSモードの利用者にnftablesモードへの移行を勧めている[5]。
