阿里K8S容器服务和普通K8S有什么区别和共同点？[阿里云容器服务Kubernetes版] 暂停朗读为您朗读

1、新版本很性感，升级 or 不升级，这是个问题 K8S 是很活跃开源项目，更新很快，每次新版本都有让人眼前一亮的新功能。每次升级集群的过程都是巨大的大调整，带来巨大的运维负担。 某个客户A每次都“禁不住”诱惑，最后使用了至少三个版本的集群；而另外一个客户B则选择了不升级，停留在非常老旧的版本，受到掣肘，工作难以开展。

而阿里云的容器服务 K8S 提供升级方案，通过镜像滚动升级，且有完整的元数据备份策略。可以方便地回归到先前版本。一键升级，减少运维负担。

2、 应用的快速伸缩，想说爱你不容易 某研究机构使用自建的 K8S 进行大数据相关业务，涉及数据采集、清洗、训练等等。在高峰时期，自建集群无法快速伸缩容，导致处理进度停滞。

但是阿里云容器服务可以实现应用弹性伸缩，虚拟机节点的自动弹性伸缩，无需手动处理即可从容应对数据分析业务的高峰。

3、频繁发布，人为出错不可避免？ K8S 操作起来非常复杂，如果自建集群需要进行很多参数配置。某用户业务频繁发布，导致Ingress配置压力从而增加出错概率。

而容器服务的SLB方案支持原生的阿里云高可用负责均衡，自动完成网络配置的修改和更新，稳定性和可靠性大大超过用户自建的入口实现。

4、开源版本并不直接适用于企业级应用 开源版本是面向开发者爱好者，距离严肃的企业级应用场景，仍然有很多不足及空白。

比如，某用户A在使用自建 K8S 集群时，发现docker engine hang以及内核兼容问题；再比如，某用户B受困于社区版本中的一个网络bug， 用户受制于无力修复的开源版本问题。 但是容器服务提供了最佳实践，通过内核和docker engine的版本控制，参数调优，提供了docker ce兜底和docker修复的能力。

5、安全无小事，专业才能更安心 某客户因为配置失误导致K8S集群中了木马攻击，从而造成了巨大的损失。 容器服务所有组件提供了双向证书验证，另外预制开启了RBAC等鉴权能力，通过阿里云控制台可以安全地管理集群资源，避免了潜在的安全风险。

6、历经千锤百炼，大规模生产实践 另外一个例子是，用户自建镜像仓库，在百万级客户端同时拉取镜像时发生崩溃。 而阿里云的容器镜像仓库经过如双十一等实战打磨，可以轻松应此种规模。