CNDT2021、Kubernetesのマルチテナントを実装したIIJのSREが語る運用の勘所

CNDT2021から、Kubernetes上でマルチテナント環境を実装した事例のセッションを紹介する。これは株式会社インターネットイニシアティブ（以下、IIJ）のSREである田口景介氏が行ったもので「シングルテナント・マルチクラスタ vs マルチテナント・シングルクラスタ論争 決着のとき」というタイトルが示すように、シングルテナントとマルチテナントの利点や欠点などを実際に実装した経験を元に解説するものだ。

単一のクラスタ上で実装されるKubernetesでは、IIJのようなインターネットサービスを提供するサービスプロバイダーなどにおいては不十分であることは理解できる。またサーバーハードウェアのリソースをフルに活用できていないことから、より効率的な運用のために複数のテナントを共存させることでハードウェアリソースを効率的に運用できることを目指すもの理にかなっていると言える。

直近のKubeCon NA 2021では、Cluster APIへのマルチクラスタの機能の追加についてキーノートでも紹介された。またKubeCon EU 2021やKubeCon China 2019でも、その実装方法についてRed HatやHuaweiなどのエンジニアによるセッションが行われているように、マルチクラスタ、マルチテナントに関する議論は活発な状況だ。

KubeCon EU 2021でのRed Hatが提案するkcpに関する記事：KubeCon EU 2021でRed Hatが発表した複数のKubernetesを制御するkcpを紹介

KubeCon China 2019でのHuaweiのセッションに関する記事：KubeCon China：サーバーレスとマルチテナンシーのセッションに注目

このような状況で、IIJはKubernetesのエコシステムが成熟するのを待つよりも、自力でマルチテナントを実装していくことを選択したわけで、このセッションはその内容を紹介するものとなった。

CNDT2021の動画：シングルテナント・マルチクラスタ vs マルチテナント・シングルクラスタ論争 決着のとき

セッションのタイトル

セッションの内容は、次のスライドに端的にまとめられている。つまりKubernetesを最大限に使うためにはマルチテナントが望ましいが、実際にそれを実装するためには多くのコンポーネントが必要となる。実際に本番用として利用できる事例を、IIJの目線で紹介するというのがこのセッションの目的だ。

セッションの要約

次に紹介したスライドではIIJが使っているKubernetesのコンポーネントを解説している。この図においてピンクで色付けされているのが、IIJ開発のソフトウェアだ。

IIJが運用するIKE（IIJ Kubernetes Engine）のコンポーネント群

ネットワークスタックであるCalicoをCNI（Container Network Interface）として利用、ストレージにはCSI（Container Storage Interface）の先にLinstor、KongのAPI Gateway、TraefikのIngress Controllerなども存在していることからわかるように、オープンソースを最大限利用していることが見てとれる。まだ商用ソフトウェアであるSysdig Secureも採用し、ノードのセキュリティを高めていることもわかる。

Kubernetesのメリットを最大限に引き出すためには

Kubernetesのメリットを最大限に利用するためには、継続的なアップデートとマルチテナントクラスタが必要だというのが田口氏の意見だ。

IKEのKubernetesアップデートの方針

Kubernetesに限らす活発に開発が行われているオープンソースプロジェクトの場合、利用する側にとっては新機能やバグフィックスが次々に登場するのは喜ばしいが、実際にそれに追従して更新を行っていく立場の運用管理者にとっては頭痛の種でもあるだろう。IIJの場合は、それを敢えて運用担当の仕事として行っているのがわかる。4か月ごとに最新のひとつ前のリリースに環境を更新しているというのがIIJのサーバー環境であるという。

ここからマルチテナントの話

そしてこのスライドから、どうしてIIJがマルチテナントを運用しているのかを解説するフェーズとなる。「シングルテナント・マルチクラスタ vs マルチテナント・シングルクラスタ」の比較表を使って解説を行っている。IIJとしては収容効率を上げながら、テナント自身の運用負荷を下げるためにはマルチテナントを採用するのは自明だったという。

