第一层：Deployment—应用的载体

1. Deployment概述

Deployment是Kubernetes中管理Pod生命周期的核心控制器，本身不负责流量转发。它管控应用实例的运行状态、副本数量以及版本更新策略。

Deployment不会对外暴露网络访问入口，它创建的Pod属于集群内部网段，IP地址临时且不固定。为了屏蔽Pod重建、漂移所带来的IP变化，就需要Service的这一层抽象来提供稳定访问入口。Deployment的关键特性如下表所示：

特性	说明
Replicas	控制Pod副本数量，支持弹性伸缩
Selector	通过“matchLabels”关联Pod，Service的selector必须与此一致
RollingUpdate	默认滚动更新策略，保障服务连续性
Revision History	保留历史版本，支持一键回滚

2. Deployment部署

[Step1] 本地新建YAML清单，定义Deployment资源描述模板。基于Nginx镜像部署WEB应用，设置应用副本数量为2个。

root@k8s-master:~# vim nginx-deployment.yaml

# 写入下列内容
apiVersion: apps/v1     # 固定配置
kind: Deployment        # 资源类型
metadata:
  name: web-app
spec:
  replicas: 2       # 预期副本数量
  selector:
    matchLabels:    # 标签匹配模式：精确匹配
      app: web      # 匹配的标签值
  template:     # 对Pod模板的定义，至少要定义一个Label
    metadata:
      labels:
        app: web    # 定义Pod的标签，需要和Selector定义一致
    spec:
      containers:   # 定义容器的属性
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

[Step2] 基于YAML清单向Kubernetes集群声明式地创建Deployment资源。

root@k8s-master:~# kubectl create -f nginx-deployment.yaml

[Step3] 验证：查看当前集群中的名为web-app的Deployment资源。

root@k8s-master:~# kubectl get deployments.apps web-app

[Step4] 筛选标签为app=web的Pod并查看详细信息，可以看到2个以web-app开头的Pod以及对应的详细运行信息。

root@k8s-master:~# kubectl get pods -l app=web -o wide

[Step5] 此时访问后端业务Pod的方式是通过Pod IP。

root@k8s-master:~# curl -I http://10.0.2.125
root@k8s-master:~# curl -I http://10.0.1.99

第二层：Service—内部服务发现与负载均衡

1. Service概述

Service是Kubernetes里非常核心的资源，提供固定的访问入口，用于对接一组随时可能发生变化的Pod。属于四层负载均衡，工作在传输层，不解析HTTP等七层协议内容。

2.1 Service的四种类型

类型	作用域	使用场景
ClusterIP	集群内部	默认类型，仅内部可以访问
NodePort	集群外部（通过节点IP）	临时暴露、开发测试
LoadBalancer	云平台LB	生产环节下外部暴露
ExternalName	外部DNS	引用外部服务

2.3 Service的局限

Service属于四层负载均衡，工作在传输层，仅依靠IP地址和端口完成流量转发，不会解析HTTP请求内容。无法识别域名（Host）、URL路径（Path）、Cookie、请求头（Header）这类应用层特征，不能基于这些条件做路由分流。如果需要基于HTTP应用层特征实现灵或的路由控制，则需要七层负载均衡资源Ingress。

2. Service工作机制

下图是Service到后端Pod的流量转发示意图，描述四层负载均衡的工作流程：

Service: web-app-svc：集群内分配固定ClusterIP 10.96.2.15，Service端口80，转发目标端口targetPort为80，访问10.96.2.15时，流量会转发到Pod的80端口。
kube-proxy：节点上的kube-proxy支持iptables和IPVS两种工作模式，负责维护流量转发规则，完成流量分发和实现负载均衡。kube-proxy持续监听新增和删除事件，自动更新对应的转发规则，把访问ClusterIP的请求均衡分发到后端Pod。
Endpoints（端点）：Endpoints资源记录了当前就绪Pod的真实IP和端口，是Service和Pod之间的桥梁。这里一共有三个Pod，kube-proxy收到请求后，会将流量轮询分发到这三个Pod的80端口。Endpoints由endpoints-controller控制器自动维护。

3. 部署Service

[Step1] 本地新建YAML文件，创建ClusterIP类型的Service。

root@k8s-master:~# vim nginx-service.yaml

