吃力不讨好，自建 K8S 很辛苦
首先先分享自建 K8S 会遇到的几个痛苦场景：
case 1:新版本很性感，升级 or 不升级，这是个问题
K8S 是很活跃开源项目，更新很快，每次新版本都有让人眼前一亮的新功能。每次升级集群的过程都是巨大的大调整，带来巨大的运维负担。 某个客户A每次都“禁不住”诱惑，最后使用了至少三个版本的集群；而另外一个客户B则选择了不升级，停留在非常老旧的版本，受到掣肘，工作难以开展。
而阿里云的容器服务 K8S 提供升级方案，通过镜像滚动升级，且有完整的元数据备份策略。可以方便地回归到先前版本。一键升级，减少运维负担。
case 2: 应用的快速伸缩，想说爱你不容易
某研究机构使用自建的 K8S 进行大数据相关业务，涉及数据采集、清洗、训练等等。在高峰时期，自建集群无法快速伸缩容，导致处理进度停滞。
但是阿里云容器服务可以实现应用弹性伸缩，虚拟机节点的自动弹性伸缩，无需手动处理即可从容应对数据分析业务的高峰。
case 3: 频繁发布，人为出错不可避免？
K8S 操作起来非常复杂，如果自建集群需要进行很多参数配置。某用户业务频繁发布，导致Ingress配置压力从而增加出错概率。
而容器服务的SLB方案支持原生的阿里云高可用负责均衡，自动完成网络配置的修改和更新，稳定性和可靠性大大超过用户自建的入口实现。
case4: 开源版本并不直接适用于企业级应用
开源版本是面向开发者爱好者，距离严肃的企业级应用场景，仍然有很多不足及空白。
比如，某用户A在使用自建 K8S 集群时，发现docker engine hang以及内核兼容问题；再比如，某用户B受困于社区版本中的一个网络bug， 用户受制于无力修复的开源版本问题。
但是容器服务提供了最佳实践，通过内核和docker engine的版本控制，参数调优，提供了docker ce兜底和docker修复的能力。
case5：安全无小事，专业才能更安心
某客户因为配置失误导致K8S集群中了木马攻击，从而造成了巨大的损失。
容器服务所有组件提供了双向证书验证，另外预制开启了RBAC等鉴权能力，通过阿里云控制台可以安全地管理集群资源，避免了潜在的安全风险。
case6：历经千锤百炼，大规模生产实践
另外一个例子是，用户自建镜像仓库，在百万级客户端同时拉取镜像时发生崩溃。
而阿里云的容器镜像仓库经过如双十一等实战打磨，可以轻松应此种规模。
总结而言，自建 K8S 有哪些痛苦呢？
• 搭建集群繁琐。
• 在公共云上，需要投入大量的成本实现和云产品的集成
• 容器是一个系统性工程，涉及网络、存储、操作系统、编排等各种技术，需要专门的人员投入。
• 容器技术一直在不断发展，版本迭代快，需要不断的采坑、升级、测试。
• 容器平台的端到端的安全是在生产应用中比不可少的要素。
自己造的过程不仅痛苦，而且效果很差。
其实你不用重复造轮子，阿里云容器服务K8S的优势
选用阿里云容器服务K8S，究竟能带来哪些好处呢？
小结
阿里云容器服务Kubernetes兼容社区版本，作为CNCF白金会员、Docker唯一官方战略合作、CF黄金会员，获得全球首批Kubernetes一致性认证；此外，我们主动与社区合作为 Kubernetes 代码库做贡献。
同时，产品充分考虑到了企业级的稳定性、安全性需求。阿里云的容器服务，每个Linux版本，每个Kubernetes版本都会在经过严格测试之后才会提供给用户，经过大规模测试，具备多AZ支持，支持备份和容灾等众多特性。用户无需担心平台的稳定行，可以集中精力安心运行业务应用。
容器服务 Kubernetes 版提供高性能可伸缩的容器应用管理能力，支持企业级 Kubernetes 容器化应用的全生命周期管理。容器服务 Kubernetes 版简化集群的搭建和扩容等工作，整合阿里云虚拟化、存储、网络和安全能力，打造云端最佳的 Kubernetes 容器化应用运行环境
