Kubernetes从零到精通（01-简介）

提起kubernetes，很多运维和开发的小伙伴因为所谓的“学习线陡增”望而却步，实践下来之后，我们会发现kubernetes的设计精妙可以跟区块链技术想媲美，并且同样的容易理解，容易入手。废话不多说，先上官方架构图：

kubernetes是谷歌开发并开源的一款软件，经过不断的优化设计，最终架构如上图所示，左侧是master，也就是控制节点，实际生产环境可以根据需要部署为多台master机器节点。其中etcd是kv格式数据库，kube-api-server负责提供api接口，供其他组件调用，kube-scheduler和kube-controller-manager是调度和控制组件。右侧是node，也就是工作节点，实际生产环境部署的应用程序，都在node节点上，其中kubelet负责pod的创建，启动停止等，kube-proxy实现service通信与负载均衡等，cri是容器运行时(如旧版本的docker，新版本的containerd进一步增强可扩展性，摆脱docker的束缚），负责本机容器的创建管理等。

上面提到的pod和service就是kubernetes定义的基础资源对象，后面会跟其他概念一起介绍。整个架构一目了然，这里简单提一下安装部署，开发测试环境可以用kubeadm快速安装，生产环境针对每一个组件可能都需要多个节点，所以一般采用二进制文件部署，然后注册成操作系统的服务，如linux的systemd管理。云服务器厂商如aws等都有封装好的kubernetes服务，托管master，进一步减少工作量，让企业开发运维工作者更多的关注应用在node节点的部署。

对于大规模的应用部署，kubernetes优势明显，我们举个实例：现在有一个后端服务需要部署30个节点，如果只用docker部署，可能需要5台物理服务器或者虚拟服务器，每台服务器上部署6个节点，这样每台服务器上可能都有一个docker-compose.yml启动文件，配置参数有端口映射等，部署启动后，前端的代理服务如nginx和负载均衡，要在upstream里把这30个节点用ip:port的方式配置好；然后运行了一段时间发现需要调整，如增加到50个节点，我们要做什么？准备上线新服务器，服务器上用docker-compose.yml启动新的容器，前端nginx或负载均衡再手动调整。

上面的实例，已经让运维工程师比较难过了，如果企业里有成百上千个这种需求和服务，会给运维开发带来巨大的工作量。那有没有一种软件，能帮我们自动去做这些事情，比如根据cpu和内存的使用情况，自动扩展或者减少服务节点数量，并且有故障自愈能力；比如某台服务器停机了，上面的服务节点自动在其他服务器启动，并且前端的service如nginx自动匹配新节点。完全不需要运维和开发手动介入，全自动化。这就是kubernetes要做的事情！