處理完 Workloads 接下來就是處理每個Pod的Network溝通。
但Pod是非永久性資源,網路又有分走內外網,可以在Service層溝通,
Service
ClusterIP
: 通過Cluster的內網 IP,只能夠在Cluster內網訪問NodePort
: 透過 NodePort<Node IP>:<Node port>
,可以從Cluster
透過NodePort
訪問到相對的Pod
LoadBlancer
: 透過 Cloud Provider雲端供應商 (Example: GCP) 直接向外暴露 PodExternalName
: 通過返回CNAME
和對應值,可以將服務映射到externalName
字段的內容(例如,foo.bar.example.com)。無需創建任何類型代理。
Ex:
kubectl expose deploy nginx --type=NodePort --port=80
Pod 與 Service 的 DNS 關係
那為什麼這樣 Pod 就能透過 Service 溝通 呢? 其實是因為Pod中的 /etc/resolv.conf
檔案
Pod 的 DNS 的最新規範
在網路層級有兩的檔案很重要,一個是
/etc/resolv.conf
和/etc/hosts
etc/hosts
: 用來定義 domain name (example: 127.0.0.1 本地之所以叫 localhost,因為預設設定在這檔案)etc/resolv.conf
: 用來解析 DNS紀錄的 (紀錄有: A/AAAA/等,本地預設檔案是沒有設定指向誰)
如何看Pod中的 /etc/resolv.conf
kubectl create deploy nginx --image=nginx
kubectl get pod
kubectl exec pod/<pod-name> cat /etc/resolv.cof
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
了解原理就足夠了
Ingress
集中管理對 Cluster 中的服務外部訪問進行管理的 API ,通常是 HTTP。 算是 Cluster 唯一出入口 管理路由規則而導向某個 Service
類似 Nginx-proxy 分發的功能,官網基本介紹使用: ingress-nginx
ingress-controller 本身也是一個服務,所以也有 Pod 相關的資源啟用於 k8s ,然後要用 k8s 本身提供 RBAC 給應用服務,通常官網手把手都會直接建立一整套服務起來 \
ingress-controller 的 Pod 使用的 Service 通常都是以 Service.Type=NodePort
或 Service.Type=LoadBalancer
其他 Pod 使用的 Service 通常是以 Service.Type=ClusterIP
是由 ingress-controller 接收到封包 再由 ingress role 分發路由到 內網 Service
結語:
HTTP服務 Service 最常遇到的就是如何使用內網溝通,內網在有些雲端運算是不算錢的,所以搭配雲端自己的應用服務,這樣可以達到分散式系統。
其實蠻常遇到 Ingress 的情境只要你是做 HTTP 相關的服務蠻常是遇到 proxy 的實作案例,在K8s中Proxy實作就是常常使用到 Ingress 這樣,Ingress Controller 提供商有很多其實不只有 Nginx 也有蠻多人推崇的 istio 或著 我剛開始使用的是 Traefik,都是不錯的選擇。