プラットフォーム・アズ・コードの未来はKubernetes拡張機能

翻訳者 |李睿

校正：孫淑娟

コードとしてのインフラストラクチャ: その起源

近年、Docker の登場とコンテナの人気の高まりにより、Infrastructure as Code (IaC) の概念が拡大しました。 Infrastructure as Code (IaC) は、仮想マシン、ネットワーク、ストレージなどの特定のインフラストラクチャに接続するための API として始まり、徐々にオペレーティング システムや Kubernetes、およびそれらの構成と強化ポリシーを含むように拡張されました。 Terraform などの Infrastructure as Code (IaC) ツールを見ると、ワークロードのデプロイメントもサポートされています。

変わっていないのは、そもそもなぜ人々が「as code」に興奮したのかということです。結局のところ、ソフトウェア開発で使用される使い慣れたツール (エディター、CI/CD など) とプロセス (コードレビュー、バージョン管理など) を、記述的、反復可能、共有可能、そして何よりも自動化しながら下位層に適用することになります。

プラットフォーム・アズ・コード: 今後の方向性

次のステップは、このコンセプトとその利点を、開発者が利用できるプラットフォームに拡張することです。目標は、Platform as a Service (PaaS) に似たシステムを構築し、インフラストラクチャを抽象化してエンジニアがコードに集中できるようにすることです。理想的には、PaaS システムは、開発者の手を煩わせることのないセルフサービス、共通のベスト プラクティスの標準化と共有、ある種のセキュリティと強制のコンプライアンスなどの利点を提供します。

ただし、一般的な PaaS システムには、回避すべき共通の落とし穴がいくつかあります。

まず、PaaS の抽象化によって人為的な制限が生じることが多く、ソフトウェアと開発者が成長し成熟するにつれて、さらに多くの制限が発生します。現在、従来の、またはクローズドな PaaS システムの場合、これは異常をもたらし、不適切なソリューションとしてモデル化されます。第二に、従来の PaaS ではベンダー ロックインの率が高くなります。 3 番目に、あまり一般的ではない質問をする必要があります。1 つのプラットフォームを採用するだけで本当に十分なのでしょうか?データ サイエンス エンジニアは、e コマース チームと同じプラットフォームを使用する必要がありますか?

Kubernetesは

「Kubernetes はプラットフォームを構築するためのプラットフォームです。」 Kelsey Hightower や Joe Beda のような Kubernetes の思想的リーダーに詳しい、または知っている人は、彼らがこの発言をしているのを聞いたことがあるかもしれません。

同様に、Kubernetes は実際にはコンテナ以外の用途でもプラットフォームとして選ばれる可能性があると示唆されています。実際、これが、人々が思い描くプラットフォーム・アズ・コードという理想を最終的に実現するために必要な唯一のものなのかもしれません。

Kubernetes の利点 (オーケストレーターや統合インターフェースであることなど) がこの議論の基礎となります。オーケストレーターとしての Kubernetes は、より強力な宣言型パラダイムと考えることができる、オーケストレーションへの効果的なアプローチをもたらします。これにより、運用知識をエンコードすることが可能になり、その知識を何らかの形式のスクリプトに組み込むよりも、より回復力があり、将来性も高まります。さらに、状態ベースのストレージは、一般的な IaC ツールのストレージと状態の典型的な欠点です。

Kubernetes は、統一されたインターフェースとして、認証、レート制限、監査機能が組み込まれた共通 API をユーザーに提供します。さらに、API はクラウドネイティブのワークロード管理の標準となり、ネイティブの拡張性により、Kubernetes API に精通していることが API 拡張につながります。近年の Kubernetes の成功と人気により、継続的インテグレーション (CI)/継続的デリバリー (CD) の従来の IaC から最新の GitOps アプローチまでのツールが広く支持されるようになりました。

最後に、多くの企業がさまざまなユースケースに合わせて API を拡張しており、クラスター、アプリケーション、インフラストラクチャ サービスを定義するための共通の抽象化に関して Kubernetes 内で初めての合意に達しました。

Kubernetes プラットフォームの構成要素 — コンテナ オーケストレーションを超えて

まず、1.0 で本番環境対応になっている Cluster API プロジェクトがあります。初心者のために説明すると、Cluster API は、あらゆるインフラストラクチャ上の Kubernetes クラスターのライフサイクルを宣言的に管理するためのコンセンサス API のアップストリームの取り組みです。これが単なる単純な API のように思われる場合でも、ハイパースケーラーや一般的なオンプレミス ソリューションを含む多くのインフラストラクチャ プロバイダーでクラスターを生成するための、この API の実用的な実装が含まれているので安心してください。

