Ingress 是 Kubernetes API 的标准资源类型之一 ，它其实就是一组基于 DNS 名称 （ hos t )
或 URL 路径把请求转发至指定的 Service 资源的规则 ， 用于将集群外部的请求流量转发至
集群内部完成服务发布 。 然而， Ingress 资源自身并不能进行“流量穿透”，它仅是一组路由
规则的集合，这些规则要想真正发挥作用还需要其他功能的辅助，如监昕某套接字 ， 然后根
据这些规则的匹配机制路由请求流量 。 这种能够为 Ingress 资源监听套接字并转发流量的组
件称为 Ingress 控制器（ Ingress Controller ） 。
Ingress 控制器可以由任何具有 反向代理（ HTTP /HTTPS ）功能的服务程序 实 现，如
Nginx 、 Envoy 、 HAProxy 、 Vulcand 和 Traefik 等。 Ingress 控制器自身也是运行于 集 群中
的 Pod 资源对象，它与被代理的运行为 Pod 资源的应用运行于同 一 网络中，如图 6 - 12 中
ingress-nginx 与 podl 、 pod3 等 的关系所示 。
另一方面，使用 Ingress 资源进行流量分发时， Ingress 控制器可基于某 Ingress 资源定
义的规则将客户端的请求流量直接转发至与 Service 对应的后端 Pod 资源之上，这种转发机
制会绕过 Service 资源，从而省去了由 kube“proxy 实现的端口代理开销 。 如图 6-12 所示，
Ingress 规则需要由一个 Service 资源对象辅助识别相 关的所有 Pod 对 象，但 i ngress-nginx
控制器可经由 api.ilinux.io 规则的定义直接将请求流量调度至 pod3 或 pod4 ，而无须经由
Service 对象 API 的再次转发， WAP 相关规则的作用方式与此类同 。
IngreSS 控制器自 身是运行于 Pod 中的容器应用， 一般是 Nginx 或 Envoy －类的具有代
理及负载均衡功能的守护进程，它监视着来 自 于 API Server 的 Ingress 对象状态，并以其规
则生成相应的应用程序专有格式的配置文件并通过重载或重启守护进程而使新配置生效 。
本章重点讲解了 Kubernetes 的 S巳rvice 资源及其发布方式 ， 具体如下 。
口 Service 资源通过标签选择器为一组 Pod 资源创建一个统一的访问入口，其可将客户
端请求代理调度至后端的 Pod 资源 。
口 Service 资源是 四层调度机制，默认调度算法为随机调度 。
口 Service 的实现模式有三种： userspace 、 iptables 和 ipvs 。
口 Service 共用四种类型 ： ClusterIP 、 NodePort 、 LoadBalancer 和 Externa!Name ，它们
用于发布服务 。
口 Headless service 是一种特殊的 Service 资源，可用于 Pod 发现 。
D Ingress 资源是发布 Service 资源的另 一种方式，它需要结合 Ingress 控制器才能正常
工作 。
D Ingress Controller 的实现方式除 了 Nginx 之外，还有 Envoy 、 HAProxy 、 Traefik 等 。