Kubernetes に関する新しいブログシリーズへようこそ！このシリーズでは、Zadara での Kubernetes のデプロイの世界と AWS 互換のクラウドでコンテナ化されたアプリケーションを管理するために Zadara をどのように使用できるかを探ります。Kubernetes とコンテナオーケストレーションの基本からスケーリング、回復力、ライフサイクル管理といった高度なトピックまで幅広いトピックを取り上げます。また、お客様のニーズに応じて Kubernetes を zCompute にデプロイしカスタマイズするさまざまな方法についても掘り下げます。
このシリーズでは、Kubernetes を初めてお使いになる方にも経験豊富な方にも、Zadara クラウドでコンテナ化されたアプリケーションを管理するための貴重な洞察とベストプラクティスを提供します。さらなるエキサイティングなコンテンツにご期待ください！
最初のブログポストはクラウド環境全般、特に Zadara クラウド上の Kubernetes に焦点を当てます。このブログポストでは Kubernetes の歴史、機能、運用に関するすべての側面を網羅するわけではありませんが（これはおそらく別のブログシリーズが必要でしょう…）、Kubernetes クラウド統合の主要な要素と、それらが Zadara Compute クラウド環境（zCompute）にどのように関連しているかを掘り下げていきます。
背景
コンテナオーケストレーションのデファクトスタンダードであることに加え、Kubernetes はしばしば「クラウドのオペレーティングシステム」と表現されます。この言葉は他のどのアプリケーションよりもクラウドのコアサービスと相互作用することでクラウドのパワーを活用すると同時に、クラウドの API を Kubernetes API で抽象化するという事を表しています。
このようにクラウドレベルのサービスを Kubernetes レベルのリソースでマスキングすることで、ユーザーは特定のクラウド仕様ではなく、アプリケーションレベルの仕様に集中することができます。これはマルチクラウド手法の根底にある能力ですが、シングルクラウドのユースケースであっても Kubernetes はもはやワークロードを実行するクラウドの詳細を知る必要のない開発者にとって選択すべきプラットフォームとなっています。
ネイティブのコンピュート、ロードバランシング、ストレージ、さらには動的スケーリングのクラウド統合機能を備えた Kubernetes のユーザーは、クラウドと直接やり取りすることなくクラウドのパワーを享受することができます。このブログポストでは、よく知られた Kubernetes の成果物、業界標準のデプロイツール、ベストプラクティスの手順を使用して、Zadara クラウド上でこれらの利点を探ります。
クラウドでの Kubernetes
Kubernetes は一般的なアプリケーションではなくむしろ複雑なプラットフォームであり、複数の異なるサービスから構成され、コンテナ化されたアプリケーションデリバリのさまざまな側面を（クラウドサービスとの直接的な関係の有無にかかわらず）包含していることを念頭に置いています。それを使いこなすには利用（データプレーン）だけでなく、内部管理（コントロールプレーン）に関しても、かなり多くの学習努力が必要であることが明らかになりました。具体的には日常的な Kubernetes の利用とは異なり、クラウドでの Kubernetes の初期デプロイにはクラウドレベルの詳細な知識（および昇格した権限）が必要となるため、クラウドベンダーはいち早く以下のようなさまざまなレベルのマネージド Kubernetes の提供を開始しました。
提供タイプ | コントロールプレーン | データプレーン |
セルフマネージド | ユーザーの責任 | ユーザーの責任 |
セミマネージド | クラウドの責任 | ユーザーの責任 |
フルマネージド | クラウドの責任 | クラウドの責任* |
* データプレーンに対するクラウドの責任とは、ユーザーがワークロードの下層のコンピュートリソースに関心を持たない（ポッドレベルの仕様にのみ関心を持つ）ことを意味します。
加えて、Kubernetes は最初のクラウドネイティブアプリケーション（2016年に Google から最初の CNCF プロジェクトとして寄贈）で、そのクラウド API 統合は、ソースコード内に組み込まれたインツリーサポートからクラウドベンダーやサービスごとに外部でサポートされるツールへと年々成熟していきました。例えば、Kubernetes に組み込まれていた AWS クラウドのサポートはバージョン1.26で削除され（バージョン1.29では他のすべてのクラウドベンダーに対応）、基本的なクラウド統合コンポーネント（Cloud Controller Manager）は Kubernetes のコアコンポーネントとは別にデプロイする必要があります。このパラダイムシフトはクラウド固有の API を扱うために専用の外部ユーティリティが必要になった為、ストレージやロードバランシングといった他の領域にも影響を及ぼしました。
この変化の結果、クラウドベンダーはオリジナルの Kubernetes プロジェクトのダウンストリームディストリビューションを使用し、自社のクラウドに特化したツールをバニラ Kubernetes アーティファクトにバンドルして自社のクラウドに向け合理化されたエクスペリエンスを実現しました。
AWS での Kubernetes
ユーザーが AWS 上でセルフマネージド型の Kubernetes デプロイメントとワークロードを何年も実行してきた後、2018 年に Amazon は EKS（Elastic Kubernetes Service）を発表しました。このサービスは 2019 年に Fargate と統合されフルマネージドサービスとなります。
2020 年、AWS は EKS で使用される独自の Kubernetes ディストリビューションである EKS-D をオープンソース化し、AWS の外でも EKS ライクな Kubernetes クラスタを容易に構築できるようにしました。
EKS-D はすべての AWS Kubernetes サービスの基盤であるため、EKS-D を使用することで他のクラウドベンダーやオンプレミスを含め、AWS の内外で同じ Kubernetes コンポーネントを実行できるようになります。しかし、今でも AWS 指向のコンポーネントは AWS クラウド API でのみ動作するため、AWS クラウドでのみ EKS のような完全なエクスペリエンスを得ることができます。
特に、EKS-D には以下のコンポーネントが含まれており、これらはすべて AWS によってテストされ統合されたバージョンバンドルとして EKS で動作することが検証されています。
- コアコンポーネント（API Server や ETCD など）
- ベーシックプラグイン（CoreDNS や kube-proxy など）
- CSI コンポーネント（external-provisioner や external-attacher など）
- CSI スナップショット（snapshot-controller や csi-snapshotter など）
Zadara での Kubernetes
Zadara のクラウドが AWS のようなパブリッククラウドと異なるのは、そのエッジの性質によるところが大きいです。少数の巨大なデータセンター（リージョン）ではなく、500以上の小規模なエッジロケーションを提供し、それぞれが完全に独立してプライベートクラウドまたはハイブリッドクラウドの機能を提供しています。
高度な分散コンピューティングでは、ワークロードを複数のクラウド（それぞれが独立しているが性質は似ている）上で実行することで、耐障害性が確保され Kubernetes のマルチクラウドデプロイメント戦略にも適合します。1つの大きなインセンティブは、異なるクラウドベンダーの API（AWS vs. GCP vs. Azure など）に投資する代わりに、顧客が同じ AWS API で多数のクラウドを制御できる事にあります。
当社のユニークなサービスは、MSP だけでなくエンドユーザーにもテナント指向、低レイテンシー、ダイレクトネットワーキングというオンプレミスの利点を維持しながら、パブリッククラウドのようなダイナミックな性質を提供することができる点にあります。
Zadara クラウドは AWS と互換性があるため、AWS の外で EKS-D ワークフローを実行するのに最適なクラウドになります。少しの調整は必要ですが ( AWS 以外のクラウドエンドポイントなど）、Zadara は AWS CCM、AWS EBS CSI driver 、AWS Load Balancer Controller など、同じ AWS 指向のユーティリティーをサポートしています。また、Zadara は AWS Auto-Scaling Groups API を利用する Kubernetes Cluster Autoscaler のような、AWS をサポートする Kubernetes ネイティブツールもサポートしています。すべての主要なクラウド統合に関して EKS のような体験を楽しむことができます。
EKS-D との互換性に加えて Zadara クラウドは、AWS 公式プロバイダーを使用する Terraform （またはその新しい代替となる OpenTofu）や、AMI ベースのイメージ構築のための Packer などの標準的なクラウド自動化ツールをサポートしています。このような Infrastructure-as-Code (IaC) アプローチにより、ユーザーは様々なチームや顧客向けに複雑でありながら一貫性のあるアーキテクチャを作成することができます。
ここ数年、私たちは備わっている能力を活用して、Vanilla（オリジナルの Kubernetes）、RKE2（Rancher ベースのディストリビューション）、そして最近では EKS-D 自体など、さまざまな Kubernetes ソリューションのリファレンスアーキテクチャを作成してきました。EKS-D は Zadara 上での Kubernetes にとって、AWS との互換性から最も恩恵を受ける正しいアプローチだと感じています。
このシリーズの次回のブログポストでは、セルフマネージド型 EKS-D クラスタ自動デプロイのための Zadara の高度にカスタマイズ可能なソリューションについて説明します！
