1、Kubernetes 網絡模型

Kubernetes 網絡模型由幾個部分構成：

1. 集群中的每個 Pod 都會獲得自己的、獨一無二的集群范圍 IP 地址。

   • Pod 有自己的私有網絡命名空間，Pod 內的所有容器共享這個命名空間。 運行在同一個 Pod 中的不同容器的進程彼此之間可以通過 localhost 進行通信。

2. Pod 網絡（也稱為集群網絡）處理 Pod 之間的通信。它確保（除非故意進行網絡分段）：

   • 所有 Pod 可以與所有其他 Pod 進行通信， 無論它們是在同一個節點還是在不同的節點上。 Pod 可以直接相互通信，而無需使用代理或地址轉換（NAT）。

   在 Windows 上，這條規則不適用于主機網絡 Pod。

   • 節點上的代理（例如系統守護進程或 kubelet）可以與該節點上的所有 Pod 進行通信。

3. Service API 允許你為由一個或多個后端 Pod 實現的服務提供一個穩定（長效）的 IP 地址或主機名， 其中組成服務的各個 Pod 可以隨時變化。

   • Kubernetes 會自動管理 EndpointSlice 對象，以提供有關當前用來提供 Service 的 Pod 的信息。

   • 服務代理實現通過使用操作系統或云平臺 API 來攔截或重寫數據包， 監視 Service 和 EndpointSlice 對象集，并在數據平面編程將服務流量路由到其后端。

4. Gateway API （或其前身 Ingress 使得集群外部的客戶端能夠訪問 Service。

   • 當使用受支持的 云提供商（Cloud Provider） 時，通過 Service API 的 type: LoadBalancer 可以使用一種更簡單但可配置性較低的集群 Ingress 機制。

5. NetworkPolicy 是一個內置的 Kubernetes API，允許你控制 Pod 之間的流量或 Pod 與外部世界之間的流量。

在早期的容器系統中，不同主機上的容器之間沒有自動連通， 因此通常需要顯式創建容器之間的鏈路，或將容器端口映射到主機端口，以便其他主機上的容器能夠訪問。 在 Kubernetes 中并不需要如此操作；在 Kubernetes 的網絡模型中， 從端口分配、命名、服務發現、負載均衡、應用配置和遷移的角度來看，Pod 可以被視作虛擬機或物理主機。

這個模型只有少部分是由 Kubernetes 自身實現的。 對于其他部分，Kubernetes 定義 API，但相應的功能由外部組件提供，其中一些是可選的：

- Pod 網絡命名空間的設置由實現容器運行時接口（CRI）的系統層面軟件處理。
- Pod 網絡本身由 Pod 網絡實現管理。 在 Linux 上，大多數容器運行時使用容器網絡接口 (CNI) 與 Pod 網絡實現進行交互，因此這些實現通常被稱為 CNI 插件。- Kubernetes 提供了一個默認的服務代理實現，稱為 kube-proxy， 但某些 Pod 網絡實現使用其自己的服務代理，以便與實現的其余組件集成得更緊密。- NetworkPolicy 通常也由 Pod 網絡實現提供支持。 （某些更簡單的 Pod 網絡實現不支持 NetworkPolicy，或者管理員可能會選擇在不支持 NetworkPolicy 的情況下配置 Pod 網絡。在這些情況下，API 仍然存在，但將沒有效果。）- Gateway API 的實現有很多， 其中一些特定于某些云環境，還有一些更專注于“裸金屬”環境，而其他一些則更加通用。

2、為什么需要 Service？

Pod 的 IP 不是固定的，Pod 重建時 IP 會變。

應用之間需要 穩定的訪問入口。
👉 Service 提供了一個固定的訪問地址（ClusterIP / DNS），并通過標簽選擇器將流量轉發到后端 Pod。

解決使用Pod IP 訪問應用的問題；

Kubernetes 中 Service 是主要用于Pod之間的通信，相對于Pod的IP它創建完成以后就是不變的資源； 將運行在一個或一組 Pod 上的網絡應用程序公開為網絡服務的方法。

Namespace級別的隔離。

2.1、定義service

最常用的service

apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: demo-nginxports:- protocol: TCPport: 80targetPort: 80name: http

2.2、Service的類型

    - ClusterIP：在集群內部使用的，默認類型- NodePort：在每個宿主機上暴露一個隨機端口，30000-32767，--service-node-port-range，集群外部可訪問。- LoadBalancer：使用云服務商提供的IP地址。成本太高。- ExternalName：反代到指定的域名上。

沒有Selector的service。不會自動創建EndPoints。
192.168.1.100 3306 沒有selector的service的名字+端口進行訪問到192.168.1.100 3306。
172.16.1.100

ClusterIP+Ingress 域名訪問

