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 等 。