2. Kubernetes 核心概念
聊到 Kubernetes，很多人一上来就被一堆概念砸晕了。Pod、Service、Deployment、Namespace…… 说实话，我刚接触那会儿也觉得头大。但后来我发现，只要搞懂这四个核心概念，K8s 的基本骨架就搭起来了。
今天我就带你把这四个东西彻底捋清楚。我会结合自己踩过的坑来讲，希望能帮你少走弯路。
Pod：最小的调度单元
Pod 是 K8s 里你能创建和部署的最小单位。它不是单个容器，而是一个或多个容器的组合。
为什么要有 Pod？
你想想看，有些应用需要两个进程紧密协作——比如一个写日志，一个读日志。如果把它们拆到不同机器上，网络通信就成了麻烦。Pod 就是解决这个问题的：里面的容器共享网络栈和存储卷，可以用 localhost 互相访问。
Pod 的生命周期
Pod 是有状态的：Pending → Running → Succeeded/Failed。如果节点挂了，Pod 不会自动恢复——它只是一个“租户”，不是“永动机”。
Service：稳定的网络入口
Pod 是动态的，IP 会变。那怎么让客户端稳定访问？Service 就是干这个的。
Service 为一组 Pod 提供固定的虚拟 IP 和 DNS 名称。它通过标签选择器（selector）找到对应的 Pod，然后把流量转发过去。
Service 的几种类型
| 类型 | 说明 | 适用场景 |
|---|---|---|
| ClusterIP | 集群内部可访问，外部不行 | 内部微服务通信 |
| NodePort | 在每个节点上开一个端口，外部可通过节点 IP + 端口访问 | 开发测试环境 |
| LoadBalancer | 云厂商提供负载均衡器，自动分配公网 IP | 生产环境对外暴露服务 |
| ExternalName | 返回一个 CNAME 记录，不代理流量 | 将外部服务映射到集群内 |
我建议： 生产环境用 LoadBalancer 对外暴露，内部服务用 ClusterIP。NodePort 只用来临时调试，别上生产。
Deployment：声明式应用管理
Deployment 是 K8s 里最常用的工作负载控制器。它负责保证你想要的 Pod 数量一直存在，并且支持滚动更新和回滚。
Deployment 的核心能力
- 自愈： Pod 挂了，自动创建新的
- 扩缩容： 调整副本数，秒级生效
- 滚动更新： 逐步替换旧 Pod，不停机
- 回滚： 更新出问题，一键回到上一个版本
下面是一个简单的 Deployment YAML 示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80我的经验： 更新镜像时，一定要改 image 标签，不要用 latest。我见过有人用 latest 导致回滚时拉到了错误版本，整个服务挂了半小时。
Namespace：逻辑隔离的利器
Namespace 用来把集群划分成多个虚拟空间。不同 Namespace 里的资源可以重名，互不干扰。
什么时候用 Namespace？
- 多环境隔离：dev、test、prod 各一个 Namespace
- 多团队共用集群：每个团队一个 Namespace
- 权限控制：结合 RBAC，限制不同 Namespace 的访问
K8s 默认有四个 Namespace：
default：没指定 Namespace 时默认使用kube-system：系统组件（如 kube-dns、kube-proxy）kube-public：所有用户可读kube-node-lease：节点心跳信息
我曾经犯过的错： 把所有资源都丢到 default Namespace 里，结果不同环境互相污染。后来我强制要求每个环境一个 Namespace，问题就解决了。
四个概念的关系图
下面这张图展示了 Pod、Service、Deployment、Namespace 之间的关系：
总结一下
这四个概念的关系其实很简单：
- Pod 是跑应用的“最小单元”
- Deployment 是管理 Pod 的“管家”
- Service 是访问 Pod 的“门牌号”
- Namespace 是划分空间的“隔断墙”
搞懂这些，你就掌握了 K8s 的底层逻辑。后面讲编排框架选型时，你会发现这些概念是理解一切的基础。