はじめに
この記事はEKS Anywhere(EKS-A)がGAになった最初の時点での情報です。あくまで参考程度にご覧いただけると幸いです。
先にみなさんに誤解がないように言っておくと、EKS-Aは以下のどの製品（サービス）とも異なる性質があります。そのため比較検討の対象ではないことを認識しておくと良いです。
- Google Anthos
- Tanzu Kubernetes Grid
- RedHat OpenShift
- ECS Anywhere(名前は似ていますが本当に全く別物です。比較対象にはしないほうがいい)
EKS Anywhere(EKS-A)とは
EKSで使われているKubernetesディストリビューション（コミュニティ的には「EKS Distro」と呼ばれています）を、EKS外でも容易に使えるようにしたプロダクトです。
プロダクトとは言いますが、AWS上のサービスではありません。これめっちゃ重要で、つまりマネコンからは触れません。どういうことか見ていきましょう。
まず、このリポジトリに含まれるものが何かをよく見る必要があります。公式ドキュメントを覗くと、実態はただのCLIでしかないということがわかります。もう少し具体的に言うと、EKS-Aとは、eksctlのサブコマンド(プラグイン)のことを指します。
eksctl anywhere version ←これが、EKS Anywhereの実態です。
EKS-Aは、ただのCLIツールであるということを大きく念頭に置いてください。いいですね？EKS-AはAWSのマネージドサービスでもなんでもありません。ただのCLIツールなのです。
じゃあ、何をするCLIなの？
便宜上、「EKS-Aは何でないか」を説明するほうが簡単なので先に書きましたが、逆に一体これはなんなんだ？と思った方もいらっしゃるかと思います。
ここから先は以下の言葉に聞き覚えのある方を前提にお話していきます。逆に、ピンとこないという方については恐らくEKS Anywhereのユースケースにマッチしていない可能性が高いですが、それでも気になる場合は @r_takaishi さんのCluster APIに関する資料を先にご覧になることを強くおすすめします。
- Cluster API
- EKS Distro(EKS-D)
- kind(Kubernetes-in-Docker)
EKS-Aが提供するサブコマンドには以下のような機能があります
eksctl anywhere generate clusterconfig $CLUSTER_NAME --provider (docker|vsphere)で指定したプロバイダー向けのCluster APIセットアップYAMLを生成eksctl anywhere create cluster -f $CLUSTER_NAME.yamlで、生成した構成をもとに、EKS Distroを用いたKubernetesクラスターを作成する
EKS Distro(EKS-D)とは
EKS-DはEKSで用いられているKubernetesディストリビューションで、アップストリームで使われているKubernetesをベースにAWSがEKSで使うために細かいパッチを当てたバージョンのことです。逆に言えば、クラスター運用者はEKS-Dを用いることでEKSが使うものと全く同じKubernetesディストリビューションを使える、ということを意味します。なお、EKS-Dは公式ドキュメントにもある通りAWSから認証をうけたOSSなので、以下のようなコンポーネントがサポートされています。
EKS Distro には、オープンソース (アップストリーム) の Kubernetes コンポーネントと、クラスターの作成に必要な構成データベース、ネットワーク、ストレージコンポーネントなどのサードパーティー製ツールが含まれます。これには、Kubernetes コントロールプレーンコンポーネント (kube-controller-manager、etcd、CoreDNS など)、Kubernetes ノードコンポーネント (kubelet、Kubernetes CSI、CNI など)、コマンドラインクライアント (kubectl や etcdctl など) が含まれます。
また、セットアップにはCluster APIを用いるため、以下のようなカスタムリソースを定義した上でクラスターの作成や管理といったクラスターのライフサイクル管理をKubernetesリソースでできるのが強みです。細かい言及は避けますが、Cluster APIは既にマネージドサービスとしてのEKSでも内部的に使われており、1.21でkubectl get crdするとcapi周りのリソースを見ることもできます。
apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: Cluster metadata: name: dev-cluster spec: clusterNetwork: cni: cilium pods: cidrBlocks: - 192.168.0.0/16 services: cidrBlocks: - 10.96.0.0/12 controlPlaneConfiguration: count: 1 datacenterRef: kind: DockerDatacenterConfig name: dev-cluster externalEtcdConfiguration: count: 1 kubernetesVersion: "1.21" workerNodeGroupConfigurations: - count: 1 --- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: DockerDatacenterConfig metadata: name: dev-cluster spec: {} ---
ここまでで分かることは
- EKS-Aは
eksctlCLIのサブコマンドである - EKS-Aを使うと、DockerやvSphereなどの環境に、EKSと同じディストリビューションのKubenretesを簡単にセットアップできる
- EKS-Dは公式にサポートされたコンポーネント軍を含むディストリビューションである
という点です。
刺さるユースケースは・・・？
簡単に言えば、「オンプレで」、「EKSと同じKubernetesを」、「サクッと立てて運用したい」というユースケースであれば刺さりやすいと思います。逆に言えばOpenShiftやTanzuの上位製品、Anthosといった「CICDからモニタリングからわりと全部入り」な商用製品を使いたい場合は競合にはならないです。
EKS Connectorの話
マネコンにつなぎたいという要望もあると思いますが、それについては同時期にパブリックプレビューになったAmazon EKS Connectorを合わせて使うことになります。
EKS ConnectorはEKSのマネコンの中で誰でも使えるようになっていますが、以下のように複数のKubernetesディストリビューションをサポートしています。
この中にある「EKS Anywhere」を選ぶと、さっきのCLIで自分がセットアップしたクラスターの簡単なダッシュボードをマネコンで見られるようになります。追加の手順はやや複雑なのでドキュメントをよく読んで挑むようにしてください。今回は、そこの思想まで言及するとマジで長くなりそうなので割愛しますが、基本的にはセットアップするとECS Agentとかに近いものがお使いのKubernetesクラスターの中にデプロイされます。
EKS-AとEKS Connectorの組み合わせ
EKS Connectorを使ってEKS-Aのクラスターを管理すると、管理者にとってどんなメリットがあるでしょうか。
1. クラスター管理をeksctlに一本化できる
オンプレ/AWS(EKS)のどちらを使ったとしても、クラスター自体の運用(作成、削除、アップグレード)を同じ方法で行うことができます。なお、EKS-Aの場合ロードバランサーなどはオンプレ側で管理する必要がありますし、当然ノードのオートスケールなども別途検討が必要です。
2. クラスターAPIによるメリットが享受できる
世の中見渡すとRancherやらAnthosやらさまざまな複数環境にまたがったクラスター管理ツールがありますが、Cluster APIはアップストリームでの決定版みたいなところがあるので今後のメンテナンス性としては期待ができるかなと思います。
3. AWSの管理画面からワークロードの様子などが確認できる
EKS-Aについては見られる項目がマネージドのEKSに比べると少ない(例えばAdd-onなどもないしFargateやAWS VPCに関する設定もないため)ですが、ワークロードがどのNamespaceにあるかなどといった基本的な情報や、クラスターに配置されたノードの基本的な情報を見ることができます。
これらのことから、EKS-Aを使いたいユースケースとしては「オンプレで」、「EKSと同じKubernetesを」、「サクッと立てて運用したい」がやはり一番刺さるかなと思います。実際の使い勝手についてはDockerプロバイダーを用いたローカルクラスターの作成はkindなどとほぼ同等で、現状本番環境はvSphereしか対応していませんが、ロードマップやユーザーリクエストの数によってはさまざまな環境に対応していくことも予想できます。今後のロードマップについては、ぜひともEKS-AのIssueをウォッチしておくことをおすすめします。
他にもいろいろ
EKS-Aのドキュメントを見ているといろいろ本番運用を意識したタスクのやり方についても言及がありますが、中でも「GitOpsでクラスターの構成を管理する」というセクションは目を引きました。なかなか攻めていて面白いですね。なおEKSはWeaveworksと協業している部分もあり(eksctlとか)、FluxCDを推しているみたいですね。
さいごに
今回いろいろ検証するにあたって、@toriclsに大変お世話になりました。Twitter Spacesで色々話したときのやりとりについては以下ツイートのスレッドにも残っておりますので、合わせてご覧ください。
— Tori Hara (@toricls) September 9, 2021
というわけで、今日はこのへんで。
