3、Kubernetes核心概念：Pod、Deployment、Service、Namespace。kubectl常用命令。理解声明式API。
好，咱们进入正题。这一章是Kubernetes的基石，说白了就是你必须搞懂的几个核心概念。我见过不少新手，上来就对着YAML文件一顿复制粘贴，结果Pod起不来、Service连不上，一脸懵。嗯，这很正常，因为没理解底层逻辑。
我个人习惯，学K8s先别急着敲命令。先把这几个“积木”是什么、怎么拼，想清楚。今天我们就聊聊Pod、Deployment、Service、Namespace，还有那个听起来很玄乎的“声明式API”。
3.1 Pod：K8s里最小的“计算单元”
Pod是你能在Kubernetes里创建和部署的最小单位。它不是单个容器，而是一个或多个容器的“共享环境”。
核心特点：
- 共享网络：同一个Pod里的容器共享同一个IP和端口空间。它们可以通过localhost互相通信。
- 共享存储：可以挂载同一个Volume，方便数据交换。
- 生命周期一致：Pod里的容器要么一起启动，要么一起挂掉。
重要理解：Pod是“逻辑主机”。容器是跑在这个主机上的“进程”。
我在项目中遇到过一个问题：有个同事把两个需要频繁通信的进程拆成了两个独立的Pod，结果网络延迟成了瓶颈。后来我建议他合并到一个Pod里，用localhost通信，性能直接翻倍。你想想看，这就是对Pod共享网络特性的理解差异。
3.2 Deployment：声明式的“应用管家”
Deployment是用来管理Pod的“控制器”。你告诉它“我要跑3个nginx副本”，它就会帮你创建3个Pod，并持续保证这个状态。
Deployment能做什么？
- 滚动更新：升级版本时，逐个替换Pod，保证服务不中断。
- 回滚：新版本出问题了？一键回到旧版本。
- 扩缩容：流量大了，把副本数从3改成10，Deployment自动搞定。
- 自愈：某个Pod挂了，它会重新创建一个新的顶上。
我的建议：生产环境里，永远不要直接创建Pod。用Deployment来管理。这是血的教训换来的经验。
为什么会这样？因为直接创建的Pod，节点宕机了就真的没了。而Deployment会帮你重新调度，保证你期望的副本数始终在线。
3.3 Service：稳定的“网络入口”
Pod是动态的，IP会变。今天这个Pod在节点A，明天可能就在节点B了。那谁来给客户端提供一个固定的访问地址？Service就是干这个的。
Service的类型：
| 类型 | 说明 | 使用场景 |
|---|---|---|
| ClusterIP | 集群内部可访问，外部不可达 | 内部微服务通信 |
| NodePort | 在每个节点上开放一个端口，外部可通过节点IP+端口访问 | 测试环境、小规模暴露 |
| LoadBalancer | 云厂商提供负载均衡器，自动分配公网IP | 生产环境对外暴露服务 |
Service通过标签选择器（Label Selector）来找到它要代理的Pod。说白了，就是给一组Pod起了一个“固定的名字”。
注意：Service默认是四层负载均衡（基于IP和端口）。如果你需要七层（基于HTTP域名、路径），需要用Ingress。
3.4 Namespace：逻辑上的“隔离墙”
Namespace用来把集群资源划分成多个虚拟空间。同一个集群里，不同团队、不同项目可以各用各的Namespace，互不干扰。
常见用途：
- 区分环境：dev、test、prod
- 多租户隔离：team-a、team-b
- 资源配额管理：限制每个Namespace的CPU、内存上限
我曾经踩过一个坑：两个服务在不同的Namespace里，但Service名字一样。结果一个Pod通过Service名去调用，死活连不上。后来才发现，跨Namespace调用必须用“服务名.命名空间.svc.cluster.local”这种完整域名。嗯，这个细节很容易被忽略。
3.5 kubectl常用命令：你的“瑞士军刀”
kubectl是K8s的命令行工具。我每天至少敲几百次。下面这些命令，建议你背下来。
基础操作：
# 查看所有Pod
kubectl get pods
# 查看所有Deployment
kubectl get deployments
# 查看所有Service
kubectl get services
# 查看所有Namespace
kubectl get namespaces
# 查看详细信息
kubectl describe pod <pod-name>
# 查看日志
kubectl logs <pod-name>
# 进入Pod内部
kubectl exec -it <pod-name> -- /bin/bash创建和删除资源：
# 通过YAML文件创建
kubectl apply -f deployment.yaml
# 删除资源
kubectl delete pod <pod-name>
# 删除一组资源（通过标签）
kubectl delete pods -l app=nginx小技巧：用 kubectl get all -n <namespace> 可以一次性看到该命名空间下所有资源。排查问题时特别好用。
3.6 理解声明式API：K8s的“灵魂”
声明式API，说白了就是“告诉系统你想要什么状态，系统自己想办法达到”。
举个例子：
- 命令式：你手动执行“创建3个Pod”、“如果Pod挂了就重启”。
- 声明式：你写一个YAML文件，里面写着“replicas: 3”。然后K8s自己负责创建、监控、自愈。
你想想看，哪个更省心？当然是声明式。你只需要关注“目标状态”，不用关心“怎么实现”。
我刚开始接触时，总觉得YAML文件写起来麻烦。但后来发现，一旦你习惯了声明式思维，运维效率会提升好几个量级。尤其是配合GitOps，把YAML文件放到Git仓库里，版本控制、回滚、审计全都有了。
核心思想：声明式API = 告诉系统“要什么”，而不是“怎么做”。
3.7 本章知识体系图
下面这张图，帮你理清这几个核心概念的关系：
这张图你看懂了吗？从上往下看：Namespace是最大的隔离边界，里面可以放多个Service和Deployment。Deployment负责管理Pod的生命周期，Service负责给Pod提供稳定的访问入口。Pod里面才是真正的容器。
一句话总结：Namespace隔离环境，Deployment管理Pod，Service暴露服务。三者配合，构成了K8s应用部署的“铁三角”。