为什么我说小公司也一定要用K8S

Kubernetes是谷歌以Borg为前身，基于谷歌15年生产环境经验开源的一个项目。Kubernetes致力于提供跨主机集群的自动部署、扩展、高可用以及运行应用程序容器的平台，其遵循主从式架构设计，其组件可以分为工作节点（Node）组件和控制平面组件。Kubernetes Master是集群的主要控制单元，用于管理其工作负载并指导整个系统的通信。Kubernetes控制平面由各自的进程组成，每个组件都可以在单个主节点上运行，也可以在支持高可用集群的多个节点上运行。

为什么要用Kubernetes

很多人会有疑问，有Docker了为什么还用Kubernetes？在业务开始进行容器化时，前期需要容器化的项目可能并不多，涉及的容器也并不多，此时基于Docker容器直接部署至宿主机也能实现自己的需求。但是随着项目越来越多，管理的容器也越来越多，此时使用“裸容器”部署的方式管理起来就显得很吃力，并且随着业务量的增加，会明显体会到“裸容器”的不足，比如：

• 宿主机宕机造成该宿主机上的容器不可用，且无法自动恢复。
• 容器明明在运行，接口就是不通（健康检查做得不到位）。
• 应用程序部署、回滚、扩缩容困难。
• 成百上千的容器和涉及的端口难以维护。

上面的问题只是做一个简单的罗列，真正使用时还有很多其他的问题。可能你也体验过过像docker-compose、docker-swarm等编排工具，但这些工具的功能和Kubernetes的功能还是相差甚远，所以注定Kubernetes编排工具将成为主流的容器编排工具。

对于开发人员

由于公司业务多，开发环境、测试环境、预生产环境和生产环境都是隔离的，而且除了生产环境，为了节省成本，其他环境可能没有进行日志收集。在没有用Kubernetes的时候，查看线下测试的日志，需要开发或者测试人员找到对应的机器，再找到对应的容器，才能查看日志。在使用Kubernetes之后，开发和测试人员直接在Kubernetes的Dashboard上找到对应的Namespace，即可定位到业务的容器，然后可以直接通过控制台查看到对应的日志，大大降低了操作时间。

把应用部署到Kubernetes之后，代码的发布、回滚以及蓝绿发布、金丝雀发布等都变得简单可控，不仅加快了业务代码的迭代速度，而且全程无须人工干预。生产环境可以使用Jenkins、GitRunner等工具进行发版或回滚等。从开发环境到测试环境，最后到生产环境，完全遵守一次构建，多集群、多环境部署，通过不同的启动参数、不同的环境变量、不同的配置文件区分不同的环境。

在使用服务网格后，开发人员在开发应用的过程中，无须再去关心代码的网络部分，这些功能都被服务网格实现，让开发人员可以只关心代码逻辑部分，即可轻松实现网络部分的功能，比如断流、分流、路由、负载均衡、限速和触发故障等功能。

在测试过程中，可能同时存在多套环境，当然也会创建其他环境或临时环境，之前测试环境的创建需要找运维人员或者自行手工搭建。在迁移至Kubernetes集群后，开发人员如果需要新的环境，无须再找运维，只需要在Jenkins上点点鼠标即可在Kubernetes集群上创建一套新的测试环境。

对于运维人员

对于运维人员，可能经常因为一些重复、烦琐的工作感觉厌倦，比如一个项目需要一套新的测试环境，另一个项目需要迁移测试环境至其他平台。传统架构可能需要装系统、装依赖环境、部署域名、开通权限等，这一整套下来，不仅耗时，而且可能会因为有某些遗漏而造成诸多问题。而如今，可以直接使用Kubernetes包管理工具，一键式部署一套新的测试环境，甚至全程无须自己干预，开发人员通过Jenkins或者自动化运维平台即可一键式创建，大大降低了运维成本。

在传统架构体系下，公司业务故障可能是因为基础环境不一致、依赖不一致、端口冲突等问题，而现在使用Docker镜像部署，Kubernetes进行编排，所有的依赖、基础都是一样的，并且环境的自动化扩容、健康检查、容灾、恢复都是全自动的，大大减少了因为这类基础问题引发的故障。另外，也有可能公司业务由于服务器宕机、网络等问题造成服务不可用，此类情况均需要运维人员及时去修复，而在Kubernetes中，可能在收到严重告警信息时，Kubernetes已经恢复完成了。

在没有使用Kubernetes时，业务应用的扩容和缩容都需要人工去处理，从采购服务器、上架到部署依赖环境，不仅需要大量的人力物力，而且非常容易在中间过程出现问题，又要花费大量的时间去查找问题。成功上架后，还需要在前端负载均衡添加该服务器。而如今，可以利用Kubernetes的弹性计算一键式扩容和缩容，不仅大大提高了运维效率，而且还节省了不少的服务器资源，提高了资源利用率。

在反向代理配置方面，可能对Nginx的配置规则并不熟悉，一些高级的功能也很难实现，但是在Kubernetes上，利用Kubernetes的Ingress即可简单地实现那些复杂的逻辑，并且不会再遇到Nginx少加一个斜杠和多加一个斜杠的问题。

在负载均衡方面，之前负载均衡可能是Nginx、LVS、HAProxy、F5等，云上可能是云服务商提供的负载均衡机制。每次添加删除节点时，都需要手动去配置前端负载均衡，手动去匹配后端节点。在使用Kubernetes进行编排服务时，使用Kubernetes内部的Service即可实现自动管理节点，并且支持自动扩容、缩容。

在高可用方面，Kubernetes天生的高可用功能让运维人员彻底释放了双手，无须再去创建各类高可用工具，以及检测脚本。Kubernetes支持进程、接口级别的健康检查，如发现接口超时或者返回值不正确，会自动处理该问题。

在中间件搭建方面，根据定义好的资源文件，可以实现秒级搭建各类中间件高可用集群，并且支持一键式扩容、缩容，如Redis、RabbitMQ、Zookeeper等，并且大大减少了出错的概率。

在应用端口方面，传统架构中，一台服务器可能跑了很多进程，每个进程都有一个端口，需要人为地去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙。在Kubernetes中，端口统一管理、统一配置，每个应用的端口都可以设置成一样的，之后通过Service进行负载均衡，大大降低了端口管理的复杂度和端口冲突。

无论是对于开发人员、测试人员还是运维人员，Kubernetes的诞生不仅减少了工作的复杂度，还减少了各种运维成本。上述带来的便利性只是比较小的一部分，更多优点只有用了才能真正体会到。

同时，为了让大家更好的学习云原生K8S知识，会送给大家一份我整理了一个月多的K8S实战操作资料。关注公众号「程序员溪昂」，回复云原生资料即可。