ECS vs. Kubernetes 类似而又不同

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
云服务器(按量付费),48vCPU 186GiB
简介: C2Container Service (ECS)和Kubernetes (K8s) 都解决了同样的问题:跨越主机集群管理容器。ECS和Kubernetes之间的斗争让我想起了vi和Emacs之间的编辑器之战:激烈的讨论集中于技术问题和个人信仰上。

C2Container Service (ECS)和Kubernetes (K8s) 都解决了同样的问题:跨越主机集群管理容器。ECS和Kubernetes之间的斗争让我想起了vi和Emacs之间的编辑器之战:激烈的讨论集中于技术问题和个人信仰上。接下来的问题将帮助你明智的选择。考虑到问题和答案包含了我的主张——ECS和K8s之间的区别,基于我最近项目上的经验。


它合适吗?

一个容器是一个隔离的元素。但是跨主机集群启动容器只是挑战的一小部分。你的容器在一个由基础设施和服务组成的世界中存在:举几个来说,存储系统,数据库,域名服务。

你打算在哪运行你的容器?

  • Amazon Web Services (AWS)
  • Google Cloud Platform (GCP)
  • 其他IaaS供应商

本地部署

能够整合容器管理解决方案到基础设施中是关键。

ECS在容器和其他AWS服务之间提供最无缝的集成。下面是几个例子:

  • 分配IAM角色给每个容器,允许细粒度访问控制其他服务。
  • 在外部负载均衡器注册容器(应用负载均衡器)。
  • 基于集使用扩展EC2实例(自动伸缩)。
  • 收集日志(监测日志)。

在K8s和AWS之间实现一个类似水平的集成是一个大量的工作。例如,用etcd构建一个生产就绪的关键值存储,需要K8s,需要高可用,加密,和几周的滚动更新。通过负载均衡器和域名系统集成K8s是另一个重大的障碍。

另一方面,K8s提供了与GCP免费的集成。Google Container Engine提供以下内容:

  • 在多个高可用区域之间分布集群。
  • 基于使用扩展集群。
  • 为容器提供持久的磁盘。

K8s在使用Google Container Engine(GKE)时提供了最大的价值,因为它与GCP集成。

如果你正在使用其他IaaS供应商,而不是Amazon和谷歌,或运行在本地部署上,那么K8s是唯一的选择,因为ECS只在AWS上运行。可比较的ECS在AWS上或在K8s在GCP上,在这种情况下,构建一个类似的基础设施将是大量工作。

它和你的架构匹配吗?

ECS和K8s在服务发现上遵循不同的策略。

ECS使用负载均衡器进行服务发现。通过负载均衡器可以访问外部和内部服务。应用程序负载均衡器(ALB)提供路径和基于主机的路由以及内部或外部连接。

K8s使用不同的策略。只有来自集群外部的请求通过负载均衡器。虚拟IP提供对内部服务的访问,而不需要负载均衡器。

如果你的微服务架构严重依赖服务到服务通信,K8s提供较少的通信成本。除此之外,ECS也为微服务体系结构提供了朴素而简单的方法。特别是,如果大部分的服务需要从互联网上进行访问。

谁运营它?

我强烈反对你自己去运营一个容器集群,只要可能。或者,一个自己动手的容器基础设施是否有有价值会增加你的业务?

通过ECS提供的集群管理是一个完成的管理服务,提供高可用,可扩展性和安全。使用ECS没有额外费用,而且它也被AWS支持计划所覆盖。但是,你仍然对由EC2和VPC组成的底层基础设施负责。

Google Container Engine(GKE)也提供管理服务。GKE提供管理K8s集群包括底层基础设施。如果你的集群由超过5个节点组成,Google的管理费用是每月100美元。

它成功了吗?

K8s在Apache许可2.0下获得许可,然而ECS是AWS提供的专有服务。尽管如此,AWS发布了Blox,这是一个开源项目的集合,用于在ECS上进行容器管理和编排。

K8s社区充满活力,产生了许多创新的解决方案。开源生态系统提供了灵活性。但是不要期望除了K8s核心之外的生产解决方案。

厂商锁定一个流行的争论在ECS与K8s讨论中。我认为,ECS和K8s都将你锁定在他们的解决方案中。尽管K8s是开源的,但是谷歌在技术演变和商业化其云平台方面是主要贡献者。

总结

