亚马逊弹性容器服务提供了Kubernetes (EKS)和AWS Fargate两种选择
本文是个人意见,与所属组织的观点无关。

在2017年的AWS re:Invent大会主题演讲中,发布了Amazon EKS。
亚马逊弹性容器服务(Amazon Elastic Container Service)为Kubernetes(云原生应用编排平台)提供了托管服务,使用户能够轻松在亚马逊云平台上运行Kubernetes集群,无需自行安装和操作。
https://aws.amazon.com/jp/eks/
在这篇文章中,我想重点介绍在同样的re:Invent大会上举行的CON215: 介绍亚马逊弹性容器服务(Amazon Elastic Container Service)的Kubernetes内容,以及Amazon EKS是什么,以及与2018年计划合作的AWS Fargate是什么。
Kubernetes在AWS上
不久之前,Amazon Web Services加入了云原生计算基金会(Cloud Native Computing Foundation)作为白金会员,并开始托管许多项目,其中包括Kubernetes 1。根据在12月初举行的KubeCon + CloudNativeCon NA的最新调查2显示,目前有69%的人使用AWS,这是包括本地环境在内的最高使用率。
根据这些用户的反馈,管理Kubernetes主节点和分布式数据存储etcd是非常困难且无差别的重负劳动。
亚马逊弹性容器服务(Amazon EKS)的原则
根据这些反馈意见,我们开发了Amazon Elastic Container Service for Kubernetes(简称EKS)。在详细了解EKS的详细功能之前,先看看它的教义(Tenets)将有助于理解。
-
- Tenet 1: EKSはエンタープライズ企業が本番のワークロードを実行するためのプラットフォームであること
信頼性、可視性、スケーラビリティ、管理の容易さ
Tenet 2: EKSはネイティブで最新のKubernetesの体験を提供すること
現状でKubernetesで実現できることと同じことができる
Tenet 3: EKSユーザが他のAWSサービスを使うときには、シームレスな連携を実現し不要な作業を取り除くこと
Tenet 4: EKSチームは積極的にKubernetesプロジェクトに貢献していくこと
亚马逊EKS的架构说明
由于EKS提供完全托管的Kubernetes控制平面,您只需要使用分配的端点来加入该集群的节点和操作kubectl即可。控制平面采用多AZ架构,并由EKS进行监控,可以在需要时自动保持可用性并进行扩展。
Worker Nodes可以自行带入自由的EC2实例。这样,您可以充分利用例如Spot Fleet等现有的EC2功能,并且没有可用的Amazon Machine Image (AMI)限制。同时,我们也理解到有许多人不希望自己完成诸如Auto Scaling Group等设置以及在操作系统上进行Kubernetes所需的所有配置,因此我们计划提供以下内容:
-
- Amazon LinuxベースのEKS Worker Node用のAMI
更新があれば通知されるAmazon SNS Topicも提供予定
上記AMIをプロビジョンできるPacker3スクリプト
自由なOSをベースにして簡単にカスタムのEKS Worker Node AMIが作成可能
Worker Node設定用のAWS CloudFormationテンプレート
必要なパラメータを埋めるだけでWorker Nodesを立ち上げられるテンプレート
EKS的网络
Kubernetes的Pod(容器)需要具有专用的私有IP地址,并且能够在一个平坦的网络中彼此连接。实现这一点的方法可以是像Overlay Network这样的方式,即使用与节点网络完全不同的地址范围,但这往往会影响性能,并且在运维和故障排除方面也更加困难。
EKS团队正在开发一款新的CNI插件,以最大程度地利用Amazon VPC网络,并已经在GitHub上进行了公开。CNI是CNCF项目的一个,通过它可以对容器的网络设置进行标准化,不仅限于Kubernetes。通过将其作为CNI插件进行实现,可以实现网络配置的灵活性。
由於該插件支付的IP地址是可分配給EC2實例的彈性網路接口(ENI)的次要IP地址,因此它將成為所屬VPC CIDR範圍內的地址。因此,在VPC中可以在路由範圍內進行正常通信而無需進行任何特殊配置(安全組和NACL也按常規方式發揮作用)。由於一個ENI可以分配多個次要IP地址,因此還可以將多個IP地址集中在一個實例上。有關技術細節的詳細說明,請參閱CON409《Amazon彈性容器服務用於Kubernetes的深入探索》,如果您有興趣,建議您去查看一下。
上述的CNI插件不僅適用於EKS,而且也可以在目前在AWS上建立的Kubernetes叢集中使用。使用方法是將該插件與名為L-IPAM的組件一起配置在每個實例的DaemonSet中。在用於構建Kubernetes叢集的kops工具中,已經合併了使用此插件建立的選項,因此很快它可能也會包含在發行版中。
此外,使用这种设置方法,VPC的安全组将在ENI单位进行配置,因此无法为每个Pod使用不同的安全组。如果想要设置更详细的网络策略,可以使用Kubernetes提供的网络策略(Network Policy)功能。目前最常用的实现方式是Project Calico。虽然它是开源实现,但TIGERA公司也提供付费支持。这个CNI插件也与TIGERA合作,使得Project Calico可以在此插件中使用。
使用AWS IAM进行身份验证
在EKS中,我们使用AWS IAM对Kubernetes的Endpoint进行认证。我们利用Heptio开发的Authenticator来实现这个功能。通过这个功能,我们可以利用现有的IAM对可以访问EKS集群的身份进行认证(即确认他们是谁)。另一方面,关于已认证身份的授权(即他们有什么权限/没有什么权限),我们使用Kubernetes拥有的RBAC(基于角色的访问控制)功能。这是基于很多已经在使用RBAC并且认为它是必要的反馈而进行的设计。虽然kubectl还不支持IAM认证,但我们的EKS团队正在推进相关的改进工作。
对于技术细节,您也可以看一下CON409 Amazon Elastic Container Service for Kubernetes Deep Dive的解释,如果您感兴趣的话。
Kubernetes的版本
目前,EKS计划支持Kubernetes 1.7,并将在之后添加更多版本。补丁级别将自动应用最新版本,其中包括安全补丁,但对于次要版本,计划提供从最新版本到过去3个版本之间的选择。许多反馈表明希望能够精确控制次要版本的升级策略,因此EKS计划支持自动升级和手动升级的选择。
当继续使用旧版本且该版本的支持(包括补丁级别的适应)即将结束时,将提前通知并在规定时间内选择进行升级或自动升级。
自动缩放
关于主节点的自动伸缩,EKS会自动处理,无需担心。但是关于Pod和节点的自动伸缩,可以直接利用现有的Kubernetes自动伸缩功能。这包括Pod级别的伸缩和节点级别的伸缩,前者是根据诸如CPU利用率等指标来调整Pod数量,而后者是在Pod调度失败时自动增加节点数量。两种伸缩方式都可用。
当然有一些需要加强与AWS协作的部分,并且可以考虑一些功能,例如根据ELB的度量标准或者SQS队列的长度进行自动扩展。
私密链接
在EKS发布前不久,有一个名为AWS PrivateLink的新功能被发布。这个功能允许在VPC内创建ENI,作为各种AWS服务的终端节点(更准确地说,不仅限于AWS,任何人都可以注册服务)。计划提供使用PrivateLink的选项,使得可以将其应用于EKS的主节点终端节点,并且使用PrivateLink可以在不允许访问互联网的情况下使用EKS。
AWS Fargate 可实现原生的中文释义
AWS Fargate是在re:Invent Keynote上宣布的新的服务。这是一个无需基础设施的容器运行环境,是一个全新的平台,可以将注意力集中在容器上,而无需关心EC2实例。一旦设置了容器所需的CPU和内存,只需支付按秒计费的资源分配。在Amazon ECS中,已经通过将Launch Type参数设置为FARGATE来提供可使用的版本。关于Fargate,我们正在举办AWS Fargate Advent Calendar 2017,并汇集了许多日文文章,请务必参阅此处。

