re:Invent 2024: AWSが提案するKubernetes APIベースのインフラ管理
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Infrastructure as Kubernetes APIs (OPN312)
この動画では、組織のDevOpsプラットフォーム進化について、AWSのSolutions ArchitectであるChristine Andinoが解説しています。Culture、Technology、Processという3つの組織変革のレバーの中で、最も変更が困難なCultureに焦点を当て、エンジニアリング組織での課題を指摘します。その解決策として、ACKとCrossplaneを組み合わせたKubernetes APIベースのインフラストラクチャ管理を提案しています。ACKには50のGAコントローラーが実装済みで、CrossplaneのResource Group機能と組み合わせることで、開発者に統一されたプラットフォームを提供できます。デモを通じて、S3バケット、IAMロール、Pod Identityなど複数のリソースを一元管理する実例も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
組織変革の3つのレバーとDevOpsプラットフォームの進化
組織を方向づけたい時、経営者が持っているレバーは、Culture（文化）、Technology（技術）、Process（プロセス）の3つです。この3つの中で、おそらくTechnologyが最も変更しやすく、Processは中程度の難しさで、「ここではこうやる」という文化であるCultureが最も変更が困難です。もし、人類の中でも最も意見の強い生き物であるエンジニアで構成されたエンジニアリング組織を任されている場合、Cultureの変更は特に困難を極めます。
皆さん、こんにちは。Christine Andinoと申します。AWSのSolutions Architectとして、組織のDevOpsプラットフォームの進化をサポートする仕事をしています。今日は、将来のバランスの取れた組織変革を実現するために、DevOpsプラットフォームをどのように進化させていけばよいかについてお話しします。まず、バランスの取れていない組織変革とは何かについてお話ししましょう。それは3つのレバーすべてを最大限に引く時のことで、皆さんは過去にそのような変革を経験されているはずなので、どんな感じなのかご存知でしょう。
複雑化するクラウドインフラと開発者体験の課題
クラウドへの移行時に、このような変革を経験されたことでしょう。おそらく少数のチームから始めて、AWSコンソールへのアクセス権を与え、EC2インスタンスを素早く作成していました。しかしすぐに、SecurityとComplianceの部門が介入して、開発者にAWSコンソールへのアクセスを許可できないと言い出しました。その後、コンテナへの移行を始め、EKSプラットフォームやECSプラットフォームを導入しましたが、大規模組織の多くはまだオンプレミスを保持しています。企業買収などで新しい会社が加わると、その会社は独自のプラットフォーム（おそらくServerless）を持ち込みます。そして過去5～10年のAI/MLの台頭により、今ではDataプラットフォームも加わっています。
これは私たちのお客様が直面している状況を非常に単純化したものです。平均して7～8個の異なるプラットフォームを管理しています。そして皆さんは何をするでしょうか？これを見て、「一度に全て解決しよう、集中型のプラットフォームチームを設置しよう」と考えます。集中型プラットフォームチームは集まって、複数のクラウドで動作し、すでにオンプレミスでも動いているかもしれず、ECSプラットフォームも比較的移行しやすいということで、Kubernetesに標準化することを決めます。でも、Lambdaは？MLプラットフォームは？
仮にランタイムを標準化して全員を移行できたとしても、開発者の体験という観点から見て、そのプラットフォームは将来的にどのような姿になるのでしょうか？将来の状態で、開発者がマイクロサービスとそのデータベースを作成する場合のワークフローについて考えてみましょう。通常、彼らはいくつかのパイプラインを呼び出し、ネットワーキングパイプラインを実行して、そのパイプラインの出力からセキュリティグループIDやVPC IDなどを取得し、それをデータパイプラインに渡します。うまくいけば、セキュリティチームがデータベースチームと協力して、そのパイプラインがRDSデータベースを提供するだけでなく、そのデータベースにアクセスするための認証情報も提供してくれるでしょう。
開発者はその後、RDSのエンドポイントとSecretを取得してKubernetesのパイプラインに渡し、うまくいけば最初の試みで全てが動作して、マイクロサービスがデータベースにアクセスできるようになります。でも、その開発者は次に何をするかご存知ですか？ 数時間もデータベースを見守って待つことになるんです。なぜなら、コンプライアンスチームがそのアカウントでコンプライアンスチェックを継続的に行っており、データベースの設定のどれか1つでもコンプライアンス要件に合わないと判断されれば、そのデータベースは消されてしまうからです。
ここで一歩下がって、これらのパイプラインについて考えてみましょう。なぜこのような状況に陥っているのでしょうか？まず、パイプラインには組み合わせ性がありません。あるパイプラインの出力を別のパイプラインに渡すための標準的な仕組みがないのです。また、自己修復機能もありません。パイプラインが失敗した場合、開発者としては再実行するしかなく、次にすべきことは、パイプラインを作成した担当者とミーティングを設定するか、チケットを発行することです。さらに、パイプラインには単一の信頼できる情報源がありません。Terraformにはステート管理があると言えるかもしれませんが、それはパイプラインの状態であって、データベースの状態ではありません。つまり、データベースパイプラインがデータベースを作成し、コンプライアンスパイプラインがそれを削除した場合、私の信頼できる情報源はどこにあるのでしょうか？私が知りたいのは、データベースが稼働しているかどうかであって、パイプラインの状態ではありません。
これが1つのマイクロサービスと1つのデータベースだけなら、開発者は半日程度で全てを動作させることができるでしょう。何も移行する必要がない場合や、めったにこの作業をする必要がない場合は、それでも問題ありません。しかし、新しいリージョンに展開して全てのアプリケーションをデプロイしなければならない場合、それは開発チーム全員が数ヶ月かかりきりになる作業です。メインフレームをAWSに移行する場合はどうでしょうか？開発者の作業時間はどれくらいかかるでしょうか？新しい単位が必要かもしれません - 開発者の人生何人分くらいかかると思いますか？
このアプローチに投資し続けることもできます。シェルスクリプトやカスタムコードで全てを繋ぎ合わせることもできます。しかし、そもそもパイプラインは正しいアプローチなのでしょうか？代わりに、組み合わせ可能で自己修復機能があり、状態を提供してくれるAPIのようなものを使うべきではないでしょうか？結局のところ、インターネット全体がAPIで動いているのです。AWSアカウントを開設する際、4つのパイプラインを呼び出すわけではありません。APIを呼び出せば、そのAPIがアカウントを提供してくれます。クレジットカード番号の入力ミスなどのエラーがあれば、正しく入力するように指示してくれます。私たちはこのAPIを何年もかけて何度も変更してきましたが、UIを変更しない限り、ユーザーは気付きもしませんでした。
KubernetesとACKによるインフラストラクチャAPI化への挑戦
なぜインフラストラクチャを作成するための開発者向けインターフェースとしてAPIを使用しないのでしょうか？開発者がHTTP APIを作成しようとする場合、どのプログラミング言語にも少なくとも5つのフレームワークがありますが、クラウドインフラストラクチャに関してはAPIのためのフレームワークがありません。約5年前、Kubernetes 1.16でCRD（Custom Resource Definitions）がGAになり、いくつかの大規模組織がこれをAPIのフレームワークとして使えないかと考えました。CRDはRBACを提供してくれるので、権限を一から作る必要がありません。また、reconciliationループやメカニズムも最初から備わっており、実際にこれを成功裏に活用している顧客も何社かあります。
しかし、これは非常に難しいことが分かってきました。その難しさは技術そのものというよりも、その技術を作る人々に関係しています。Platform Engineerの大多数は、大規模なコードの運用方法を知っていて、オープンソースプロジェクトの運用方法を知っていて、TerraformやCloudFormationなどのInfrastructure as Codeツールの運用方法も知っています。でも、カスタムControllerを書くのは彼らの得意分野ではありません。一方、Developerはその正反対で、一日中コードを書くことを楽しみ、日々の仕事としてTerraformのテストやTerraformパイプラインのトラブルシューティングをするわけではありません。もちろん「でもChristina、Controllerを書くPlatform Engineerや、Terraformが大好きなDeveloperもいるじゃないか」と言われるでしょう。
はい、そういう人たちは確かに存在しますが、非常に少数です。そして、彼らがこのプラットフォームを作ったとしても、誰かがそれをサポートしなければなりません。大多数のPlatform Engineerがそれをサポートしなければならないのです。このことを約4年前に認識したAWSは、ACK（AWS Controllers for Kubernetes）というオープンソースプロジェクトを作りました。誰もがS3 Bucketを必要とし、誰もがRDS Databaseを必要とするので、私たちはこれらのControllerを作ることにしたのです。
このプロジェクトでは、各サービスが独自のControllerを持つという決定など、いくつかの正しい選択をしました。S3サービスにはS3 Controller、RDSサービスにはRDS Controllerというように。当時、AWS内の各サービスチームが自分たちのControllerの面倒を見ることも決めました。しかし、これはうまくいきませんでした。つまり、一部のControllerは非常によくメンテナンスされていた一方で、他のControllerは担当チームの人員の異動やビジネスの優先順位の影響を受けて苦労していました。今年初め、これを認識したCareサービスチームが全てのControllerの所有権を引き継ぎ、現在では50のControllerがあります。昨日時点で全50個がGAとなり、GAとは皆さんにとってEnterprise Supportの対象となることを意味します。
サービスとそのデータベースをデプロイするためにACKを使用する場合、おそらくこれらのControllerのいくつかをインストールすることになります。この場合、S3、EKS Controller - これはPod Identityの設定に必要で、IAM Controllerも必要です。これによってS3 Bucket Policyを作成し、これらすべてを接続するためのAPIが提供されます。しかし、これだけでは十分ではないため、さらに別の構成要素が必要です。これらのリソースを組み合わせ、開発者から複雑さを抽象化する方法が必要です。リソース間で論理演算を行い、文字列やARNをリソース間で受け渡し、条件分岐を設定する必要があります。これはある程度までしかできず、その代替案はカスタムControllerを書くことですが、先ほど話したように、それは完全にユニコーンビジネスです。
かなり時間が経ちました。ここで何か良いものが必要だと思いませんか？私はそう思います。私たちはCrossplaneというオープンソースプロジェクトに取り組んでいます。これはKubernetesリソースのための万能な接着剤として機能します。私は、Crossplaneが、開発者インターフェースのためにKubernetesリソースモデルを活用してプラットフォームを構築するための、最後の欠けているピースだと考えています。これが開発者インターフェースで、彼らが通常アプリケーションのデプロイに使用するもので、彼らはそれにとても満足しています。Crossplaneを使用すれば、S3を有効にするだけで - S3 Bucketの背後にある複雑さを知る必要はなく、単にS3 Bucketを提供してもらえばいいのです。
Platform Teamのインターフェースについて説明しますと、Platform Teamができることは、クラスターにCrossplaneをインストールすることです。Crossplaneをインストールすると、クラスター内にResource Groupと呼ばれる1つのCRDが提供されます。このResource Groupを使用することで、これらの構成要素をグループ化し、複雑さを抽象化し、値を渡し、クラスター内で利用可能な任意のAPIに対して論理的な操作を実行することができます。先ほど申し上げたように、Crossplaneをインストールすると、Resource Group APIが提供されます。つまり、今やResource Group APIを手に入れ、さらに上位レベルでResource Groupをグループ化することもできるのです。
ここでCrowのデモをお見せする時が来たと思います。今年の初め、私は会議で彼と初めて対面で会い、この話をし始めました。会議の廊下で4時間も話し込み、私はとても興奮しました。まるでお菓子屋さんに来た子供のような気分でした。そして、Crowの作者であり、コアメンテナーの一人から、皆さんにもその同じ喜びを体験していただきたいと思います。
Crowを活用したカスタムアプリケーション管理のデモンストレーション
私の名前はAminで、EKSサービスチームのソフトウェアエンジニアです。これからCrowのライブデモを行いますので、何か問題が発生するかもしれませんが、その場合は途中で修正していきます。通常、Kubernetesでアプリケーションをデプロイする場合、Deployment、Service、そして外部に公開するためのIngressを作成する必要があります。私のアプリケーションの基本ファイルを見てみましょう。このようにDeploymentを作成し、Serviceと、Ingressを作成します。これらのリソースを本当にグループ化したい場合、いくつかの方法があります。テンプレート化にHelmを使用する方法や、Kustomizeのようなものを使用する方法があります。さらに勇気がある方は、自分でコントローラーを作成してこのような作業を行うこともできます。
クラスター内でそれらのリソース、つまりCRDを公開することは完全に可能です。あるいは、Crowを使用することもできます。今日は、Helm、Kustomize、または独自のコントローラーを作成することなく、カスタムアプリケーションを管理するコントローラーとしてCrowを設定する方法をお見せします。これら3つのリソースを持つために、ユーザーが何をデプロイする必要があるのか見てみましょう。ユーザーはWeb Appを作成する必要があり、必要なのは名前、ポート、Ingress、そしておそらくデフォルトのイメージ（ここではXとします）を提供することだけです。CrowにCRDの提供を開始するよう指示するために必要なことは、Web Appと呼ばれるCRDを作成し、バックグラウンドでアプリケーションの提供を開始するように設定するYAMLファイルを送信することだけです。
この場合、必要なのはResource Groupと呼ばれるものを作成することだけです。Resource GroupはKubernetesの単なる別のCRDで、新しいオブジェクトの監視とバックグラウンドでのアプリケーション管理を開始するようCrowを設定するためのエントリーポイントです。非常に簡単です。バックグラウンドで行うことは2つだけです。1つ目は、CRDを管理させることです。ここでは、v1alpha1のCRDが必要で、kindをWeb Appにしたいと指定できます。Kubernetesに詳しい方なら、OpenAPIスキーマという概念をご存知でしょう。コントローラーを構築する際は、それらのCRDをOpenAPIスキーマで定義する必要があります。これは正確にOpenAPIスキーマですが、より軽量で単純な方法です。ここでは、ユーザーに名前、ネームスペース、イメージ、ポート、そしてIngressやServiceを有効にするかどうかを提供してもらいたいということがわかります。ここで見ているのはCEL式（Common Expression Language）で、最近APIサーバーに導入されました。これはJSONPathに非常によく似た、ポータブルで安全なセキュアな言語です。
Kroに対して、ユーザーにいくつかのフィールドや情報をパブリッシュバックするよう指示を出したいと思います。ユーザーがWebアプリを見たときに、デプロイメントの状態、利用可能なレプリカ数、ホスト名を確認できるようにしたいのです。Webhook検証アドミッションポリシーやミューテーションアドミッションポリシーに詳しい方なら、このコンテキストでのCEL式の使用についてご存じでしょう。
このCRDを特定の形式で管理するようKroに指示したので、Webアプリを見かけたらデプロイメントを作成するように指示することができます。同じCEL言語を使用して、ユーザー入力のspec.nameを取得し、デプロイメント名に注入することができます。レプリカについても同様に、ユーザーのspec.replicasをデプロイメントで使用するよう指示できます。これは画像やポートにも適用でき、S3バケットがある場合は、S3バケット名をデプロイメントコンテナの環境変数として注入することもできます。
デプロイメントができたので、次はServiceが必要です。通常、Kubernetesでサービスを作成する際には、Selectorも必要になります。デプロイメントが持つラベルと同じものを指すSelectorを作成できます。Ingressを作成する際には興味深い点があります。というのも、Ingressを間違ったServiceに向けたくはありませんよね。KroにServiceのメタデータ名を取得させ、それをIngressのServiceに注入するよう指示します。裏側では、IngressがServiceに依存していることをKroに伝えているのです。この2つには依存関係があるため、Kroはこの関係を理解し、まずServiceを作成し、特定の状態になるのを待ってからIngressを作成する必要があることを理解します。
これだけで、Kroに2つのリソースを一緒に管理させる、つまり1つのユニットとしてグループ化するよう指示することができます。リソースグループを確認してみましょう。このリソースグループの名前を見てみましょう。これはwebapp.kro.runになります。get resource groupsを実行すると、Kroが活性状態でwebapp v1alpha1 CRDを管理していることがわかります。また、トポロジカルな順序も示してくれます。リソースをどのような順序で作成すべきかをよく理解しており、場合によってはあなたが提供した順序とは全く異なる場合もあります。Ingressから始めてDeploymentで終わるような場合でも、それが適切な順序ではないことを理解して修正してくれます。
Kroが管理しているCRD、例えばwebappという名前のものを見てみましょう。Kroによって作成され管理されているCRDが存在することがわかります。その内部を調べてみると、CRDを管理する際に通常見られる多くのフィールドがあることがわかります。これは、このようなものを作成するために提供する必要がある元のOpenAPI仕様です。Kroでは、これを非常にシンプルな方法で行っており、裏側ではやはりOpenAPIスキーマとなっています。リソースグループが登録されたので、あとはこのようなものを送信するだけで、Kroが裏側でDeploymentとServiceを作成し、ここにあるtest appとポート80を使用します。さらに一歩進んで、S3バケットやデータベース、あるいはAWS上の何かが必要な場合はどうでしょうか？ACKのようなコントローラーを使用して、次のようなことができます。
例えば、AWSのS3バケットは非常に簡単に管理できます。この例では、AWS RDというバケットがあり、コントローラーがこれを処理して、ステータスでは「3つのRをインスタンスにパブリッシュしてほしい」というように指定できます。また、自分のIAMロールも確認できます。S3バケットと同様に、ACKにIAMポリシーの作成を指示することもできます。CloudFormationでの操作と非常によく似ていて、名前とポリシードキュメントを指定するだけです。
Pod Identityも作成できます。Pod Identityについてご存知の方もいると思いますが、これは昨年EKSが公開した新しいAPIで、Podに対するIAMパーミッションや認証情報を非常にスムーズに設定できるようにするものです。この場合、CrossplaneにPod Identityという新しい抽象化があることを指示します。これは内部的には、IAMロールの作成、Pod Identity関連付けの作成、サービスアカウントの作成を行います。これらの処理をユーザーから抽象化し、デプロイメント、サービス、イングレス、Pod Identity、バケット、IAMロールなど、すべてを1つのスタックにまとめてWebスタックと呼ぶことができます。
ここでWebスタックのリソースグループを見てみましょう。内部的には、先ほど定義したWebアププ、少し前に示したPod Identity、そしてIAMロールなどを内部的に作成するS3バケットを使用していることがわかります。私たちが行ったのは、多くのリソースの作成をCrossplaneに指示することです。トポロジカルな順序を見ると、Crossplaneが各リソースの扱い方を非常によく理解していることがわかります。
このWebスタックのインスタンスを1つ作成してみましょう。作成には時間がかかるかもしれませんし、うまくいかないかもしれませんが、試してみましょう。うまくいかない場合は、すでに用意してあるものをお見せします。ユーザーとしてこれらすべてを作成するために必要なのは、Webスタックインスタンスをリクエストすることだけです。イメージと名前、S3バケット、サービス、イングレスが必要かどうかを指定するだけで、他のすべてはCrossplaneが処理します。これは新しいデモなので、Crossplaneが同じリソースとして扱ってしまうため、インスタンスの名前を変更する必要があります。この場合、「this is rain advanced app two」としましょう。これで必要なものはすべて揃いました。
このインスタンスを適用してみましょう。新しいCRができ、Crossplaneはすでにこれらのリソースすべてを監視するように設定されており、相互に接続された多くの他のリソースに展開されていきます。最終的に、ここでお見せできるAPIエンドポイントが見えるはずです。Webスタックを表示すると、エラーが出ていますが、これは良いことです。なぜなら、Crossplaneが内部でエラーがあることを認識するからです。これはコントローラーなので、継続的に調整を行います。これが特定の概念で、エラーを確認し、Crossplaneが最善を尽くしてすべてを結びつけ、正常に動作するようにします。
何が起きているか見てみましょう。S3バケットがあるかどうか確認してみましょう。kubectl get bucketsを実行すると、51秒前に作成された新しいバケットが表示されます。IAMロールを確認すると、awesomeタグが付いた新しいIAMロールが見えます。そして、Pod Identity Associationを確認すると、新しいものが表示されるはずです。これは、Crossplaneがすべてのリソースのデプロイメントを進めている証です。
Podが作成されたので、Ingressを見てみましょう。新しいIngressとエンドポイントがあります。Crossplaneは、APIの遅延や何かが正しく接続されていないなど、問題が発生したことに気付いた後、修正を行いました。すべてが完全に同期されるまで再試行を続け、私たちのためにIngressエンドポイントを提供してくれました。
エンドポイントを見つけるためにIngressを確認する必要はありません。Web Stackを確認するだけでいいのです。Web Stackのステータスを見ると、CrossplaneがこのURLを私に公開し、Web Stackのデプロイメント状態やS3バケットのARNを教えてくれます。これをブラウザで開いてみても、まだ伝播していません。そのため、このセッションの前にアプリケーションをデプロイしようとしたのです。少し時間がかかるからです。
最初のアプリのエンドポイントを見てみましょう。HTTPSのURLです。古いALBエンドポイントはセッションの前にプロビジョニングされており、EKSクラスターに作成されたアプリケーションが表示されています。裏側では、ファイルをアップロードできるS3バケットがあります。「re:Inventはすごい」と入力して追加すると、S3バケットに追加されます。これは、Crossplaneが裏側で多くのリソースのフローをオーケストレーションできることを示すデモです。
なぜこれを使うのでしょうか？私たちはみんなGitOpsが大好きで、CRDやAPIの構築、CLIの使用も大好きです。使うのはとても楽しいものです。Crossplaneを使うと、多くの機能がすぐに使えます。例えば、RBACやネームスペースの分離などです。これらすべてはKubernetesエコシステムの一部として、Crossplaneでスムーズに動作します。ここで足りないのは、おそらくkubectlプラグインですが、これは現在開発中で、今週リリースされる予定です。
私たちが持っているのは、kubectl プラグインとしての Crossplane CLI です。これを使えば、実行中のすべてのインスタンスを確認できるだけでなく、Crossplane はインスタンスの存在だけでなく、すべてのサブリソースも表示してくれます。re:Invent アプリ、S3 バケット、IAM アイデンティティ、Web アプリなどが確認できます。S3 バケットの中身をより詳しく見ることもでき、その中には S3 バケットと IAM ポリシーという2つのリソースがあることがわかります。
これらのリソースが見えるようになったら、他に何ができるでしょうか？特定のリソースグループに対して、非常に制限された RBAC が必要かもしれません。クラスター内のあらゆるものを管理する権限を Crossplane に与えることは避けたいものです。本当に必要なのは、リソースグループの管理に限定することです。Crossplane CLI を使えば、「generate RBAC」のような簡単なコマンドで RBAC を生成できます。この場合、私のリソースグループで、Crossplane は Web スタックアプリケーションの管理に必要なものを直接教えてくれます。S3 バケットへのアクセス、IAM アイデンティティ、Web アプリ、そしてそれらのアプリケーションを管理するために必要なすべての動詞が必要になります。S3 バケットでも同じことができます。
S3 バケットの管理については、Crossplane はこれらのリソースを管理するために IAM アクセスと S3 アクセスが必要だと教えてくれます。他に何を生成できるでしょうか？開発者やプラットフォームチームがリソースグループを作成する際に、インスタンスの生成に時間をかけたくない場合、Crossplane にエミュレートしてもらうことができます。例えば、インスタンスの生成をリクエストすると、インスタンスがどのように見えるべきかを教えてくれます。kind、name、namespace、リソースを持つ名前を提供してくれるので、すべてを一から作成する必要はありません。フードの下にあるすべての例を見ることができます。
Crossplane が RBAC とインスタンスを管理するためのマニフェストの生成を手伝ってくれるようになったので、これらのリソースグループを ECR に置いて全チームに配布したり、アプリケーション作成の標準的な方法として使用したりできれば素晴らしいですよね。これは最近私たちが行ったことです。Helm コマンドラインを使用するのと同様に、Helm で認証したいときのようなことができます。このデモでは、私の個人的な AWS アカウントを使用して、Helm で AWS ECR get login を実行するのと非常によく似た方法で、この ECR URL に Crossplane を認証しようとしています。
Crossplane のログインができたら、リソースグループをパッケージ化できます。web stack リソースグループを web stack.tar にパッケージ化してみましょう。web stack.tar が作成されるのが確認できます。フードの下では、これは ECR に保存できる OCI 準拠のイメージです。つまり、リソースグループを tar ファイルに入れて、ECR で公開し、チームに配布できるようになりました。プラットフォーム管理者として ECR に公開したい場合、この URL を使うだけです。go run を実行してみましょう。これが私の tar ボール、これが URL です。タグ v1 で Crossplane publish を実行し、ファイルは web stack tar になります。dev という名前のものがあったと思います。これが初めて web stack をパッケージ化するところなので、まさにライブデモをご覧いただいています。
ご覧の通り、CrossplaneはこのTarボールをECRにプッシュしました。ECR describe imagesを実行すると、my devパス上にv1タグがあることが確認できます。これらのイメージをローカルにプルする代わりに、Crossplaneのインストールを実行できます。Kubernetesエコシステムの他のツールと同様に、このv1リソースグループを簡単にインストールできます。まず、web stackリソースグループが存在しないことを確認しましょう。これを実行すると、Crossplaneがクラスターにリソースグループを正常にインストールしたことがわかります。get resource groupsを実行すると、5秒前にインストールされたことが確認できます。このように、コントローラーを取得するだけでなく、リソースグループを管理し、チームに配布するためのCLIも取得でき、KubernetesエコシステムとCrossplaneエコシステムの優れた機能をすべて活用できます。
CrossplaneとACKの今後の展望と開発者への呼びかけ
Crossplaneの機能と、お客様が期待する使用パターンについて理解したところで、チームごとにKubernetesクラスターを使用する場合、チームがKubernetesクラスターを作成するためのAPIを提供したいというニーズが明確に聞こえてきました。これは、管理クラスター内にインストールされたACKとCrossplaneを組み合わせることで、他のEKSクラスターを作成することができます。これは非常に簡略化された図です。例では、VPCやネットワーク、EKSクラスターを含む例があり、まもなく、これらのEKSクラスターをArgo CDに接続し戻す方法や、Argo CDがそれらのクラスターにWeb Stackをデプロイできるように管理クラスター内にシークレットを作成する方法についても紹介する予定です。
アプリケーションのデプロイについては、集中管理されたArgo CD、Crossplane、ACKを推奨しています。これは組織の構造によって異なります。アカウントごとにクラスターを作成しない組織もあれば、クラスターのないアカウントを各チームに提供する場合もあることを認識しています。組織の構造に応じて、これらを組み合わせて、インストールと管理の最適な方法を見つけることができます。ただし、Crossplaneはわずか2週間前にオープンソース化されたばかりで、まだ活発に開発が進められています。そのリソースグループAPIはアルファAPIであり、本番環境でアルファAPIを使用すると、予期せぬ副作用が発生する可能性があることを警告しておきます。具体的には、事前の通知なしに機能が突然消失したり、午前3時のデバッグ過剰摂取、開発チームの忍耐力の喪失、あるいはランダムにすべてを書き直す必要が生じたりする可能性があります - 注意して進めてください。事前にセラピストまたはローカルサポートグループに相談することをお勧めします。
なぜこのように言うのでしょうか？今日から始められることは何でしょうか？プラットフォームの構築とこれらのAPIの構築には時間がかかることを私たちは理解しています。先ほど述べたように、ACKには50のGAコントローラーがあります。50のコントローラーは通常、Kubernetesプラットフォームに必要なものの大部分をカバーしており、GAであるため、ACKの構築から始めることができます。Crossplaneについては、活発な開発中であるため、試用してフィードバックを提供し、GitHubで関与し、CNCF SlackのCrossplaneチャンネルに参加していただきたいと考えています。これらのAPIを実装すると、技術は変更しますが開発者インターフェースは変更しないため、組織にとってはある程度バランスの取れた変更となり、開発者の採用はある程度保証されます。
Kubernetes APIとしてのインフラストラクチャを使用してプラットフォームの基盤を構築し、そこに到達して開発者全員に統一されたプラットフォームを提供できたら、このAPIの新しい世界でランタイムの拡張を考え始めることができます。CrossplaneとACKで見たように、プログラミングは必要なく、インフラストラクチャをコードとして記述するだけで済むため、あらゆるプラットフォームエンジニアのスキルセットに対応できます。開発者と協力して、彼らが望むインターフェースを提供することが重要です。また、すべてのユニコーン企業の皆様にCrossplaneとACKの開発に参加し、オープンソースに貢献していただきたいと考えています。APIに移行すれば、プラットフォームでこのようなことが可能になります。セッションリソースをご確認ください。このスライドをしばらく表示させていただきます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion