kubernetes为什么会火？为什么值得我们学习？

首先抛出我的结论，kubernetes一定会火，非常值得我们学习。

就像N年前企业需要自建机房部署服务器，当阿里云等云厂商兴起之后，大家都开始“上云”了，既方便快捷稳定，又免去了运维人员的开销。

而kubernetes能进一步解放生产力，提高项目部署的灵活性，提高应用的容灾能力，动态伸缩等。

简介

Kubernetes(简称：k8s)是Google开源的容器集群管理系统，是一个全新的基于容器技术的分布式架构领先方案，简单来说K8S是容器编排管理平台。

在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

一图胜前言

构成要件

• Kubernetes集群主要由Master和Node两类节点组成
• Master的组件包括：etcd、Api Server、Scheduler和Controller Manager等几个组件，其中Api Server是整个集群的网关。
• Node主要由Docker、Kubelet、Kubenetes Proxy等组件组成。

功能介绍

Master

• 是Kubernetes的主节点，管理节点。
• 是集群的网关和中枢枢纽，主要作用：暴露API接口，跟踪其他服务器的健康状态、以最优方式调度负载，以及编排其他组件之间的通信。
• 单个的Master节点可以完成所有的功能，但是考虑单点故障的痛点，生产环境中通常要部署多个Master节点，组成Cluster。

Node

• 是Kubernetes的工作节点。
• 负责接收来自Master的工作指令，并根据指令相应地创建和销毁Pod对象。
• 调整网络规则进行合理路由和流量转发。
• Node节点往往有多个。

功能

官方的说法是：

• 快速部署和扩展应用
• 无缝对接新的应用
• 节省资源，动态扩缩容

是不是觉得官方介绍的功能很抽象，下面我结合自己的项目经验来介绍一下K8S的功能：

自动化上线和回滚

传统的上线方式大多是通过手动操作git：本地开发好之后上传到测试环境，测试环境确定好之后上传到生产环境。

当团队多人协同开发或者出现特殊情况时，比如：本地和测试环境安装了新的依赖，生产环境没有及时安装，git上传到生产环境后出现异常。

甚至在有些特殊情况下，我们需要在生产环境merge代码（别问我怎么知道的)。在这种情况下真的冒汗， 生产环境merge过程中出现代码冲突，一定会影响项目正常访问的。

有了K8S，能优雅的帮我们解决这个问题：

Kubernetes会分步骤地将针对应用或其配置的更改上线，同时监视应用程序运行状况以确保不会同时终止所有实例。如果出现问题，Kubernetes会为你回滚所作更改。

自动修复

我曾经因为没有很好的管理服务器磁盘出现过一次事故，当时身边又没有电脑，真是愁的跳脚。

从此以后我就把ECS/RDS等都设置了报警，当有隐患或者异常时能第一时间收到信息及时处理。

当时我就在思考🤔一个问题：报警固然有用，有什么办法能实现自动修复吗？

Now，K8S就能帮我们做到：

K8S能够通过使用简单的命令、一个UI或基于CPU使用情况自动对应用程序进行动态扩缩。

如果出现我上面提到磁盘使用率问题K8S能自动帮我扩容。（周末出门再也不用背着Mac了😄 ）

而且当容器有异常时，K8S能够重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。

没错，K8S能让我们的应用在服务器出现问题时自愈，动态扩缩。

负载均衡

对后端开发工程师来说，负载均衡概念早已深入人心。

Kubernetes为容器提供了自己的IP地址和一个DNS名称，并且可以在它们之间实现负载均衡。

k8s能够通过集群管理、动态扩缩容、自动更新SLB等特点智能且稳定的实现负载均衡，应对并发场景。

负载均衡

春江水暖鸭先知

各大厂商的嗅觉是最敏锐的，我在百度搜索了一下k8s，这么多云厂商都在打广告，都提供了K8S的解决方案。（立志整理一篇各大云厂商K8S使用情况的横评文章😈 ）

image.png

各大云厂商的入局又变相降低了学习门槛，毕竟自己从0搭建K8S进行容器的编排管理还是要学习很多概念的，而云厂商们提供的解决方案肯定会大大降低我们的学习成本。（我真是有点拿来主义了）

这样又从另外一个角度推动了K8S的火爆。

总结

随着容器技术的兴起与成熟，K8S可以实现容器集群的自动化部署、自动扩缩容、维护等功能，再加上云厂商的推波助澜以及均提供了拆箱即用的解决方案。

相信kubernetes一定会火，而且在不久的将来会成为应用部署运维的标配。