[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-kubernetes-turns-clusters-into-declared-state-zh":3,"article-related-kubernetes-turns-clusters-into-declared-state-zh":30,"series-tools-749d323d-fc9b-4492-946d-48f95ee0037d":82},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"749d323d-fc9b-4492-946d-48f95ee0037d","kubernetes-turns-clusters-into-declared-state-zh","Kubernetes 把叢集變成宣告狀態","\u003Cp data-speakable=\"summary\">我拆 Kubernetes 的控制迴圈、核心物件和可直接複製的叢集模板，讓你少走一堆 YAML 冤枉路。\u003C\u002Fp>\u003Cp>我用 Kubernetes 有一陣子了，越用越火大。第一次把真的服務接上去，我以為是 manifest 寫錯；後來怪 ingress，再怪 network policy，最後才發現都不是。它根本不是在幫我「理解」應用，它只是在很認真地照我下的指令做事。我要三份，它就給我三份；我把 node 弄掛，它就重排；我忘了 resource limit，它也不會良心發現幫我擋一下。這就是 Kubernetes 最煩的地方：它不是部署按鈕，它是一個會一直修正現實的控制系統。你不懂它的 loop，就只會一直跟自己裝的機器打架。\u003C\u002Fp>\u003Cp>後來我去看 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKubernetes\">Kubernetes 的 Wikipedia 頁面\u003C\u002Fa>，不是當百科看，是當設計筆記看，才突然通了。這頁很密，但錨點夠準：\u003Ca href=\"\u002Ftag\u002Fgoogle\">Google\u003C\u002Fa> 在 2014 年 6 月 6 日公開它，創辦人是 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FJoe_Beda\">Joe Beda\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FBrendan_Burns\">Brendan Burns\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FCraig_McLuckie\">Craig McLuckie\u003C\u002Fa>，現在由 \u003Ca href=\"https:\u002F\u002Fwww.cncf.io\u002F\">CNCF\u003C\u002Fa> 維護。這段歷史不是八卦，因為它直接解釋了 Kubernetes 的脾氣：宣告式、reconciliation、一直把叢集拉回你指定的狀態。\u003C\u002Fp>\u003Ch2>Kubernetes 不是部署工具，它是修正迴圈\u003C\u002Fh2>\u003Cblockquote>Kubernetes defines a set of building blocks (“primitives”) that collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory or custom metrics.\u003C\u002Fblockquote>\u003Cp>翻譯一下就是：Kubernetes 不太在乎你想不想被理解，它只在乎「目前的狀態」跟「你宣告的狀態」有沒有對上。你殺掉一個 pod，它會補回來；你改掉副本數，它會調整；你把機器弄壞，它會想辦法把工作搬走。這不是包裝容器而已，這是一直在修正偏差。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779197095928-obv6.png\" alt=\"Kubernetes 把叢集變成宣告狀態\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前把 orchestration 想成 \u003Ca href=\"\u002Ftag\u002Fdocker\">Docker\u003C\u002Fa> 的豪華外掛，這個理解很害人。因為你一旦把它當外掛，就會期待它去猜你的意圖。它不會。它只讀物件、比對狀態、執行動作。這就是為什麼它看起來很死板，但其實是很一致。它不是在討好你，它是在維持模型。\u003C\u002Fp>\u003Cp>我自己剛上手時最常犯的錯，就是把 manifest 當 startup script 寫。結果每次出事都在怪 YAML 太難寫。後來我才懂，Kubernetes 要的是宣告，不是命令。你要先回答三件事：要存在什麼、要幾份、狀態偏掉時要\u003Ca href=\"\u002Fnews\u002Fhow-to-read-a-solana-price-forecast-zh\">怎麼\u003C\u002Fa>拉回來。這三題答得出來，你才算真的在用 Kubernetes。\u003C\u002Fp>\u003Cp>實操上，我現在都先用這個順序想：先定義 desired state，再決定 controller，最後才補 runtime 細節。不要反過來。你如果先想容器怎麼起，再回頭補叢集要什麼，最後通常會長成一坨只能靠人肉維運的 YAML。\u003C\u002Fp>\u003Ch2>控制平面不是一台機器，是一組會互相盯著的角色\u003C\u002Fh2>\u003Cp>Kubernetes 最容易被講爛的一句話就是「控制平面」。很多人把它講得像一個黑盒子，彷彿整個叢集就是一顆腦袋。不是。它是幾個職責很清楚的元件湊在一起：\u003Ca href=\"https:\u002F\u002Fetcd.io\u002F\">etcd\u003C\u002Fa>、\u003Ca href=\"\u002Ftag\u002Fapi\">API\u003C\u002Fa> server、scheduler、controllers。你只要把這四個角色分開看，很多故障會突然變得很白話。\u003C\u002Fp>\u003Cp>\u003Cstrong>etcd\u003C\u002Fstrong> 是真相來源。它存 cluster state。Wikipedia 有提到它在分割時偏向 consistency 而不是 availability，這個取捨我反而很喜歡。因為如果狀態庫開始亂講話，後面全部都會變成戲劇。很多團隊平常把 etcd 當背景音，等 cluster 開始怪怪的才突然想起來它的重要性。\u003C\u002Fp>\u003Cp>\u003Cstrong>API server\u003C\u002Fstrong> 是前門。所有請求都走 API，透過 JSON over HTTP 驗證、寫入，最後進 etcd。你用 \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Ftools\u002F\">kubectl\u003C\u002Fa>、client library，甚至很多 operator，都是在跟它說話。這也是 Kubernetes 之所以像一個可編程系統的原因：沒有旁門左道，全部都經過同一個 API。\u003C\u002Fp>\u003Cp>\u003Cstrong>Scheduler\u003C\u002Fstrong> 是配對的人。它決定未排程的 pod 要放哪裡，依據的是資源、限制、約束，而不是什麼神秘的「最佳機器」。這很重要，因為很多 Pending 的 pod 其實不是壞掉，只是你給的條件太刁，根本沒有 node 同時滿足。\u003C\u002Fp>\u003Cp>\u003Cstrong>Controllers\u003C\u002Fstrong> 是修正引擎。ReplicaSet 會把你要的副本數維持住，少了就補，多了就收。這不是額外加裝的功能，這就是整套系統的心臟。\u003C\u002Fp>\u003Cp>實操寫法很簡單：debug 時先分類，不要亂猜。是狀態沒存到、請求沒進來、排程失敗，還是 reconcile 沒發生？我現在都用一個很土但很有效的檢查法：物件存在但 pod 不存在，先看 scheduling；pod 存在但活不久，先看 controller 跟 app；連物件都不穩，先看 API 或定義本身。\u003C\u002Fp>\u003Cul>\u003Cli>etcd 存狀態。\u003C\u002Fli>\u003Cli>API server 收請求、驗證、寫入。\u003C\u002Fli>\u003Cli>Scheduler 負責放置。\u003C\u002Fli>\u003Cli>Controllers 負責修正漂移。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Pod 才是你真正交付的單位，不是 container\u003C\u002Fh2>\u003Cp>Kubernetes 很愛講 pod，因為它逼你別再用單一 container 的腦袋看世界。Pod 才是排程的基本單位。也就是說，scheduler 排的是 pod，controllers 管的是 pod，Service 通常也是對著 pod 這群人。你如果還在想「一個 container 就是一個 app」，很容易卡在網路、生命週期、sidecar 這些地方。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779197096022-olgh.png\" alt=\"Kubernetes 把叢集變成宣告狀態\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己踩過的坑是，把 sidecar 跟 app container 當成 Docker Compose 那種獨立服務在想。表面上好像可以，直到我想讓它們一起死、一起起來，才發現 Kubernetes 根本不是那個模型。它把關係講得很明白：同一個 pod，共享生命週期。這很煩，但也很乾淨。\u003C\u002Fp>\u003Cp>Wikipedia 也提到 namespaces、labels、selectors。這些不是裝飾品。Namespace 是範圍；labels 跟 selectors 是讓 controller 和 service 找到正確 pod 的方式，不是靠硬編碼名稱。這件事小看不得，因為一旦 workload 變多，你就會感謝自己沒有把名字寫死。\u003C\u002Fp>\u003Cp>白話一點說，Kubernetes 偏好的是「描述式身分」，不是「名字式身分」。pod 可以消失再生出來，但 label selector 才是系統持續黏著同一個工作負載的方式。這也是為什麼 Deployment 換掉 pod，Service 幾乎不會在意。它原本就不該在意單一 pod，它在意的是那一群。\u003C\u002Fp>\u003Cp>實操上，我現在的 label 會分三類：app identity、environment、ownership。像是 \u003Ccode>app=payments\u003C\u002Fcode>、\u003Ccode>env=prod\u003C\u002Fcode>、\u003Ccode>team=platform\u003C\u002Fcode>。然後 selector 只吃這些 label，不吃名字。這樣 rollout、查問題、切流量都會少很多蠢事。\u003C\u002Fp>\u003Cul>\u003Cli>用 pod 表示共享生命週期。\u003C\u002Fli>\u003Cli>用 labels 做分群。\u003C\u002Fli>\u003Cli>用 selectors 做穩定指向。\u003C\u002Fli>\u003Cli>用 namespaces 做範圍與清理邊界。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Deployment 之所以好用，是因為它很無聊而且很堅持\u003C\u002Fh2>\u003Cp>Wikipedia 把 ReplicaSet、ReplicationController、Deployment 都列出來，這一段我建議你直接抓核心：Deployment 是描述 rollout 的方式，ReplicaSet 是維持副本數的機械手臂。重點不是「生出一個 pod」，而是「在變動中維持這個工作負載」。\u003C\u002Fp>\u003Cp>我看過不少團隊手改 production 裡的 pod，然後一臉驚訝地問為什麼改動不見了。拜託，pod 本來就不是拿來長住的。你要的是持久變更，就該改 controller 或 Deployment spec。Kubernetes 只認這個版本，其他臨時補丁它根本不當一回事。\u003C\u002Fp>\u003Cp>這背後其實是一個很不討喜但很實用的觀念：每個 instance 都應該是可拋棄的。這對從傳統 VM、SSH、手動修機器走來的人很不友善，因為以前你修的是「那台機器」，現在你修的是「一份宣告」。但 Kubernetes 就是吃這套，它要的是 repeatability，不是英雄主義。\u003C\u002Fp>\u003Cp>實操寫法我會很早就定好 rollout 策略：更新怎麼做、失敗怎麼回、要不要 scale down。不要等服務長大才補，因為到那時候你只會得到一堆 YAML 跟一堆「先手動 patch 一下」的爛習慣。我也幹過，最後只會更貴。\u003C\u002Fp>\u003Cp>我現在的規則很簡單：如果這東西要撐 restart、要撐 scale change、要撐 node 掛掉，就丟進 controller。反過來，如果只是一次性任務，就別硬裝成長期服務。Kubernetes 有不同物件不是裝飾，是因為它真的分工不同。\u003C\u002Fp>\u003Ch2>Service、Volume、Config 才是 app 真的開始像 app 的地方\u003C\u002Fh2>\u003Cp>Wikipedia 會把 Services、Volumes、ConfigMaps、Secrets 一起講，因為這裡才開始碰到真實世界。光有 pod 不夠。真的\u003Ca href=\"\u002Fnews\u002Fvibe-coding-turns-app-ideas-into-crowded-markets-zh\">上線\u003C\u002Fa>的 app 還需要穩定入口、持久儲存、以及不用每次改設定就重建 image 的能力。\u003C\u002Fp>\u003Cp>\u003Cstrong>Service\u003C\u002Fstrong> 提供穩定的網路身份，解掉「pod 重啟 IP 就變」這種老問題。你應該把 client 指向 service，而不是 pod。這個概念很抽象，直到你某天因為硬編碼 pod IP 而掉一下午，才會真的記住。\u003C\u002Fp>\u003Cp>\u003Cstrong>Volume\u003C\u002Fstrong> 處理應該活得比 pod 久的資料。像 database、需要持久化的 cache，或任何不能在重啟時消失的狀態，都得靠它。你如果忽略這件事，最後通常會得到資料遺失跟很尷尬的 retrospective。\u003C\u002Fp>\u003Cp>\u003Cstrong>ConfigMap\u003C\u002Fstrong> 跟 \u003Cstrong>Secret\u003C\u002Fstrong> 則是把設定跟 image 分開。這件事看起來普通，但它直接救你脫離「每個環境都重 build 一次」的地獄。非敏感設定放 ConfigMap，敏感值放 Secret，然後再掛進去。\u003C\u002Fp>\u003Cp>實操寫法是：不要把環境值烤死在 image 裡。我看過太多人這樣做，因為初期很快，後面卻會把環境差異、憑證、端點全揉成一團。比較健康的做法是 image 保持笨，runtime 保持聰明。image 放\u003Ca href=\"\u002Fnews\u002Fibm-vibe-coding-guide-turns-prompts-into-code-zh\">程式\u003C\u002Fa>，cluster 放環境。\u003C\u002Fp>\u003Cp>如果你要查官方說法，我會直接看 \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fhome\u002F\">Kubernetes 官方文件\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fservices-networking\u002Fservice\u002F\">Service 概念頁\u003C\u002Fa>、以及 \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fconfiguration\u002Fsecret\u002F\">Secrets 頁面\u003C\u002Fa>。不是叫你背，是別亂猜。\u003C\u002Fp>\u003Ch2>API 才是產品核心，其他東西都只是它的附屬品\u003C\u002Fh2>\u003Cp>Wikipedia 提到 Kubernetes 可擴充，而且內部元件與外部擴充都依賴 Kubernetes API。這句其實很直白：API 才是中心。你一旦接受這件事，整個生態系就合理了。像 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkubectl\">kubectl\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Fkubernetes-api\u002F\">API objects\u003C\u002Fa>、custom resources、controllers、operators，全部都是圍著這個 API contract 在轉。\u003C\u002Fp>\u003Cp>我以前以為 operator 是平台團隊才會玩的高階技巧。後來才發現，它本質上就是包了一層 domain 的 controller。只要你能把自己的領域定義成 desired state，就能教 Kubernetes 幫你 reconcile。這很方便，但也很殘酷，因為你寫錯了，它也會很誠實地幫你做錯。\u003C\u002Fp>\u003Cp>換句話說，這套平台真正厲害的地方不是 container，而是你可以在同一個 control plane 上，建立自己的 automation language。這也是為什麼很多 Kubernetes 周邊工具看起來都很像，因為它們都在講同一種 API 句法。\u003C\u002Fp>\u003Cp>實操上，如果你在做內部平台工具，我會優先考慮 custom resource 加 controller，而不是寫一堆 shell script 去 loop kubectl。Script 可以做一次性管理，拿來當控制策略就太脆了。如果行為需要持續，就做 controller；如果行為需要宣告，就做 resource。\u003C\u002Fp>\u003Cp>我也會順手看 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fcluster-api\">Cluster API\u003C\u002Fa>。如果你管的是 cluster 本身，那它就是把同一套宣告式思維往上一層延伸。這種東西一開始看起來很繞，但一旦通了，你會發現它跟 workload 的邏輯其實是一樣的。\u003C\u002Fp>\u003Ch2>你選哪種 Kubernetes，會直接改變你怎麼活\u003C\u002Fh2>\u003Cp>Wikipedia 有提到 open-source distribution、commercial distribution、managed distribution。這不是註腳，這是現實。\u003Ca href=\"https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\">GKE\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Feks\u002F\">EKS\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fazure.microsoft.com\u002Fen-us\u002Fproducts\u002Fkubernetes-service\">AKS\u003C\u002Fa> 都是同一套核心概念外面包不同的操作責任。這差很多。\u003C\u002Fp>\u003Cp>我看過團隊以為「Kubernetes」就是一個固定東西，結果從自架 cluster 換到 managed service 之後，才發現升級、網路、權限、節點管理的假設全都要重來。這很正常。核心物件沒變，但你要付出的營運成本會換地方。\u003C\u002Fp>\u003Cp>實操寫法是：先決定你到底想不想養 cluster。如果團隊不想天天顧 control plane 升級，就用 managed。你如果真的需要高度客製，而且有人力承擔，那再自己管多一點。不要假裝這兩者差不多，完全不是。\u003C\u002Fp>\u003Cp>我還會在叢集出事前就定好支援政策。Wikipedia 提到 Kubernetes 1.19 之後支援窗口從 N-2 變 N-3，這種政策看起來很無聊，但它其實就是升級節奏。你不先排，最後就是它來排你。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Kubernetes operating template\n\n## 1) 我在宣告什麼\n- App name:\n- Namespace:\n- Environment:\n- Owner\u002Fteam:\n\n## 2) Desired state\n- Replicas:\n- Container image:\n- Resource requests:\n- Resource limits:\n- Health checks:\n- Rollout strategy:\n\n## 3) Stable identity\n- Labels:\n  - app:\n  - env:\n  - team:\n- Service name:\n- Selector:\n\n## 4) Configuration\n- ConfigMaps:\n  - non-sensitive env values\n  - feature flags\n  - endpoints\n- Secrets:\n  - passwords\n  - tokens\n  - certificates\n\n## 5) Storage\n- Volume needed? yes\u002Fno\n- PersistentVolumeClaim name:\n- Mount path:\n- Retention policy:\n\n## 6) Scheduling rules\n- Node affinity:\n- Tolerations:\n- Anti-affinity:\n- Priority class:\n\n## 7) Failure behavior\n- What should restart automatically?\n- What should scale horizontally?\n- What should be recreated if a node dies?\n- What should never be auto-replaced?\n\n## 8) Controller choice\n- Deployment for long-running stateless app\n- StatefulSet for stable identity and storage\n- DaemonSet for one pod per node\n- Job for run-to-completion work\n\n## 9) Day-2 checks\n- kubectl get pods -n \u003Cnamespace>\n- kubectl describe pod \u003Cpod>\n- kubectl get events -n \u003Cnamespace>\n- kubectl get svc -n \u003Cnamespace>\n- kubectl get deploy -n \u003Cnamespace>\n\n## 10) Copy-ready starter manifest\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: example-app\n  namespace: example\n  labels:\n    app: example-app\n    env: prod\n    team: platform\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: example-app\n  template:\n    metadata:\n      labels:\n        app: example-app\n        env: prod\n        team: platform\n    spec:\n      containers:\n        - name: app\n          image: ghcr.io\u002Fyour-org\u002Fexample-app:1.0.0\n          ports:\n            - containerPort: 8080\n          envFrom:\n            - configMapRef:\n                name: example-app-config\n            - secretRef:\n                name: example-app-secrets\n          resources:\n            requests:\n              cpu: \"100m\"\n              memory: \"128Mi\"\n            limits:\n              cpu: \"500m\"\n              memory: \"256Mi\"\n          readinessProbe:\n            httpGet:\n              path: \u002Fhealthz\n              port: 8080\n            initialDelaySeconds: 5\n            periodSeconds: 10\n          livenessProbe:\n            httpGet:\n              path: \u002Flivez\n              port: 8080\n            initialDelaySeconds: 15\n            periodSeconds: 20\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: example-app\n  namespace: example\nspec:\n  selector:\n    app: example-app\n  ports:\n    - port: 80\n      targetPort: 8080\n  type: ClusterIP\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板我刻意寫得很無聊，因為叢集狀態本來就該無聊。它給你的東西很基本：宣告 identity、穩定 selector、明確 config、真的 resource limits、健康檢查，還有一個不靠 pod 名稱的 Service。這些夠你在真實團隊裡起步了。\u003C\u002Fp>\u003Cp>如果我今天要把它丟進新 repo，我會先改三件事：換 image、換 namespace、把 resource requests 收到符合 app 的真實需求。然後只有在真的需要持久化時才補 storage。我寧願先上一個乾淨的 Deployment，也不要假裝自己有 state，結果硬做一個假的 StatefulSet。\u003C\u002Fp>\u003Cp>原始觀點主要來自 \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKubernetes\">Kubernetes Wikipedia 頁面\u003C\u002Fa>，我加上的是自己的實務理解，外加幾個常用官方文件與生態系連結。模板是我根據這些概念重新整理的原創版本，能直接拿去改。\u003C\u002Fp>","我拆 Kubernetes 的控制迴圈、核心物件和可直接複製的叢集模板，讓你少走一堆 YAML 冤枉路。","en.wikipedia.org","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FKubernetes",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1779197095928-obv6.png","tools","zh","ea288b1e-ddae-44ff-be40-c1056ab5a9d9",[17,18,19,20,21],"Kubernetes","control loop","desired state","controller","Deployment",[23,24,25],"Kubernetes 的核心不是部署，而是持續把現實拉回宣告狀態。","控制平面、Pod、Service、Config、Storage 各司其職，別把它們混成一坨。","最實用的起手式是先定義 desired state，再選 controller，最後才補模板。",1,"2026-05-19T13:24:24.468851+00:00","2026-05-19T13:24:24.411+00:00","c3c88dd2-a940-438a-b359-0e5a24562273",{"tags":31,"relatedLang":41,"relatedPosts":45},[32,33,35,37,39],{"name":20,"slug":20},{"name":17,"slug":34},"kubernetes",{"name":21,"slug":36},"deployment",{"name":18,"slug":38},"control-loop",{"name":19,"slug":40},"desired-state",{"id":15,"slug":42,"title":43,"language":44},"kubernetes-turns-clusters-into-declared-state-en","Kubernetes turns clusters into declared state","en",[46,52,58,64,70,76],{"id":47,"slug":48,"title":49,"cover_image":50,"image_url":50,"created_at":51,"category":13},"d3ec03a8-a805-4a21-9826-72a74a72b625","databricks-model-serving-llm-deploy-guide-zh","Databricks Model Serving 讓 LLM 部署變簡單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525998117-7ur8.png","2026-06-03T22:32:51.005996+00:00",{"id":53,"slug":54,"title":55,"cover_image":56,"image_url":56,"created_at":57,"category":13},"4dd225a8-bf6c-4768-a486-a27956c7033d","opencode-digitalocean-model-freedom-zh","OpenCode+DigitalOcean 讓你切換模型","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780525116428-1q7g.png","2026-06-03T22:18:06.969758+00:00",{"id":59,"slug":60,"title":61,"cover_image":62,"image_url":62,"created_at":63,"category":13},"4bdcf208-fb80-484e-b4b6-06af035a6df1","modulate-aws-voice-chats-into-signals-zh","Modulate 用 AWS 把語音聊天做成訊號","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780519733892-rxue.png","2026-06-03T20:48:22.697917+00:00",{"id":65,"slug":66,"title":67,"cover_image":68,"image_url":68,"created_at":69,"category":13},"f44a28d3-2305-43de-b5fa-21217d561054","amazon-rekognition-content-moderation-filter-zh","Amazon Rekognition把審核變成過濾器","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780517005409-bxfc.png","2026-06-03T20:02:57.634353+00:00",{"id":71,"slug":72,"title":73,"cover_image":74,"image_url":74,"created_at":75,"category":13},"80f6f40b-3217-45e4-acff-7b2f6d261779","codex-workspace-limits-tell-you-why-zh","Codex 讓工作區限額錯誤說人話","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780514293711-ltqa.png","2026-06-03T19:17:41.340056+00:00",{"id":77,"slug":78,"title":79,"cover_image":80,"image_url":80,"created_at":81,"category":13},"daa3d568-4bc5-4f29-aa64-225928ace9b4","book-2-turns-sneaker-drop-into-merch-zh","Book 2 把球鞋發售變成周邊系統","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780513400116-8jeh.png","2026-06-03T19:02:49.03795+00:00",[83,88,93,98,103,108,113,118,123,128],{"id":84,"slug":85,"title":86,"created_at":87},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":129,"slug":130,"title":131,"created_at":132},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]