マルチテナントの実装方式の違い

このスライドではマルチテナントを実装する方式、モデルの違いを解説している。IIJが採用したのはnamespaceでテナントを分離する方法だ。ちなみにKubeCon China 2019でHuaweiが解説していたのはVirtual Cluster方式で、Red HatのkcpもKubernetes on KubernetesでHuaweiのモデルに近いと言える。

IIJがVirtual Clusterを採用しなかったのは、Virtual Clusterではテナント自身が運用するためのコストが高いことを挙げている。一方、検証目的などでKubernetesのクラスタを多数立ち上げる必要がある場合などには、Virtual Clusterを採用するのは理にかなっていることも説明している。

マルチテナントの課題

ここからIIJが実際に直面したマルチテナントの課題について解説を行うフェーズとなった。最初に解説したのは認証と承認についてだ。

IIJの認証と承認のモデル

マルチテナント対応のAuthn（承認）とAuthz（認証）としてOpenID Connectを活用しているが、実際の実装ではIIJでいくつかのコンポーネントを開発する必要があったという。namespaceとそれに紐づいたRBAC（Role Based Access Control）が実装されている。

Kubernetesクラスタを制御するリソースに関する課題

ここではKubernetesクラスタを制御するリソースに対して、テナントからのリクエストを自動化することは諦めて運用側で対応していることを解説した。本来であれば、API経由でテナント自身が設定された範囲内で自由に設定できることが望ましいが、現状ではそれは難しいとして、ホスト運用担当がその都度対応しているという。これはIIJがテナント運用担当者の運用コストを下げることを主目的としているための弊害とも言える。現状では、ホスト側の運用担当者がそのコストを負担しているということになる。

ネットワーク環境もマルチテナント対応に

このスライドではIKEのネットワークについて解説している。テナントが必要とするトラフィック制御を実装するための複数のロードバランサーが稼働している。IPアドレスのプールを管理するのはCalicoのIPAMだ。

マルチテナントに必須のリソース管理

ここではノードの効率的な活用を行うためには複数のテナントが同じノードのリソースを分配して使うことは理想的だが、実際にはテナント側の安定稼働、劣化しない性能などのリクエストに応えるためには、テナントが専有するノードを設置することは不可避であることを解説。ただ今後はテナント毎にQoS（Quality of Service）を設定して、QoSに応じたPodの配置が柔軟に行えるスケジューラーが必要だと解説した。

モニタリングもマルチテナント対応に

モニタリングの部分ではIKEが利用するVictoria Metrics、Grafana Labsが開発するLokiやTempoもマルチテナントに対応していたために、テナントが持つクライアント証明書を使ってmTLSを使ってセキュアなアクセスが可能になっているという。ログについては特にセンシティブな情報が含まれる可能性が高いために、この部分が確実に分離されていることは必須だろう。

Sysdig Secureでノードのセキュリティを管理

ここで田口氏はマルチテナントにおけるセキュリティについて解説した。セキュリティを脅かす事象が起こった場合、それを防ぐ対処を行うのはテナント運用担当の責任だが、クラスタにおいてその可能性があることを検知するのはクラスタホストの運用担当であると説明し、責任分界点が存在することを解説した。その上で、IKEにおいてはSysdig Secureを導入して運用していることを解説した。

最後に「Kubernetesとの付き合い方」として「データプレーンは手堅く、コントロールプレーンはイケイケ」で運用するべきだと解説した。イケイケの意味は安全安定だけを目的とせずに進化の速いオープンソースプロジェクトに追従するということで、それによる利益が運用管理コストを上回るということだろう。一旦完成したらなるべく更新しないように塩漬けで運用することが多いインフラストラクチャー担当者にとっては、注目に値する意見だ。IIJのマルチテナントの実装例は、マルチテナントの採用に踏み切れないサービス事業者にとってはひとつのベンチマークとなることだろう。