處理完 Workloads 接下來就是處理每個Pod的Network溝通。
但Pod是非永久性資源，網路又有分走內外網，可以在Service層溝通，

Service

• ClusterIP: 通過Cluster的內網 IP，只能夠在Cluster內網訪問
• NodePort: 透過 NodePort <Node IP>:<Node port>，可以從 Cluster 透過 NodePort 訪問到相對的 Pod
• LoadBlancer: 透過 Cloud Provider雲端供應商 (Example: GCP) 直接向外暴露 Pod
• ExternalName: 通過返回 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，都是不錯的選擇。