Amazon Elastic Container Service for Kubernetes (EKS)とAWS Fargate

本記事は個人の意見であり、所属する組織の見解とは関係ありません。

AWS re:Invent 2017のKeynoteにおいて、Amazon EKSが発表されました。

Amazon Elastic Container Service for Kubernetes (Amazon EKS) は、Kubernetes クラスターのインストールと運用を自分で行うことなく、Kubernetes を AWS で簡単に実行できるようにするマネージドサービスです。
https://aws.amazon.com/jp/eks/

この記事では、同じくre:Inventで行われたCON215: Intro to Amazon Elastic Container Service for Kubernetesの内容を中心に、Amazon EKSとはどんなものなのか、および2018年での連携が予定されているAWS Fargateとは何なのか、をご紹介したいと思います。

Kubernetes on AWS

少し前になりますが、Amazon Web ServicesはKubernetesを始め多数のプロジェクトをホストしているCloud Native Computing FoundationにPlatinum Memberとして参加をしました¹。そして、12月頭に開催されたKubeCon + CloudNativeCon NAでの最新のアンケート調査²によると、69%の方がAWSを現時点で利用されていて、これはオンプレミスも含めた中で最も利用比率が高い環境となっています。

こうした利用者の方々からのフィードバックとして、Kubernetesのマスターおよびその分散データストアであるetcdの管理は非常に大変でありかつ差別化にならない重労働(undifferenciated heavy lifting)である、というものがありました。

Amazon EKSのTenets

そうしたフィードバックを元に、マネージドサービスであるAmazon Elastic Container Service for Kubernetesを開発しました。EKSがどういうものなのか細かい機能を見る前に、そのTenets(日本語にすると教義、信条)を見てみるのが、理解を助けてくれます。

• Tenet 1: EKSはエンタープライズ企業が本番のワークロードを実行するためのプラットフォームであること
  • 信頼性、可視性、スケーラビリティ、管理の容易さ
• Tenet 2: EKSはネイティブで最新のKubernetesの体験を提供すること
  • 現状でKubernetesで実現できることと同じことができる
• Tenet 3: EKSユーザが他のAWSサービスを使うときには、シームレスな連携を実現し不要な作業を取り除くこと
• Tenet 4: EKSチームは積極的にKubernetesプロジェクトに貢献していくこと

Amazon EKSのアーキテクチャ

EKSはKubernetesのControl planeをフルマネージドで提供するので、そのクラスタにjoinするNodesや操作したいkubectlは割り振られるEndpointを利用するだけで良いです。Control planeはMulti AZ構成になっておりEKSが監視していて、必要に応じて可用性を保ったまま自動でスケールしてくれます。

Worker Nodesは自由なEC2インスタンスを持ち込むことができます。なので、例えばSpot Fleet等既存のEC2で使える機能をフル活用することができますし、利用できるAmazon Machine Image (AMI)にも制約はありません。一方で、Auto Scaling Group等の設定や、OS上でKubernetesに必要な設定を自身で全て行いたくない方も多いのは理解しているので、以下のものが提供される予定です:

• Amazon LinuxベースのEKS Worker Node用のAMI
  • 更新があれば通知されるAmazon SNS Topicも提供予定
• 上記AMIをプロビジョンできるPacker³スクリプト
  • 自由なOSをベースにして簡単にカスタムのEKS Worker Node AMIが作成可能
• Worker Node設定用のAWS CloudFormationテンプレート
  • 必要なパラメータを埋めるだけでWorker Nodesを立ち上げられるテンプレート

EKSのネットワーク

KubernetesのPod(コンテナ)は、専用のPrivate IPアドレスを持っていて互いにフラットなネットワークで接続可能であることを要求されます。これを実現する方法には例えばOverlay Networkの様にNodeのネットワークとは全く異なるアドレス帯を利用することもできますが、パフォーマンスに影響があったり運用やトラブルシューティングも大変になることが多いです。

