Kubernetes——引言

缘起从“家庭作坊”到“工业革命”让我们先回顾一下在“物流帝国”建立之前世界是什么样子的。传统部署时代家庭作坊式你想运行一个应用就直接把它绑在一台物理服务器上。就像在一个小作坊里所有工具都放在一张桌子上。如果另一个应用也想运行就可能抢桌子资源导致大家都没法好好干活。扩容那就再买一张桌子新服务器耗时耗力。虚拟化部署时代公寓楼后来我们学会了虚拟化。在一台物理服务器上可以运行多个虚拟机VM每个都是一个独立的“小公寓”有自己的操作系统。隔离性好了资源利用率也高了。但每个“公寓”都自带一整套家具完整的操作系统有点笨重启动也慢。容器化部署时代集装箱货轮这就是容器的世界容器就像标准化的集装箱。你的应用和它的运行环境依赖、配置都被打包进这个集装箱里。它轻量、启动快、在任何港口服务器都能一致运行。Docker 让制造和运输这些“集装箱”变得超级简单。但问题来了当你有了成千上万个这样的“集装箱”遍布在全球各地的“港口”服务器上你怎么管理它们谁来决定哪个集装箱该上哪艘船船坏了怎么办集装箱里的货物怎么互相发现和通信这就是 Kubernetes 登场的时刻。它就是这个“全球集装箱物流帝国”的总调度中心。Kubernetes 王国大脑与肌肉Kubernetes 集群由两个核心部分组成控制平面Control Plane和节点Nodes。你可以把它们理解为王国的大脑和肌肉。1. 控制平面Control Plane王国的大脑这是王国的“中央政府”负责所有的决策和指令下发。它通常运行在几台专门的“管理服务器”上以确保高可用性。kube-apiserver王国的“对外窗口”这是整个王国唯一的入口。所有的命令、所有的内部沟通都必须通过这个窗口。无论是你下达的指令还是其他组件汇报情况都要找它。etcd王国的“金库”这是一个极其可靠、安全的保险库。王国所有的状态、配置、谁是谁、哪个集装箱在哪……所有关键信息都存储在这里。绝对不容有失。kube-scheduler王国的“调度大师”这位大师的任务是当一个新的“集装箱”Pod我们马上会说到需要被安置时它会根据集装箱的大小资源需求、各个港口节点的繁忙程度和特殊规则精准地决定它应该被运送到哪个节点上并通知那边准备接收。kube-controller-manager王国的“纠察大队长”这位大队长手下有一群不知疲倦的“纠察员”控制器。他们的工作就是一刻不停地巡视确保王国的实际情况和你下达的“圣旨”期望状态完全一致。比如你要求有3个一模一样的集装箱在运行如果有一个坏了纠察员会立刻发现并命令调度大师再找一个新地方重新造一个始终保持3个。2. 节点Nodes王国的肌肉这些是真正干活的“工人”机器可以是物理机或虚拟机。每个节点上都运行着必须的组件来接收和执行大脑的命令。kubelet节点的“工头”这是每个节点上的“小头目”。它唯一听从的就是来自大脑通过API Server的命令。它负责管理这个节点上的所有活动确保集装箱按要求启动、运行并定期向大脑汇报这个节点的健康状况。kube-proxy节点的“交通警察”它负责维护网络规则让发往某个服务的网络流量能够被正确地、负载均衡地分发到后端的实际集装箱上。容器运行时“搬运工”这是真正干体力活的比如containerd或CRI-O。它负责真正地拉取镜像、启动和停止容器。核心概念王国里的“资源”有了大脑和肌肉我们来看看王国内部到底在管理哪些“资源”。Pod“标准集装箱”这是 Kubernetes 中最小的调度和管理单位。一个 Pod 里可以装一个或多个紧密相关的容器就像一个大集装箱里可以放几个小箱子。Pod 里的容器共享网络和存储总是在同一个节点上一起运行、一起停止。比如一个运行 Web 应用的容器和一个负责把日志同步到中央存储的辅助容器sidecar就可以放在同一个 Pod 里。Deployment“集装箱船的配载图”你几乎从不直接创建 Pod。而是通过 Deployment 来声明你想要什么样的 Pod以及想要多少个副本。Deployment 是一个“无状态应用”的控制器它负责按照你的“配载图”来创建、更新和维持 Pod 的数量。它指挥着 ReplicaSet 这个更基层的“小组长”来完成具体的数量保障。Service“码头服务大厅”Pod 是短暂的它们可能会被随时创建和销毁IP 地址也会变化。这就好比每个集装箱的临时泊位总在变。Service 就是提供了一个永久的、固定的服务入口和负载均衡器。不管后端的 Pod 怎么变只要通过这个 Service 的名字或IP就能稳定地访问到它们。你可以把它想象成码头的服务大厅你只要知道服务大厅的地址比如my-service它就能把你的需求转发给正确的、空闲的办事窗口Pod。Ingress“王国海关”如果说 Service 是集群内部的服务发现那Ingress 就是管理从“国外”集群外部到“国内”的访问规则。它像一个智能海关可以根据你访问的域名如app.my-company.com或路径如/api将流量路由到集群内部不同的 Service 上。它还常常负责 SSL 证书卸载等工作。ConfigMap Secret“货品清单和密函”应用的配置如环境变量、配置文件和敏感信息密码、密钥不应该写死在容器镜像里。ConfigMap 就是用来存放这些非机密配置的“货品清单”而 Secret 则是用来安全传递“加密密函”的方式。应用启动时可以从这里读取配置做到了配置与镜像的解耦。实战演练部署你的第一个“集装箱”理论说完了我们来点实际的。想象一下你手下有了一整套王国系统一个 Kubernetes 集群现在你想部署一个 Nginx 服务器让它跑起来并提供服务。你的命令会像这样下达指令你写了一个 YAML 文件就像一份标准订单上面写着“我要一个名叫nginx-deploy的 Deployment运行 3 个 Nginx 的 Pod每个 Pod 里有一个容器使用nginx镜像开放 80 端口。”提交给窗口你用kubectl apply -f my-nginx.yaml命令把这份“订单”提交给了kube-apiserver王国的窗口。大脑决策API Server 把订单内容存进etcd保险库。Controller Manager 里的 Deployment 控制器看到了新订单它立刻命令 Scheduler调度大师去找三个合适的地方来放这三个 Pod。肌肉执行Scheduler 选好了三个节点并通知各自节点上的kubelet工头。工头们接到命令马上叫来“搬运工”容器运行时从仓库拉取nginx镜像启动容器。Pod 运行起来了提供服务为了让外界能稳定地访问这3个随时可能变化的 Pod你再次提交一份订单一个 Service YAML创建一个名为nginx-service的服务。这个 Service 有了一个固定的IP并会自动将流量分发给那3个 Nginx Pod。自我修复假设其中一个 Pod 运行的节点突然宕机了。Kubernetes 的自我修复机制立刻生效Controller Manager 发现 Pod 数量少了马上命令 Scheduler 在其他健康节点上重新创建一个新的 Pod集群中始终保持3个可用的副本。整个过程你只是提交了两份声明式的文件剩下的所有复杂的调度、部署、网络、监控和修复工作都由 Kubernetes 这个“物流帝国”自动完成了。组件/概念角色/比喻核心职责控制平面王国的大脑做出全局决策调度、响应事件管理集群状态节点王国的肌肉运行容器化应用执行大脑的指令Pod标准集装箱一组紧密相关的容器共享资源是调度的最小单元Deployment集装箱船配载图管理无状态应用的部署、副本数量和滚动更新Service码头服务大厅提供稳定的服务发现和负载均衡屏蔽后端 Pod 的变化kubectl向王国发令的工具用户与 Kubernetes API 交互的主要命令行工具总结为什么你需要这个“物流帝国”Kubernetes 不仅仅是一个技术工具它是一种思维方式的转变。它让你从“关心每一台服务器、每一个容器”的“运维工人”变成了“只关心业务需求和最终状态”的“指挥官”。你告诉它“我要什么”它负责“怎么实现”。这就是云原生时代的基础设施核心