Kubernetes 基础：对象、YAML 和失败处理

从 Kubernetes 的对账和失败方式理解 Pod、Deployment、Service 和 Namespace，再用真实命令验证每次变更。

官方文档会说，Kubernetes 是一个容器编排系统。这个定义没错，但在故障现场不够有用。

更实用的心智模型是：etcd 这类分布式存储保存目标状态，一组控制器不断把实际状态往目标状态对齐。理解了这个闭环，再看 Pod、Deployment、Service 和 Namespace 就不会觉得它们只是几行 YAML。

四个核心对象

日常 Kubernetes 工作大多绕不开这四个对象。

1. Pod 由一组共同调度的容器组成

Pod 里的容器共享网络命名空间、存储卷和生命周期。主应用旁边如果有紧密配合的日志采集器或服务代理，放在同一个 Pod 里通常更自然。

2. Deployment 维持期望副本数

生产环境很少直接创建裸 Pod。节点消失后，没有任何控制器负责补齐它。Deployment 声明 replicas: 3，ReplicaSet 持续检查匹配的 Pod，少了就补；镜像或模板变更时，也由它做受控滚动更新。

3. Service 提供稳定入口

Pod 会被替换，IP 也经常变化。Service 给一组 Pod 一个稳定的虚拟 IP 和 DNS 名称，再由 iptables、IPVS 等机制把流量转发到健康、Ready 的 endpoints。

4. Namespace 是组织作用域

Namespace 适合划分团队或环境，但它不是完整的安全边界。没有 RBAC 和 NetworkPolicy 时，不同 Namespace 的工作负载仍可能互相访问。

YAML 是结构化的 API 请求

再长的清单，也先拆成 API 版本、对象类型、身份信息和期望状态：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80

`apply` 成功不等于应用成功

kubectl apply 返回成功，只说明目标状态被 API 接受，不代表工作负载已经运行、Ready 或可访问。

常见失败形态有：

节点选择器、污点或资源不匹配导致 Pod Pending
镜像地址或凭据错误导致 ImagePullBackOff
启动、配置或探针失败导致 CrashLoopBackOff

应用后立刻验证：

kubectl get deploy,pods -n demo
kubectl describe pod <pod-name> -n demo

用一个小闭环练习

每次本地实验都走同一组命令：

kubectl create namespace demo
kubectl apply -f app.yaml
kubectl get pods -n demo
kubectl describe pod -n demo
kubectl get events -n demo --sort-by=.metadata.creationTimestamp

多做几轮，events 和控制器行为就不会再显得抽象。

常见误解

Kubernetes 不是 PaaS，它不会帮你构建镜像或写 CI/CD。
Pod 不是长期运行的小虚拟机。
Service 不是服务进程本体，它是通向 endpoints 的稳定路由。
Namespace 只是组织作用域，不是完整安全模型。
对账是异步的，created 不等于 ready。

入门阶段最容易混淆的三件事

Q: 最先应该理解哪些 Kubernetes 对象？ A: Pod、Deployment、Service 和 Namespace。它们覆盖大多数日常操作。

Q: 为什么说 Kubernetes 是声明式系统？ A: 因为你在 YAML 里描述目标状态，控制器持续把集群往这个状态收敛。

Q: Kubernetes 能替代 CI/CD、监控或应用设计吗？ A: 不能。它负责编排和生命周期，交付、观测、安全代码和运维标准仍然要你自己建设。