使用容器服务Kubernetes 与自建Kubernetes的区别_运维_weixin

吃力不讨好，自建 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 有哪些痛苦呢？
• 搭建集群繁琐。
• 在公共云上，需要投入大量的成本实现和云产品的集成
• 容器是一个系统性工程，涉及网络、存储、操作系统、编排等各种技术，需要专门的人员投入。
• 容器技术一直在不断发展，版本迭代快，需要不断的采坑、升级、测试。
• 容器平台的端到端的安全是在生产应用中比不可少的要素。
自己造的过程不仅痛苦，而且效果很差。