Service 類型	作用	使用場景
ClusterIP（默認）	僅在集群內訪問	微服務之間通信
NodePort	在每個節點上開放一個端口（30000-32767），轉發到后端 Pod	對外暴露服務（開發/測試）
LoadBalancer	使用云廠商負載均衡器，對外提供統一入口	云環境生產環境
ExternalName	將 Service 映射到外部 DNS 名稱	調用外部數據庫/第三方 API
Headless Service	不分配 ClusterIP，直接返回 Pod IP	數據庫、StatefulSet 場景

2.3、Service 工作原理

kube-proxy 是核心組件，支持兩種主要模式：

• iptables 模式：通過 iptables 規則轉發流量到后端 Pod。

• ipvs 模式：基于 Linux IPVS，性能更高，適合大規模集群。

📌 流量路徑：
客戶端 → Service VIP（ClusterIP） → kube-proxy → Pod

2.4、Service 與 DNS

kube-dns/CoreDNS 自動為 Service 創建 DNS 記錄。

訪問方式：

myservice.my-namespace.svc.cluster.local

直接 myservice（同一命名空間）

3、Ingress（高級流量管理）

它是Kubernetes集群中服務的入口，可以提供負載均衡、SSL終止和基于域名的虛擬主機。Treafik、Nginx、HAProxy、Istio。

Ingress 提供從集群外部到集群內服務的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 資源所定義的規則來控制。

• Service 暴露的是 四層網絡 (TCP/UDP)。

• Ingress 負責 七層 HTTP/HTTPS 路由，支持：

  • 域名路由（api.example.com → serviceA）

  • URL 路由（/shop → serviceB）

  • SSL 證書管理（HTTPS）

• 常用 Ingress Controller：

  • Nginx Ingress Controller

  • Traefik

  • HAProxy

Ingress 官方文檔：https://kubernetes.io/docs/concepts/services-networking/ingress/

Ingress-Nginx安裝文檔：https://kubernetes.github.io/ingress-nginx/deploy/

Ingress-Nginx 文檔：https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/

3.1、定義Ingress 資源

一個最小的 Ingress 資源示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: minimal-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:ingressClassName: nginx-examplerules:- http:paths:- path: /testpathpathType: Prefixbackend:service:name: testport:number: 80

host: 可選參數，一般都會配置我們自己的域名。
path: 一個路徑對應一個serviceName和一個Port
backend: path對應的后端是誰。
foo.bar.com/foo ? service1:4200

Ingress：https://kubernetes.io/docs/concepts/services-networking/ingress/

3.2、Ingress 規則

每個 HTTP 規則都包含以下信息：

• 可選的 host。在此示例中，未指定 host，因此該規則基于所指定 IP 地址來匹配所有入站 HTTP 流量。 如果提供了 host（例如 foo.bar.com），則 rules 適用于所指定的主機。
• 路徑列表（例如 /testpath）。每個路徑都有一個由 service.name 和 service.port.name 或 service.port.number 確定的關聯后端。 主機和路徑都必須與入站請求的內容相匹配，負載均衡器才會將流量引導到所引用的 Service，
• backend（后端）是 Service 文檔中所述的 Service 和端口名稱的組合， 或者是通過 CRD 方式來實現的自定義資源后端。 對于發往 Ingress 的 HTTP（和 HTTPS）請求，如果與規則中的主機和路徑匹配， 則會被發送到所列出的后端。

通常會在 Ingress 控制器中配置 defaultBackend（默認后端）， 以便為無法與規約中任何路徑匹配的所有請求提供服務

4、常見面試高頻問答

• Q1：Pod IP 為什么不能直接對外提供服務？
  👉 Pod IP 動態變化、生命周期不固定，外部客戶端無法直接依賴。

• Q2：Service 如何選擇后端 Pod？
  👉 通過 Label Selector 機制，所有匹配的 Pod 會加入 Endpoints。

• Q3：NodePort 的局限性是什么？
  👉 端口范圍有限（30000-32767），跨節點訪問需要 NodeIP，不適合大規模生產。

• Q4：Ingress 與 LoadBalancer 有什么區別？
  👉

LoadBalancer：提供四層入口，通常由云廠商實現。

Ingress：基于七層應用層路由，更靈活，能做域名/路徑轉發。

• Q5：Headless Service 的應用場景？
  👉 數據庫集群（如 MySQL、Redis、ZooKeeper、Kafka），需要直接訪問每個 Pod 的真實 IP。

5、總結

Service 解決 Pod 動態 IP 的問題，Ingress 解決復雜的 HTTP 路由問題，LoadBalancer 提供云環境對外統一入口。

---

“人的一生會經歷很多痛苦，但回頭想想，都是傳奇”。

---