AWS認定資格 WEB問題集＆徹底解説DevOpsエンジニア プロフェッショナル（DOP）

会員登録/ログイン

1. サービス概要

Amazon EKS Distro（EKS-D）は、Amazon EKSが内部で使っているKubernetesの部品を、EKSと同じソース・同じビルド手順で作ったディストリビューションとしてAWSが公開しているものです。 kube-apiserver、kube-scheduler、kube-controller-manager、etcdといったコントロールプレーンの部品と、CoreDNS、kube-proxy、CNIプラグイン、aws-iam-authenticatorなどが含まれます。

EKS Distroはマネージドサービスでも、クラスター構築ツールでもありません。部品（コンテナイメージとバイナリ）とリリース情報を提供するだけで、それをどのツールで組み立て、どう運用するかは利用者が決めます。 ベアメタル、vSphere上の仮想マシン、Amazon EC2、他社クラウドなど、場所を問わず動かせます。動かし始めた後の管理やアップグレードは利用者の責任です。

位置づけを一言でいえば、「EKSと同じKubernetesを、自分の道具で、自分の環境に」です。構築と運用の自動化までAWSに頼りたいならEKS Anywhere、コントロールプレーンの運用をAWSに任せたいならEKS Hybrid NodesやEKS本体が選択肢になります。

2. 主な特徴と機能

2.1 EKSと同じバージョン・同じビルド

EKS DistroはEKSと同じKubernetesのバージョン・リリースサイクルに従い、EKSと同じ部品のバージョンをそろえて提供します。 クラウドのEKSとオンプレミスのクラスターでKubernetesや周辺部品の版とパッチ水準をそろえたい場合に、自前でアップストリームを追いかけてビルドする手間を省けます。

2.2 セキュリティパッチの提供

AWSが検証したセキュリティ修正を含むビルドが提供され、コミュニティのサポートが終わった後もEKSのバージョンライフサイクルに合わせた延長のパッチ提供があります。 EKSがあるマイナーバージョンのサポートを終えると、EKS Distroの該当リリースチャネルも退役します。

2.3 配布形態

• コンテナイメージ: Amazon ECR Publicで、amd64とarm64向けに公開される。
• バイナリ: 一部の部品は圧縮アーカイブや実行ファイルとして配布され、sha256/sha512のチェックサムが付く。
• リリースマニフェスト: リリースとリリースチャネル（Kubernetesのマイナーバージョンごと）はKubernetesのカスタムリソースとして記述され、各部品の取得先がまとめて示される。
• ソース: GitHubでオープンソースとして公開され、再現可能なビルドが可能。

2.4 インストール手段は利用者が選ぶ

• EKS Anywhere: AWSがサポートするインストール手段。EKS AnywhereはEKS Distroをベースにクラスターのライフサイクルを自動化する。
• コミュニティのツール: kubeadm、kOpsなどで構築する。
• パートナーの製品: パートナーのディストリビューションや構築ツールを使う。
• 既存の社内ツールチェーン: Cluster APIベースの社内基盤やAnsibleなどの構成管理で、取得するイメージだけをEKS Distroに切り替える。

2.5 サポートの考え方

EKS Distro単体でのデプロイはAWSのサポートプランの対象外です。AWSは報告された問題をベストエフォートで確認し、パートナー経由で導入した場合はそのパートナーがサポートします。 AWSのサポートを受けたい場合は、EKS AnywhereのEnterprise Subscriptionや、マネージドのEKSを検討します。

3. アーキテクチャおよび技術要素

1. 使いたいKubernetesのマイナーバージョンに対応するリリースチャネルと、その最新リリースを選ぶ。
2. リリースマニフェストから、各部品のコンテナイメージ（ECR Public）とバイナリの取得先を確認する。
3. エアギャップ環境では、イメージとバイナリを事前に取得してチェックサムを検証し、社内のレジストリやファイルサーバーへ置く。
4. kubeadmなどの構築ツールで、取得先をEKS Distroのイメージに向けてクラスターを構築する。
5. 新しいリリース（パッチ）が出たら、同じ手順で部品を差し替えてクラスターを更新する。更新の計画と実施は利用者が行う。