EKSチームではAmazon VPCのネットワークを最大限活用できる新しいCNI Pluginを開発していて、既にGitHubにて公開されています。CNIとは、Container Network InterfaceというCNCFのプロジェクトの1つで、Kuberenetesに限らずコンテナでのネットワーク設定を標準化したものとなっています。CNI Pluginとして実装を行うことで、ネットワークの設定を柔軟に行うことが可能となります。⁴

こちらのPluginが払い出すIPアドレスは、EC2インスタンスのElastic Network Interface(ENI)に割当可能なSecondary IPアドレスになっているので、所属するVPCのCIDRの範囲のアドレスとなります。そのため、VPCでルーティング可能な範囲で何も工夫しなくても疎通可能です(Security GroupやNACLも通常通り作用します)。1つのENIに複数のSecondary IPアドレスを割り振れるので、多くのIPアドレスを1つのインスタンス上に集めることも可能です。技術的な詳細についてはCON409 Amazon Elastic Container Service for Kubernetes Deep Diveで説明されているので、興味のある方はご覧になると良いと思います。

上記のCNI PluginはEKSだけでなく、現時点でAWS上に構築しているKubernetesクラスタでも利用可能です。利用方法はPluginの配置と合わせて、L-IPAMというコンポーネントをDaemonSetで各インスタンスに配置する必要があります。Kubernetesクラスタを構築するツールであるkopsでは既にこのPluginで構築するオプションがmergeされているので、近いうちにリリース版にも含まれると思われます。⁵

また、この設定方法ではVPCのSecurity GroupはENI単位での設定となるので、Pod毎に異なるSecurity Groupを使うことはできません。そうしたより詳細なネットワークポリシーを設定したい場合には、Kubernetesが持っているNetwork Policyという仕組みを利用します。その実装で最もよく利用されているのがProject Calicoです。オープンソースの実装ですが、TIGERA社が有償のサポートも行っています。このCNI PluginでもProject Calicoが利用可能となるようにTIGERAと連携しています。

AWS IAMでの認証

EKSでは、KubernetesのEndpointの認証にAWS IAMを利用します。この実装にはHeptio社が開発しているAuthenticatorを活用しています。これによって、EKSのクラスタにアクセスできるIdentityの認証(それが誰であるかの確認)には既存のIAMを活用できます。一方で、認証したIdentityの認可(何をする権利を持っているか/いないか)については、Kubernetesが持っているRBAC(Role-Based Access Control)を利用します。これは、既にRBACを利用している方が多くそれが必要であるというフィードバックを元にした設計です。kubectlはまだこのIAMでの認証に対応していませんが、この機能にむけた改修をEKSチームで進めているところです。

こちらも、技術的な詳細についてはCON409 Amazon Elastic Container Service for Kubernetes Deep Diveで説明されているので、興味のある方はご覧になると良いと思います。

Kubernetesのバージョン

現時点ではEKSはKubernetes 1.7をサポート予定で、その後バージョンを追加していきます。パッチレベルについてはセキュリティパッチも含まれるので常に最新のものを自動で適応しますが、マイナーバージョンについては最新から過去3つの中から選択できるようにする予定です。マイナーバージョンのアップグレードのポリシーを細かく制御できるようにしたいというのも多くのフィードバックがあったポイントで、EKSでは自動アップグレードや手動でのアップグレードが選択可能になる予定です。

古いバージョンを使い続けていてそのバージョンのサポート(パッチレベルの適応)が終了するときには、事前に通知が行われ期間内にアップグレードするか、自動でアップグレードさせるかという選択をする形になります。

オートスケール

マスターのオートスケールに関しては、EKSが勝手にやってくれるので全く気にする必要はないですが、PodおよびNodeのオートスケールについては既存のKubernetesが持っているオートスケールに機能をそのまま利用することができます。PodレベルのスケーラとNodeレベルのスケーラがあり、前者はCPU利用率といったメトリクスでPodの数を調整するもので、後者はリアクティブにPodのスケジュールに失敗したらNodeの数を増やすというものですが、どちらも利用可能です。