你有在用AWS作为基础设施供应商吗?使用ECS来管理和调度容器,并从高度集成和完全托管的服务中获益。

你是否使用GCP作为基础设施提供商?使用谷歌容器引擎(GKE)提供完全管理的K8s集群,并集成到GCP基础设施中。

你是在本地部署上运行还是使用另一个IaaS提供商?运营K8s集群可能是你唯一的选择。在集成你现有的基础设施,构建一个高可用和伸缩的K8s集群时,预期会有大量的eff。

本文转自中文社区-ECS vs. Kubernetes 类似而又不同

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
1天前
|
弹性计算 Kubernetes 监控
【阿里云弹性计算】阿里云 ECS 与 Kubernetes 集成:轻松管理容器化应用
【5月更文挑战第28天】阿里云ECS与Kubernetes集成,打造强大容器管理平台,简化应用部署,实现弹性扩展和高效资源管理。通过Kubernetes声明式配置在ECS上快速部署,适用于微服务和大规模Web应用。结合监控服务确保安全与性能,未来将深化集成,满足更多业务需求,引领容器化应用管理新趋势。
15 2
|
13天前
|
应用服务中间件 网络安全 Apache
构建高性能Web服务器:Nginx vs Apache
【5月更文挑战第16天】Nginx与Apache是两种主流Web服务器,各具优势。Nginx以其轻量级、高并发处理能力和反向代理功能见长,适合大型网站和高并发场景;而Apache以功能丰富、稳定性强闻名,适合企业网站和需要多种Web服务功能的场景。在性能上,Nginx处理高并发更优,Apache则可能在高负载时遭遇瓶颈。在选择时,应根据实际需求权衡。
|
14天前
|
弹性计算 运维 Kubernetes
云原生K8S场景自动化响应ECS系统事件
客户云原生K8S场景下,通过社区开源NPD+Draino+Autoscaler零开发,对接响应ECS主动运维事件,通过自动响应事件减少非预期宕机。
|
14天前
|
Kubernetes 网络协议 网络架构
「译文」比较开源 k8s LoadBalancer-MetalLB vs PureLB vs OpenELB
「译文」比较开源 k8s LoadBalancer-MetalLB vs PureLB vs OpenELB
|
7月前
|
存储 Kubernetes NoSQL
【K8S系列】第七讲:有状态服务 VS 无状态服务
【K8S系列】第七讲:有状态服务 VS 无状态服务
241 0
|
9月前
|
Kubernetes Devops 关系型数据库
阿里云内部K8s、ECS、RDS、DevOps实战手册,超赞
有不少小伙伴,一直在后台问我要一些资料,同时,我也在想,其实大家谁都不缺资料,缺的是有实战价值,能够看了之后在实际的工作环境可以用起来的实战技术资料,而并非那些纸上谈兵的理论,所以。。。
|
10月前
|
Kubernetes 负载均衡 网络协议
简单操作:10分钟实现在kubernetes(k8s)里面部署服务器集群并访问项目(docker三)
简单操作:10分钟实现在kubernetes(k8s)里面部署服务器集群并访问项目(docker三)
|
10月前
|
存储 Kubernetes Cloud Native
Kubernetes vs OpenShift浅析
古语有云:“知彼知己,百战不殆。不知彼而知己,一胜一负。不知彼,不知己,每战必殆。” 这句话同样也适用于技术体系。无论我们在落地,还是在学习、实践某一项技术,对提供相同功能的体系框架的对比学习,可以使得我们能够快速、全面地去拥抱其生态。
254 0
|
11月前
|
Kubernetes 负载均衡 算法
对决:Kubernetes vs Docker Swarm - 谁才是最优秀的容器编排方案?
对决:Kubernetes vs Docker Swarm - 谁才是最优秀的容器编排方案?
259 0
|
Kubernetes 调度 C++
kubernetes的节点与节点池概念 vs karpenter的去节点池理念 在调度上的思考
kubernetes的节点与节点池概念 vs karpenter的去节点池理念。 k8s在给定的节点资源或集群资源上调度并运行应用,其先决条件是资源某种程度上既定(即资源总量某种程度上是一定的,虽然有弹性扩容,但资源的规格是固定的,并且一旦扩容完成后再在此资源总量上执行调度决策,这仍然可以看做是资源总量固定),然后在该资源范围上做调度决策。调度的碎片化不可避免。 karpenter的逻辑是去节点
436 0