3. Kubernetes核心概念速览：快速回顾Pod、Service、Deployment、Namespace等核心概念
说实话，很多刚开始接触Kubeflow的朋友，一上来就被各种K8s概念搞懵了。我当年也是这样，Pod、Service、Deployment……这些词看着都认识，但组合在一起就不知道谁管谁了。
别急，咱们今天就把这几个核心概念捋一遍。你不需要成为K8s专家，但得知道它们各自是干什么的。毕竟Kubeflow是跑在K8s上的，这些概念你躲不开。
一句话总结：Pod是最小单元，Deployment管Pod的“生老病死”，Service管Pod的“对外联络”，Namespace管“谁跟谁是一伙的”。
Pod：K8s世界里的“最小单元”
Pod是Kubernetes中最小的部署单元。你可以把它理解成一个“容器的小房间”——里面可以住一个或多个容器。它们共享网络、存储，以及“生死与共”的命运。
我刚开始用K8s时犯过一个低级错误：以为Pod和容器是一回事。其实Pod是容器的“外壳”，容器是Pod里的“住客”。一个Pod里可以只住一个容器，也可以住多个（比如一个跑应用，一个做日志收集）。
💡 我的经验：在Kubeflow中，每个训练任务通常对应一个Pod。如果Pod挂了，任务就断了。所以别把Pod想得太神秘——它就是个“临时工”，干完活就销毁。
# 一个最简单的Pod定义
apiVersion: v1
kind: Pod
metadata:
name: my-first-pod
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80Deployment：Pod的“管家”
直接创建Pod？我劝你别这么干。Pod太脆弱了——节点挂了、资源不够、OOM了，Pod说没就没。你需要一个“管家”来帮你盯着。
Deployment就是那个管家。你告诉它：“我要3个nginx Pod跑着”，它就会一直确保有3个。少了一个？它立刻补一个。版本要升级？它帮你滚动更新，一个接一个换，服务不中断。
我记得有一次线上服务半夜挂了，就是因为有人直接删了Pod。后来我强制要求：所有Pod必须通过Deployment管理，谁再直接操作Pod谁请客。从那以后，再没出过这种问题。
⚠️ 避坑指南：我曾经见过有人把Deployment的replicas设为0，以为这样能“暂停”服务。结果Pod全没了，服务彻底挂了。记住：replicas: 0 等于“全部干掉”，不是“暂停”。
# Deployment示例：保证3个Pod始终运行
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: 80Service：Pod的“外交官”
Pod的IP是动态的——每次重启都可能变。你想想看，如果前端服务要调用后端，总不能每次都去查IP吧？
Service就是来解决这个问题的。它提供一个固定的虚拟IP和DNS名称，不管背后的Pod怎么变，前端只管访问Service就行。Service会自动把流量转发给健康的Pod。
在Kubeflow中，你部署了一个模型服务，它背后可能有多个Pod在跑。客户端只需要访问Service的地址，Service会帮你做负载均衡。说白了，Service就是Pod的“前台接待”。
| Service类型 | 适用场景 | 访问方式 |
|---|---|---|
| ClusterIP | 集群内部访问 | 虚拟IP，仅集群内可达 |
| NodePort | 外部调试/测试 | 节点IP + 固定端口 |
| LoadBalancer | 生产环境对外暴露 | 云厂商负载均衡器 |
💡 我的建议：开发环境用NodePort方便调试，生产环境用LoadBalancer。ClusterIP适合服务间调用——比如Kubeflow的各个组件之间通信。
Namespace：K8s里的“隔间”
一个K8s集群可能同时跑着好几个项目：A团队的训练任务、B团队的模型服务、C团队的监控系统……全混在一起？那不乱套了。
Namespace就是用来做逻辑隔离的。每个Namespace里的资源名可以重复，互不干扰。你可以在Namespace里设置资源配额（比如这个团队最多用10个CPU），也可以设置权限控制。
在Kubeflow中，每个用户或每个项目通常会分配一个独立的Namespace。这样做的好处是：A用户删错了东西，不会影响到B用户。我见过最惨的一次，就是有人在default命名空间里执行了 kubectl delete all --all，结果整个集群的服务全没了……
⚠️ 血的教训：永远不要在default命名空间里做重要操作。我习惯给每个项目建一个独立的Namespace，名字就叫项目名。这样就算手滑，也只是影响一个项目，不会波及全局。
# 查看所有Namespace
kubectl get namespaces
# 在指定Namespace下创建资源
kubectl create deployment my-app --image=nginx -n my-project它们是怎么配合的？
嗯，到这里你应该有个大概印象了。咱们串一下：
- Namespace 先划好地盘（比如
kubeflow-system、my-project） - Deployment 在这个地盘里声明“我要跑3个Pod”
- Pod 真正跑起来，干活（比如跑一个训练脚本）
- Service 给这些Pod一个固定的入口，方便别人调用
说白了，这四兄弟各司其职，缺一不可。你不需要背下所有K8s概念，但把这四个搞明白，Kubeflow的安装和配置你就已经入门了。
一句话记住：Pod是“工人”，Deployment是“工头”，Service是“前台”，Namespace是“车间”。
公众号:蓝海资料掘金营，微信deep3321