Istio API の進化

Istio API の設計原則とその進化について説明します。

2019年8月5日 | Louis Ryan - Google、Sandeep Parikh - Google 著

Istio の主要な目標の1つは、常に、チームがそれぞれの組織とワークロードに最適な抽象化を開発できるようにすることです。Istio は、サービス間ネットワーキングのための堅牢で強力なビルディングブロックを提供します。Istio 0.1以来、Istio チームは本番環境のユーザーから、独自のアーキテクチャ、ワークロード、制約を Istio の機能にどのようにマッピングするかについて学び、Istio の API を進化させて、より使いやすくなるようにしてきました。

Istio API の進化

Istio の進化の次のステップは、焦点を絞り、Istio ユーザーの役割に合わせる事です。セキュリティ管理者は、Istio メッシュ内のセキュリティ操作を論理的にグループ化して簡素化する API と対話できる必要があります。サービスオペレーターとトラフィック管理操作についても同様です。

さらに一歩進めると、各役割の初心者、中級者、上級者のユースケースについて、より良いエクスペリエンスを提供する機会があります。多くの一般的なユースケースは、明白なデフォルト設定と、ほとんど設定不要なより明確に定義された最初のエクスペリエンスで対処できます。中級のユースケースでは、Istio チームは環境からの状況的手がかりを活用し、より簡単な設定エクスペリエンスを提供したいと考えています。最後に、高度なシナリオでは、簡単なことは簡単に、難しいことは可能にすることを目指しています。

しかし、これらの役割中心の抽象化を提供するには、それらのもとにある API が Istio のすべての機能と能力を記述できる必要があります。歴史的に、Istio の API 設計へのアプローチは、他のインフラストラクチャ API と同様のパスに従っていました。Istio は次の設計原則に従います。

  1. Istio API は次のことを目指すべきです。
    • マッピングされる基盤となるリソースを適切に表現する
    • 基盤となるリソースの有用な機能を隠すべきではない
  2. Istio API はコンポーザブルであるべきです。エンドユーザーは、独自のニーズに合った方法でインフラストラクチャ API を組み合わせることができます。
  3. Istio API は柔軟であるべきです。組織内では、基盤となるリソースの異なる表現を持ち、各チームにとって意味のあるものを提示することが可能です。

今後数回のリリースで、Istio の API と Istio ユーザーの役割との整合性を強化する取り組みの進捗状況をお知らせします。

コンポーザビリティと抽象化

Istio と Kubernetes はしばしば一緒に使用されますが、Istio は Kubernetes のアドオン以上のものです。Istio は Kubernetes と同様に *プラットフォーム*でもあります。Istio はインフラストラクチャを提供し、強力なサービスメッシュに必要な機能を提供することを目指しています。たとえば、Kubernetes を基盤として使用し、Kubernetes のコンポーザビリティを基にアプリケーション開発者向けの API のサブセットを提供するプラットフォーム・アズ・ア・サービスのオファリングがあります。

アプリケーションをデプロイするために設定する必要があるオブジェクトの数は、Kubernetes のコンポーザビリティの具体的な例です。私たちの集計によると、少なくとも 10 個のオブジェクトを設定する必要があります。`Namespace`、`Service`、`Ingress`、`Deployment`、`HorizontalPodAutoscaler`、`Secret`、`ConfigMap`、`RBAC`、`PodDisruptionBudget`、`NetworkPolicy`です。

複雑に聞こえますが、誰もがこれらの概念と対話する必要はありません。一部は、クラスター、ネットワーク、またはセキュリティ管理チームなどの異なるチームの責任であり、多くは適切なデフォルトを提供します。クラウドネイティブプラットフォームとデプロイメントツールの大きな利点は、少量の情報を受け入れてこれらのオブジェクトを設定することで、その複雑さを隠すことができることです。

ネットワーキング分野におけるコンポーザビリティのもう1つの例は、Google Cloud HTTP(S) ロードバランサー (GCLB) に見られます。GCLB のインスタンスを正しく使用するには、6 つの異なるインフラストラクチャオブジェクトを作成して設定する必要があります。この設計は、分散システムの 20 年間の経験の結果であり、それぞれが互いに異なる理由があります。しかし、Google Cloud コンソールを使用してインスタンスを作成する場合は、手順が簡素化されます。より一般的なエンドユーザー/役割固有の設定を提供し、後からあまり一般的ではない設定を設定できます。最終的に、インフラストラクチャ API の目標は、機能を犠牲にすることなく最大の柔軟性を提供することです。

Knative は、サーバーレスワークロードの構築、実行、運用のためのプラットフォームであり、役割中心のより高度な API の優れた実世界の例を提供します。Knative Serving は、Kubernetes と Istio を基盤としてサーバーレスアプリケーションと関数のデプロイとサービス提供をサポートする Knative のコンポーネントであり、アプリケーション開発者がサービスのルートとリビジョンを管理するためのオピニオン化されたワークフローを提供します。そのオピニオン化されたアプローチのおかげで、Knative Serving は、リビジョンとトラフィックルーティングをサポートする簡素化されたRoutesオブジェクトを介して、アプリケーション開発者に最も関連性の高い Istio のネットワーキング API のサブセットを公開し、Istio の`VirtualService`と`DestinationRule`リソースを抽象化します。

Istio が成熟するにつれて、本番環境のユーザーが Istio のインフラストラクチャ API の上に、ワークロードと組織固有の抽象化を開発する様子も見られました。

AutoTrader UK は、Istio 上に構築されたカスタムプラットフォームのお気に入りの例の1つです。Google の Kubernetes Podcast のインタビューで、Russel Warman と Karl Stoney は、Prometheus と Grafana を使用したコストダッシュボードを備えた、Kubernetes ベースのデリバリープラットフォームについて説明しています。最小限の労力で、開発者がネットワークで設定したいものを決定するための設定オプションを追加し、それが実現するために必要な Istio オブジェクトを管理するようになりました。エンタープライズ企業やクラウドネイティブ企業では、他にも無数のプラットフォームが構築されています。一部は企業固有のカスタムスクリプトのウェブを置き換えることを目的としており、一部は汎用的なパブリックツールを目指しています。より多くの企業がツールについて公に話し始めるにつれて、彼らの話をこのブログに掲載していきます。

今後の展開

今後のリリースに向けて取り組んでいる改善点の一部を以下に示します。

そして、何らかの理由でツールボックスをインストールする CRD のリストで判断する場合、Istio 1.2 では、その数を 54 から 23 に削減しました。なぜですか？多くの機能がある場合、それらをすべて設定する方法が必要になります。インストーラーを改善したことで、アダプターで動作する設定を使用して Istio をインストールできるようになりました。

すべてのサービスメッシュ、そして Istio も、ネットワーキングやセキュリティなどの複雑なインフラストラクチャ操作を自動化することを目指しています。つまり、API には常に複雑さが存在しますが、Istio は常にオペレーターのニーズを解決することを目指すと同時に、堅牢なビルディングブロックを提供し、役割中心の抽象化による柔軟性を優先して API を進化させ続けます。

Istio を使用して次に何を構築するか、ぜひ私たちのコミュニティに参加して見てください！

この投稿を共有する