初探 Kubernetes (k8s) 时简介部分重点是什么？

初探 Kubernetes 时，简介部分的重点应放在理解核心抽象概念（如 Pod、Service）和集群架构角色上，而不是急于动手搭建生产环境。

先说结论：初学者应优先掌握集群的基本组成单元和交互方式，避免一开始就陷入复杂的网络或存储配置。

适合：刚接触容器编排、希望建立系统性认知的开发者或运维人员
先看：Pod 生命周期、Deployment 控制器、Service 网络抽象
建议：使用本地轻量工具（如 kind 或 minikube）进行实验，而非直接操作云厂商托管服务

快速处理思路

由于这是概念学习阶段，不涉及故障修复，以下是快速建立认知的操作路径：

# 1. 准备本地环境（以 kind 为例）
kind create cluster `--name` demo

# 2. 验证集群连通性
kubectl cluster-info

# 3. 运行一个最基础的 Pod
kubectl run nginx `--image`=nginx `--restart`=Never

# 4. 查看运行状态
kubectl get pods

为什么会这样

Kubernetes 的设计初衷是管理容器化应用，但它引入了一层较厚的抽象。如果在简介阶段只关注“如何安装”，很容易忽略“为什么需要这样设计”。官方文档将概念分为工作负载、服务网络、存储等类别，目的是让用户理解集群如何声明式地维护期望状态。跳过概念直接操作，会导致后续遇到故障时无法定位是网络问题、调度问题还是配置问题。

分步处理

按照认知顺序，建议分三步走：

1. 理解最小调度单元
不要只盯着 Docker 容器，Kubernetes 调度的是 Pod。一个 Pod 可以包含一个或多个容器，它们共享网络和存储命名空间。尝试创建一个包含 sidecar 容器的 Pod 定义文件，观察它们如何共享 localhost。

2. 理解期望状态维护
不要直接创建 Pod，而是使用 Deployment。Deployment 负责确保指定数量的 Pod 副本始终运行。修改 Deployment 的副本数，观察集群如何自动创建或销毁 Pod 来匹配设定。

3. 理解服务发现
Pod 的 IP 是临时的。使用 Service 资源为一组 Pod 提供稳定的访问入口。创建一个 ClusterIP 类型的 Service，并在集群内部尝试通过 Service 名称访问应用。

怎么验证是否生效

学习过程中，通过以下命令确认理解是否正确：

# 检查 Pod 是否处于 Running 状态
kubectl get pods -o wide

# 查看 Deployment 管理的副本情况
kubectl get deployments

# 查看 Service 分配的集群内部 IP
kubectl get services

如果 Pod 状态为 Pending，说明调度未成功；如果为 CrashLoopBackOff，说明应用启动失败。这些状态码是验证配置是否生效的直接依据。

常见坑

混淆 Pod 与容器：认为重启 Pod 就是重启容器，实际上 Pod 销毁后数据会丢失（除非挂载持久卷）。
忽略命名空间：默认操作都在 default 命名空间，多用户或多环境场景下容易资源冲突。
过早关注高可用：初学阶段单机集群即可，不要一开始就研究多主节点架构，会增加不必要的复杂度。
直接编辑运行中的资源：尽量避免使用 kubectl edit 修改运行中的配置，应修改 YAML 文件后 apply，以保持版本可控。

参考来源

Kubernetes Official Documentation, "Kubernetes Components", https://kubernetes.io/docs/concepts/overview/components/
Kubernetes Official Documentation, "What is Kubernetes?", https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/