【ITニュース解説】A Quick Dive into Kubernetes Operators - Part 1

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースプラットフォームである。現代の分散アプリケーション管理が抱える多くの課題を解決できるため、その人気は非常に高い。アプリケーションを構成するコンテナ群を論理的な単位にまとめ、管理や発見を容易にする。Kubernetesはコンテナオーケストレーションを標準化し、アプリケーションが様々なクラウドやオンプレミスの環境で回復性、スケーラビリティ、ポータビリティを持つことを保証する。基盤となるインフラストラクチャを抽象化することで、開発者は運用上の複雑さに煩わされることなく、コードを書くことに集中できる。

Kubernetesの中核には、「Desired State（あるべき状態）」という概念がある。これは、アプリケーションがどのような状態であるべきかを宣言的に定義するモデルであり、Kubernetesはその状態を実現し、維持するために絶えず動作する。例えば、ウェブサーバーのPodが常に3つのレプリカで稼働していることを宣言できる。このパターンを実装するのがControllerである。Controllerは、クラスタの現在の状態を継続的に監視し、設定で指定されたDesired Stateと比較する制御ループである。もし不一致があれば（例えばPodがクラッシュしてレプリカが2つになった場合）、Controllerはその2つの状態を調和させるためのアクション（例えば新しいPodを起動する）を実行する。このデザインパターンこそが、Kubernetesの自己修復能力の根源である。

KubernetesにはPod、Service、Deploymentといった組み込みのリソースがあるが、特定のアプリケーションに最適なプリミティブが常に用意されているとは限らない。そこで登場するのがCustom Resources（CRs）である。CRsは、Kubernetes API内で独自のオブジェクトタイプを定義できるようにするAPI拡張機能である。例えば、データベースを実行している場合、バージョン、サイズ、ユーザー認証情報などのフィールドを持つDatabaseというCustom Resourceを作成できる。Operatorは、これらのCustom Resourcesを管理する特定のタイプのControllerである。Operatorは、データベースやメッセージキューのような複雑なアプリケーションを管理するために必要な運用知識をコード化する。新しいAPIタイプ（Custom Resource）と、そのAPIタイプを監視・管理するControllerを追加することで、Kubernetes APIを拡張する。

Kubernetesは、Operatorがそのネイティブな機能を拡張し、複雑なアプリケーションを管理するための豊富な機能を提供する。これらの機能は、OperatorがDesired Stateを達成するための構成要素である。 SecretsとConfigMapsは、Operatorが機密データ（パスワード、APIキー）や設定を管理するために利用する。Operatorはこれらのリソースの変更を監視し、必要に応じてアプリケーションを自動的に再設定できる。 Role-Based Access Control（RBAC）は、Operatorが特定のリソースと対話するためのきめ細かい権限を付与できる重要なセキュリティ機能である。Operatorは、リソースを作成、更新、削除するためにRBACロールを必要とし、自身のCustom Resourcesを管理する権限も必要とする。この最小権限の原則により、Operatorが必要なアクションのみを実行できるようになり、セキュリティ侵害時の影響範囲を限定する。人間がkubectlのようなツールを使ってKubernetesクラスタと対話するには、まず認証が必要となる。Kubernetes APIサーバーはユーザーアカウントを内部で管理せず、外部の認証プロバイダに依存する。これには、クラスタの認証局（CA）によって署名されたクライアント証明書、外部サービスを使用してベアラトークンを検証する認証Webhook、外部アイデンティティプロバイダで認証しトークンを受け取るOpenID Connect（OIDC）といった方法がある。 Admission Controllersは、Kubernetes APIサーバーへのリクエストが永続化される前にそれを傍受するプラグインである。OperatorはValidatingおよびMutating Admission Webhooksを使用して、自身のCustom Resourcesに対するポリシーを強制できる。 より複雑なユースケースでは、Kubernetes Aggregation APIにより、Operatorは拡張APIサーバーとして機能できる。これにより、Operatorは独自のAPIを提供でき、そのCustom Resourcesはkubectlや他の標準ツールから、KubernetesのネイティブAPIの一部であるかのように見えるようになる。 Network Policiesは、アプリケーションのコンポーネント間のトラフィックフローを制御するためにOperatorが定義・管理できる機能である。 Ingress/Egress Controllersは、ウェブアプリケーションのOperatorがIngressおよびEgressリソースを管理し、アプリケーションを外部に公開したり、アウトバウンドトラフィックを制御したりできる。 高度なネットワーク機能のために、OperatorはIstioやLinkerdのようなサービスメッシュと統合できる。Operatorはアプリケーションのサービスメッシュコンポーネントを自動的に設定・管理し、カナリアデプロイメント、A/Bテスト、きめ細かいトラフィックシフトといった、手動では管理が難しい機能を有効にできる。

クラウドネイティブのランドスケープは、絶えず成長しているプロジェクトと製品の巨大なエコシステムであり、公式のCloud Native Computing Foundation（CNCF）のランドスケープだけでも千以上のエントリがある。このコミュニティ主導の取り組みの広範さが、その最大の強みの一つである。人気のあるサードパーティツールには、業界標準の監視ツールであるPrometheus、豊富な機能を持つサービスメッシュであるIstio、GitOpsツールであるArgo CD、コンテナレジストリであるHarbor、CI/CDフレームワークであるTekton、クラウドネイティブセキュリティツールであるFalcoなどがある。

