EKS Blueprints を使用してクラスターをブートストラップする

この記事は Bootstrapping clusters with EKS Blueprints (記事公開日: 2022 年 4 月 20 日) を翻訳したものです。

本日、Amazon Elastic Kubernetes Service (Amazon EKS) の導入をより簡単かつ迅速にする、EKS Blueprints という新しいオープンソースプロジェクトを紹介します。EKS Blueprints は、Infrastructure as Code (IaC) モジュールのコレクションで、アカウントやリージョンをまたがって、一式が揃っている EKS クラスターの構成およびデプロイを支援します。EKS Blueprints を使用すると、Amazon EKS アドオンだけでなく、Prometheus、Karpenter、Nginx、Traefik、AWS Load Balancer Controller、Fluent Bit、Keda、Argo CD など、人気のある幅広いオープンソースアドオンを使用して、EKS クラスターを簡単にブートストラップすることができます。また、EKS Blueprints は、複数のチームのワークロードを同じクラスターで運用するために必要な、関連するセキュリティ制御の実装を支援します。

EKS Blueprints は、HashiCorp Terraform と AWS Cloud Development Kit (AWS CDK) というインフラストラクチャのデプロイを自動化するのに役立つ 2 つの人気のある IaC フレームワークに実装されています。始めるには、EKS Blueprints for Terraform または EKS Blueprints for CDK のいずれかの Getting Started ガイドをご覧ください。

モチベーション

Kubernetes は、コンテナ化されたアプリケーションを大規模にデプロイおよび管理できるようにする、強力で拡張可能なコンテナオーケストレーションテクノロジーです。 Kubernetes の拡張性により、一般的にアドオンと呼ばれるさまざまな人気のあるオープンソースツールを、Kubernetes クラスターで使用することができます。このように多数のツールや設計の選択肢があるため、アプリケーション固有のニーズを満たすオーダーメイドの EKS クラスターを構築するには、かなりの時間がかかることがあります。これには、幅広いオープンソースツールと AWS サービスの統合が必要であり、AWS と Kubernetes に関する深い専門知識が必要です。

もし複数のチームのワークロードを同じクラスターで運用している場合、Network Policy、EKS クラスターへのアクセス、EKS クラスターの外部で実行される AWS リソースへのアクセスの管理など、さらに考慮しなければならないことがあります。また、EKS クラスターの導入が進むにつれ、クラスター間の一貫性と標準化を確保することが、さらなる課題となる可能性があります。

AWS のお客様は、Kubernetes ツールのランドスケープをどのように統合するかを示す例を求めており、特定のアプリケーション要件を満たすこだわりの EKS クラスターを簡単にプロビジョニングしたいと考えています。彼らは、Terraform、CDK、Helm などの使い慣れたツールを使用して、EKS クラスターのライフサイクル、各クラスターで実行される運用ソフトウェア、および各クラスターでワークロードを実行する必要があるチームの設定を管理するためのソリューションを求めています。EKS Blueprints は、このようなお客様のニーズに応えるために開発されました。

EKS Blueprints とは何か？

EKS Blueprints は、ワークロードのデプロイと運用に必要とされる運用ソフトウェアで完全にブートストラップされた完全な EKS クラスターを構成するのに役立ちます。コントロールプレーン、ワーカーノード、Kubernetes アドオンなど、EKS クラスターの望ましい状態の構成を IaC ブループリント (設計図) として記述することができます。ブループリントを構成すると、それを使って継続的デプロイ自動化を使用して、複数の AWS アカウントやリージョンに一貫した環境をデプロイすることができます。EKS Blueprints は、クラスターのプロビジョニングに terraform-aws-eks モジュールを使用するなど、EKS オープンソースコミュニティの既存の作業を基に構築されています。

次のアーキテクチャ図は、EKS Blueprints を使用して構成およびデプロイできる EKS 環境を表しています。この図は、3 つのアベイラビリティゾーンで実行され、さまざまな Kubernetes アドオンでブートストラップされ、複数の異なるチームのワークロードをホストする EKS クラスターを示しています。

