Kubernetes、Docker与Docker Compose：联系、部署场景与实战指南

一、三者之间的关系与定位

1. Docker——容器化的基础

Docker 是一个容器化平台，核心作用是将应用程序及其依赖打包成标准化的容器镜像，并在任意支持 Docker 的环境中运行。Docker Engine 负责从镜像创建和运行容器。可以把 Docker 理解为“打包工具”——它解决了“在我机器上能跑，在你机器上跑不了”的环境一致性问题。

2. Docker Compose——单机多容器编排

Docker Compose 是一个用于定义和运行多容器 Docker 应用的工具。通过一个 docker-compose.yml 文件描述服务、网络和卷，用一条命令就能启动整套服务。

核心定位：单机环境下的多容器编排。所有容器运行在同一台主机上。

适用场景：

• 本地开发环境搭建
• 集成测试和 CI/CD 测试
• 概念验证（POC）和小型演示
• 服务数量较少（2-6个）、流量可预测的小型应用

局限性：

• 单主机架构，主机宕机整套应用不可用
• 无自动扩缩容
• 无滚动更新（更新会造成服务中断）
• 无故障自愈能力

3. Kubernetes（K8s）——企业级容器集群编排

Kubernetes 是一个分布式容器编排平台，管理多台物理机/云服务器组成的集群，容器可跨节点调度和分布运行。K8s 提供自动扩缩容、滚动更新、自我修复、服务发现和负载均衡等生产级能力。

核心定位：集群级别的容器编排与管理。

适用场景：

• 生产环境大规模微服务部署
• 需要高可用和零停机更新的业务
• 需要自动弹性扩缩容的系统
• 多云/混合云部署
• 大数据、机器学习等计算密集型工作负载

4. 三者关系总结

维度	Docker	Docker Compose	Kubernetes
定位	容器化引擎	单机多容器编排	集群容器编排
管理范围	单个容器	单台主机	多台主机集群
学习曲线	低	低	高
生产就绪	需配合其他工具	不推荐	原生支持
扩缩容	手动	手动	自动（HPA）
故障自愈	无	无	原生支持
滚动更新	无	无	原生支持

三者是互补关系，而非替代关系。Docker 是基础容器技术，Compose 是单机编排工具，K8s 是集群编排平台。

二、Docker Compose 常用操作

1. 核心命令

命令	说明
docker compose up -d	后台启动所有服务
docker compose down	停止并移除容器、网络
docker compose ps	查看容器状态
docker compose logs -f	查看实时日志
docker compose build	构建镜像
docker compose restart	重启服务
docker compose exec <service> <cmd>	在服务容器中执行命令

2. docker-compose.yml 示例

version: '3.8'
services:
  web:
    image: nginx:1.25
    ports:
      - "8080:80"
    depends_on:
      - api
  api:
    build: ./api
    environment:
      - DATABASE_URL=postgres://db:5432/app
    depends_on:
      - db
  db:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

这个例子定义了三个服务（web前端、api后端、postgres数据库），通过 docker compose up -d 一键启动。

三、Kubernetes 核心概念与常用操作

1. 核心概念

• Pod：Kubernetes 中最小的可部署单元，封装一个或多个容器。Pod 中的所有容器共享网络和存储，始终运行在同一节点上。
• Deployment：管理 Pod 的控制器，提供副本管理、滚动升级和自愈能力。
• Service：为一组 Pod 提供稳定的网络访问入口和负载均衡。
• Ingress：七层路由，将外部 HTTP/HTTPS 流量路由到集群内的 Service。
• Namespace：资源隔离和配额管理的逻辑分区。

2. kubectl 常用命令

基础命令：

# 查看资源
kubectl get pods -A -o wide          # 查看所有 Pod
kubectl get deployments              # 查看部署
kubectl get services                 # 查看服务
kubectl get nodes                    # 查看节点

# 查看详情
kubectl describe pod <pod-name>      # 查看 Pod 详情

# 查看日志
kubectl logs -f <pod-name>           # 实时查看 Pod 日志

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash  # 进入 Pod 容器

部署管理：

# 应用配置
kubectl apply -f <yaml-file>         # 声明式创建/更新资源

# 扩缩容
kubectl scale deployment <name> --replicas=5  # 调整副本数

# 滚动更新
kubectl set image deployment/<name> <container>=<new-image>  # 更新镜像
kubectl rollout status deployment/<name>      # 查看更新状态
kubectl rollout undo deployment/<name>        # 回滚

3. Kubernetes YAML 示例

