随着数字化转型的大潮到来，越来越多的企业开始上云，同时也纷纷加入到微服务和K8S队伍中。但在K8S整体环境究竟应该用自建的还是非自建？以及他们需要用到的服务，究竟应该自建还是直接用PAAS服务？这些问题往往会困扰住大家。
我在这里以中立的角度阐述下各自的优劣，给大家提供一些参考帮助大家能做出更利于公司发展的选择。1、什么是自建K8S？
所谓自建，就是使用自己在物理机和虚拟机上部署的开源Kubernetes平台。
非自建就是云上的PAAS服务，全套的从物理层到容器层的环境都由云厂商提供，底层也是基于开源的Kubernetes打造的，云上一般都自带管理工具。
K8S平台无论你用云上的还是自建的，其底层都是一样的。云上的服务会比自建的多一个管理界面，让管理K8S平台变得更容易。在实际生产过程中，我们也很少需要登录到Master节点上去进行命令行操作。发布可以通过统一的发布平台，看日志排错可以通过统一的日志平台。只有极少数的紧急突发情况需要登录到K8S的容器环境里去进行生产的直接调试排错。因为整个K8S环境是面向所有服务的，所以要尽可能的避免直接登录到K8S服务器上进行操作。然后回到对比这个问题的本身，个人认为云上的服务比自建要好。云上优势如下：云上K8S服务除了不需要你部署之外，产品自身出现问题均有客服帮你解决。且自带的管理界面基本满足日常的配置需求。如果你要和NAS或其它PAAS服务做集成，那肯定是用云上的更方便，如果是自建的会有一定的定制开发成本甚至完全无法集成都有可能。稳定性为什么会比自建高呢？因为自建的是面向所有大众的哪怕有人踩过了坑但他解决后不提交问题，所以这个问题仍然存在未被修复。而云上的只要有人反馈必定会被解决，而且厂商肯定会想办法修复这些问题避免其它客户踩坑。不要小看这个优势，也许有一天他是你业务能快速恢复的救命稻草。根据选择的版本不同会有价格的差异，部分版本会收取额外的平台增值费用。案例1：某服装电商K8S选型历程
该公司最初为了不被云厂商绑定，选择了自建k8S平台，但在运行一段时间准备上生产之前，突然K8S网络出现故障，持续数日无法解决问题。最后，还是选择云上K8S服务，运行至今未出现任何问题。案例2：某在线教育公司自建K8S故障
该公司初期资源都在IDC机房，和上面案例一样，某一天突然K8S网络出现故障，导致生产业务全部中断，所幸当时已过了业务高峰期，在确定无法修复的前提下进行重新环境部署和生产发布调试，整个过程持续了一天一夜。在做这个对比之前，我首先要灵魂拷问一下读者，你要用这个管理平台做什么？是想要一个能从创建到应用发布多功能的平台，还是要一个只管理K8S平台自身的工具。如果你想要一个多功能的平台，那这个平台是否直接支持云上K8S服务？功能是不是全部满足？每个功能模块是不是足够出色？如果有新功能需求是否支持定制开发？还有如果是第三方产品，本身出问题或不更新维护了是否意味着业务将停止不前？所以管理平台我建议还是选用只管理K8S平台自身的工具，让非K8S自身的模块交给其它专业的工具去处理。如果是用云服务的那用云服务自身的管理平台就足够了。下面我分别介绍一个第三方的和阿里云自身K8S管理平台，并做下比较供大家参考。Rancher是一个开源的企业级容器管理平台。通过Rancher，企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。Rancher由以下四个部分组成：
整体来说Rancher满足企业日常的K8S平台管理功能，同时他也能管理主流的云上K8S服务集群。如果作为一个K8S基础管理平台，它是完全符合的。
阿里云ACK平台在经过数年打磨之后已经相当成熟和稳定，功能也比较丰富，并且可以结合服务网格服务进行流量的管控。
它主要功能如下：
除了可以管理自身的集群外，也可以通过注册集群管理外部的Kubernetes集群：• 镜像服务
• 编排模版
• 应用市场
可以多云多集群的部署分发：
• 备份中心
备份中心为Kubernetes集群中应用/数据提供了备份、恢复与迁移的一站式的解决方案，并支持跨集群和混合云。从功能来说阿里云ACK平台要比Racher更强大。完全可以满足企业的日常需求。针对K8S配套的数据库和中间件
使用自建和PAAS服务选型
如果你是怕被绑定而选择自建服务，那大可不必。因为在你选择拥抱公有云的那刻起你就注定了会被公有云给绑定。它的优劣和选择自建和非自建K8S服务基本是一样。核心点也是稳定性，PAAS服务的稳定性要大于你自建服务。而且PAAS服务通常会伴随着各家云的一些特色功能。比如阿里云的RDS原生支持数据存储加密和传输加密，还支持读写分离。做备份和容灾也更容易。也许你还会问如果你要迁移怎么办？迁移的话无论你是用自建还是PAAS服务都是可以迁移的，两者在耗时上实际是差不多的。迁移服务一直都不是一件容易的事。现在各家平台和厂商都会在管理K8S的时候集成发布平台。但要把发布这个工作做好并不容易。各家平台提供的大多数是基础的修改Yaml配置来达到发布的效果。如果要在发布流水线中集成代码安全扫描和自动化测试会变得很困难。所以专业的发布工作还是要交给专业的发布工具。例如：Jenkins。K8S环境应该为业务服务，要力求稳定、可弹性，其它任何理由均要在这个基础上才能做进一步的分析。一、K8S平台选择自建还是非自建个人建议选择非自建的PAAS服务，原因是更稳定。无论其它理由在怎么充分稳定肯定是业务的首要关注点。如果非要尝试自建则建议在非生产环境部署同样版本的K8S环境。二、K8S管理平台选择顺序如下：
• 如果云环境自带的管理平台功能满足则优先使用云平台自带的。
• 如果云环境自带功能不满足则考虑多个产品同时使用，不建议绑死在一个产品上。三、数据库和中间件选择云的PAAS服务，如果是非核心业务且对稳定性要求不高的可以考虑自建。四、CICD使用专业的工具，前期维护成本略高，后期稳定后只要修改下模板参数即可。最后建议，如果最终目标是想要实现PAAS服务自建的，建议在非生产环境做。如果有一天认为各方面条件都达到上生产环境了。则进行逐步的生产环境业务替换。把生产环境的PAAS服务逐步替换成自建服务。