EKS Distro自体はAWSへの接続を必要としないため、部品を取得できればAWSから切り離された環境でも動かせます。一方で、ノードの管理、etcdのバックアップ、監視、アップグレードの自動化などはすべて利用者側で用意する必要があります。

4. セキュリティと認証・認可

• パッチ適用の責任: AWSは修正済みのビルドを提供するが、それをクラスターへ適用するのは利用者。リリースを定期的に確認する運用が必要。
• 完全性の検証: 取得したバイナリはチェックサムで改ざんがないことを確かめてから使う。
• 認証: aws-iam-authenticatorを使えばIAMの認証情報でクラスターにアクセスさせられる。OIDCなど他の方式も構成できる。
• 認可とネットワーク: KubernetesのRBAC、ネットワークポリシー、etcdの暗号化などは利用者が構成する。
• 隔離環境: AWSとの通信を必要としないため、外部通信が許されないセグメントでも、社内ミラーから部品を配布して運用できる。

5. 料金形態

• ソフトウェア: EKS DistroはオープンソースとしてGitHubとECR Publicで公開されており、ソフトウェアの利用料は設定されていない。
• インフラ: 動かす場所のハードウェア、仮想化基盤、クラウド（EC2で動かすならEC2・EBSなど）の費用は通常どおり発生する。
• サポート: AWSのサポートプランの対象外。サポートが必要ならパートナーの有償サポートや、EKS AnywhereのEnterprise Subscription（クラスター単位の定額）を検討する。
• 見えにくいコスト: 構築・アップグレード・障害対応を自前で行う運用工数が最大のコストになりやすい。

6. よくあるアーキテクチャ・設計パターン

• 既存の社内基盤を維持したパッチ運用の効率化: クラスター構築・更新の社内自動化はそのまま使い、取得するイメージとバイナリだけをEKS Distroに切り替えて、Kubernetes・etcd・CoreDNS・CNIの脆弱性修正を自前でビルドする手間をなくす。
• クラウドとオンプレの版の統一: クラウドではEKS、オンプレではEKS Distroを使い、Kubernetesのバージョンとパッチ水準、マニフェスト、運用手順をそろえる。
• 他社クラウドやエッジでの一貫性: 複数のクラウドや拠点で同じビルドのKubernetesを動かす。

6.1 オンプレミス・エッジ向けの選択肢との違い

• EKS Distro: 部品だけを提供。構築・運用ツールもサポートも利用者が用意する。接続不要。
• EKS Anywhere: EKS Distroに、構築・アップグレードの自動化（Cluster APIベース）と任意の有償サポートを加えたもの。接続不要で、エアギャップ環境にも対応。
• EKS Hybrid Nodes: コントロールプレーンはAWSリージョンのEKSが管理し、自社サーバーをノードとして参加させる。安定した接続が必要。
• EKS on Outposts: AWS所有のハードウェアを拠点に置き、EKSを使う。
• ECS Anywhere: Kubernetesを使わず、ECSで既存サーバーを管理する。接続が前提。

7. 設定・デプロイ手順（ハンズオン例）

kubeadmで検証用のクラスターを作る流れの例です（バージョン表記は実際のリリースマニフェストに合わせます）。

1. EKS Distroのリリース一覧から、使うKubernetesのマイナーバージョンと最新リリース番号を確認する。
2. 各ノードにコンテナランタイムを入れ、リリースマニフェストに記載されたkubelet・kubeadm・kubectlのバイナリを取得し、チェックサムを確認して配置する。
3. kubeadmの設定で、イメージの取得先をEKS DistroのECR Publicリポジトリに、Kubernetesのバージョンをeks付きの版に指定する。例:

   apiVersion: kubeadm.k8s.io/v1beta3
   kind: ClusterConfiguration
   imageRepository: public.ecr.aws/eks-distro/kubernetes
   kubernetesVersion: vX.Y.Z-eks-X-Y-N

4. コントロールプレーンを初期化する: sudo kubeadm init --config kubeadm-config.yaml
5. CNIを導入し、ワーカーノードをkubeadm joinで参加させる。
6. kubectl get nodesで状態を確認する。以後のパッチ適用は、新しいリリースの部品へ差し替えて利用者が行う。

8. 試験で問われやすいポイント