Deployment（部署3个 nginx Pod） ：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

Service（暴露服务） ：

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

四、实战案例：多主机 K8s 集群部署与管理

场景描述

部署一个高可用的 Web 应用集群，包含：

• 3台控制平面节点（高可用）
• 3台工作节点（承载业务 Pod）
• 应用包含：前端（Nginx）、后端 API（Node.js）、数据库（PostgreSQL）
• 要求：滚动更新、自动扩缩容、故障自愈

第一步：环境准备

节点规划：

角色	主机名	IP	配置要求
控制平面1	k8s-master1	10.0.1.11	≥2核/4GB
控制平面2	k8s-master2	10.0.1.12	≥2核/4GB
控制平面3	k8s-master3	10.0.1.13	≥2核/4GB
工作节点1	k8s-worker1	10.0.1.21	≥2核/4GB
工作节点2	k8s-worker2	10.0.1.22	≥2核/4GB
工作节点3	k8s-worker3	10.0.1.23	≥2核/4GB

生产环境建议控制平面节点为奇数（3或5），有利于故障时重新选举。

所有节点执行：

# 1. 设置主机名
hostnamectl set-hostname k8s-master1  # 各节点对应修改

# 2. 禁用 Swap（K8s 强制要求）
swapoff -a
sed -i '/swap/d' /etc/fstab

# 3. 开启 IP 转发
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

# 4. 关闭防火墙或开放必要端口
# 6443/TCP: API Server, 2379-2380: etcd

# 5. 安装容器运行时（containerd）
yum install -y containerd.io  # CentOS
# 或 apt install -y containerd  # Ubuntu

# 6. 安装 kubeadm、kubelet、kubectl
# CentOS:
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
EOF
yum install -y kubelet kubeadm kubectl
systemctl enable kubelet

第二步：初始化集群

仅在第一个控制平面节点执行：

# 1. 初始化集群
kubeadm init --control-plane-endpoint "10.0.1.10:6443" \
  --pod-network-cidr=10.244.0.0/16 \
  --upload-certs

# 2. 配置 kubectl
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# 3. 安装 CNI 网络插件（以 Flannel 为例）
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

初始化成功后会输出两个重要命令：

• 控制平面加入命令：用于将其他控制平面节点加入集群
• 工作节点加入命令：用于将工作节点加入集群

第三步：加入其他节点

在其他控制平面节点执行（使用 init 输出的命令）：

kubeadm join 10.0.1.10:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane --certificate-key <key>

在工作节点执行：

kubeadm join 10.0.1.10:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

第四步：验证集群

# 查看所有节点状态
kubectl get nodes -o wide
# 预期输出：6个节点全部 Ready

# 查看系统 Pod
kubectl get pods -n kube-system

第五步：部署应用

1. 部署 PostgreSQL（StatefulSet）

# postgres.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          value: "secret"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: pgdata
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: pgdata
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  ports:
  - port: 5432

2. 部署后端 API（Deployment + Service）

# api.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp/api:latest
        env:
        - name: DATABASE_URL
          value: "postgres://postgres:secret@postgres:5432/app"
        ports:
        - containerPort: 3000
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 3000

3. 部署前端 Nginx（Deployment + Service + Ingress）

# frontend.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: frontend
  ports:
  - port: 80
    targetPort: 80
  type: NodePort  # 或 LoadBalancer
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 80

部署所有资源：

kubectl apply -f postgres.yaml
kubectl apply -f api.yaml
kubectl apply -f frontend.yaml

第六步：管理与调度

1. 查看部署状态

kubectl get pods -o wide        # 查看 Pod 分布在哪些节点
kubectl get deployments         # 查看 Deployment
kubectl get services            # 查看 Service

2. 滚动更新

# 更新 API 镜像版本
kubectl set image deployment/api api=myapp/api:v2.0

# 查看更新进度
kubectl rollout status deployment/api

# 如果出问题，立即回滚
kubectl rollout undo deployment/api

3. 自动扩缩容（HPA）

# 基于 CPU 使用率自动扩缩容
kubectl autoscale deployment api --cpu-percent=50 --min=2 --max=10

4. 调度策略——将 GPU 任务调度到特定节点：

# 给节点打标签
kubectl label nodes k8s-worker1 hardware=gpu

# Pod 中指定 nodeSelector
spec:
  nodeSelector:
    hardware: gpu
  containers:
  - name: ml-worker
    image: ml-app:latest

5. Pod 反亲和——将 Pod 分散到不同节点提高可用性：

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: api
        topologyKey: kubernetes.io/hostname

