Kubernetesは「コンテナを実行する基盤」ではない　拡張性を活かしてクラウドネイティブな特性を得るサイバーエージェント開発部隊

devチームでは「Kubernetes as a Service」と「ML Platform」を開発中

青山真也氏：本日は「"Platform for Platform" with Kubernetes」というテーマで発表いたします。よろしくお願いします。

軽く自己紹介します。私は青山と申します。2016年に株式会社サイバーエージェントに新卒入社して、現在はメディア側とAI事業本部側の、プライベートクラウドのインフラ部隊を合併して作った「CyberAgent group Infrastructure Unit」、通称CIUで働いています。

ふだんの主な業務は、今日紹介するKubernetes as a Serviceと、ML Platformの開発を行なっています。Kaas（Kubernetes as a Service）はプロダクトオーナーという立ち位置でやっています。

サイバーエージェントにはDeveloper Expertsという制度があって、私はKubernetes／CloudNative領域のExpertとしても認定されています。ほかにも、「CloudNative Days」や「Kubernetes Meetup Tokyo」のco-chairやオーガナイザーなどをやっています。

要はKubernetesが大好きなんですね。趣味も「おうちKubernetes」で、SynologyのNAS（ネットワークHDD）を買って、CSIドライバを書いて自宅クラスターを作っているので、もし興味があれば、この記事もぜひ読んでみてください。

ということで、さっそく内容に入っていきたいと思います。私たちCIUの中には、実はdevチームと呼ばれる開発部隊がいます。このdevチームで開発している基盤は、現状主に次の2つです。Kubernetes as a ServiceとML Platformです。

Kubernetes as a Serviceは、通称AKEと呼ばれるシステムでして、Googleの「GKE（Google Kubernetes Engine）」やAWSの「EKS（Elastic Kubernetes Service）」のように、Kubernetesクラスターをユーザーにフルマネージドなかたちで提供するようなサービスです。

もう一方のML Platformは、後ほど細かく紹介しますが、機械学習をシームレスに行うための基盤を作っています。

Kubernetesは「コンテナを実行する基盤」ではない

このどちらもKubernetesをベースとして作っています。まずはKubernetesの拡張性の話をしていきたいなと思います。

おさらいですが、Kubernetesは複数台のコンテナのホストマシンを管理する機能がある「コンテナオーケストレーションツール」の1つです。ここでいう「管理」は、スケジューリングやローリングアップデートなど、さまざまなものが挙げられます。Kubernetesはこのオーケストレーションツールの1つです。

もう1つ、Kubernetesではコンピューティングリソースの資源や、ストレージ系の資源、またGPUなど、さまざまな資源を抽象化して扱えるのもKubernetesの特徴です。このあたりが、よくあるKubernetesの説明かと思います。

ここまで聞くと、「Kubernetesはコンテナを実行する基盤なのか？」「インフラの基盤っぽい」「ただ実行するだけの基盤なのか」と思う方も多いと思いますが、実はそうではないという話をしていきたいと思います。

もう少しKubernetesの内部の話をしていきたいと思います。Kubernetesでは、右のYAMLファイルのようなReplicaSetリソースと呼ばれるものがあります。このマニフェストで、どういうコンテナを何個起動するか、何個複製するかを定義してKubernetesにApplyすると、ReplicaSetの定義をもとにコンテナが3つ起動する流れになっています。

このマニフェストを登録した時に、3つ作られるだけではなく、実はKubernetesの内部でControllerと呼ばれるプログラムが、この状態に収束するように制御しています。この収束する制御は、Reconciliation loopと呼ばれていて、日本語に訳すと「調整ループ」になります。

この調整ループは、主にObserveとDiffとActの3フェーズから成っています。Observeでは現状を把握。要求された状態と実際のステータスがどうかを見て、Diffで差分を計算して、Actionでその差分に対して何かしらのアクションを行います。3つあってほしいのに2個しかない時は、実際に1個作る処理をずっとループ処理で行なうイメージです。

Kubernetesでは、複数のControllerが中でいっぱい動いています。今回はReplicaSetコントローラーの例を紹介しましたが、ほかにもいっぱいあります。

例えばノード障害の時に自動復旧するものもあれば、ロードバランサーのメンバーを管理するコントローラーもあります。これによってKubernetesは分散システムとして成り立っています。

Controllerの仕組みなど、いろいろな拡張ポイントがあって、そういったControllerの仕組みをもとに、KubernetesやCNCF（Cloud Native Computing Foundation）のコミュニティでは、オープンな技術推進とそのエコシステムの開発が積極的に行われています。

例えば、先ほどのReconciliation loopを活用したOSSのControllerの例としてここに挙げているCert Managerは、IngressリソースというLoadBalancerを作った時に、自動的に証明書を払い出して、シークレットリソースを作り、Ingressと自動連携できるようにするものです。

またExternal DNSは、LoadBalancerから払い出されたIPアドレスをDNSと自動的に紐付けて管理したり、従来人がやっていた運用のナレッジもController化してまとめてKubernetesに任せたりできるようになっています。こうしたエコシステムが、非常にたくさんあります。

不足の部分はKubernetesの拡張性を活かした拡張機能を実装している

私たちの基盤でもこういうエコシステムはたくさん使っていますが、私たちの会社のユースケースに対応しきれない運用業務や取り扱いたいものは、けっこうあります。そうした時に、私たちはKubernetesの拡張性を活かして、自社の特定のドメインに特化した拡張機能を実装して提供しています。

先ほど紹介したControllerも、独自のカスタムControllerというかたちで作れますし、Kubernetesのリソースも独自のリソースを定義して作れます。あとは、Mutating WebhookやValidating Webhookという拡張ポイントも用意されています。

これはどんなものかというと、kubectl applyなどでKubernetesのAPIサーバーにマニフェストを送った時に、そのマニフェストを一部改変して登録したり、リクエストが来たマニフェストの内容を細かくチェックして、通すか通さないかを判別する拡張ポイントも用意されています。あとはkubectlのpluginや、さまざまなデバイスを扱うためのpluginなどといった拡張ポイントもあります。

ほかにもKubernetesの標準化のポイントとしては、コンテナランタイムや、ネットワークやストレージなどがあります。あとは標準化ではないのですが、クラウドプロバイダとの連携部分はインターフェイスがしっかり切られていて、自分たちの使いたいプロバイダがない場合には、自前で作ってPluggableに差し込めるようになっています。

Kubernetesの強みは豊富なエコシステムと拡張性の高さ

まとめると、Kubernetesの強みは、先ほど紹介したとおりReconciliation loopが宣言された状態に収束してくれるところや、それをもとにしたエコシステムがいっぱいあるところです。ない場合には拡張性の高さがあるので、それをもとに自社のドメインに特化したControllerなど、拡張できることが強みです。

こうした特徴を私たちは活かしながら、いわゆるCNCF（Cloud Native Computing Foundation）が提唱しているクラウドネイティブな特性を得られると考えています。

なぜこういう特性を得ていきたいかというと、こうしたOSSの進化にも適切に追従しながら、プラットフォーム自体もきちんと進化させ続けることで、ビジネスの成功をプラットフォーム側からも支えたいという思いがあるからです。

ということで、ちょっと駆け足ですが、Kubernetesのどんなところがいいのか、どういった内部ロジックで拡張性を持っているのかを紹介しました。

（次回へつづく）