# 写入下列内容
apiVersion: v1      # 固定配置
kind: Service       # 资源类型
metadata:
  name: web-app-svc
spec:
  type: ClusterIP   # Service类型
  selector:         # 标签选择器，匹配后端Pod
    app: web        # 匹配后端Pod的标签
  ports:
    - port: 80          # Service自身暴露的端口
      targetPort: 80    # 后端Pod实际监听的端口
      protocol: TCP     # 使用TCP协议

[Step2] 根据YAML文件向Kubernetes集群声明式地创建Service资源。

root@k8s-master:~# kubectl create -f nginx-service.yaml

[Step3] 查看当前集群中的名为web-app-svc的Service资源。

root@k8s-master:~# kubectl get services web-app-svc

[Step4] 此时访问后端业务Pod的方式可以通过Service分配的ClusterIP，Service会以轮询的方式，将请求流量分发到后端两个Pod。

root@k8s-master:~# curl -I http://172.17.10.102

第三层：Ingress—七层路由规则

1. Ingress概述

Ingress是Kubernetes中声明式API资源，专门用于定义HTTP、HTTPS应用层路由规则，支持基于域名、URL路径实现流量分发。Ingress本身不具备转发流量的能力，只负责描述路由需求，真正处理流量的是Ingress Controller，它以Pod的形式运行在集群节点上。当Ingress资源创建或修改时，Ingress Controller会监听资源变更，自动读取Ingress的规则并更新内部反向代理的配置，完成七层流量路由。

3.1 Ingress的核心字段

字段	作用	示例
rules.[].host	匹配域名	www.meaauf.com
rules.[].http.paths[].path	匹配路径前缀	/、/api、/static
rules[].http.paths[].pathType	匹配类型	Prefix、Exact、ImplementationSpecific
rules[].http.paths[].backend.service.name	目标Service	web-app-svc
tls	TLS证书配置	加密HTTPS流量
annotations	控制器特定配置	Nginx注解、Rewrite规则

3.2 PathType详解

