Kubernetes Controller Sharding を用いた、3世代以上にわたるカスタムコントローラーの水平スケールを実現（インターンレポート）

東京大学大学院 情報理工学系研究科 修士1年の加藤大翔と申します。

私は、LINEヤフーの社内PaaSの開発チームにおいて、4週間のインターンシップに参加しました。本レポートでは、私のインターンシップで取り組んだ「Kubernetes カスタムコントローラーの水平スケールの実現」について紹介します。

背景

LINEヤフーでは、Webアプリケーションのデプロイを容易にする基盤として「LINEヤフー社内向けPaaS」を開発しています。このLINEヤフー社内向けPaaSは Kubernetes をベースに構築されており、開発者向けに抽象化されたマニフェストを適用するだけで、アプリケーションが起動し、自動でユーザーに公開できます。さらに管理コンソールやテレメトリ情報の自動送信、認証・認可、シークレットマネージャーとの連携による機密情報の管理なども一元的に提供しています。

LINEヤフー社内向けPaaS上には、LINEヤフーの多数のサービスが稼働しており、1万以上のノード、10万以上のPodが存在する、非常に大規模な環境です。そのため、LINEヤフー社内向けPaaSでは、アプリケーションクラスター（アプリケーションが実際に稼働するクラスター）と、それらを統括する管理クラスターという複数のKubernetes クラスターを組み合わせてプラットフォームを構成しています。

詳細は、LINEヤフーにおける超大規模プラットフォーム実現への挑戦と学びをご参照ください。

この管理クラスターでは、Kubernetes カスタムコントローラーが使用されています。これは全アプリケーションクラスター上のアプリケーションを統合的に管理するため、非常に高い負荷がかかっています。しかし、Kubernetes コントローラーには、管理リソースの競合を避けるため、基本的に1インスタンスのみが稼働する（水平スケールできない）という制約があり、スケーラビリティに課題がありました。

本インターンシップでは、このカスタムコントローラーの水平スケールを可能にすることを目的に取り組みました。

Kubernetes コントローラーのシャーディング

Kubernetes コントローラーのシャーディング は、Tim Ebert 氏の修士研究をもとに開発されたOSS（Open Source Software）で、2025年の KubeCon Europe でも発表されています（参考： 限界を超えて: Kubernetes コントローラーの水平方向のスケーリング – Tim Ebert、STACKIT）。この仕組みのコアアイデアは、管理対象リソースに担当コントローラーのラベルを付与し、競合を避けつつコントローラーの水平スケールを可能にするというものです。

しかし、Kubernetes Controller Sharding をそのままLINEヤフー社内向けPaaSに導入するのは困難でした。理由は、ラベル付けに使用されるハッシュキーの生成方法にあります。この仕組みでは、ハッシュキーとカスタムコントローラーの Lease を用いて consistent hashing を計算し、その計算結果をもとにリソースへラベル付けを行います。親リソースと子リソースで同一のラベルを持たせるには、同じハッシュキーが必要になります。このハッシュキーの導出には、親リソースのNamespace、GVK（Kubernetes のリソースを区別するための Group・Version・Kind のセット）、リソース名の組み合わせが利用されます。一方、子リソースは親への ownerReference（参考：所有者と扶養家族 – Kubernetes）をもとに同一のキーを導出しています。

ただし、3世代以上のリソース構造を持つ場合、孫リソースは親リソースへの直接的な ownerReference を持たないため、同一のハッシュキーを付与することができません。