6. 查看日志与调试

# 查看特定 Pod 日志
kubectl logs -f <pod-name>

# 查看某个节点的 Pod 分布
kubectl get pods -o wide --field-selector spec.nodeName=k8s-worker1

五、从 Docker Compose 到 Kubernetes 的迁移思路

如果已有 Docker Compose 配置，迁移到 K8s 的推荐路径：

1. 审计现有系统：梳理服务依赖、环境变量、数据卷、网络配置
2. 转换服务：将每个 Compose service 转换为 K8s Deployment + Service
3. 适配存储：将 Compose volumes 转换为 PersistentVolumeClaim
4. 配置网络：将 Compose 网络转换为 K8s Service 发现（注意 DNS 命名差异）
5. 验证：逐步迁移，灰度验证

可使用 kompose 工具辅助转换，但需手动调整细节。

六、选型决策建议

使用 Docker Compose 的场景：

• 本地开发和原型验证
• 服务数量少（2-6个）
• 单台服务器足以承载业务
• 更新期间短暂停机可接受
• 团队规模小，运维能力有限

使用 Kubernetes 的场景：

• 生产环境多服务部署
• 需要高可用（零停机更新）
• 需要自动扩缩容应对流量波动
• 多台主机/多云部署
• 微服务架构，服务数量多
• 需要精细的调度、资源配额和权限控制

---

深度拆解底层工作原理

解析Pod、Deployment、Service之间的关系

这里涉及了Kubernetes最核心的几个概念，理解它们的“分工”和“绑定”方式是掌握K8s的关键。我用通俗的方式来拆解一下。

一、Pod、Deployment、Service 到底是什么关系？

用一个餐厅后厨的比喻，就能秒懂：

• Pod（厨师 + 灶台）：是K8s里最小、最基础的“干活单元”。它里面装着一个或多个容器（比如装菜品的锅）。这个“灶台”有自己的IP地址，但它是临时的——如果厨师生病（Pod挂了），灶台会被撤掉，换个新灶台，但IP地址就变了。
• Deployment（厨师长）：是管Pod的“大管家”。它不干活，只管指挥手下有多少个厨师（Pod）。告诉它“我要3个厨师”，它就保证一直有3个在岗；如果有个厨师请假（Pod挂了），它会立刻招一个新厨师顶上；如果食谱更新（镜像升级），它会安排轮流换岗（滚动更新），保证后厨不停业。
• Service（餐厅前台/门牌号）：是固定不变的“入口”。不管后厨的厨师（Pod）怎么换人（IP怎么变），客户（前端应用）只需要记住“餐厅地址”（Service的固定IP和DNS名）。Service会自动把请求转发给当前在岗的、符合要求的厨师（Pod），并在他们之间分担压力（负载均衡）。

一句话总结三者的协作流：

Deployment 创建和管理 Pod（干活的人），Service 通过标签找到这些 Pod，为它们提供一个永远不变的访问入口。

---

二、一个主机（节点）可以有多个 Pod 吗？如何分配？

当然可以，而且必须有！

一台物理机或虚拟机（Node）上通常运行着几十甚至上百个Pod。K8s之所以叫“容器编排”，就是要把大量的Pod合理地塞进有限的机器里。

Pod是怎么分配到某台主机的？ 这个过程叫调度（Scheduling），由K8s集群里的“大脑”组件——kube-scheduler 负责。它的分配逻辑主要分三步：

1. 过滤（硬性条件）：先把不符合条件的机器踢掉。比如，Pod要求必须有4GB内存，那内存不足的主机直接Pass；或者Pod声明了“我要用GPU”，那没装显卡的主机直接排除。
2. 打分（择优录取）：在剩下的候选主机中，调度器会算一个“分数”。它会尽量把Pod分散到不同机器（避免单点故障），也会优先把资源剩余最多的机器排前面。
3. 绑定（最终执行）：调度器把Pod“绑定”到分数最高的那台主机上，然后该主机上的kubelet组件就会拉取镜像，把Pod真正跑起来。

可以干预分配吗？ 完全可以！

• 用 nodeSelector：给主机贴标签（如 disktype=ssd），让Pod只跑到SSD机器上。
• 用 亲和性/反亲和性：强制定义“这两个Pod必须在一台机器”（就近高速通信）或“这两个Pod绝对不能在一台机器”（故障隔离）。

---

三、一个 Pod 可以有多个 Service 吗？如何分配/对应？

当然可以！一个Pod可以被无数个Service同时指向。

