每週 Kubernetes 社群線上交流記錄 - 2015 年 4 月 3 日

Kubernetes：每週 Kubernetes 社群線上交流記錄

每週 Kubernetes 貢獻社群都會透過 Google Hangouts 進行線上會議。我們希望任何有興趣的人都能了解這個論壇中討論的內容。

議程

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

會議記錄

1. Quinton - 叢集聯邦

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

1. 身份驗證 (Auth(n)(z))

2. 排程策略

3. …

• 叢集聯邦的不同原因

1. 區域 (不) 可用性：對區域故障具有彈性

2. 混合雲：部分在雲端，部分在本地部署。基於各種原因

3. 避免雲端供應商鎖定。基於各種原因

4. 「雲爆發」- 自動溢出到雲端

• 困難的問題

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

   1. 工作負載耦合

   2. 絕對位置 (例如，歐盟資料需要位於歐盟)

2. 跨叢集服務發現

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

3. 跨叢集工作負載遷移

   1. 如何跨叢集逐步移動應用程式？

4. 跨叢集排程

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

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

   3. 也可以使用成本來決定在哪裡排程 (使用率不足的叢集比使用過度的叢集便宜)

• 隱含需求

1. 跨叢集整合不應產生跨叢集故障模式

   1. 在 Ubernetes 崩潰的災難情況下可獨立使用。

2. 統一的可見性

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

3. 統一的配額和身分管理

   1. 希望在單一位置擁有使用者資料庫和身份驗證 (auth(n)/(z))

• 重要的是要注意，大多數軟體故障的原因並非基礎架構

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 月關閉。應該仍然適用於升級現有叢集等。

• ←上一篇
下一篇→