EKS Blueprints を使用すると、EKS クラスターで EKS アドオンとセルフマネージドアドオンの両方をプロビジョニングすることができます。EKS サービスが EKS アドオンのライブラリを拡張し続けるにつれて、EKS Blueprints もそれらの機能を追加するように進化していきます。また、各アドオンに適切な IAM ポリシー、ロール、および Service Account を構成します (IAM Roles for Service Accounts (IRSA) のドキュメントで指定されているように) 。

複数のチームが同じクラスター内でワークロードを実行できるようにする場合、EKS Blueprints を使用して、クラスターにアクセスできるユーザーとチーム (管理者チーム) 、およびクラスター内の Namespace にアクセスできるユーザーとチーム (アプリケーションチーム) を構成および管理できます。

クラスター設定とワークロードの両方を管理するために GitOps ベースのアプローチを活用したい場合は、EKS Blueprints を使用して、Argo CD と任意の数の Argo CD Application リソースでクラスターをブートストラップすることができます。Flux のサポートもロードマップにあります。

Blueprints のサンプル

EKS Blueprints を使用して EKS 上の特定の技術的な課題を解決する方法を示す実装例のライブラリも開発しました。このライブラリには、現在、EMR on EKS を実行する方法、Karpenter を使用してノードをプロビジョニングするように EKS クラスターを構成する方法、EKS クラスターとワークロードにオブザーバビリティを実装する方法、Crossplane を使用して EKS クラスターをブートストラップする方法、EKS Blueprints を AWS Proton で使用する方法などを示すサンプルが含まれています。

時間の経過とともに、サンプルライブラリは成長し、進化し続けます。もし、追加で見たいサンプルがあれば、GitHub Issue を作成してお知らせください。さらに、独自のブループリントを作成してコミュニティと共有したい場合は、プルリクエストを歓迎します！

EKS Blueprints を使用する

実際の EKS Blueprints を見てみましょう。次の Terraform の例は、マネージド型ノードグループを持つ新しい EKS クラスターをデプロイするシンプルなブループリントです。また、vpc-cni、coredns、kube-proxy、aws-load-balancer-controller、 metrics-server、そして cluster-autoscaler アドオンでクラスターをブートストラップしています。EKS クラスターにアドオンをインストールする必要があることを示すには、ブール値を true に設定するだけです。

module "eks_blueprints" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.0.2"

  # EKS Cluster VPC and Subnet mandatory config
  vpc_id             = <vpc_id>
  private_subnet_ids = <private_subnet_ids>

  # EKS CLUSTER VERSION
  cluster_version = "1.21"

  # EKS MANAGED NODE GROUPS
  managed_node_groups = {
    mg_5 = {
      node_group_name = "managed-ondemand"
      instance_types  = ["m5.large"]
      min_size        = "2"
    }
  }
}

# Add-ons
module "kubernetes_addons" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons?ref=v4.0.2"

  eks_cluster_id = module.eks_blueprints.eks_cluster_id

  # EKS Add-ons
  enable_amazon_eks_vpc_cni            = true
  enable_amazon_eks_coredns            = true
  enable_amazon_eks_kube_proxy         = true
  enable_amazon_eks_aws_ebs_csi_driver = true

  # Self-managed Add-ons
  enable_aws_for_fluentbit            = true
  enable_aws_load_balancer_controller = true
  enable_aws_efs_csi_driver           = true
  enable_cluster_autoscaler           = true
  enable_metrics_server               = true
}

CDK を使う場合、次のようにできます。

const app = new cdk.App();

const stackId = "<stack_id>";

// By default will provision in a new VPC
blueprints.EksBlueprint.builder()
    .region('us-west-2')
    .version(eks.KubernetesVersion.V1_21)
    .addOns(
        new blueprints.addons.VpcCniAddOn(),
        new blueprints.addons.CoreDnsAddOn(),
        new blueprints.addons.KubeProxyAddOn(),
        
        // Self-managed Add-ons
        new blueprints.addons.AwsForFluentBitAddOn(),
        new blueprints.addons.AwsLoadBalancerControllerAddOn(),
        new blueprints.addons.ClusterAutoScalerAddOn(),
        new blueprints.addons.EfsCsiDriverAddOn(),
        new blueprints.addons.MetricsServerAddOn()
    )
    .build(app, stackId);

