ただのメモです。色々な基本的なことは書いてません。
k8sの説明書だと、コンテナの管理概念が多いですが、今回はそこから少し離れて別の視点で。
ALB/EC2な構成で、ECS/EKSを比べることで分かるk8sの考え方です。
目次
- ECSとEKSは、ほぼ同じALB/EC2構成に出来る。
- k8sの世界観は2階建て、それが大切。
- 論理構造を物理構造に変換するのが、Reconciliation Loop。
- ECS/EKSは、オーケストレーションとコレオグラフィとして対比できる。
- 一息で言うと
- ぼやき:EKS特有の抽象on抽象
ECSとEKSは、ほぼ同じALB/EC2構成に出来る。
ALB -> Listener -> Target groups -> Container On EC2 Instance
EC2がFargateでもだいたい同じ。ECSとEKSは、このALB/EC2構成にほぼ差がありません。ALBの構成パターンなので当然です。だからこそ、コンテナの管理の部分が違う。という話になるのですが、今回はそこに行かず。
構成が同じだからこそ、考え方の違いが明白になるよねーというメモ。
このようなALB/EC2構成を、この記事に限って、後に出る"論理"と対比して、"物理"的な構成と呼びます。 ※記事以外で、物理と呼ぶとインフラ屋さんに怒られるから注意
k8sの世界観は2階建て、それが大切
ECSとEKSで対比することで、世界観の差を比べて行きます。
ECSの世界観
まずは、ECSの世界観。
ECSのクラスター構造の概念
ECS Cluster -> Service -> Task
この概念は、ECSを知るという以外にあまり役に立ちません。
Serviceが中心
アプリケーションサービスは、ECSにインテグレーションされてる物理構成(AWSサービス)の機能だけが使えます。構成もほぼ固定されています。といっても、ALB(ロードバランサー)/Scaling/Deploy等必要十分なものを備えており、Deploy戦略を切り替える等ある程度の柔軟さも担保されています。
これらはService毎に集中管理され、Serviceを中心に下記のような協調して行きます。
- スケーリングの定義に沿って、タスク数を増やしてく。(Scaling)
- Listener や Target gropsのInstanceの調整 (ALB/Deploy)
k8sの世界観は2階建て
k8sの世界観は、2階建てになっています。
- アプリケーションサービスの論理的な定義
- アプリケーションサービスの物理的な構造
前者の論理的な定義を構成する部品をResourceと呼びます。k8sの最初に習うPodやDeplymentやReplicaSetも全部Resourceです。
論理的な定義
ALB/EC2の物理構成を実現する場合、k8sでは↓のようなResourceを定義します。
Ingress -> Service -> Pods
※ ALB/EC2と比べやすいようにシンプルにしましたが、Deplyment/ReplicaSet等も実際には存在します。
物理的な構造
論理的な定義が、物理的な構造として実現されると、ALB/EC2構成になるわけです。
ALB -> Listener -> Target groups -> Container On EC2 Instance
Reconciliation Loop 論理構造を物理構造に変換する
論理的な構造を、物理構造に変換するのが、k8sのコアコンセプトである、Reconciliation Loopです。
Reconciliation Loopは、公式説明等ではk8sのアーキテクチャが強く語られて分かりづらいことが多いですが、基本はこれ。
ちょっと正確にすると、個別のリResourceに対応するControllerが存在し、ControllerはResourceを参照しながら己の責務を果たします。具体的にControllerは下記のようなことをしていることが多いです。
- Resource通りになるように、物理的な実体を用意する。
- Resource通りになるように、別のResourceを定義(更新)する。
ALBの例で言えばこうなります。
1. EKS上で、IngressのResourceを定義する
2. 対応する"AWS Load Balancer Controller"が、Resourceを参照する。
3. Controllerは、Resource通りなるように、ALBをプロビジョニングする。
これららが、Resource毎に(場合によっては連鎖的に)発生し、最終的に論理定義->物理構造に変換されます。
ECS/EKSは、オーケストレーションとコレオグラフィとして対比できる。
ECSとEKS(k8s)を対比すると下のようになります。
- ECS -> アプリケーションサービスは、Serivceによって集中管理される。Serivceに統合された機能のみ協調できる。
- EKS(k8s)-> アプリケーションサービスは、Controllerによって分散管理される。Resourceによる抽象化層があり、そこで協調させている。
この対比をみて、コレオグラフィという言葉ピンと来ました。
マイクロサービスの協調モデルの文脈で、オーケストレーションとコレオグラフィとして対比されるあれです。
- オーケストレーションは、指揮者にあたるサービスが存在し、個々のサービスを調整して、協調させて行きます。
- コレオグラフィは、個々のサービス毎に動作条件があり、動作後のフィードバック(所謂イベント)が媒体となり、別のサービスの動作条件になることで、協調して行きます。
ECSとEKS(k8s)の対比っぽいですね。
(実際、ECSのSerivceが直接操作してるわけではないはずなので、あくまでも概念的)
一息で言うと
k8sは、コンテナオーケストレーションサービスなんだけど、アーキテクチャ的にはコレオグラフィなマイクロサービスによって実現されています。結果、論理構造が抽象化されて、物理構造と分離しています。そのため汎用性や拡張性が優れてそう(簡単だとは言ってない)なんだ。って感じですね。
ぼやき: EKS特有の抽象on抽象
素のALBなら出来る構成を、"AWS Load Balancer Controller"によって、実現できるか調べたりすることになり、もやっとします。
ALBって、ALBそのものが"抽象化されたロードバランサー"なのに、さらに抽象化を重ねてる感じがします。特にAWS内で完結するサービスの場合は、抽象on抽象ってどこまでの意義があるのでしょうか。今後が気になります。