Kubernetes 基础

Kubernetes 的核心思路很简单：把“期望状态”写进 YAML，控制器会不断把现实拉回到这个状态。

四类核心对象

• Pod：最小调度单元
• Deployment：管理副本与滚动更新
• Service：稳定访问入口
• Namespace：逻辑隔离边界

声明式模型

• 你描述“要什么”
• 控制器负责“怎么做到”
• 同一份 YAML 可以重复 apply，不会破坏一致性

最小 Deployment 示例

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

常用命令

• kubectl apply -f hello.yaml
• kubectl get deploy,pods
• kubectl describe deploy hello
• kubectl logs deploy/hello

常见误区

• 忘记 selector 与 labels 对齐
• 只改 YAML，不观察 rollout 状态
• 把 Service 当成“反向代理”来理解

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

用系统视角理解 Kubernetes 基础

理解 Kubernetes 基础 时可以把 Kubernetes 看成一套契约体系：你在 YAML 中描述期望状态，控制器不断对齐实际状态。无论是创建 Pod、Service 还是环境级资源，这个心智模型都成立。关键是从“动作”转为“意图”，接受系统会持续自愈和收敛。

声明式流程如何落地

常见流程是编写清单、应用、观察、再调整。真正的事实来源是对象的 spec，而不是你敲过的命令。每一次更新都是对“期望状态”的修改，控制器负责推进。这个模式带来可重复、可回滚的发布能力，也适合自动化和多环境复用。

对象模型与命名习惯

每个对象都有 apiVersion、kind、metadata、spec 这些固定结构。metadata 不是可有可无的字段，名称、标签和注解是资源被发现和管理的索引。建立清晰的命名规范和标签体系，可以让 Service、监控和排障都更可靠，否则规模一大就难以定位。

控制回路会改变你的思考方式

控制回路持续运行，失败后的重试是常态，最终一致性是机制的一部分。节点故障时调度器会补副本，配置变化时控制器会滚动更新。这就是为什么 Kubernetes 更希望你描述目标，而不是一步一步手工操作。设计流程时要围绕“观察、回滚、再观察”。

最小实验流程

建议做一个小实验把概念落地：创建命名空间，部署一个简单应用，暴露访问，然后观察事件与状态变化。反复练习“创建-观察-描述-日志”这条路径，有助于理解系统的收敛节奏。

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

常见误解纠正

不少人把 Kubernetes 当成 PaaS 或虚拟机调度器，其实都不准确。它假设应用可以重启，Pod 不是长期存在的机器，Service 不是一个进程。Namespace 用于组织资源，但本身不是强安全边界。纠正这些误解会让后续概念更顺畅。

运维习惯要提前建立

即便是入门阶段，也建议把清单放入版本管理，使用统一标签，明确资源 requests 和 limits。日志与指标应该从第一天就开启，因为排障高度依赖这些数据。把集群当作系统记录库，会让日常操作更可控。

关键取舍

Kubernetes 给了很多选择：Deployment 还是 StatefulSet，滚动更新还是重建，更多副本还是更大节点。这些选择没有绝对答案，最好记录决策理由。快速不一定安全，复杂也未必必要。

控制面角色速览

API Server 是所有请求的入口，etcd 保存系统状态，Scheduler 负责调度，Controller 负责收敛。理解角色分工后，排障时能更快定位问题的责任边界。

版本与兼容性

API 会演进并逐步废弃旧字段。生产环境应优先使用稳定版本，升级前阅读变更说明，避免依赖实验特性。保持 API 兼容是长期可维护的基础。

心智检查清单

在提交变更前问自己：期望状态是什么，谁在负责收敛，失败如何被发现，回滚怎么做，哪些资源删除后仍会保留。这个清单让你关注意图、归属与可观测性，同时也避免残留资源。

什么时候回看 Kubernetes 基础

当你经历过一次故障或一次失败发布后，再回看 Kubernetes 基础 会有完全不同的理解。这种复盘会把快速入门知识转化为生产能力。

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。

参考链接

• Kubernetes 概览
• 工作负载
• 服务与网络