觀點 · 資訊分享
Amazon MSK 能就地從 ZooKeeper 換成 KRaft：不用搬資料、不改客戶端，叢集全程可用
AWS 在 8 月 10 日宣布 Amazon MSK 支援從 ZooKeeper 到 KRaft 的就地遷移，不必準備新基礎設施、搬資料或重設客戶端。Kafka 3.9.x 是最後支援 ZooKeeper 的版本。
- 發布
- 2026-08-10
- 篇幅
- 約 3 分鐘 · 1,453 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：AWS 的託管 Kafka（Amazon MSK）現在能就地把叢集從 ZooKeeper 換成 KRaft，不用另開新叢集、不用搬資料、客戶端程式也不用改，而且過程中叢集持續可用。
先用白話講：ZooKeeper 和 KRaft 是什麼？
Kafka 是很多公司用來傳遞大量訊息的「物流中心」。物流中心要運作，得有個地方記錄「哪個倉庫在哪、誰負責哪條路線」這些管理資料，也就是 metadata（後設資料）。
過去這本「管理帳本」是交給一個外面的獨立系統 ZooKeeper 保管，等於物流中心旁邊另請了一個會計事務所。KRaft 則是 Kafka 自己內建的做法：把帳本改成由 Kafka 內部一組「控制器」自己記、自己同步，不再需要外面的事務所。
發生什麼事
AWS 在 8 月 10 日宣布，Amazon MSK 支援從 ZooKeeper 到 KRaft 的就地遷移（in-place migration）。依公告，這個做法的好處是：
- 不需要準備新的基礎設施
- 不需要搬移資料
- 不需要重新設定客戶端應用程式
- 遷移過程中，叢集維持可用
為什麼要搬？
依官方說明，KRaft 讓管理資料的傳播更快、擴充性更好、叢集架構更單純。更現實的原因是版本：
| Kafka 版本 | ZooKeeper 支援 |
|---|---|
| 3.9.x | 最後一個支援 ZooKeeper 的版本 |
| 4.x | 只支援 KRaft |
也就是說，想升到 Kafka 4.x，就一定得先離開 ZooKeeper。這次的就地遷移，就是替既有叢集鋪好這條路。
給開發者的技術細節
- 流程：如果叢集版本低於 3.9.x，要先升級到 3.9.x；接著啟動遷移。步驟可以用 MSK 主控台、AWS CLI 或 API 完成
- 範圍：適用於提供 Amazon MSK provisioned（預先配置叢集）的所有 AWS 區域，歐洲主權雲（德國）除外
- 官方公告沒有說明遷移需要多久、是否有額外費用，也沒有說能不能退回 ZooKeeper；這幾點請看 MSK 開發者指南，並先用測試叢集演練
- 公告提到「叢集持續可用」，但實務上建議挑流量低的時段，並先確認你的客戶端與 Kafka 版本相容
我的看法
Kafka 這類基礎設施最讓人頭痛的就是「不敢動」：它穩定跑著，沒人想去碰，等到版本被淘汰才發現沒路可走。ZooKeeper 退場已經是確定的方向，早一點遷移，比等到被迫升級時再手忙腳亂好。
不過我會很保守地處理這種變更。我的步驟是：先確認目前的 Kafka 版本與監控，建立一個測試叢集完整演練一次，確認客戶端沒有異常，再挑一個低流量時段處理正式叢集。公告說「不需要重新設定客戶端」，但自己的應用程式有沒有特殊設定，只有實測才知道。
名詞小辭典
- Kafka：高吞吐的訊息串流平台，常用來在系統之間傳遞大量事件。
- ZooKeeper：Kafka 舊架構中用來保管叢集管理資料的外部協調系統。
- KRaft：Kafka 內建的共識機制，用內部控制器取代 ZooKeeper。
- 就地遷移（In-place migration）：在原本的叢集上直接改，不必另建新叢集再搬資料。