「Zadara × Kubernetes」ではじめるクラウドネイティブな世界：AWS互換エッジクラウドで構築する最強インフラ入門

![kubernetes-cloud-768x461.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4099447/80d4884d-47f8-447c-b746-92f37def31f4.jpeg)

コンテナ化やKubernetesの導入が当たり前になりつつある今、クラウド上でKubernetesをどのように設計・運用していくかは多くの開発者・インフラ担当者にとって重要なテーマとなっています。特にマルチクラウドやハイブリッド環境が前提となる場面では、柔軟性・可搬性・スケーラビリティの観点で、プラットフォーム選びがシステム全体の運用に大きく影響します。

このブログシリーズでは、**AWS互換のクラウドプラットフォーム「Zadara」**を活用しながら、Kubernetesを実践的に展開・運用していくためのポイントを解説していきます。基本的な概念はもちろん、スケーリングや可用性設計、ライフサイクル管理など、日々の運用に役立つトピックを幅広く取り上げる予定です。Zadaraのクラウド基盤（zCompute）におけるKubernetesの展開方法や、カスタマイズの工夫についても触れていきますので、初心者の方も、すでにKubernetesを使いこなしている方もぜひご覧ください。

# 【背景】

コンテナオーケストレーションのデファクトスタンダードであることに加え、Kubernetes はしばしば「クラウドのオペレーティングシステム」と表現されます。この言葉は他のどのアプリケーションよりもクラウドのコアサービスと相互作用することでクラウドのパワーを活用すると同時に、クラウドの API を Kubernetes API で抽象化するという事を表しています。

このようにクラウドレベルのサービスを Kubernetes レベルのリソースでマスキングすることで、ユーザーは特定のクラウド仕様ではなく、アプリケーションレベルの仕様に集中することができます。これはマルチクラウド手法の根底にある能力ですが、シングルクラウドのユースケースであっても Kubernetes はもはやワークロードを実行するクラウドの詳細を知る必要のない開発者にとって選択すべきプラットフォームとなっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4099447/9437ec56-2dc3-4e32-82f6-b9c9dae91f82.png)
ネイティブのコンピュート、ロードバランシング、ストレージ、さらには動的スケーリングのクラウド統合機能を備えた Kubernetes のユーザーは、クラウドと直接やり取りすることなくクラウドのパワーを享受することができます。このブログポストでは、よく知られた Kubernetes の成果物、業界標準のデプロイツール、ベストプラクティスの手順を使用して、Zadara クラウド上でこれらの利点を探ります。

# 【クラウドでの Kubernetes】
Kubernetes は一般的なアプリケーションではなくむしろ複雑なプラットフォームであり、複数の異なるサービスから構成され、コンテナ化されたアプリケーションデリバリのさまざまな側面を（クラウドサービスとの直接的な関係の有無にかかわらず）包含していることを念頭に置いています。それを使いこなすには利用（データプレーン）だけでなく、内部管理（コントロールプレーン）に関しても、かなり多くの学習努力が必要であることが明らかになりました。具体的には日常的な Kubernetes の利用とは異なり、クラウドでの Kubernetes の初期デプロイにはクラウドレベルの詳細な知識（および昇格した権限）が必要となるため、クラウドベンダーはいち早く以下のようなさまざまなレベルのマネージド Kubernetes の提供を開始しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4099447/53e23b4b-3622-461f-8661-a80fe7b72714.png)
*データプレーンに対するクラウドの責任とは、ユーザーがワークロードの下層のコンピュートリソースに関心を持たない（ポッドレベルの仕様にのみ関心を持つ）ことを意味します。

