Kubernetes Web 服务部署架构总结
一、Kubernetes 基本概念对比
| 概念 |
类型 |
作用 |
是否运行实体 |
属于控制面/数据面 |
| Pod |
最小运行单元 |
封装容器，提供统一网络/存储视图 |
✅ 是，运行容器进程 |
数据面 |
| Node |
虚拟/物理主机 |
承载 Pod 的计算资源 |
✅ 是，运行 kubelet/containerd 等 |
数据面 |
| Deployment |
控制器资源 |
管理 Pod 副本数与滚动发布策略 |
❌ 否，仅为声明式配置 |
控制面 |
| Service |
虚拟资源 |
提供 Pod 的统一访问入口与负载均衡 |
❌ 否，由 kube-proxy 实现 |
控制面 + 数据面 |
| Ingress |
路由规则 |
定义 HTTP(S) 的域名路由 |
❌ 否，实际代理由 Ingress Controller 执行 |
控制面 |
| Ingress Controller |
实体服务 |
实现 Ingress 路由转发，如 nginx/traefik |
✅ 是，运行在 Pod 中 |
数据面 |
| kubelet |
Agent 进程 |
每个 Node 的管理守护进程，控制容器运行 |
✅ 是，常驻进程 |
数据面 |
| kube-proxy |
网络代理 |
维护 Service 到 Pod 的路由规则 |
✅ 是，运行在每个 Node 上 |
数据面 |
| kube-apiserver |
中心组件 |
控制面入口，所有操作都需通过它 |
✅ 是，集群入口服务 |
控制面 |
| kube-scheduler |
控制器 |
负责 Pod 的调度分配 |
✅ 是 |
控制面 |
二、典型 Web 服务部署架构组件
以下是一个对外提供 HTTP 服务的典型架构组成：
| 组件 |
功能 |
类型 |
部署位置 |
| Web 应用 Pod |
运行业务容器 |
Deployment → Pod |
多个 Node 上调度运行 |
| Service |
提供内部统一访问 + 负载均衡 |
ClusterIP |
控制面定义，Node 上转发 |
| Ingress |
定义路由规则 |
资源对象 |
控制面定义 |
| Ingress Controller |
实际处理 HTTP 请求 |
DaemonSet / Deployment |
多个节点运行 |
| External LB |
提供公网入口 |
云厂商资源 |
集群外（如 AWS ELB） |
| ConfigMap/Secret |
配置与密钥注入 |
K8s 原生对象 |
控制面中，由 API Server 管理 |
| Fluentd / Promtail |
日志采集 |
DaemonSet / Sidecar |
每个节点或 Pod 内 |
| HPA / PDB |
弹性伸缩与高可用保障 |
控制器资源 |
控制面运行逻辑 |
| kubelet / kube-proxy |
控制与转发 |
进程守护 |
每个 Node 上 |
三、典型网络流量路径
1用户请求 ➜ 云厂商 LB ➜ Ingress Controller Pod ➜ Service ➜ Pod(8080)
- 云 LB 是公网/入口网关，一般为四层或七层代理（TCP/HTTP）；
- Ingress Controller 实际执行反向代理，通常使用 NGINX、Traefik、Istio Gateway 等；
- Service 实现 Pod 层的负载均衡，使用 kube-proxy 的 iptables 或 ipvs；
四、AWS 和阿里云架构差异对比
AWS 架构示意：
1[Route53]
2 ↓
3[AWS ALB/NLB] (公网/内网)
4 ↓
5[Ingress Controller Pod] (运行在 Node 上)
6 ↓
7[Service]
8 ↓
9[Pod]
- 云 LB：ALB (7层)、NLB (4层)
- 证书管理：AWS Certificate Manager
- 弹性扩容：结合 ASG + HPA + Cluster Autoscaler
- 镜像仓库：ECR (Elastic Container Registry)
阿里云架构示意：
1[阿里云解析 DNS] (阿里云 DNS)
2 ↓
3[SLB (共享型/独享型)]
4 ↓
5[Ingress Controller Pod] (支持 Cert-Manager)
6 ↓
7[Service]
8 ↓
9[Pod]
- 云 LB：阿里云 SLB
- 证书管理：阿里云证书中心（或接入 cert-manager）
- 弹性扩缩容：ACK 支持弹性伸缩组 + Cluster Auto Scaling
- 镜像仓库：阿里云容器镜像服务（ACR）
五、CI/CD 集成部署流程
| 阶段 |
工具举例 |
说明 |
| 代码提交 |
GitHub / GitLab |
开发者推送代码至主干分支 |
| 编译构建 |
Docker / BuildKit |
制作镜像并打 tag（CI） |
| 镜像发布 |
Harbor / ACR / ECR |
镜像推送到仓库 |
| 部署触发 |
ArgoCD / Jenkins / GitLab CI |
自动或手动触发部署流程 |
| 应用发布 |
Helm / Kustomize / kubectl |
通过 Helm 或 YAML 部署到 K8s |
| 发布策略 |
RollingUpdate / Blue-Green / Canary |
分批上线、灰度发布等策略支持 |
CI/CD 通常与 GitOps 结合，可通过 ArgoCD/Flux 监听 Git 仓库中 YAML 变化，自动完成部署。
六、常见问题 Q&A
Q1: 节点和 Pod 的区别与联系？挂了怎么恢复？
| 比较项 |
Node（节点） |
Pod（运行单元） |
| 定义 |
物理或虚拟主机 |
K8s 中最小部署单元 |
| 内容 |
OS、kubelet、容器运行时等 |
一个或多个容器及其共享资源 |
| 管理者 |
云平台 + kubelet |
K8s 控制面（Deployment、ReplicaSet） |
| 挂掉后恢复 |
云平台重启或重新加入集群 |
K8s 控制器检测后重新调度到其他节点 |
Q2: Deployment 和 Service 是“实际运行服务”吗？
不是，它们是 Kubernetes 控制面上的逻辑资源：
- Deployment：声明式定义副本数、更新策略，由控制器创建 Pod；
- Service：定义访问策略、负载方式，由 kube-proxy 实现访问路径；
- 都不是进程，也不是运行在 Node 上的实体程序。
Q3: 各个组件运行位置分别在哪？
| 组件 |
运行位置 |
| kube-apiserver / controller-manager / scheduler |
Master 节点（控制面） |
| kubelet / containerd / kube-proxy |
所有工作节点（Node） |
| Deployment / Service / Ingress |
存储于 etcd，通过控制器解释执行 |
| Pod（业务） |
部署在多个 Worker Node 上 |
| Ingress Controller |
一般以 DaemonSet 或 Deployment 运行在 Node 上 |
Q4: Ingress Controller 为什么在图里画在 Cluster 外边？
- 从网络流量视角来看，公网流量先经过云 LB，再进入 Ingress Controller；
- 所以图中将 Ingress Controller 视为“集群边缘接入点”；
- 实际上它是运行在集群内部的 Pod，只是为了便于理解边界流量而画在外面。
Q5: Kubernetes 提供的负载均衡 vs 云厂商的 LB 有何区别？
| 比较项 |
Kubernetes Service |
云厂商 LB（如 ELB） |
| 作用域 |
集群内部 Pod 之间 |
集群外部 → 内部入口 |
| 实现方式 |
kube-proxy + iptables/ipvs |
云平台原生资源，如四层/七层代理 |
| 是否自动创建 |
是（ClusterIP / NodePort / LoadBalancer） |
是（Service 设置为 LoadBalancer） |
| 是否需公网 IP |
否（除非 LoadBalancer 类型） |
是 |
| 使用场景 |
Pod-to-Pod、微服务内部调用 |
终端用户访问集群 HTTP 服务 |