架構

Zeabur 顯示的內容讀自叢集裡的 Kubernetes 物件：用 kubectl 改了副本數，Zeabur 下次讀取就顯示新的數字。服務、網域、磁碟區和備份設定都存在 Kubernetes 物件裡，移除 Zeabur 後，原本的控制器照樣管理它們。

實際操作的例子見 Zeabur 如何管理服務。要移除 Zeabur 並保留工作負載和它們依賴的元件，見移除 Zeabur。

請求從哪裡進入叢集

使用方式	使用者開啟什麼	Kubernetes API 使用的認證資訊
zeaburctl ui	本機 127.0.0.1 上的網頁	啟動時選的 kubeconfig context
叢集內的 zeabur	透過 Ingress 或 HTTPRoute 公開的 Zeabur 網址	Zeabur Identity 發給使用者的權杖。管理員帳號的權杖帶 admins 群組

zeabur 同時提供 /api 下的 API 和網頁介面。Chart 建立的 ServiceAccount 沒有綁定任何 Role，Pod 也不掛載 ServiceAccount token，每一次讀寫都用登入者的權杖。

Zeabur Identity 負責登入、通行密鑰和短效權杖。Zeabur 是它的 OAuth client，保存 client secret。kube-apiserver 要設定信任 Zeabur Identity 的 issuer，才會接受這些權杖。

專案與服務如何組成

專案就是帶 zeabur.com/project: "true" 標籤的 Namespace。把既有 Namespace 加入 Zeabur 只是加上這個標籤。從 Zeabur 移除專案只拿掉標籤，裡面的物件都還在。

Zeabur 讀取 Deployment、StatefulSet、DaemonSet 和相關物件，依下列關係組成服務：

• ownerReferences 和工作負載的 selector：哪些 Pod 屬於這個服務。
• Service selector、Ingress backend 和 HTTPRoute backendRefs：流量怎麼進來。
• 環境變數、envFrom 和 volume：用到哪些 Secret、ConfigMap 和磁碟區。
• operator 自己的物件：資料庫、物件儲存和備份。
• Helm、Argo CD、Flux 留下的標籤和管理資訊：服務是不是由其他工具管理。

Zeabur 沒有自己的資料庫。資料庫是 operator 的 CR，從 Git 部署是 Zeabur Builder 的 Build，備份是各備份控制器的物件。

變更怎麼進入 Kubernetes

1. 檢查變更 讀取現況，算出要建立、修改或刪除哪些物件，以及會造成什麼影響。
2. API 回傳一份變更權杖，以 AES-256-GCM 加密和驗證，裡面有使用者、群組、專案、請求、物件版本和期限。權杖 10 分鐘內有效。
3. 確認套用時，瀏覽器只送回這份權杖。API 核對身分和期限，重讀物件、重新計算。有物件的版本變了，就要你重新檢查。
4. 每一筆寫入先送 kube-apiserver dry run，全部通過才依序真正寫入。每筆寫入都帶著版本，刪除則帶前置條件，物件被別人改過就不會寫入。

一份變更可能修改多個物件，而 Kubernetes 沒有跨物件的交易。後面的寫入失敗時，前面寫成功的物件會留在叢集，錯誤訊息會列出已套用的項目。重新載入現況，再檢查下一份變更。

Helm、Argo CD、Flux 管理的物件，Zeabur 只接受重新啟動，其他修改會拒絕，並指出要到 Helm values 或 Git 儲存庫修改。這樣下次同步時，不會有人的修改被蓋掉。

移除介面後誰繼續工作

工作	依賴的執行元件
啟動副本、擴縮、排程工作	Kubernetes 原生控制器與 kubelet
公開網域、轉送與維護頁	ingress controller／Gateway，以及專案內的頁面工作負載
HTTPS 憑證簽發與續期	cert-manager 及其 issuer 設定
資料庫與物件儲存	各自的 operator 與儲存系統
Git 建置與自動部署	Zeabur Builder，以及有啟用時的 Keel
Secret／ConfigMap 更動後重新啟動	有安裝且設定好的 Reloader
排程備份	對應的資料庫 operator、K8up 或 Velero

這些元件都不依賴 Zeabur。移除 Zeabur 時，服務還在用的元件、CRD 和設定要留著。

狀態與歷史紀錄從哪裡來

即時 CPU 和記憶體用量來自 metrics-server。用量歷史、節點磁碟和磁碟區用量來自支援 Prometheus HTTP API 的 metrics store，Zeabur 以使用者的權限透過 Kubernetes Service proxy 查詢。啟用 Zeabur Proxy 時，用量歷史改由 Proxy 依專案權限查詢預設的 metrics store。

部署紀錄 來自工作負載保留的修訂版本，時間和修改者來自事件、容器狀態和 managedFields。叢集清掉的修訂版本、超過保留期的事件，Zeabur 也讀不到。

容器日誌預設來自 kubelet，只有副本這一次和上一次執行的內容。啟用 Zeabur Proxy 後，可以依專案權限讀取 VictoriaLogs 裡的歷史日誌。移除 chart 時 Proxy 一起移除，VictoriaLogs 裡的日誌不受影響。日誌收集器的 includePodLabels: false 在 operator v0.75.0 沒有作用，日誌仍會帶 kubernetes.pod_labels.*。

Zeabur 自己儲存什麼

• Chart 建立或指定的 Secret：OAuth client secret、變更權杖金鑰，以及啟用 Proxy 時的 TLS 憑證。
• 叢集名稱和 metrics store 設定：Zeabur 所在 Namespace 的 zeabur-settings ConfigMap。
• 成員權限：Kubernetes 的 RoleBinding 和 ClusterRoleBinding。
• 已登錄的 S3 目的地：zeabur-s3-destinations Namespace 裡的 ConfigMap 和 Secret。
• kubectl 終端機的 tools Pod：zeabur-terminals Namespace，只有 Zeabur 的 ServiceAccount 能在裡面建立和使用 Pod。
• 登入設定：Zeabur Identity 所在 Namespace 的 zeabur-identity-settings ConfigMap。設定 頁寫入，Zeabur Identity 讀取，見登入設定。
• 登入工作階段：只在伺服器程序的記憶體裡，閒置太久（最多 1 小時）或登入滿 12 小時就結束，見登入能維持多久。chart 用單一副本和 Recreate 策略，Zeabur 重新啟動後，每個人都要重新登入。

終端機會用到短暫的 Pod 和記憶體裡的 kubeconfig，權限和存活時間見安全性。