加えて、Kubernetes は最初のクラウドネイティブアプリケーション（2016年に Google から最初の[CNCF プロジェクト](https://www.cncf.io/projects/kubernetes/)として寄贈）で、そのクラウド API 統合は、ソースコード内に組み込まれたインツリーサポートからクラウドベンダーやサービスごとに外部でサポートされるツールへと年々成熟していきました。例えば、Kubernetes に組み込まれていた AWS クラウドのサポートはバージョン1.26で削除され（[バージョン1.29](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/)では他のすべてのクラウドベンダーに対応）、基本的なクラウド統合コンポーネント（Cloud Controller Manager）は Kubernetes のコアコンポーネントとは別にデプロイする必要があります。このパラダイムシフトはクラウド固有の API を扱うために専用の外部ユーティリティが必要になった為、ストレージやロードバランシングといった他の領域にも影響を及ぼしました。

この変化の結果、クラウドベンダーはオリジナルの Kubernetes プロジェクトのダウンストリームディストリビューションを使用し、自社のクラウドに特化したツールをバニラ Kubernetes アーティファクトにバンドルして自社のクラウドに向け合理化されたエクスペリエンスを実現しました。

# 【AWS での Kubernetes】
ユーザーが AWS 上でセルフマネージド型の Kubernetes デプロイメントとワークロードを何年も実行してきた後、2018 年に Amazon は EKS（Elastic Kubernetes Service）を[発表](https://aws.amazon.com/blogs/aws/amazon-eks-now-generally-available/)しました。このサービスは 2019 年に [Fargate](https://aws.amazon.com/blogs/aws/amazon-eks-on-aws-fargate-now-generally-available/)と統合されフルマネージドサービスとなります。

2020 年、AWS は EKS で使用される独自の Kubernetes ディストリビューションである[EKS-D](https://aws.amazon.com/blogs/aws/amazon-eks-distro-the-kubernetes-distribution-used-by-amazon-eks/)をオープンソース化し、AWS の外でも EKS ライクな Kubernetes クラスタを容易に構築できるようにしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4099447/882f1238-f9c4-4fac-84b0-d2d3646ba6ea.png)
EKS-D はすべての AWS Kubernetes サービスの基盤であるため、EKS-D を使用することで他のクラウドベンダーやオンプレミスを含め、AWS の内外で同じ Kubernetes コンポーネントを実行できるようになります。しかし、今でも AWS 指向のコンポーネントは AWS クラウド API でのみ動作するため、AWS クラウドでのみ EKS のような完全なエクスペリエンスを得ることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4099447/e68f2222-ef0b-4642-b1f3-63ebdae6c782.png)
特に、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](https://github.com/kubernetes/cloud-provider-aws)、 [AWS EBS CSI driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)、 [AWS Load Balancer Controller ](https://github.com/kubernetes-sigs/aws-load-balancer-controller)など、同じ AWS 指向のユーティリティーをサポートしています。また、Zadara は AWS Auto-Scaling Groups API を利用する Kubernetes [Cluster Autoscaler ](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)のような、AWS をサポートする Kubernetes ネイティブツールもサポートしています。すべての主要なクラウド統合に関して EKS のような体験を楽しむことができます。

EKS-D との互換性に加えて Zadara クラウドは、AWS 公式プロバイダーを使用する [Terraform ](https://developer.hashicorp.com/terraform)（またはその新しい代替となる  [OpenTofu](https://opentofu.org/)）や、AMI ベースのイメージ構築のための [Packer ](https://www.packer.io/)などの標準的なクラウド自動化ツールをサポートしています。このような Infrastructure-as-Code (IaC) アプローチにより、ユーザーは様々なチームや顧客向けに複雑でありながら一貫性のあるアーキテクチャを作成することができます。

ここ数年、私たちは備わっている能力を活用して、Vanilla（オリジナルの Kubernetes）、RKE2（Rancher ベースのディストリビューション）、そして最近では EKS-D 自体など、さまざまな Kubernetes ソリューションのリファレンスアーキテクチャを作成してきました。EKS-D は Zadara 上での Kubernetes にとって、AWS との互換性から最も恩恵を受ける正しいアプローチだと感じています。

このシリーズの次回のブログポストでは、セルフマネージド型 EKS-D クラスタ自動デプロイのための Zadara の高度にカスタマイズ可能なソリューションについて説明します！