サイボウズサマーインターン2025 Kubernetes 基盤コース開催報告

Kubernetes

今年もサイボウズのサマーインターンシップで Kubernetes 基盤開発コースを開催しました。 インターンには 3 名の方に参加してもらい、サイボウズの Kubernetes 基盤である Neco についての業務を体験していただきました。

この記事では、インターンの様子と、それぞれ取り組んでいただいた作業について紹介します。

日程

8/18（月）〜 8/22（金）の 1 週間と 8/18（月）〜 8/29（金）の 2 週間の 2 日程で、それぞれフルリモートで開催しました。
初日はオンボーディング作業や Neco についての説明をし、2 日目からそれぞれ作業を開始、最終日に成果発表をしていただきました。

また、インターン期間中はメンター以外の以下のチームの社員と交流できる会をいくつか開催しました。

  • Neco ネットワーク班
    • Neco のネットワーキングコンポーネントの管理を担当
  • Neco インフラ班
    • Kubernetes の中心的なコンポーネントやサーバーの管理を担当
  • Cloud Platform チーム
    • 旧システムから Neco への移行やサイボウズ製品の運用支援を担当
  • PDX チーム
    • Neco の利用者に提供するツールやコンポーネントの管理を担当
  • CSA チーム
    • Neco のデータストアコンポーネントの管理を担当

他にも、Neco の開発・運用を担当するチームの週次定例や、本部の月次定例などにも参加していただき、日々の業務への理解をより深めてもらいました。

取り組んでいただいたテーマ

neco-admission の VAP 置換

neco-admission の VAP(Validating Admission Policy)置換では、Validating Webhook から VAP への置き換えを行なっていただきました。 Neco の環境では、neco-admission と呼ばれる Validating Webhook を用いて、使用できるコンテナイメージを制限したり、リソースの誤削除の防止をする機能を提供しています。 VAP とは、CEL(Common Expression Language)式を用いて Kubernetes のリソースの妥当性を検証する仕組みで、Kubernetes 1.30 で GA(General Availability)になりました。 Validating Webhook から VAP に置き換えることで、以下のようなメリットがあります。

  • API サーバー内で処理が完結するため、通信の遅延や障害点を減らせる
  • Webhook 用のコンテナイメージや証明書の作成が不要になるため、メンテナンスが楽になる
  • CEL で記述できるため、ポリシーがシンプルになり保守しやすい

今回は、neco-admission で提供している機能のうち、以下の機能を VAP に置き換えるタスクを行なっていただきました。

  • validate_delete
    • 重要なリソースの誤削除を防止する機能
  • validate_preventdelete
    • 特定の annotation が付与されたリソースの誤削除を防止する機能
  • validate_pod
    • Pod が使用できるコンテナイメージを制限する機能
  • validate_grafana
    • GrafanaDashboard の設定を制限する機能

また、これらの VAP をテストするためには、Kubernetes 環境を用意して、手動で VAP の内容が合っているかをテストする必要がありました。 この問題を解決するため、kaptestと呼ばれる CEL 表現をチェックするためのテストツールを使い、CI 環境でテストが自動で実行されるような仕組みも追加していただきました。

Sabakan メトリクス改善・kube-scheduler プラグイン開発

Sabakan メトリクス改善、kube-scheduler プラグイン開発という 2 つのタスクを実施してもらいました。

Sabakan メトリクス改善では、重複して収集されていたメトリクスを、収集のルールを変更して重複せずに収集されるようにしていただきました。 Sabakanは Neco のサーバーの管理をするソフトウェアです。 この Sabakan ではメトリクスを公開していますが、インスタンスごとに同じメトリクスを公開しています。 モニタリングシステムが Sabakan のメトリクスを収集すると、同じメトリクスが重複して収集されてしまいます。 そのため、メトリクスを用いて集計をする際に、重複を排除するために余計なクエリが必要になっていました。 この問題を解決するため、Sabakan のメトリクスの収集ルールを変更し、重複せずに収集されるようにしていただきました。

kube-scheduler プラグイン開発では、kube-scheduler の拡張方法について調査してドキュメントにまとめていただきました。 そして、調査結果を踏まえて Scheduling Framework を活用した PoC を実装していただきました。 kube-scheduler デフォルトの設定では、リソースが均一に使われるように Pod が配置されます。そのため、request が小さい Pod を同時に複数作成するとリソース使用量が少ない Node に大量の Pod がスケジュールされるという現象が発生します。 この際に、特定のノードに Pod が大量に作成されることで、Cilium の CNI リクエストのレートリミットにかかってしまいます。 Cilium の CNI リクエストのレートリミットにかかることで、Pod の作成が遅れたり、できなくなるという問題が起きていました。 この問題を解決するために、Cilium のレートリミットに関するメトリクスを元に、スコアを計算する kube-scheduler プラグインを PoC として開発していただきました。

Coil EgressNAT の nftables 対応

Neco では CNI プラグインとして自社 OSS の Coil を使用しています。
Coil は EgressNAT という機能をもっており、Neco 内の Pod はこの EgressNAT を経由することでクラスタ外と疎通性のある IP アドレスに変換し通信しています（詳しくは【連載】Cybozu.comクラウド基盤の全貌 第3回 Neco のネットワークもよければご覧ください）。

この Coil EgressNAT はデータプレーンとして iptables のマスカレードルールを使用しています。
しかし、iptables は逐次的なルールマッチングによる非効率さや、ルールの追加・削除操作がアトミックでない点などいくつかの欠点があります。 これら iptables の欠点を克服するために、nftables がその後継として開発・導入が進んでいます。
今回のインターンでは、Coil でもこの nftables を利用したパケットのマスカレードを実装するため、ライブラリの選定から取り組んでいただきました。 この作業で取り組んでいただいた nftables 実装は近日Coil のリリースに含まれる予定です。

また、実装にあたっては過去に不具合対応で入れていた iptables についてのコードブロックの内容を見直していただいたり、Linux 環境を前提としていた開発環境を Mac 環境にも対応していただくなどもしていただきました。

おわりに

1 週間・2 週間という短い期間でしたが、みなさん素晴らしい成果を出していただきました。 Kubernetes 基盤開発コースでは、実際の業務から生まれた様々なテーマのタスクや社員との交流から、サイボウズがオンプレミス環境で運用している Kubernetes クラスタに理解を深められます。 興味のある方はぜひ次回開催時に応募してみてください！