Kubernetes是一個工程實現，將「大量機器+容器+網絡+存儲」抽象為「作業系統」。
它沒有解決「如何運行程式」，而是：
當計劃規模失控時，系統還能由人類管理嗎？
1. Kubernetes的問題邊界
在Kubernetes之前，工程界面臨著一個非常現實的問題：
- Docker解決 「如何打包和運行應用程式」的問題
- 但它沒有起作用：
- 哪台機器正在運行？
- 如果我掛斷電話該怎麼辦？
- 如何擴張？
- 多個服務如何通信？
- 如何不中斷地更新？
當系統從：
- 1 - 10單位-100單位-1000單位
「SSH +腳本+人工doxxing」完全無效。
Kubernetes的界限很明確：
它不關心你的業務邏輯，只關心系統是否始終處於「你聲明的狀態」。
2.聲明系統：Kubernetes的工程核心
Kubernetes的設計理念本質上只有一句話：
您描述了「目標狀態」，系統負責不斷接近它。
例如：
複本：3這不是命令，而是 約束.
- 如果現在只有2個|補1個
- 如果有5個，則殺死2個
- 如果節點掛起→遷移
這與傳統的腳本操作的不同之處在於：
| 傳統方式 | Kubernetes |
|---|---|
| 人們決定每一步 | 人們只宣布結果 |
| 一次性行動 | 持續趨同 |
| 成功結束了 | 始終對齊 |
從工程角度來看，Kubernetes更多的是一個「約束求解系統」。
3.從架構角度來看：典型的大規模分布式系統
如果你認為Kubernetes是一個「工具」，它就會被使用得非常膚淺;
但如果你認為它是 分布式系統示例，價值會非常高。
核心組件非常「教科書級」：
1. API伺服器：單一真相來源
- 所有的州都寫在這裡
- etCD是底層存儲
- 所有組件 只能通過API進行通信
這是典型的 集中國家+分散執行
2.：約束下的最優解搜索
收件箱的工作不是「只是找到一台機器」，而是：
- 過濾（資源/親和力/污漬）
- 評分（負載/平衡/策略）
- 選擇最佳節點
這基本上是一個 約束優化問題.
3.控制者：不斷讓世界保持一致
控制器的邏輯非常天真：
观察状态 → 对比期望 → 执行动作 → 再观察但工程價值極高，因為它帶來：
- 自動修復
- 國家自行治癒
- 系統穩定性
👉這是許多工程師真正理解的地方 控制論 第一次
4. Kubelet：執行層代理
- 在每個節點上運行
- 將「抽象狀態」轉化為「真實容器操作」
- 它是控制平面和物理世界之間的接口
4.為什麼Kubernetes原始碼如此「沉重」？
很多人第一次看原始碼時都會感到困惑：
為什麼有這麼多代碼？這麼多抽象？
原因不是「過度設計」，而是：
- 支持 插件 需要
- 支持 雲供應商差異化
- 落後 兼容性 需要
- 需要支持 大規模進化
Kubernetes的工程權衡是：
複雜性集中在平台層，釋放了業務層。
這是一個非常成熟且非常昂貴的工程決策。
5.它不是一個框架，而是基礎設施
在工程生態系統中的位置：
- Docker：運行時
- Kubernetes：平台內核
- 舵手/操作員：生態系統層
- 雲供應商：託管和集成
Kubernetes不再是「選擇」的問題，而是「是否參與現代工程體系」的問題。
Github：https://github.com/kubernetes/kubernetes
管材：