Kubernetes 是什么?核心概念

为什么需要 Kubernetes

当你只有一台服务器、跑几个容器时,docker run 就够用了。但业务长大后,问题接踵而至:一台机器扛不住要多机分摊、进程崩了要自动拉起、上线新版本不能停服、流量高峰要临时扩容……手工管理很快失控。

Kubernetes(常简写为 K8s)是一个容器编排系统:你把"想要的状态"告诉它,它负责在一堆机器上把这个状态变成现实,并一直维持住。

和单机 Docker 的关系

Docker 解决的是单台机器上怎么打包和运行一个容器;Kubernetes 解决的是一群机器上怎么调度、连接、伸缩和守护这些容器。二者不是竞争关系:K8s 底层仍然运行容器(通过容器运行时),Docker 镜像可以直接被 K8s 使用。可以理解为:Docker 造砖,K8s 盖楼并管物业。

核心对象与相互关系

• Node(节点):集群里的一台工作机器(物理机或 VPS),提供 CPU、内存来跑容器。
• Pod:K8s 调度的最小单位,里面装一个(或少数几个紧密协作的)容器,共享网络与存储。Pod 是"可随时被丢弃重建"的,不该被当成宠物养。
• ReplicaSet:确保某个 Pod 始终有 N 个副本在运行,少了就补、多了就杀。
• Deployment:管理 ReplicaSet 的上层控制器,负责滚动升级 / 回滚。日常你几乎只跟它打交道。
• Service:一个稳定的虚拟入口(固定名字 / IP),把请求负载均衡到一组随时增减的 Pod 上,解决"Pod 的 IP 一直在变"的问题。
• Namespace(命名空间):逻辑隔离的分组,把不同团队 / 环境(如 dev、prod)的资源隔开。

关系链条大致是:Deployment → ReplicaSet → Pod → 容器,跑在 Node 上,由 Service 对外暴露,统一装在某个 Namespace 里。

一段最小的 Deployment 声明长这样:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3          # 我想要 3 个副本
  template:
    spec:
      containers:
        - name: web
          image: myapp:1.0

声明式与自愈

你注意到上面写的是 replicas: 3,而不是"启动 3 个、如果挂了再启动"。这就是声明式:你描述期望状态(想要什么),而不是操作步骤(怎么做)。K8s 的控制器不断对比"期望"与"现状",有差就纠正——这就是自愈:某个 Pod 崩了、某台 Node 宕了,它会自动在别处重建,把副本数补回 3,无需你半夜爬起来处理。

什么规模才值得上

K8s 很强,但也有实打实的复杂度成本:概念多、运维门槛高、排错链条长。取舍建议:

• 只有 1–2 台机器、几个服务、流量平稳:多半不需要,docker compose 或托管平台更省心。
• 需要多机高可用、频繁滚动发布、弹性伸缩、多团队多环境隔离:K8s 的收益开始压过成本。

一句话:先有让 K8s 值得的问题,再上 K8s,别为了技术而技术。

小结

Kubernetes 是把容器编排到一片服务器集群上的声明式系统:你声明期望状态,它负责调度、暴露并持续自愈。记住核心链条 Deployment → ReplicaSet → Pod、Service 提供稳定入口、Namespace 做隔离、Node 是底座。规模不到时,单机 Docker 仍是更划算的选择。