在K8S中,有几种Controller控制器并说一下其工作原理及ingress-controller的工作机制。
在 Kubernetes 中,Controller(控制器)是集群的“大脑”,负责监控集群状态(通过 API Server)并驱动实际状态向期望状态收敛。以下是核心控制器类型及其工作原理,以及 Ingress Controller 的详细工作机制:
一、Kubernetes 核心 Controller 类型及工作原理
1. Deployment
- 作用:管理 无状态应用 的 Pod 副本集,支持滚动更新、回滚、扩缩容。
- 工作原理:
- 用户声明期望状态(如
replicas: 3
、容器镜像版本)。 - Deployment 创建并管理一个 ReplicaSet。
- ReplicaSet 通过 Pod Template 创建/删除 Pod 以匹配副本数。
- 更新时:创建新 ReplicaSet 并逐步替换旧 Pod(滚动更新)。
- 用户声明期望状态(如
- 适用场景:Web 服务、API 服务等无需持久化数据的应用。
2. StatefulSet
- 作用:管理 有状态应用(如数据库),提供稳定的网络标识、有序部署、持久存储。
- 工作原理:
- 为每个 Pod 分配唯一序号名称(如
web-0
、web-1
)。 - 按顺序启停 Pod(如扩容时从
web-0
到web-N
)。 - 绑定 PersistentVolumeClaim (PVC) 实现持久化存储(每个 Pod 独立卷)。
- 通过 Headless Service 提供稳定的 DNS 记录(
web-0.nginx.default.svc.cluster.local
)。
- 为每个 Pod 分配唯一序号名称(如
- 适用场景:MySQL、Redis、ZooKeeper 等需要稳定标识和存储的应用。
3. DaemonSet
- 作用:确保每个 Node 上运行一个指定 Pod 的副本(新节点加入时自动部署)。
- 工作原理:
- 监听 Node 列表变化。
- 若某节点无匹配 Pod,则创建 Pod;若节点被删除,则删除对应 Pod。
- 适用场景:日志收集(Fluentd)、监控代理(Node Exporter)、网络插件(Calico)。
4. Job
- 作用:创建一次性任务,任务完成后 Pod 自动退出。
- 工作原理:
- 启动 Pod 执行任务(如批处理脚本)。
- 若 Pod 成功退出(Exit Code 0),Job 标记为完成。
- 支持并行任务(
parallelism
)和重试机制(backoffLimit
)。
- 变体:
CronJob
按计划周期执行(如每天备份数据库)。
5. ReplicaSet
- 作用:确保指定数量的 Pod 副本持续运行(Deployment 的底层组件)。
- 工作原理:
- 通过 Label Selector 匹配管理的 Pod。
- 若实际 Pod 数少于期望值,则创建新 Pod;若多于则删除多余 Pod。
- 注意:通常不直接使用,而是通过 Deployment 管理。
二、Ingress Controller 工作机制
1. Ingress 与 Ingress Controller 的关系
组件 | 作用 |
---|---|
Ingress (资源) | 定义 HTTP/HTTPS 路由规则(如域名、路径指向哪个 Service)。 |
Ingress Controller | 是具体实现者,监听 Ingress 规则并配置反向代理服务器(如 Nginx、Traefik)。 |
2. Ingress Controller 工作流程
graph TD
A[用户创建 Ingress 资源] --> B[Ingress Controller 监听 API Server]
B --> C{解析 Ingress 规则}
C --> D[生成代理配置<br>(如 Nginx.conf)]
D --> E[动态加载配置到代理服务器]
E --> F[外部流量通过代理路由到后端 Pod]
详细步骤:
-
部署 Ingress Controller
- 以 Deployment + Service 形式部署(如
ingress-nginx-controller
)。 - 其 Service 通常为
LoadBalancer
或NodePort
类型,作为流量入口。
- 以 Deployment + Service 形式部署(如
-
用户创建 Ingress 资源
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app spec: rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: web-svc # 指向后端 Service port: 80
-
Ingress Controller 监听与处理
- 持续监听 API Server 的 Ingress、Service、Endpoint 变化。
- 当检测到变更时:
- 解析所有 Ingress 规则,生成反向代理配置(如 Nginx 的虚拟主机配置)。
- 将配置应用到代理服务器(通过热加载或重启进程)。
-
流量路由示例
- 用户访问
http://app.example.com
→ DNS 解析到 Ingress Controller 的 Service IP。 - Ingress Controller(如 Nginx)根据
Host
和Path
匹配规则。 - 将请求转发到后端 Service 对应的 Pod(通过 Endpoints 列表负载均衡)。
- 用户访问
三、常见 Ingress Controller 实现
实现方案 | 特点 |
---|---|
Nginx Ingress | 基于 Nginx,功能丰富(限流、重定向、SSL),社区生态成熟。 |
Traefik | 动态配置热更新,支持多种后端(Consul、Docker),内置 Dashboard。 |
HAProxy Ingress | 高性能 L4/L7 代理,适合高并发场景。 |
AWS ALB Ingress | 集成 AWS ALB,自动创建云负载均衡器(无需 NodePort)。 |
四、关键概念对比
概念 | 职责 | 是否内置 |
---|---|---|
Controller | 管理 Pod 生命周期(如副本数、更新) | 是(如 Deployment) |
Ingress 资源 | 声明路由规则(YAML 配置) | 是 |
Ingress Controller | 实现路由规则的代理服务器 | 否(需额外部署) |
总结
- 核心控制器:
Deployment
(无状态)、StatefulSet
(有状态)、DaemonSet
(节点代理)、Job
(任务)是管理应用的核心。 - Ingress Controller:
本质是一个动态配置的反向代理,通过监听 Ingress 规则将外部流量路由到集群内 Service。
部署时必须注意:- 需单独部署 Ingress Controller Pod(如 Nginx)。
- 其 Service 需暴露到集群外(LoadBalancer/NodePort)。
- Ingress 资源仅定义规则,需关联到正确的 Ingress Controller(通过
ingressClassName
)。
理解控制器的工作机制是掌握 Kubernetes 自动化的关键,而 Ingress Controller 是实现外部访问和七层负载均衡的核心组件。