博士

やっほー、ロボ子！今日のITニュースはね、Automatticのエンジニアさんが書いた、Kubernetesのファイアウォールに関する面白いケーススタディなのじゃ。

ロボ子

Kubernetesのファイアウォールですか、興味深いですね。具体的にはどのような内容なのでしょうか？

博士

WordPress VIPアプリケーションを動かすために、Kubernetesを使っているらしいのじゃ。で、ファイアウォールルールを設定して、リアルタイムで監視してたんだって。

ロボ子

リアルタイム監視は重要ですね。何か問題が発生したのでしょうか？

博士

そう！定期メンテナンス中に、ファイアウォールの監視が失敗し始めたのじゃ。原因を調べたら、Linuxカーネルの`ipset`モジュールにリグレッションが見つかったんだって！

ロボ子

`ipset`モジュールですか。具体的に何が問題だったのでしょう？

博士

`ipset`の一部の操作が、最大で1,000倍も遅くなったらしいのじゃ！Kubernetesホストのセキュリティポリシーを監視するスクリプトが、普段2秒で終わるのに、1分以上かかるようになったんだって。

ロボ子

それは大変ですね。原因は特定できたのでしょうか？

博士

`iptables`が`getsockopt`を使って`ipset`の情報を取得するのに時間がかかっていたのが原因らしいのじゃ。AutomatticのクラスターはCNIプラグインとして`kube-router`を使っていて、`kube-router`が`iptables`ルールと`ipset`を使って`NetworkPolicy`を実装しているから、影響が大きかったみたい。

ロボ子

`kube-router`が`ipset`を頻繁に更新していた、ということですね。

博士

その通り！新しいポッドが作られたり、不要なポッドが終了するたびに、`kube-router`は`ipset`を更新する必要があるのじゃ。クラスター内のポッドのチャーンが多いと、`ipset swap`操作の数が多くなって、速度低下につながるのじゃ。

ロボ子

`ipset swap`操作が遅くなった原因は何だったのでしょう？

博士

カーネルのアップグレード（6.1.67から6.1.69）が原因だったのじゃ！Debianのchangelogに、`netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test`という記述があったんだって。

ロボ子

原因が特定できてよかったですね。どのように解決したのでしょうか？

博士

`git bisect`を使って、リグレッションを引き起こしたコミットを特定したのじゃ。そして、`ip_set_swap`での`synchronize_rcu()`の呼び出しが原因だと突き止めたんだって。Jozsef Kadlecsikさんがすぐに修正パッチを送ってくれて、解決したらしいぞ！

ロボ子

素晴らしいですね。迅速な対応で、実稼働環境への影響を最小限に抑えられたのですね。

博士

まさにそうじゃ！今回のケーススタディから、カーネルのアップグレードには注意が必要だってことがよくわかるのじゃ。あと、`kube-router`を使っている場合は、`ipset`のパフォーマンスにも気を配る必要があるぞ。

ロボ子

勉強になります。私も気をつけます。

博士

ところでロボ子、`ipset`って、まるでアイドルグループの名前みたいじゃない？

ロボ子

確かにそうですね。でも、博士、オチが弱いですよ。