Kubernetes アドオンのカスタマイズ

各アドオンは、オープンソースのアップストリーム Helm リポジトリを参照します。EKS Blueprints には、AWS API にリクエストを行う各アドオンのデフォルトの IAM Roles for Service Accounts (IRSA) 設定が含まれています。高度な設定 (プライベート Helm リポジトリなど) が必要な場合は、Helm のデフォルト値を簡単に上書きすることができます。

例えば、Helm チャートで使用する Docker イメージは、values.yaml で ECR や Artifactory などのプライベート Docker リポジトリに置き換えることができます。次のコードは、AWS Load Balancer Controller アドオンの高度な設定をサポートする方法を示しています。

module "kubernetes_addons" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons?ref=v4.0.2"

  eks_cluster_id = module.eks_blueprints.eks_cluster_id

  enable_aws_load_balancer_controller = true
  aws_load_balancer_controller_helm_config = {
    name       = "aws-load-balancer-controller"
    chart      = "aws-load-balancer-controller"
    repository = "https://aws.github.io/eks-charts"
    version    = "1.3.1"
    namespace  = "kube-system"
    values = [templatefile("${path.module}/values.yaml", { 
        operating_system = "linux"
    })]
  }
}

CDK を使用する場合も、アドオンを設定することができます。

const loadBalancerAddOn = new blueprints.AwsLoadBalancerControllerAddOn({
    name: "aws-load-balancer-controller",
    chart: "aws-load-balancer-controller",
    repository: "https://aws.github.io/eks-charts",
    version: "1.3.1",
    namespace: "kube-system",
    enableWaf: true, 
    values: {
        operating_system: "linux"
    } 
});

blueprints.EksBlueprint.builder()
    .addOns(loadBalancerAddOn)
    .build(app, stackId);

ワーカーノード

EKS Blueprints は、マネージド型ノードグループ、セルフマネージド型ノード、AWS Fargate プロファイルなど、さまざまなノード構成で EKS クラスターのプロビジョニングをサポートします。

module "eks_blueprints" {
  ...
  # Managed Node Groups
  managed_node_groups = {
    mg_5 = {
      node_group_name = "managed-ondemand"
      instance_types  = ["m5.large"]
      min_size        = "2"
      max_size        = "5"
    }
  }

  # Fargate Profiles
  fargate_profiles = {
    default = {
      fargate_profile_name = "default"
      fargate_profile_namespaces = [{
        namespace = "default"
      }]
      additional_tags = { ExtraTag = "Fargate" }
    }
  }
}

CDK を使用する場合も、ノード構成を指定することができます。

...
// Managed Node Group
const props: blueprints.MngClusterProviderProps = {
  version: eks.KubernetesVersion.V1_21,
  minSize: 2,
  maxSize: 5,
  instanceTypes: [new ec2.InstanceType('m5.large')],
}
const mngClusterProvider = new blueprints.MngClusterProvider(props);

// Fargate Profile
const fargateProfiles: Map<string, eks.FargateProfileOptions> = new Map([
    ["default", { selectors: [{ namespace: "default" }] }]
]);
  
