Aws EKS Vs AliCloud ACK 体会

最近因为工作需要，深刻的体验了，Aws EKS（Aws 托管 k8s 集群）& AliCloud ACK（AliCloud 托管 k8s 集群），写下简单 Ops 相关的一些体验吧。

EKS

• Amazon EKS 是什么？
• 架构上面很清晰，一个全托管的 Master 在一个 aws 的 vpc 内，与用户的 Node Group 来进行 api 交互，配合 Aws 完善的 API & RAM 机制保证自动化 & 安全性，配合 ami + launch template + labels/tags 来做到独占 Or 特殊化部署，这样在日常运维上面的体感非常的优雅
• 用户只要认认真真、仔仔细细的看文档并实践即可高效的上线一套生产级集群
• 网络相关有 Aws 自己的 CNI 插件并社区非常活跃
• 省去了维护任务最重的 Master 节点，用户只要使用 node group 配合 HPA + Cluster autoscaler 即可从让 Ops 从重复的添加机器这种事情上面完全解放出来

ACK

• AliCloud ACK 是什么？
• 架构上面很清晰，同样是一个全托管的 Master 在一个 阿里云的vpc 内，与用户的机器组来进行交互，但是 API 的逻辑存在问题，创建集群的时候强耦合，必须让 master & 默认的机器组同时创建，RAM 相关还是完善的，同样在体感上面比较特别，需要一路点点点
• 用户看完文档只能知道一个大概，需要阿里云支持同学配合教学 & 后台配合，方可在首次使用的时候顺利启动一个集群
• 网络相关有以自己的 CNI 插件 厂商也在努力的迭代，这个还是很看好的
• 在熟悉了一段时间后同样也是解放生产力的，机器组配合 HPA + Cluster autoscaler （能不能顺利弹出，看库存，可以尝试使用 阿里云 RI），集群逻辑就是在创建的时候比较别扭，熟悉了也还好

差异总结

• ACK 有非常配合 ARMS + SLS 可以比较顺利的通过控制点出一套完整的周边 （SLS 很赞，就是有点贵）
• EKS 同样可以基于 CloudWatch 来实现监控 & 日志，但是 CloudWatch 又贵又难用（就不能好好弄吗）
• EKS API 非常完善，ACK API 非常着急
• istio 的话 EKS 全部需要用户自行完成，有好有坏吧，需要用户有比较强的能力，ACK 有一个托管的，但是同样在一些管理接口的api 上面不是很完善
• 总体而言，ACK 已经可以上生产也非常稳定，已经上线了 Pro 版本，可以看出阿里云在这块在持续努力，aws & 阿里云 k8s 产品上面基本上，简单使用 & 正常使用的话，基本上均很完善，比如 Serverless 产品、Huber 产品等，同样也支持把自建 k8s 插入托管集群，产品上面的契合度还是很高的

有了托管，用户自己还能做很多事情，把 Ops/Infra 同学从重复 & 没有价值的事情里面解放出来，蛮好的 （最近中毒 AWS）