作为EKS的路线图,我们计划支持Fargate。也就是说,我们计划让容器能够在不启动EC2实例的情况下运行,同时保留Kubernetes的功能。如果您对此有兴趣,请告诉我们您希望如何实现。如果不知道如何提供反馈,请考虑咨询AWS Japan的人员。
开源
最后,我们谈到了开源的重要性。例如,最近在Kubernetes 1.9中引入的Type LoadBalancer的Network Load Balancer(NLB)支持,AWS也进行了Pull Request的代码审核。CNI插件当然也是开源的,但在开发过程中,我们与外部社区合作,并得到了他们的代码审核。
我們將繼續對開源的Kubernetes社區做出貢獻。重要的是,我們希望大家能給予我們反饋,告訴我們你們希望我們做出什麼樣的貢獻。如果你們已經有任何需求或已經開始的專案,請務必給予我們反饋。
总结
请在此网站上申请Amazon EKS的预览版,并且我们恳请您持续提供反馈意见。AWS的大多数服务都是基于您的反馈意见而开发的。
最后,我强烈推荐对在AWS上使用Kubernetes有兴趣的人首先尝试这个工作坊。这个工作坊是由来自AWS的CNCF成员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
以下是对上述内容的中文释义:
– [Cloud Native Computing](https://medium.com/@adrianco/cloud-native-computing-5f0f41a982bf): 云原生计算
– [Cloud Native Technologies Scaling Production Applications](https://www.cncf.io/blog/2017/12/06/cloud-native-technologies-scaling-production-applications/): 云原生技术扩展生产应用
– [HashiCorp](https://www.packer.io/intro/index.html): HashiCorp是提供镜像制作工具的公司
– [在AWS上,除了这个插件外,还有其他机制用于实现Amazon ECS的任务网络,作为CNI插件也已经公开。此处是其GitHub链接,并解释了其行为。](https://github.com/containernetworking/plugins): CNI插件是用于Amazon ECS任务网络的一种机制,并且AWS除了该插件之外还有其他机制。链接提供了GitHub相关内容,并解释了该插件的功能。
– [点击此处查看PR。截至2017年12月21日,使用此功能需要自己构建kops的最新版本。此处提供了示例步骤。](https://gist.github.com/arun-gupta/87f2c9ff533008f149db6b53afa73bd0): 请点击此处查看PR。截至2017年12月21日,若要使用该功能,需要使用最新版本的自行构建的kops。此处提供了示例步骤。
– [https://github.com/kubernetes/kubernetes/pull/53400](https://github.com/kubernetes/kubernetes/pull/53400): 该链接是关于Kubernetes的PR。