よりAWSとの連携を強めるべき部分ももちろんあり、例えばELBのメトリクスやSQSのキューの長さに応じてスケールさせるといった機能が考えられています。

Private Link

EKSの発表の少し前に発表された新機能としてAWS PrivateLinkというものがあります。これは、各種AWSのサービスエンドポイントとして、VPC内に作成されるENIを利用することができる(もう少し正確に言うとAWSだけでなく誰でもサービスを登録することができる)新機能になります。EKSのマスターのエンドポイントについてもこのPrivateLinkを利用できるようにするオプションを提供予定で、これを使えばインターネットへのアクセスを一切許可することなくEKSを利用することができます。

AWS Fargate

AWS Fargateは、同じくre:Invent Keynoteで発表された新サービスです。これは、インフラ不要なコンテナ実行環境であり、EC2インスタンスのことを一切気にすること無くコンテナだけに集中できる新しいプラットフォームです。コンテナに必要なCPUとメモリ量を設定したら、あとはその割り当てたリソースに対して秒単位で料金が発生する仕組みとなっています。既に、Amazon ECSではLaunch TypeというパラメータをFARGATEとするだけで利用可能な状態でGAしています。FargateについてはAWS Fargate Advent Calendar 2017を開催していて、たくさんの日本語記事が集まっていますのでぜひこちらをご覧下さい。

EKSのroadmapとして、このFargate対応を予定しています。つまり、Kubernetesの機能をそのままにEC2インスタンスを起動することなくコンテナが実行できるようになる予定です。こちらについて興味のある方は、どういった形で実現されると嬉しいのかといったフィードバックをぜひ下さい。フィードバックの方法が分からなければ、AWS Japanの人に相談してみることをおすすめします。

オープンソース

最後に、オープンソースの重要性を話しています。例えば、最近Kubernetes 1.9で取り込まれたType LoadBalancerのNetwork Load Balancer(NLB)対応では、Pull RequestのコードレビューをAWSも実施しています⁶。CNI Pluginももちろんオープンソースで公開していますが、開発にあたっては外部のコミュニティと協力して行っていて、逆にコードレビューをしてもらっています。

今後もオープンソースのKubernetesのコミュニティへの貢献を続けていくのですが、重要なことはどういった貢献をしてほしいのかを皆さんがフィードバックして欲しいということです。もし何か既に欲しいものや、開始しているプロジェクトなどがあれば、ぜひフィードバックをして下さい。

まとめ

Amazon EKSのプレビューはこちらのサイトからお申込み下さい。そして、継続してフィードバックをお願いします。AWSのサービスのほとんどは皆さんからのフィードバックに基いて作られています。

最後に、AWS上でのKubernetesに興味がある方はまずこちらのWorkshopを試してみることを強くおすすめします。CNCFにAWSから主として参加しているArun Guptaが中心となって作成しており、以下の様な非常に豊富なコンテンツが揃っていて、初級から上級まで様々な体験をすることが簡単にできます。もし日本語でお手伝いしながらの実施をご希望される方がいればぜひお声がけ下さい。

• Beginner (100 level)
  • Prerequisites
  • Create a Kubernetes cluster using kops
  • First Steps with the Kubernetes CLI
  • Kubernetes Developer Concepts
• Intermediate (200 - 300 level)
  • Configuration and Secrets Management
  • Service Discovery with Microservices
  • Deploy Applications using Helm Charts
  • Updating Applications & Canary Deployment
  • Logging within a Kubernetes cluster
  • Monitoring within a Kubernetes cluster
  • Upgrading a Kubernetes cluster: In-place Upgrade
  • Cluster Scaling
  • Application Autoscaling
  • Application Tracing
• Advanced (300 - 400+ level)
  • StatefulSets with EBS
  • Specifying Network Policies
  • Using CoreDNS for Service Discovery
  • Managing IAM roles with kube2iam
  • ALB Ingress Controller
  • Kube AWS Ingress Controller and Skipper
  • Nginx Ingress Controller
  • Service Mesh Integration using Linkerd and Istio