每週 Kubernetes 社群環聊筆記 - 2015 年 4 月 3 日

Kubernetes：每週 Kubernetes 社群交流筆記

每週，Kubernetes 貢獻者社群都會透過 Google Hangouts 進行虛擬會議。我們希望所有感興趣的人都能瞭解這個論壇討論了什麼。

議程

• Quinton - 叢集聯邦
• Satnam - 效能基準測試更新

會議紀要

1. Quinton - 叢集聯邦

• SF 聚會後的一些想法
• • 請閱讀並評論
• 不是 1.0 版本，但整理了一份文件以展示路線圖
• 可以在 Kubernetes 之外構建
• API 用於跨多個叢集控制事物，包括一些邏輯

1. 身份驗證和授權

2. 排程策略

3. ……

• 叢集聯邦的不同原因

1. 區域（不可）用性：對區域故障具有彈性

2. 混合雲：部分在雲中，部分在本地，原因各異

3. 避免雲提供商鎖定。原因各異

4. “雲爆發” - 自動溢位到雲中

• 難題

1. 位置親和性。Pod 需要多接近？

   1. 工作負載耦合

   2. 絕對位置（例如，歐盟資料必須在歐盟）

2. 跨叢集服務發現

   1. 服務/DNS 如何跨叢集工作

3. 跨叢集工作負載遷移

   1. 如何將應用程式逐個部件地跨叢集移動？

4. 跨叢集排程

   1. 如何充分了解叢集以知道在哪裡排程

   2. 可能會使用成本函式以最小的複雜性實現親和性

   3. 也可以使用成本來決定在哪裡排程（利用率低的叢集比利用率高的叢集便宜）

• 隱含要求

1. 跨叢集整合不應建立跨叢集故障模式

   1. 在 Ubernetes 死亡的災難情況下仍可獨立使用。

2. 統一可見性

   1. 希望擁有統一的監控、警報、日誌記錄、內省、使用者體驗等

3. 統一配額和身份管理

   1. 希望將使用者資料庫和身份驗證/授權放在一個地方

• 需要注意的是，大多數軟體故障的原因並非基礎設施

1. 拙劣的軟體升級

2. 拙劣的配置升級

3. 拙劣的金鑰分發

4. 過載

5. 失敗的外部依賴

• 討論

1. “ubernetes”的界限在哪裡

   1. 可能在可用區，但也可能在機架或區域

2. 重要的是不要限制其他使用者

3. Satnam - 浸泡測試

• 希望測量長時間執行的事物，以確保叢集隨著時間的推移保持穩定。效能不會下降，沒有記憶體洩漏等。
• github.com/GoogleCloudPlatform/kubernetes/test/soak/…
• 單個二進位制檔案，在每個節點上放置大量 Pod，並查詢每個 Pod 以確保其正在執行。
• Pod 的建立速度快了很多（甚至在過去一週內），以加快程序。
• 一旦 Pod 啟動並執行，我們就會透過代理訪問 Pod。訪問代理是故意為之，以便我們測試 kubernetes apiserver。
• 程式碼已經提交。
• 將 Pod 固定到每個節點，執行每個 Pod，確保每個節點都有響應。
• 單個二進位制檔案，永遠執行。
• Brian - v1beta3 預設啟用，v1beta1 和 v1beta2 已棄用，將於 6 月關閉。現有叢集升級等仍應正常工作。

• ←上一篇
• 下一篇→