在很多项目的发展初期，都是小型或者大型的单体项目，部署在单台或者多台服务器上，以单个进程的方式来运行。这些项目随着需求的递增，发布周期逐渐增长，迭代速度明显下降。传统的发布方式是：开发人员将项目打包发给运维人员，运维人员进行部署、资源分配等操作。

随着软件行业架构方式的改变，这些大型的单体应用按照业务或者其他维度逐渐被分解为可独立运行的组件，我们称之为微服务。微服务彼此之间被独立开发、部署、升级、扩容，真正实现了大型应用的解耦工作。关于微服务的介绍，大家可以去撸一下菜菜之前的文章：

https://mp.weixin.qq.com/s/b7Bd8giwWVNF1CtkaDaVpw

https://mp.weixin.qq.com/s/BixgyGFrlwZ7wpgDdrmU_g

软件开发行业就是这样奇葩，每一个问题被解决之后总是伴随着另外的问题出现，就像程序员改bug，为什么总有改不完的bug，真的很令人头大！！!

微服务虽然解决了一些问题，但是随着微服务数量的增多，配置、管理、扩容、高可用等要求的实现变的越来越困难，包括运维团队如何更好的利用硬件资源并降低服务器成本，以及部署的自动化和故障处理等问题变得原来越棘手。

以上问题正是kubernetes要解决并且擅长的领域，它可以让开发者自主部署应用，自主控制迭代的频率，完全解放运维团队。而运维团队的工作重心从以往的服务器资源管理转移到了kubernetes的资源管理。kubernetes最厉害之处是对硬件基础设施进行了封装和抽象，使得开发人员完全不用去了解硬件的基础原理，不用去关注底层服务器。kubernetes内部把设置的服务器抽象为资源池，在部署应用的时候，它会自动给应用分配合适合理的服务器资源，并且能够保证这些应用能正常的和其他应用进行通信。一个kubernetes集群的大体结构如下：