这一次我们探讨的主题是 企业部署 Kubernetes 的终极目标是什么 。
Kubernetes，是一个开源的，用于管理云平台中多个 主机 上的 容器化的应用 。Kubernetes 这个名称中间有 8 个字母，所以也简称为 K8S 。
答案其实不复杂，企业部署 K8S 的终极目标是 节约运营成本 。
与此同时，也顺带兼顾到了工程层面自动化的推动。
资源消耗层面
以前的部署，我们是在一台机器上部署，或者安装多个虚拟机再部署。
虚拟机提供了一套完全隔离的环境，每个虚拟机都有一个属于自己的内核，这些都属于重型资源消耗；
而时下所提倡的 K8S，就囊括了一项很重要的容器技术，它调用的是同一个内核，同一个操作系统，也不存在开机、关机的概念，可以采用进程的方式来快速启动，这在整体上资源消耗就非常少。
组织架构的关注点分离
无论是企业内部，还是云端服务的部署，成功运行一个应用，交付给业务部门并最终服务于用户，这是开发者和运维团队的共同目标。
但他们也有个人目标和驱动因素，热衷于创造新功能的开发者，通常并不想成为底层操作系统和网络的维护者，而是交由运维团队或者系统管理员来做。
运维团队肯定会负责硬件基础设施，以及工程化层面的部署流程，但是他们对开发出来的应用程序之间的依赖关系，以及在基础设施发生改变时，对应用程序可能造成的影响就有些拿捏不准，甚至力有未逮。
这个问题 Google 在好多年前就意识到了，而且也解决了。
然后 Google 就把 K8S 开源了，它的强项在于，对硬件资源做了一层抽象（或者说是接口），然后自身会暴露成为一个资源平台，让开发者和运维者在这个平台可以愉快的做组合游戏，那用来盛放组合元素的实体就叫容器。像这个容器在设计之初，就考虑了跨机连接的需求，让服务间的通信更便利，这就为时下的微服务又奠定了平台基础。
有了以上的抽象平台，开发者可以自己配置和部署应用程序，而不需要系统管理员经手；作为系统管理员只要聚焦于，确保底层基础设施运转正常就可以。
那么，作为软件架构师在设计一套系统或者框架时，我们往往都会考虑采用关注点分离这个原则，让特定问题得以凸显，然后有针对性的解决。
现在我们升华一下，在组织架构层面，或者说在敏捷团队的实践里，是不是也可以做关注点分离呢？在我看来呢，K8S 平台其实就是践行了 关注点分离，它可以让开发者和运维人员各司其职，然后再以 Devops 这样一个流程理念来强化融合，确保沟通顺畅。
更完整的内容，可以 [查看视频格式] 。