EKS の「マネージド」は、何を肩代わりしているのか

Pod の置き場所を決める側と、動かす側

Part 1 では、kubectl apply を受け付けて Pod の置き場所を決める側 (kube-apiserver、etcd、scheduler、controller 群) と、その決定どおりにコンテナを起動する側 (各ノードの kubelet とコンテナランタイム) を見ました。 決める側を コントロールプレーンコントロールプレーンコントロールプレーンPod やタスクの置き場所を決め、クラスタの状態を保存する側。Kubernetes では kube-apiserver、etcd、scheduler、controller 群。用語集で見る、動かす側を データプレーンデータプレーンデータプレーン決定どおりにコンテナを起動して動かす側。Kubernetes では各ノードの kubelet とコンテナランタイム。用語集で見る と呼びます。

ECS を使ったことがあれば、同じ分け方をすでに体験しています。 ECS の API とスケジューラが決める側で、タスクが実際に走る EC2 (container instance) や Fargate が動かす側です。 ECS のドキュメントによると、各 container instance では container agent が動き、task の状態を ECS に報告し、ECS の要求で task を起動したり止めたりします。 kubelet と同じ仕事です。

ECS の用語を Kubernetes に対応づけると、おおむね次の通りです (雑な対応なので、細部は違います)。

マネージド Kubernetesマネージド Kubernetesマネージドクバネティスコントロールプレーンの運用をクラウド会社が引き受けるサービス。EKS、GKE、AKS など。用語集で見る とは、この決める側 (kube-apiserver や etcd のプロセス) を、クラウド会社が自分のアカウントの中で動かして運用してくれるサービスのことです。 EKS、GKE、AKS、OKE、そして ECS はいずれもコントロールプレーンをクラウド側で動かし、利用者には API エンドポイントの URL だけを見せます。 その結果、etcd のバックアップ、apiserver の冗長化、証明書のローテーションはクラウド側の仕事になります。

EKS の境界線

EKS を作って kubectl get pods -n kube-system を打つと、aws-node、coredns、kube-proxy が並びます。 EKS のドキュメントによると、この 3 つ (Amazon VPC CNI、CoreDNS、kube-proxy) は、どのクラスタにも EKS が自動で入れる add-on です。 一方で kube-apiserver や etcd の Pod はこの一覧に現れません。 これらは利用者の VPC の外、AWS 管理のアカウントで動いているからです。

AWS のドキュメントによると、コントロールプレーンはクラスタごとに専用で、apiserver は 2 台以上、etcd は 3 台が、リージョン内の 3 つの AZ に分けて置かれ、不調になれば AWS が置き換えます。

AWS 側には kube-apiserver、etcd、scheduler、kube-controller-manager に加えて、EKS 固有の部品が居ます。 type: LoadBalancer の Service を見て ELB を作る cloud provider の LB controller、IAM の認証情報を Kubernetes のユーザーに対応づける認証の部品 (aws-iam-authenticator)、Fargate に Pod を置くための専用スケジューラと admission controller です。 どれも kubectl get pods には出ません。

利用者の VPC 側には、サブネットごとに EC2 のノードがあり、kubelet と containerd、そして Amazon VPC CNI (aws-node DaemonSet) が動きます。 kubelet は EKS の API エンドポイントに接続して Pod の指示を受けます。 反対向きの通信のために、EKS はクラスタを作るときに利用者のサブネットへ 2〜4 個のネットワークインターフェースを作ります。 kubectl exec、kubectl logs、kubectl port-forward のような kubelet API を使う機能と、コントロールプレーンとノードの間のトラフィックがそこを通ります。 VPC で説明欄に Amazon EKS <クラスタ名> と書かれた ENI が、この差し込み口です。

誰がどの層を管理するか

境界線はサービスごとに違い、同じ EKS でも Auto Mode か、Fargate か、managed node group かで変わります。 下の表で切り替えて、層ごとの管理者を比べてみてください。

EKS のドキュメントは、ノードの選び方として EKS Auto Mode、Fargate、Karpenter、managed node group、self-managed ノード、オンプレミスや edge のマシンを繋ぐ Hybrid Nodes を挙げています。 どれを選ぶかで、この表の分担が変わります。

読み取れることは 4 つあります。

• コントロールプレーンと etcd は、どのマネージドでもクラウド側です。ここがマネージドの最低ラインです。
• ノード / OS の行が一番ぶれます。EKS の managed node group や GKE Standard は「AMI は配るが、いつ入れ替えるかは利用者」という共同管理で、Fargate や GKE Autopilot、EKS Auto Mode はノードそのものを意識させません。
• CSI と LB 連携は、EKS では長らく利用者が入れる側でした。GKE と AKS は最初から組み込みです。EKS Auto Mode でここが埋まりました。
• 自前 (EC2 + kubeadm) は全部利用者です。この教材のクラスタも構造としてはこれに近く、kubeadm で組んだコントロールプレーンに Cilium と kubevirt-csi を入れた状態です。

