返回
Featured image of post k8s - Networking

k8s - Networking

k8s - Networking

處理完 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=NodePortService.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,都是不錯的選擇。

Licensed under CC BY-NC-SA 4.0
comments powered by Disqus