Kubernetes 简介

Kubernetes 是容器编排平台，它解决的是“如何稳定、可重复地运行服务”的问题，而不是帮你写业务代码。

它解决什么

调度：把 Pod 放到合适的节点
自愈：容器挂了自动拉起
伸缩：根据负载扩缩容
服务发现：为动态 Pod 提供稳定入口

它不解决什么

业务性能瓶颈
数据库设计
代码质量问题

适用场景

多服务、多环境、频繁发布
需要标准化部署与回滚
追求一致的可观测与运维方式

一句话心智模型

Kubernetes 就是“声明式 + 控制器”的自动化运维系统。

实操要点

先做快速盘点：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 是否正常。

回滚预案

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