GKE、AKS、OKE の境界線

同じ構造を他のクラウドで見ます。 GKE のドキュメントでは、コントロールプレーンは apiserver、scheduler、主要な controller からなり、クラスタの状態の保存先は etcd か Spanner (Google 管理のデータベース) のどちらかで、どちらの場合もクラスタは etcd の API を提供すると説明されています。 ノードは kubelet が動く Compute Engine の VM です。 Standard モードではノードの設定を利用者が管理し (SSH もできる)、更新と修復は GKE が行います。 Autopilot ではノードの管理も GKE が行い、VM には触れず、課金は Pod が要求したリソースに対して行われます。

AKS は Azure のサービスで、ドキュメントによると kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager を Azure が運用します。 ノードは node pool にまとめられた Azure の VM で、既定では Virtual Machine Scale Sets で管理されます。 Azure CNI powered by Cilium を選んだクラスタでは kube-proxy の代わりに Cilium が使われます。 OKE (Oracle) も含め、どのクラウドも「コントロールプレーンはクラウド側、ノードは利用者の VCN / VNet / VPC」という構造は共通です。

ノードを増やす OSS とマネージドサービス

Karpenter は AWS 専用のサービス名ではありません。 EKS Auto Mode は Karpenter を基盤としたノード管理を提供し、AKS の Node Auto-Provisioning も Karpenter と AKS 向け provider を使ってノードを管理します。 Pod の要求から必要なノードを用意する考え方を共有しつつ、作成する VM、ネットワーク、認証は各クラウドの実装が受け持ちます。

同じ OSS が使われても、利用者が管理する範囲はサービスによって異なります。 自分で controller を導入する構成と、クラウドが更新や運用を引き受ける構成を分けて読むと、障害時にどのログを見られ、どこから先をサービス提供者に調べてもらうかが分かります。

Certified Kubernetes が保証するもの

EKS で書いた Deployment の YAML は、GKE でも AKS でもそのまま apply できます。 この互換性を支えているのが、CNCF の Certified Kubernetes Conformance Program です。 CNCF の説明では、この制度は「どのベンダーの Kubernetes も、必要な API を OSS 版と同じように備えている」ことを確かめるためのものです。 各ベンダーは自分のディストリビューションで conformance テストを流して結果を提出し、認定を受けています。

認定を受けているのは、EKS / GKE / AKS / OKE のようなホステッドサービスだけでなく、kind、minikube、k3s のようなローカル向け、OpenShift や Rancher のようなクロスプラットフォームの製品も含みます。 提出手順はリポジトリに書かれていて、Sonobuoy か Hydrophone で得たテスト結果に製品情報と再現手順を添え、Kubernetes のバージョンごとに cncf/k8s-conformance へ pull request として出します。 bot の検査とレビューを経て認定され、認定を保つには毎年、最新バージョンで結果を出し直します。

この認定が保証するのは「Kubernetes の API が仕様通りに振る舞うこと」です。 conformance テストは、たとえば Deployment の replicas を変えると Pod の数が変わるか、Service を作ると対応する Endpoints が付くか、といった挙動を実際のクラスタに対して確かめます。 その外側、つまりノードの OS、CNI の性能、LB の作り方、IAM との繋ぎ方は保証の範囲外で、クラウドごとに違います。 この Part の残りで扱うのはその外側です。

ふりかえり

参考

• Amazon EKS architecture (Amazon EKS User Guide)

• View Amazon EKS networking requirements for VPC and subnets (Amazon EKS User Guide)

• Amazon EKS add-ons (Amazon EKS User Guide)

• Architect your solution for Amazon ECS (Amazon ECS Developer Guide)

• Amazon ECS Container Agent (GitHub README)

• GKE cluster architecture (Google Cloud)

• About GKE Autopilot mode (Google Cloud)

• Azure Kubernetes Service (AKS) Core Concepts (Microsoft Learn)

• Certified Kubernetes Conformance Program (CNCF)

• Conformance Testing Instructions (cncf/k8s-conformance)

• AWS「Scale cluster compute with Karpenter and Cluster Autoscaler」: https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html

• Microsoft「Overview of Node Auto-Provisioning (NAP)」: https://learn.microsoft.com/en-us/azure/aks/node-autoprovision