它是如何关联的？——全靠“标签（Label）”和“选择器（Selector）”进行松耦合绑定。

Service并不关心Pod的IP，它只关心标签。打个比方：Pod就像商场里的商品，商品上贴着标签（比如 app=web 和 tier=frontend）。Service就像商场的指示牌，指示牌上写着“请找贴有 app=web 标签的商品”。

• 分配机制：当创建一个Service时，YAML文件里会定义一个 selector。K8s会实时扫描集群里所有Pod的标签，只要某个Pod的标签完全匹配Service的选择器，这个Service就会自动把这个Pod纳入自己的“负载均衡池”里。

举个实际例子：
假设有一个数据库Pod，它贴着标签 app=db 和 env=prod。

• Service A（内部访问）：选择器是 app=db。后端微服务通过这个Service访问数据库。
• Service B（外部监控）：选择器也是 app=db，但类型是 NodePort。运维人员通过这个Service在外部用监控工具直连数据库。
• Service C（临时调试）：甚至还可以再建一个Service，只要选择器写的也是 app=db，同样能指向这个Pod。

所以：Pod和Service是多对多的关系。一个Pod可以被多个Service选中，一个Service也可以同时选中多个Pod（只要标签相同）。

---

四、结合以上解析，画个实体关系图

                         [ kubectl get deployments ]
                                  |
                           Deployment (厨师长)
                                  | 管理/创建
                                  ▼
                         +-------+-------+
                         |               |
                    [Pod A]          [Pod B]    <- 这两个Pod有相同标签(如 app=nginx)
                    IP: 1.2.3.4     IP: 1.2.3.5
                         |               |
                         +-------+-------+
                                 |
                           标签匹配(Selector)
                                 ▼
                      [ Service (固定VIP) ]   <- 地址永远不变(如 10.96.0.1)
                                 |
                     [ kubectl get services ]

命令解析：

• kubectl get pods -o wide：看到的是实际干活的灶台，以及它们分别坐在哪张桌子（Node）上。
• kubectl get deployments：看到的是厨师长，确认我要管的3个灶台是否都正常。
• kubectl get services：看到的是固定门牌号，不管灶台怎么换，这个门牌号永远指向那群贴了特定标签的灶台。

---

pod和容器以及Service负载关系拆解

如果一个Pod里放了多个容器，它们之间是什么关系”？“Service具体是怎么做负载均衡？
下面来深入拆解，跳出厨师比喻，直接钻进技术底层，把这两块硬骨头彻底啃透。从两个维度展开：

1. Pod 里的多个容器，到底是什么“合租”关系？
2. Service 的负载均衡和流量转发，底层到底是怎么“派单”的？

---

深入拆解一：Pod 里的多个容器（紧密“合租”，而非普通“邻居”）

在 Docker 中，两个独立的容器就是两台独立的“小电脑”，有自己的 IP、自己的进程树。但在 K8s 的 Pod 里，多个容器不是“邻居”，而是“合租室友”——它们共享同一套“房间基础设施”。

它们到底共享什么？

• 共享同一个网络命名空间（Network Namespace）：这意味着 Pod 里的所有容器共用同一个 IP 地址和同一个端口范围。它们通过 localhost（127.0.0.1）就能互相通信。所以，如果 Pod 里有个 Nginx（监听80）和一个 API（监听8080），Nginx 配置文件里直接写 proxy_pass http://127.0.0.1:8080 就能转发。
• 共享同一个 IPC 命名空间：它们可以通过 System V 或 POSIX 信号量进行进程间通信。
• 共享同一个 Volume（存储卷）：它们可以挂载同一个目录，A 容器写文件，B 容器实时读取。

既然共享这么多，它们的“分工”是什么？——经典 Sidecar（边车）模式

Pod 里多个容器绝不是为了塞进一堆无关服务（比如把 MySQL 和 Nginx 塞一起是反模式）。它们通常是**“主容器（Main Container）+ 辅助容器（Sidecar）”**的关系：

• 主容器：负责核心业务（比如启动一个 Web 后端）。
• Sidecar 容器：负责辅助功能，比如：
  • 日志收集：主容器把日志打到共享 Volume 的 log 文件里，Sidecar 容器（如 Filebeat）实时读取并发送到 Elasticsearch。
  • 代理/网络网格（Istio）：主容器处理业务，Sidecar（Envoy）拦截所有进出流量，做鉴权和加密，业务代码完全无感知。
  • 配置动态刷新：主容器跑着 Nginx，Sidecar 每隔 30 秒去 Git 拉取最新配置，然后让 Nginx 热加载。

