Kubernetes Service API 初探

はじめに

Kubernetesには、クラスター内のサービスを公開するためのいくつかのソリューションがあります。その中でも特に人気があるのがIngressです。Ingressは、サービスを外部に公開するための標準であり、多くのサードパーティ実装が存在します。それぞれが独自の技術スタックを持ち、互換性のないゲートウェイに依存しています。

さまざまなIngress実装を統一し、Kubernetes上での一貫した管理を容易にするために、SIG-NETWORKコミュニティはKubernetes Service APIsをリリースしました。これは第二世代のIngressと呼ばれる標準実装のセットです。

テーマ説明

この記事では、Kubernetes Service APIsの基本的な概念について、いくつかの質問を通じて紹介します。

導入

Kubernetes Service APIsは第二世代のIngress技術と呼ばれていますが、第一世代と比べてどのように優れているのでしょうか？

Kubernetes Service APIsは、Ingressに限定されることを意図して設計されたのではなく、サービスネットワーキングを強化するために設計されました。その焦点は、表現力、拡張性、およびRBACにあります。

1. より多くの機能、例えばヘッダーや重みに基づいたトラフィック管理。

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. 拡張性の向上。Service APIsは多層APIの概念を導入し、各層が独自のインターフェースを公開することで、他のカスタムリソースがAPIと連携し、より細かい粒度（API粒度）での制御を可能にします。

3. ロール指向のRBAC：多層APIの実現の一環として、ユーザーの視点からリソースオブジェクトを設計するというアイデアがあります。これらのリソースは、最終的にKubernetes上でアプリケーションを実行する際の一般的なロールとマッピングされます。

Kubernetes Service APIsによって抽象化されたリソースオブジェクトは何か？

ユーザーロールに基づいて、Kubernetes Service APIsは以下のリソースを定義します：

GatewayClass、Gateway、Route

1. GatewayClassは、共通の設定と動作を持つゲートウェイタイプのセットを定義します：

• Gatewayとの関係は、Ingressのingress.classアノテーションに似ています。
• GatewayClassは、同じ設定と動作を共有するゲートウェイのグループを定義します。各GatewayClassは単一のコントローラーによって処理され、コントローラーとGatewayClassは一対多の関係にあります。
• GatewayClassはクラスターリソースです。機能するゲートウェイを持つためには、少なくとも1つのGatewayClassを定義する必要があります。

2. Gatewayは、トラフィックがクラスター内のサービスに変換されるポイントを要求します：

• 何をするか：クラスター外からのトラフィックをクラスター内に持ち込みます。これが実際のIngressエンティティです。
• 特定のLB設定の要求を定義します。これはGatewayClassの設定と動作の実装でもあります。
• Gatewayリソースは、オペレーターによって直接作成されるか、GatewayClassを処理するコントローラーによって作成されます。
• GatewayとRouteは多対多の関係にあります。

3. Routeは、ゲートウェイを通過するトラフィックがサービスにどのようにマッピングされるかを記述します。

さらに、Kubernetes Service APIsは、バックエンドサービスの柔軟な設定を可能にするために、BackendPolicyリソースオブジェクトを定義しています。

BackendPolicyオブジェクトを使用すると、TLS、ヘルスチェックの設定や、バックエンドサービスのタイプ（サービスやポッドなど）を指定できます。

Kubernetes Service APIsの導入によってもたらされる変化は何か？

Kubernetes Service APIsは、実装標準として以下の変化をもたらします。

1. 汎用性：Ingressと同様に、複数の実装が可能です。Ingressコントローラーはゲートウェイの特性に応じてカスタマイズできますが、すべて一貫した設定構造を持っています。1つのデータ構造を使用して、複数のIngressコントローラーを設定できます。
2. クラスの概念：GatewayClassesを使用すると、異なるタイプのロードバランシング実装を設定できます。これらのクラスにより、ユーザーはリソースモデル自体として使用できる機能を簡単かつ明確に理解できます。
3. 共有ゲートウェイ：独立したルーティングリソースHTTPRouteを同じGatewayClassにバインドすることで、ロードバランサーとVIPを共有できます。ユーザー層ごとに階層化されており、チームは下位レベルのGatewayの具体的な実装を気にすることなく、インフラストラクチャを安全に共有できます。
4. タイプ付きバックエンド参照：タイプ付きバックエンド参照を使用すると、ルートはKubernetesサービスや、ゲートウェイバックエンドとして設計された任意のKubernetesリソース（ポッドやステートフルセット、DBなど）、さらにはクラスター外部のアクセス可能なリソースを参照できます。
5. クロスネームスペース参照：異なるネームスペースのルートをGatewayにバインドでき、ネームスペースを跨いで互いにアクセスできます。また、Gateway下のルートがアクセスできるネームスペースの範囲を制限することも可能です。

現在、Kubernetes Service APIsのリソースオブジェクトをサポートしているIngress実装は何か？

コードレベルでKubernetes Service APIsのリソースオブジェクトをサポートしていることが確認されているIngressは、Contourとingress-gceです。

Kubernetes Service APIsはリソースの読み書き権限をどのように管理するか？

Kubernetes Service APIsは、ユーザー次元に基づいて3つのロールに分かれています：

1. インフラストラクチャプロバイダー GatewayClass；
2. クラスターオペレーター Gateway；
3. アプリケーション開発者 Route。

RBAC（ロールベースアクセス制御）は、Kubernetesの認可に使用される標準です。これにより、ユーザーは特定の範囲のリソースに対して誰が操作を実行できるかを設定できます。RBACを使用して、上記で定義された各ロールを有効にすることができます。

ほとんどの場合、すべてのロールがすべてのリソースを読み取ることができると期待されています。

3層モデルの書き込み権限は以下の通りです。

Kubernetes Service APIsの拡張ポイントは何か？

ゲートウェイの要件は非常に多岐にわたり、同じシナリオを実現する方法も多く、それぞれに利点と欠点があります。Kubernetes Service APIsは多層リソースオブジェクトを抽出し、いくつかの拡張ポイントも予約しています。

Kubernetes Service APIsは現在、Routeに焦点を当てています：

• RouteMatchは、Routeのマッチングルールを拡張します。
• 特定のバックエンドサービスタイプを指定します。例えば、ファイルシステムや関数式など、上記のKubernetesリソースに加えて。
• Routeフィルターは、リクエスト/レスポンスを処理するためにRouteライフサイクルに拡張を追加します。
• 上記の拡張が満たされない場合、カスタムRouteを完全にカスタマイズできます。

まとめ

この記事では、質問を通じてKubernetes Service APIsの基本的な紹介を行いました。全体として、Kubernetes Service APIsはIngressの多くのベストプラクティスを洗練させています。例えば、表現力の強化は実際にはRouteの機能を拡張し、BackendPolicyオブジェクトはほぼすべてのKubernetesバックエンドリソースをアップストリームとして指定できます。Kubernetes Service APIsは現在、リソースオブジェクトを広いレベルで指定していますが、リソースオブジェクト内にはまだ多くの詳細があり、定義する前に議論が必要です。これにより、潜在的な競合シナリオを防ぎ、構造内の特定の変数を考慮することができます。