const fargateClusterProvider = new blueprints.FargateClusterProvider({
    fargateProfiles,
    version: eks.KubernetesVersion.V1_21

複数チームでのクラスターの使用

複数のチームが同じクラスターでワークロードを実行できるようにしたい場合、EKS Blueprints はソフトマルチテナンシーを実現するためのアプローチを提供します。EKS ベストプラクティスガイドに定義されているように、ソフトマルチテナンシーは、Kubernetes のネイティブな構成要素 (例えば、Namespace、Role、Role Binding、Network Policy) を活用して、テナント間の論理的な分離を行います。さまざまな顧客に対して完全に分離されたワークロードを実行する必要がある Software-as-a-Service (SaaS) プロバイダーなど、ハードマルチテナンシー要件がある場合は、顧客ごとに専用のクラスターをプロビジョニングすることをお勧めします。

ソフトマルチテナンシーの場合、EKS Blueprints を使用すると、クラスターにアクセスできるチームと ID、そしてそのチームと ID がアクセスできるリソースを簡単に設定できます。現在、プラットフォームとアプリケーションの 2 種類のチームをサポートしています。プラットフォームチームは、EKS クラスターへの管理者アクセスを持つプラットフォーム管理者を表します。アプリケーションチームは、クラスター内の Namespace で実行されるワークロードを管理するチームを表します。アプリケーションチームは、クラスター内の 1 つ以上の専用の Namespace にアクセスできます。

module "eks-blueprints" {
  …
  application_teams = {
    team-blue = {
      "labels" = {
        "appName" = "blue-team-app",
      }
      "quota" = {
        "requests.cpu"    = "2000m",
        "requests.memory" = "4Gi",
        "limits.cpu"      = "2000m",
        "limits.memory"   = "8Gi",
      }
      users = ["arn:aws:iam::<aws-account-id>:user/team-blue-user"]
    }
  }

  platform_teams = {
    platform_admin = {
      users = ["arn:aws:iam::<aws-account-id>:user/platform-user"]
    }
  }
}

CDK の場合の例です。

const applicationTeam = new blueprints.ApplicationTeam({
    name: "team-blue",
    namespaceLabels: {
        appName: "example",
    },
    namespaceHardLimits: {
        "requests.cpu"   : "1000m",
        "requests.memory" : "4Gi",
        "limits.cpu"      : "2000m",
        "limits.memory"   : "8Gi",
    },
    users: [new ArnPrincipal("arn:aws:iam::<aws-account-id>:user/team-blue-user")]
});

const platformTeam = new blueprints.PlatformTeam({
    name: "platform-admin",
    users: [new ArnPrincipal("arn:aws:iam::<aws-account-id>:user/platform-user")]
});

blueprints.EksBlueprint.builder()
    .teams(applicationTeam, platformTeam)
    .build(app, stackId);

GitOps

GitOps ベースのアプローチを活用して、EKS クラスターにアドオンとワークロードの両方をデプロイしたい場合、EKS Blueprints は Argo CD のデプロイの out-of-the-box なサポートを提供します。Argo CD と 1 つまたは複数の Argo CD Application リソースで EKS クラスターを簡単にブートストラップすることができます。

EKS Blueprints は、ワークロードの設定を管理する方法を示すワークロードリポジトリと、アドオンの設定を管理する方法を示すアドオンリポジトリの 2 つのサンプル Argo CD リポジトリを提供します。どちらのリポジトリも、Argo CD の App of Apps パターンに従っています。次のサンプルコードは、Argo CD とサンプルリポジトリを活用して、2 つの Application リソースで EKS クラスターをブートストラップする方法を示しています。

module "kubernetes-addons" {
  ...
  enable_argocd         = true
  argocd_manage_add_ons = true # Indicates that Argo CD is responsible for managing/deploying Add-ons.
  addons = {
    path               = "chart"
    repo_url           = "https://github.com/aws-samples/eks-blueprints-add-ons.git"
    add_on_application = true
  }
  workloads = {
    path               = "envs/dev"
    repo_url           = "https://github.com/aws-samples/eks-blueprints-workloads.git"
    add_on_application = false
  }
}

CDK の場合の例です。

const stackId = "<stack_id>";

const argoBootstrapAddOn = new blueprints.ArgoCDAddOn({
    bootstrapRepo: {
        repoUrl: "https://github.com/aws-samples/eks-blueprints-workloads.git",
        path: 'envs/dev'
    }
});

blueprints.EksBlueprint.builder()
    .addOns(argoBootstrapAddOn)
    .build(app, stackId);

AWS パートナーとのコラボレーション

EKS Blueprints を開発している間、私たちはいくつかの AWS パートナーと密接に協力して、彼らの製品やサービスのためのアドオンを作成してきました。EKS Blueprints のアドオンを作成することで、パートナーは自社のソフトウェアを適切な設定で EKS クラスターにブートストラップすることに関連する労力を軽減することができます。Datadog、Dynatrace、HashiCorp、Kubecost、New Relic、Ondat、Rafay、Snyk、Tetrate、Kasten By Veeam はすべて、顧客が EKS Blueprints で自社製品を使用できるようアドオンを作成しています。アドオンの作成に興味がある他の AWS パートナーは、Terraform と CDK それぞれのリポジトリにある拡張性ガイドを参照してください。

概念的には、EKS Blueprints の機能は、CDK や Terraform などの特定のツールに制約されるものではありません。AWS パートナーは、我々のツール自由に使用したり、オープンソースのコラボレーションを通じて共同開発の取り組みに参加したり、独自のツールを開発したりできます。例えば、AWS パートナーであり、人気のある Infrastructure as Code (IaC) ツールの所有者である Pulumi は、本日プレビューで利用できる EKS Blueprints の独自の Pulumi フレーバーを発表して、我たちの取り組みに参加しています。

また、いくつかの AWS パートナーと協力し、AWS のお客様が EKS Blueprints を使用するのに役立つオファリングを作成しました。これらのパートナーは、独自のニーズに合わせて EKS Blueprints を採用し、カスタマイズしたいお客様を支援することができます。2nd Watch、Caylent、Grid Dynamics、HCL Technologies、nClouds、そして Weaveworks は、お客様の EKS Blueprints の導入を支援する専用オファリングを構築しています。

私たちが目指すもの

EKS Blueprints は、AWS のソリューションアーキテクトとスペシャリストの情熱的なグループによって、過去 1 年間にわたりオープンソースで開発されてきました。私たちは幸運にも、オープンソースコミュニティ、お客様、パートナーの協力を得て、フィードバックを収集し、プロジェクトの方向性を形成するのに役立てています。私たちの公開ロードマップは、Terraform と CDK の両方のリポジトリで利用可能であり、皆様からのご意見をお待ちしています。どのような追加のアドオンが役に立つでしょうか？どのような新しいブループリントを作ることができるでしょうか？

最後に、EKS Blueprints コミュニティはすべての人に開かれています。小さいながらもプロジェクトにコントリビュートしているオープンソースコミュニティがあり、私たちはコントリビューターの裾野を広げたいと考えています。プロジェクトに参加することに興味がある場合、バグレポート、新機能、修正、追加のドキュメントなど、Terraform または CDK プロジェクトへのあらゆるコントリビューションを歓迎します。

ネクストステップ

EKS Blueprints を使い始めるには、EKS Blueprints for Terraform または EKS Blueprints for CDK のいずれかのリポジトリにアクセスしてください。そこには、プロジェクトドキュメントへのリンクと、使い始めるための手順へのリンクがあります。

提供時期、価格、サポート

Terraform と CDK 用の EKS Blueprints は GitHub で入手できます。これらは、現在 EKS が利用可能なすべての AWS リージョンで EKS 環境をプロビジョニングするために使用できます。EKS Anywhere のサポートはロードマップにあります。

EKS Blueprints は無料で使用でき、デプロイしたリソースに対してのみ料金が発生します。例えば、マネージド型ノードグループを持つ EKS クラスターをデプロイする場合、標準的な EKS と EC2 の料金が発生します。

EKS Blueprints はコミュニティ主導のオープンソースプロジェクトであり、AWS サービスの一部ではないため、AWS エンタープライズサポートには含まれません。EKS など、EKS Blueprints によってプロビジョニングされたすべての AWS サービスは完全にサポートされます。EKS Blueprints の使用に関してサポートが必要な場合は、GitHub リポジトリで Issue を作成してください。AWS プロフェッショナルサービスや AWS パートナーもサポートする準備ができています。

翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。

Amazon Web Services ブログ