调度是怎么分配的？
记住：调度器调度的最小单位是 Pod，而不是容器。K8s 永远不会把一个 Pod 里的两个容器拆开到两台主机上。它们作为一个原子单位，被绑定在同一台 Node 上，同生共死。

---

深入拆解二：Service 的负载均衡，底层到底怎么“派单”？

“Service 怎么分配流量”，表面看是它着转发，但实际上 Service 本身并不直接处理网络包。真正干脏活累活的是每个节点上运行的 kube-proxy 组件。

目前默认主流模式是 iptables（还有性能更高的 IPVS，原理类似），详细拆解下看流量怎么走：

第一步：创建 Service 时发生了什么？

当执行 kubectl apply -f service.yaml 后，K8s 控制平面会做两件事：

1. 给这个 Service 分配一个固定的虚拟 IP（ClusterIP）（比如 10.96.0.1）。
2. 控制平面会持续监控 Pod 的变化，一旦发现新 Pod 启动或挂掉，马上更新 API Server 里的 Endpoint（端点列表）。可以执行 kubectl get endpoints <service-name> 看看，里面就是当前匹配标签的所有 Pod 的 真实 IP:Port 列表（比如 192.168.1.2:80, 192.168.1.3:80）。

第二步：kube-proxy 怎么把规则写到机器上？

每个 Node 上的 kube-proxy 监听到 Endpoint 变了，立刻在本机的内核网络规则（iptables 链）里修改转发规则。

核心机制（以 iptables 模式为例）：

1. 当集群内某个 Pod 要访问 10.96.0.1:80 时，请求先被本机的网络栈拦截。
2. 内核查到 iptables 规则，匹配到该 ClusterIP，随机（或轮询） 跳转到 Endpoint 列表中对应的 Pod IP。
3. 关键点（DNAT）：kube-proxy 做的是 目标地址转换（DNAT）——把目标 IP 10.96.0.1 悄悄换成后端某个 Pod 的 192.168.1.2，然后把包扔出去。

注意：如果后端 Pod 挂了，kube-proxy 会立即从所有节点的 iptables 规则中踢掉那个 IP。所以客户端如果正好访问到坏掉的 Pod，会连接失败，但下一次新的连接就会绕开它（K8s 不负责重试失败的单次请求，这需要业务代码或重试机制兜底）。

第三步：如果想保持“会话黏性”（Sticky Session）怎么办？

默认情况下，同一个客户端的多次请求会被随机分配到不同的 Pod。如果希望同一个客户端始终访问同一个 Pod（比如为了保留本地 Session 缓存），可以配置 sessionAffinity: ClientIP。此时 kube-proxy 会基于客户端的源 IP 做 Hash，确保同一个源 IP 的请求永远走同一条 iptables 跳转规则。

---

深入拆解三：把这两层结合起来（终极理解）

现在串联一下完整的请求链路（以外部流量通过 NodePort 进入为例）：

1. 外部请求 -> 访问 Node 的 IP:30000（NodePort）。
2. 节点内核 iptables 拦截 30000 端口，做 DNAT，将目标 IP 转为 Service 的 ClusterIP（10.96.0.1）。
3. 再次匹配 iptables，发现 ClusterIP 10.96.0.1 对应一组 Endpoint（Pod IP 列表）。
4. 随机选一个 Pod IP（比如 192.168.1.5）。
5. 第二次 DNAT，把目标 IP 改为 192.168.1.5。
6. 网络包到达目标 Node，进入目标 Pod。
7. 进入 Pod 内部：包到达 Pod 的虚拟网卡。如果这个 Pod 里有 2 个容器（比如 Web 容器 + 日志收集容器），包最终只会被监听端口的那个主容器接收（因为 IP 是共享的，但端口不同）。

特别陷阱提醒（Pod 多容器时的端口冲突）：
既然 Pod 内的容器共享网络命名空间，意味着两个容器绝对不能监听同一个端口！比如想让 Nginx 和另一个 Web 服务都监听 80 端口，完全不可能，会报端口占用。此时只能错开端口，或者其中一个容器不监听端口（只做后台任务）。

---

总结一句话

• Pod 多容器：共享 IP、Volume 和进程空间，作为不可分割的调度原子，主要用于“主业务 + 辅助运维功能”的紧耦合场景。
• Service 负载均衡：依靠 kube-proxy 维护的 iptables/IPVS 规则，实时感知 Pod 变化，动态修改内核转发策略，实现无感知的流量分发。