しかし、カスタムコントローラは大量のデータを扱う際に重大な課題に直面する。KubernetesはすべてのデータストレージをETCDに依存しており、これが複雑なワークロードや高負荷なワークロードにおけるスケーラビリティ、柔軟性、パフォーマンスを制限する。ETCDは設定データ向けに設計されており、クラスタサイズは制限されている。ETCDの整合性モデルではすべてのメンバーが完全なレプリカであり、Kubernetesはリーダーのみに接続する。ETCDはストレージレベルでデータをフィルタリングできず、Kubernetes APIサーバーはすべてのレコードを取得してクライアント側でフィルタリングする必要がある。単一のETCDインスタンスでは、クラスタ設定とカスタムデータが混在する。高負荷のカスタムサービスが通常のクラスタ操作をブロックしたり遅延させたりする可能性があり、クラスタ全体の健全性を危険にさらす。Kubernetesは分離方法を備えたマルチテナントであるが、最終的にすべてのデータは単一のデータベースに保存されるため、データベースの障害はクラスタ全体に影響を及ぼし、悪意のある攻撃者がすべてにアクセスする可能性もある。 これらの理由から、過去にはカスタムリソースとコントローラがインフラ問題の解決に利用されつつも、大量のデータを扱うアプリケーションは避けられることが多かった。Kubernetesはアプリケーションの状態を管理するための強力なAPIを提供するが、そのアーキテクチャ設計に内在する制限を理解することが重要である。更新がシステム全体ですぐに可視化されない結果整合性、ACIDトランザクションの非サポート、データエンティティ間の複雑な結合や関係の非サポート、高度なクエリエンジンを含まない限られたデータフィルタリングといった制限がある。しかし、Kubernetes API集約層は、別のバックエンドまたは拡張APIサーバーによって提供されるカスタムAPIでAPIを拡張できるようにすることで、コアAPIサーバーの制限を克服するのに役立つ。

ここでHariKubeが登場する。HariKubeは、データベースの負荷を複数のベンダーに依存しないデータベース間で透過的に分散させるミドルウェアであり、低遅延、高スループット、そして真のクラウドネイティブ開発体験を提供する。データ分散と最適化されたデータベースルーティングを通じて、卓越したパフォーマンスを実現する。リソース集約型ワークロードをETCDからオフロードすることで、HariKubeは規模に応じた一貫した応答性と運用効率を保証する。名前空間、リソースタイプ、またはサービス間で厳格なデータ分離を可能にし、組織がスケーラビリティやパフォーマンスを犠牲にすることなく、セキュリティとコンプライアンス要件を満たすのを支援する。さらに、HariKubeはインフラストラクチャの複雑さを抽象化することで、開発者のワークフローを簡素化する。開発者はデータ構造とビジネスロジックに集中でき、プラットフォームがデータルーティングとストレージを処理する。HariKubeは完全に透過的であり、KubernetesはそれがETCDインスタンスと通信していないことに気づかない。開発には限られたデータでバニラのKubernetesを使用し、本番環境ではHariKubeをデプロイして大規模なデータセットを処理し、複数のバックエンドにデータを分散できる。

Operatorは様々なプログラミング言語で開発できるが、Go言語がその強力な型システムと堅牢なフレームワークの存在から最も一般的である。Kubebuilderのようなツールを使ってOperatorを初期化し、Kindのようなツールでテストするのが一般的である。例えば、まずプロジェクトを作成し、kubebuilder initコマンドで初期設定を行う。その後、アプリケーションのドメインを設計し、kubebuilder create apiコマンドでCustom Resourceを定義する。ToDoアプリケーションのTaskのようなカスタムリソースを定義する場合、その仕様（Priority、Details、Deadline、TaskStateなど）とステータスを記述する。定義が完了したら、make manifests generateコマンドでKubernetesマニフェストとソースコードを生成する。 次に、kind create clusterでKubernetesクラスタを起動し、make installコマンドで作成したカスタムAPIをKubernetesにデプロイする。その後、定義したTaskオブジェクトをkubectl apply -f -コマンドで作成できる。 Kubernetesでは、フィールドセレクタとラベルセレクタを使ってオブジェクトをフィルタリングできる。ラベルセレクタはリソースにアタッチされたキーと値のペアで、より一般的で強力なフィルタリング機能を提供する。フィールドセレクタはリソースフィールドの値に基づいてフィルタリングするが、ラベルセレクタに比べて機能は限定的である。例えば、kubectl get tasks --selector "example.example.com/priority=3" --field-selector "spec.priority=3"のように、これらのセレクタを使って特定の条件に合致するTaskオブジェクトを検索できる。

OperatorパターンはKubernetesを強力なプラットフォームへと変えるが、ETCDへの依存はデータ量の多いアプリケーションにとってパフォーマンスのボトルネックとなる可能性がある。この問題の解決策はデータ層を分離することである。HariKubeのようなツールがカスタムリソースデータを透過的にオフロードすることで、スケーラブルで高性能なサービスを構築し、速度や安定性を損なうことなくKubernetesの真の力を活用できる。これはクラウドネイティブ開発の未来である。