Kubernetes 配置同步機制
同步機制
Kubernetes 的配置同步過程可以分為兩個階段：初始化階段和同步階段。
初始化階段：在 OpenResty Edge Admin 啟動時，會初始化 Kubernetes 配置的監聽管理器。在啟動多個 Edge Admin 例項的場景下，只有獲得鎖的 Edge Admin 會進行 Kubernetes 配置的監聽。
同步階段：監聽器管理器會定期啟動監聽器，每個 Kubernetes 叢集會啟動兩個監聽器（例如，在有三個 Kubernetes 叢集的情況下，則會有六個監聽器），分別監聽
/api/v1/watch/services和/api/v1/watch/endpoints的相關事件並進行處理。
事件處理
目前，我們支援處理以下事件：
endpoint 新增事件
事件型別：
ADDED觸發時機：
- 在首次與 Kubernetes 的 watch 介面建立連線的時候。
- 在暴露 deployment（建立 service）時，例如使用命令
kubectl expose deployment/test-hello。
事件處理：Edge Admin 會更新與 Kubernetes 上 pod 對應的上游節點資訊。
事件來源：
/api/v1/watch/endpoints事件示例：
{ "type": "ADDED", "object": { "apiVersion": "v1", "kind": "Endpoints", "metadata": { "name": "test-hello", "namespace": "default", ... }, ... } }
endpoint 修改事件
事件型別：
MODIFIED觸發時機：
- 在 pod 進行擴容或縮容時，會觸發該事件。
- 在刪除 deployment 時，例如使用命令
kubectl delete deployment test-hello。
事件處理：Edge Admin 會更新與 Kubernetes 上 pod 對應的上游節點資訊。
事件來源：
/api/v1/watch/endpoints事件示例：
{ "type": "MODIFIED", "object": { "apiVersion": "v1", "kind": "Endpoints", "metadata": { "name": "test-hello", "namespace": "default", ... }, ... } }
service 新增事件
事件型別：
ADDED觸發時機：新增 service 後會觸發該事件。
事件處理：Edge Admin 會新增對應的 DNS 記錄。
事件來源：
/api/v1/watch/services事件示例：
{ "type": "ADDED", "object": { "kind": "Service", "metadata": { "name": "test-hello", "resourceVersion": "3686", "namespace": "default", ... }, "apiVersion": "v1", "spec": { "selector": { "app": "test-hello" }, "ports": [ { "port": 80, "protocol": "TCP", "nodePort": 30476, "targetPort": 80 } ], "clusterIPs": [ "10.68.181.72" ], ... } } }
service 修改事件
事件型別：
MODIFIED觸發時機：在修改 service 後會觸發該事件，例如使用命令
kubectl edit svc test-hello。事件處理：Edge Admin 會修改對應的 DNS 記錄。
事件來源：
/api/v1/watch/services事件示例：
{ "type": "MODIFIED", "object": { "kind": "Service", "metadata": { "name": "test-hello", "namespace": "default", ... }, "apiVersion": "v1", "spec": { "selector": { "app": "test-hello" }, "clusterIP": "10.68.181.72", "ports": [ { "port": 80, "name": "http", "protocol": "TCP", "nodePort": 30476, "targetPort": 80 }, { "port": 88, "name": "http2", "protocol": "TCP", "nodePort": 30478, "targetPort": 88 } ], "clusterIPs": [ "10.68.181.72" ], ... } } }
service 刪除事件
事件型別：
DELETE觸發時機：刪除 service 後會觸發該事件。
事件處理：Edge Admin 會刪除對應的 DNS 記錄。
事件來源：
/api/v1/watch/services事件示例：
{ "type": "DELETED", "object": { "kind": "Service", "metadata": { "name": "test-hello", "namespace": "default", ... }, "apiVersion": "v1", "status": { "loadBalancer": [] }, "spec": { "selector": { "app": "test-hello" }, "clusterIP": "10.68.217.25", "ports": [ { "port": 81, "protocol": "TCP", "nodePort": 31183, "targetPort": 81 } ], "clusterIPs": [ "10.68.217.25" ], ... } } }
錯誤碼說明
在配置同步過程中，可能會出現監聽錯誤或事件處理失敗，以下是所有錯誤碼的說明：
| 錯誤碼 | key | 描述 |
|---|---|---|
| 1 | ERR_WORKER_EXITING | worker 程序正在退出 |
| 2 | ERR_CONFIG_DELETE | Kubernetes 配置已被刪除 |
| 3 | ERR_CONFIG_UPDATE | Kubernetes 配置已被更新 |
| 4 | ERR_NOT_MASTER | 當前程序不是 master |
| 5 | ERR_MAX_RUNTIME | 從 Kubernetes 叢集讀取響應體超時 |
| 6 | ERR_PARSE_DOMAIN | 解析 Kubernetes 叢集域名失敗 |
| 7 | ERR_CONNECT_FAILED | 連線 Kubernetes 叢集失敗 |
| 8 | ERR_SSL_HANDSHAKE | 和 Kubernetes 叢集進行 SSL 握手失敗 |
| 9 | ERR_REQUEST_URI | 傳送請求到 Kubernetes 叢集失敗 |
| 10 | ERR_REQUEST_DENIED | 請求被 Kubernetes 叢集拒絕 |
| 11 | ERR_REQUEST_STATUS | Kubernetes 叢集返回了非預期的響應狀態碼（非 200） |
| 12 | ERR_READ_BODY | 從 Kubernetes 叢集讀取響應體失敗 |
常見問題
Kubernetes 配置同步的延遲是多久？
Kubernetes 的事件會被合併處理，合併視窗為 1 秒，因此配置同步通常會有 1 秒左右的延遲。例如某 1 秒內，Edge Admin 收到同一個 deployment 發生了 2 次 pod 變更的事件通知，Edge Admin 將會合並 2 次通知，在 1 秒後進行 1 次配置變更，
Kubernetes 配置是否會進行全量同步？
啟動監聽器時，會立即接收到 Kubernetes 叢集中 service 和 endpoint 的
ADDED型別的事件，然後進行全量同步對應的配置。Kubernetes 的 pod 變更後，是否會導致 Edge Admin 產生髮布記錄？
由於 Kubernetes 的變更頻繁，因此 Edge Admin 不會記錄釋出日誌，但會有審計日誌。
何時會增加和刪除監聽器？
當新增 Kubernetes 配置到 Edge Admin 後，監聽器會定期重啟，以防止協程資源洩露。當從 Edge Admin 刪除 Kubernetes 配置後，會回收對應的監聽器。
如果配置未變更，是否仍會處理收到的事件？
當 Edge Admin 收到來自 Kubernetes 叢集的事件後，它會比較相關配置，如果配置未發生變更，則不會進行更新上游等操作。