寫今天這篇文章前我糾結了很久，到底應該繼續介紹 K8s 元件，還是應該直接開始記錄實作的過程呢？仔細想想、四處看看之後發現其實網路上已經有很多篇介紹基本元件的文章，所以與其介紹大家都說過的東西，不如來提一點我自己覺得概念上比較重要的地方，接著就開始邊做邊記，這樣可能也會更加貼近大家所想看見的內容！

常見的 Kubernetes Components

為了更清楚地理解 Kubernetes 的運作，我們可以將常見的元件分成四個主要面向：Workload、Networking、Config、Storage。這些元件互相搭配，讓 Kubernetes 集群能同時處理應用部署、網路連線、設定管理與資料持久化。
我想 workload 的部分應該不需要再額外多做說明，Pod 就是 K8s 在運行時的最小單位。而 Pod 又可以被 ReplicaSet / StatefulSet / DaemonSet 這三種單位控管，細節的話可以再去看看官方文件的介紹（或者其實架起來就能分辨這些 Set 之間的差異了）。個人認為比較重要的是 Networking component 所代表的概念。

Service

Service 被分成 ClusterIP / LoadBalancer / ExternalName / NodePort 四種，我們先來討論 ClusterIP 的概念。我們都知道 Pod 是一種隨時都會被開開關關的 workload，因此如果直接使用 Pod IP 來存取 Pod 裡面的服務的話，有可能在某次開關之後，同個 IP 就沒有作用了。這時我們就會需要 ClusterIP 來幫我們解決這個問題。主要的解法會是這樣：ClusterIP Service 會透過 selector 找到符合條件的 Pod，並將它們記錄在 EndpointSlice 中。kube-proxy 監聽這些 EndpointSlice，並在每個 Node 的 iptables 建立規則，讓 ClusterIP 流量能正確轉發到對應的 Pod。

一個簡單的 ClusterIP Service 範例如下，我們可以看到在 spec.selector 就是綁定符合條件的 Pod 的方式：

apiVersion: v1
kind: Service
metadata:
  name: n8n
  namespace: n8n
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: n8n
  clusterIP: 172.16.3.92
  internalTrafficPolicy: Cluster
  ipFamilies:
	- IPv4
  ports:
	- name: http
	  port: 80
	  protocol: TCP
	  targetPort: http

再來是 LoadBalancer 的概念，LoadBalancer Service 在內部一樣會透過 selector 維護 EndpointSlice，並由 kube-proxy 在節點上建立轉發規則；不同的是，它還會向雲端供應商請求建立一個外部 Load Balancer，並把流量導向 Service 的 ClusterIP，再由 ClusterIP 分配到對應的 Pod。有關雲端供應商建立 Load Balancer 的這一段，我們在後面建立 Load Balancer Controller 和 Ingress Nginx 這兩張 Helm chart 時會再詳細介紹。

以下就是一個簡單的 LoadBalancer Service 的範例，可以看到 spec.selector 的部分也會指定後面要送到的 Pod 所需要滿足的條件。另外這邊因為我們有使用 Load Balancer Controller，所以 annotation 上也會有相對應的設定：

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-xxxx: xxxxx
  name: ingress-nginx
  namespace: kube-system
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  allocateLoadBalancerNodePorts: true
  clusterIP: 172.16.6.217
  clusterIPs:
  - 172.16.6.217
  externalTrafficPolicy: Local
  internalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  loadBalancerClass: service.k8s.aws/nlb
  ports:
    - appProtocol: https
      name: https
      nodePort: 31963
      port: 443
      protocol: TCP
      targetPort: http

最後是 ExternalName（不講 NodePort 是因為我過去兩年來從來陪碰過這個 service type 🥹），其實就是有點像 DNS CNAME record 的角色，方便 cluster 內部的 Pod 向外部服務 send request 而已。

Ingress

K8s 網路元件除了 Service 以外，還有另一個很重要的概念是 Ingress。與 Service 最大的不同在於，Service 會像是 Pod 的 DNS CNAME record，Ingress 則是判斷流量要送到哪個 service 的規則。也就是說，你可以「對一個 Service 發出 request」，但你不能「對一個 Ingress 發出 request」，因為 ingress 只是規則而已。而這所謂要把流量送去哪的「規則」，通常會是根據 request 中的 host / path / prefix 等等 L7 協定才會有的欄位來進行判斷。

以下就是一個簡單的 ingress example，可以看到 rules 裡面那段就是判斷流量要去哪個 service 的規則：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/enable-cors: "true"
  name: n8n
  namespace: n8n
spec:
  ingressClassName: nginx
  rules:
	- host: n8n.xxx.xxx.xxx
	  http:
	    paths:
          - backend:
		      service:
                name: n8n
                port:
                  number: 80
            path: /
            pathType: Prefix

有規則不夠，我們還需要實作規則的人，而 ingress controller 就是負責實作 ingress 導流的物件。這個 ingress controller 可以是 nginx 或 traefik 或 AWS ALB 等等的工具。也因為基本上 ingress 是基於 L7 協定欄位設置的規則，因此常見的 ingress controller 都會是 L7 的。所以對 K8s 而言是不會有 L4 的 ingress controller 的，但如果要自行處理 L4 流量的話，需要額外安裝 traefik 等自訂的 CRD 來控制。

結語

今天詳細介紹了 Kubernetes 元件中我覺得最重要的幾個網路元件，Service 跟 Ingress 真的算是 Kubernetes 裡面最關鍵的兩個概念了。畢竟 K8s 最關鍵的價值就是幫忙處理流量，把應用穩定地曝光出去；少了 Service 和 Ingress，整個雲原生的網路世界就走不動。這篇先把觀念釐清，接下來就準備開始動手實作，看看它們在真實環境裡是怎麼跑的吧 🚀