类型	匹配逻辑	示例
Prefix	匹配路径前缀	/api匹配/api、/api/v1、/api/users
Exact	精确匹配	/api仅匹配/api
ImplementationSpecific	由控制器决定匹配逻辑	通常/api匹配/api、/api/、/api/*

2. Ingress局限性

Ingress资源本身需要Ingress Controller才能生效，如果没有部署对应的控制器，仅创建Ingress的YAML配置，只是一份静态规则，无法处理任何网络流量。
Ingress处理HTTP/HTTPS协议流量，TCP/UDP这类四层流量转发，不能依靠Ingress实现，一般使用NodePort或LoadBalancer类型的Service。
Ingress的路由能力比较基础，原生不支持A/B测试、灰度发布、熔断、限流等高级流量管控功能。这类复杂流量治理场景，通常需要借助服务网格（如Istio）实现。

3. 部署Ingress

[Step1] 配置Ingress之前需要提前部署Ingress控制器。查看ingress-nginx命名空间下所有Pod，admission相关Pod状态为Completed且controller控制器Pod状态为Running，表示控制器就绪，可以正常使用。

root@k8s-master:~# kubectl -n ingress-nginx get pods

[Step2] 查看当前集群中IngressClass资源，确认集群内已存在且可用的控制器绑定项。

root@k8s-master:~# kubectl get ingressclasses.networking.k8s.io

[Step3] 本地新建YAML清单，定义Ingress资源描述模板。

root@k8s-master:~# vim nginx-ingress.yaml

# 写入下列内容
apiVersion: networking.k8s.io/v1	# 固定配置
kind: Ingress			# 资源类型
metadata:
  name: web-ingress
  annotations:			# 路径重写注解
  	# 将匹配到的请求路径统一替换为/再转发后端
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  # 指定使用的IngressClass
  ingressClassName: nginx
  rules:		# 路由规则
    - host: www.meaauf.com		# 当访问www.meaauf.com时，转发到后端服务
      http:
        paths:
          - path: /				# 匹配以/开头的路径，也就是全部路径
            pathType: Prefix	# 路径匹配规则：前缀匹配
            backend:			# 匹配成功后，流量转发到哪
              service:			# 转发到Service
                name: web-app-svc	# Service的名称
                port:			# 端口配置
                  number: 80	# 转发Service的80端口

[Step4] 基于YAML清单向Kubernetes集群声明式地创建Ingress资源。

root@k8s-master:~# kubectl create -f nginx-ingress.yaml

[Step5] 查看当前集群中的名为web-ingress的Ingress资源。

root@k8s-master:~# kubectl get ingress web-ingress

[Step6] 本地临时添加域名解析，域名指向ADDRESS。

root@k8s-master:~# echo "192.168.8.100 www.meaauf.com" >> /etc/hosts

[Step7] 此时可以通过域名访问后端业务Pod，Ingress按照预定义的路由规则转发流量至Service，Service再以轮询形式分发到后端两个Pod。

root@k8s-master:~# curl -I www.meaauf.com

第四层：IngressClass—控制器的身份标识

1. IngressClass概述

IngressClass属于集群级资源，作用是建立Ingress资源与Ingress控制器之间的绑定关系，用于指定哪一个Ingress控制器解析并执行Ingress路由规则。

当集群内部同时部署多个不同类型的Ingress控制器，例如Nginx Ingress、Traefik时，依靠IngressClass进行区分，Ingress资源通过“ingressClassName”字段选定对应的控制器，避免路由规则被错误的控制器处理。

2. IngressClass核心字段

字段	作用	说明
spec.controller	控制器标识	必须与控制器启动参数“--ingress-class”匹配
spec.parameters	引用控制器参数	可选值，指向控制器私有配置
annotations.is-default-class	默认Class标记	如果值为true，未指定ingressClassName的Ingress会使用此Class

3. 多控制器共存场景

4. 集群默认IngressClass资源

部署Nginx Ingress控制器后，集群会自动创建一份IngressClass资源，名称默认为nginx，spec.controller字段为“k8s.io/ingress-nginx”。该资源建立Ingress和Nginx Ingress控制器的绑定关系，Ingress清单中填写“ingressClassName: nginx”，对应的路由规则就会交给Nginx Ingress控制器处理。

[Step1] 查看当前集群自动创建的IngressClass资源。

root@k8s-master:~# kubectl get ingressclasses.networking.k8s.io nginx -o yaml

第五层：四者关系总结

1. 依赖关系链

四层对象的核心关系可以概括为：

关系对	关联方式	说明
Deployment ↔ Service	Service.selector = Deployment.template.metadata.labels	Service通过标签选择Pod，Pod由Deployment管理
Service ↔ Ingress	Ingress.backend.service.name = Service.metadata.name	Ingress将流量转发到Service，Service是Ingress的路由终点
Ingress ↔ IngressClass	Ingress.spec.ingressClassName = IngressClass.metadata.name	Ingress通过名称引用IngressClass，确定由哪个控制器处理

2. 数据面与控制面分离

一个核心设计原则：Service与Ingress Controller属于数据面，负责实际转发、处理业务流量。Ingress和IngressClass属于控制面，仅作为配置声明资源，本身不承载流量。

维度	数据面（处理流量）	控制面（配置规则）
对象	Service、Ingress Controller Pod	Ingress、IngressClass
职责	实际转发、负载均衡	声明路由规则、标识控制器
生命周期	Pod持续运行	YAML被创建/修改后由控制器读取

3. 理解抽象模型

Kubernetes的流量架构是一个典型的分层抽象模型：

Deployment管理应用实例的生命周期，屏蔽Pod的临时性
Service提供稳定的网络端点和L4负载均衡，屏蔽Pod IP的变化
Ingress提供L7路由能力，支持域名和路径级别的流量分发
IngressClass解决多控制器共存问题，明确路由规则的执行主体

四者之间的关系可以简化为一条依赖链，理解这条链的本质是：从内到外，每一层都在解决上一层的抽象需求。Deployment解决Pod的临时性问题，Service解决Pod IP的变化问题，Ingress解决L7路由问题，IngressClass解决多控制器选择问题。掌握这个模型后，无论是设计流量架构还是排查网络问题，都能够从全局视角快速定位根因。

4. 整体关系图

Kubernetes的三个对象容易混，是因为其中只有一个真正参与处理流量，如下图所示。三个对象中只有Service位于流量路径上，Ingress和IngressClass都只是配置。真正转发请求的是Ingress Controller（一个Pod），它读取Ingress规则并据此配置自己的代理（Nginx/Envoy等）。

Kubernetes流量入口全景解析