Amazon EKS

Amazon EKS 跨多个 AWS 可用区为您运行 Kubernetes 管理基础设施，从而消除单点故障。Amazon EKS 经认证可与 Kubernetes 兼容，因此您可以使用合作伙伴和 Kubernetes 社区提供的已有工具和插件。所有标准 Kubernetes 环境上运行的应用程序均完全兼容，并可轻松迁移到 Amazon EKS。

Amazon EKS 可运行上游 Kubernetes，且经认证可与 Kubernetes 兼容，因此 Amazon EKS 托管的应用程序与所有标准 Kubernetes 环境托管的应用程序完全兼容。 

Amazon EKS 可跨多个 AWS 可用区预配置和扩展 Kubernetes 控制平面（包括 API 服务器和后端持久层），从而获得高可用性和容错能力。Amazon EKS 可自动检测和替换运行状况不佳的控制平面节点并修补控制平面。Amazon EKS 可与许多 AWS 产品集成，为应用程序提供可扩展性和安全性。这些产品包括用于分配负载的 Elastic Load Balancing、用于身份验证的 IAM、用于隔离的 Amazon VPC、用于访问私有网络的 AWS PrivateLink 和用于日志记录的 AWS CloudTrail。

http://www.bmc.com/blogs/aws-ecs-vs-eks/

 

If EKS is so powerful, why wouldn’t it be the automatic choice for new workloads? It turns out that because ECS simple yet mature, it still has a lot to recommend it:

• DevOps teams leveraging Terraform, Elastic Beanstalk, or other “software defined infrastructure” tools will generally find ECS well supported in these apps.
• The learning curve in ECS is much lower. Organizations with limited DevOps resources, or that are not prepared to re-architect applications around concepts like Pods, may find ECS easier to adopt.
• While Kubernetes offers many more choices regarding add-ons in its ecosystem, each choice requires time, resources, and maintenance to leverage fully. ECS has only one option in each category: if it meets your needs, you’re already done.
• If Kubernetes is a long-term goal but “too much” to adopt all at once, ECS can be a compatible first step, allowing an organization to implement a containerization strategy and move its workloads into a managed service with less up-front investment.

On the other hand, ECS can sometimes be too simple, and there are even a few lightly-documented “gotchas” that may be obstacles for some apps:

• Without a concept similar to Pods, fine-grained control over container placement is not possible. Many (most?) applications can live without this – but for those that require it, this could be a total blocker.
• Particularly when run via ECS Fargate, some additional technical limitations may apply. For instance, the only networking mode available is “awsvpc” which at the time of this writing does not allow custom hosts table definitions for running tasks (they are overridden), and may only run images from ECR or Docker Hub (public repositories).
• ECS management tools are limited to the Web Console, CLI, and SDKs. Logging and performance monitoring are done through CloudWatch, deployments through ECS itself, and service discovery via Route 53. If any of these tools are unacceptable, it may be time to step up to EKS.

In the end, every organization has different needs, and both options have pros and cons: there is no one “right” answer here. However, in this author’s opinion, there is a simple litmus test that can be applied: If you know you need Kubernetes, then you need EKS. If you do not know, you probably don’t – consider starting with ECS first.