2026-01-20 22:39
kubernetes在当初学docker的时候就接触过，那时的认知是这东西就是把docker容器分散在各个机器上运行的工具：集群版docker。后来发现它的行为如此，但是设计理念或者说要解决的问题完全不是如此。
kubernetes算是一个集群操作系统。一个典型的操作系统是硬件设备、资源接口的抽象者和管理者，提供了一个完整的心智模型简化应用程序的开发。用它比喻k8s是因为k8s也类似，将集群中的一切资源抽象为了RD——Resource Definition，这些定义和传统操作系统中的进程、可执行文件、应用配置、网络接口、内存、存储等都可以对应的上，从而借助它，我们可以在集群的角度导入可执行文件、启动前者得到若干进程、管理和限制它们使用的网络、存储、算力等资源，同时也可以借助几种模式保证进程始终运行、崩溃后自动重启等等。
除此之外，k8s允许自定义资源类型：Custom Resource Definition，你可以自定义一些数据结构，推送到k8s集群中，就可以操作和删除这种自定义的资源类型了。至于用这种资源类型干什么，你完全可以自由发挥：k8s提供了一些能力，比如说事件驱动的Resource队列和对应的消费者、对某个节点上容器的管理功能等；比如说你可以创建一个自定义资源类型叫做日志，然后当容器运行出错时就调用k8s api创建一个对应的Resource，同时再启动一个进程或者容器，在其中调用k8s api消耗日志，来给出集群服务大盘等信息。
所以，它提供的这组工具实际上类似于：单个节点的控制能力+分布式事件总线的感觉；二者组合就成为了一个云操作系统。
那它解决的问题，或者说能解决的问题就是：运行时实例的管理、应用程序升级版本、版本过渡、错误恢复、容器-资源的调度分配问题等。
说到这里，就是为什么它适合解放运维？在一般操作系统里，它自身不但扮演资源的配发者，更多的是，扮演资源的控制者：对于声明在进程树中，要求作为服务运行的进程，一般都会尽力保证其运行；同时升级软件也是使用工具安装一下的事，oom kill也是自动触发的。而运维需要启动服务并保证服务长久正常运转，这有点类似os的能力。
k8s最强的，就是实现了这个可靠的分布式事件-资源总线，它的informer实现了良好的性能-可靠性。其中的kubelet也提供了良好的节点、容器控制能力。
因此，它适合自动化部署、回滚：推送新镜像时自动触发蓝绿发版、崩溃时自动在本节点/换节点创建新容器实现高可用等。此外还能编写规则+CRD实现各种自动化流水线，比如自动换掉故障服务器等。
那总而言之，k8s就是一个择机在某个节点上运行容器的系统。而这发生的时机是：系统中存在未分配到具体节点运行的容器。即，大部分情况下只有新的容器会经过调度器计算，被指定给一个节点来创建；对应的还有不太常见的情况：正在运行的容器因为某些原因挂了，或者是被终止等，这时如果它们在k8s的蓝图中还是“规划中应该存在的”容器，那它们就会进入调度队列，即，触发重调度动作。
重调度则是一种运行时负载均衡的实用手段，运行时如果某个节点负载过重或者出现异常需要维护，就可以由维护者程序触发重调度，停止容器并由调度器将它分配到其他合适的节点。
对应到程序上。我们创建程序时需要指定程序使用的硬件资源，包括使用哪个处理器核心、内存区域等；容器也是一样，启动时会经过调度器判断，将它分配给合适的节点执行。
虽然这和单机操作系统这种响应时间级别的场景相比，它工作的时间尺度远大于前者，但是一些典型调度器还是可以供后者借鉴使用的。