クラスターを調べた後、次のステップは、そのクラスター内のアプリケーションとワークロードを調べることです。完全に機能するクラウド ネイティブ プラットフォームを実現するには、基本的な可観測性ツール、接続ツール、開発者パイプラインを構成するツール、さらには追加のセキュリティ ツールやサービス メッシュも採用する必要があります。現在、コミュニティとして、私たちは少なくとも Helm をユニバーサル パッケージ形式として同意することができます。ただし、これらの Helm チャートを実際にクラスターにデプロイする方法、特にマルチクラスター環境 (クラスター管理が容易になるにつれて一般的になりつつあります) については、依然としてコンセンサスが得られていない領域です。企業がすでに GitOps の波に乗っている場合、FluxCD などのツールには HelmRelease などの抽象化機能があり、それが役立ちます。 GiantSwarm は、Helm を拡張し、マルチクラスター機能と構成のマルチレベルオーバーライドを追加した app-operator というオープンソースの Kubernetes 拡張機能を開発しました。これにより、アプリケーションのクラスターをクラスターにデプロイするユースケースでの構成管理の負担が軽減されます。また、テスト結果や互換性情報など、展開プロセス中にさらに多くのメタデータを含めることもできます。

無視できないもう 1 つの種類のリソースは、クラウド コンピューティング プロバイダーのサービスです。ここでは、ハイパースケール開発者のほとんどが、いわゆるファーストパーティ リソースを生成する独自のネイティブ Kubernetes 拡張機能を開発していることがわかります。ファーストパーティ リソースとは、クラウド ネイティブ ワークロードから接続できる、Kubernetes 内で直接管理されるデータベースのようなものです。もう 1 つの非常に興味深いアプローチは、Crossplane です。これは、ユーザーが同じ拡張機能を通じて複数のベンダーのサービスを組み立てることを可能にするオープンソースの Kubernetes 拡張機能であり、実際のプロバイダーへのロックインを軽減する抽象化レイヤーを提供します。

これらは単なる基本的な拡張機能です。この分野では大きな成長が見られ、Kubernetes をバックグラウンドで使用したり、ユースケースに合わせて公開拡張したりするプロジェクトがますます増えています。プラットフォームをコードとして構築するという文脈では、Kubeflow プロジェクトによる MLOps/AI や KubeEdge によるエッジ コンピューティングなど、特殊でありながら一般的なユース ケースをカバーする、より具体的なフレームワークと拡張機能が特に言及されています。

将来のビジョンと課題

Kubernetes とプラットフォームをコードとして拡張する作業はまだ初期段階にあります。標準化の取り組みのほとんどもまだ初期段階ですが、合意と生産準備に向けて急速に進んでいます。

現在対処する必要がある最も重要な問題は、このような拡張機能のユーザー エクスペリエンスです。これは、API の検証とデフォルト値の改善に限定されるのではなく、拡張機能とそのドキュメント レベルの検出も含まれます。さらに、これらの標準の一部が実稼働に近づくと、コミュニティとして、API を構成可能な状態に保ち、システムを密結合せずに相互作用を促進するように注意する必要があります。最後に、多くの Kubernetes 拡張機能を備えた複雑なシステムのデバッグ可能性とトレーサビリティはまだ改善の余地があります。

しかし、確かなのは、Kubernetes がインフラストラクチャとクラウドネイティブ テクノロジーに最適なインターフェースとして確立されるということです。さらに、より多くの標準が確立され、より多くのツールがそれらの標準をサポートし、統合されるようになります。

まとめると、Kubernetes が標準的なクラウドネイティブ管理インターフェースになるというのが将来の予測です。コミュニティを統合するコンセンサス API です。もちろん、ユーザーは引き続き自由に選択したツールを使用できますが、統一されたオープンソース インターフェースにより、ユーザーがロックインされることがなくなります。

Docker とコンテナにより、ワークロードが一時的なものになる状況が生まれました。このテクノロジーを使用すると、この概念を Kubernetes クラスターだけでなく、開発者プラットフォーム全体、またはユーザーに提供される多くのプラットフォームに拡張できます。

原題:プラットフォーム・アズ・コードの未来はKubernetes拡張機能です。著者: Puja Abbassi