本週熱點：K8s的爭吵和抱怨
最近一位大牛玩K8s，發生故障了，故障現象：
我已經將GKE升級到了1.13，並且Istio從1.0 升級到了1.1。然後策略policy和mixer進入崩潰迴圈後退，帶有響應TLS握手超時和閘道器超時錯誤。像所有分散式系統一樣，以**特定**順序重新啟動東西來修復它。下一步因為邊車sidecars，需要一個接一個地殺死叢集中的所有pod。
大家眾說紛紜：
在生產中執行beta GKE外掛並不是最好的主意，尤其是當您無法控制按下升級按鈕時會發生什麼。我不知道Istio也會更新。
Kubernetes很複雜，需要運營專業知識，就像之前的其他基礎設施平臺一樣。
建造/執行正常的K8s是令人敬畏的。每個人都想認為他們已經找到了K8。真相是很少有運營商/工程師可以稱自己為K8的專家。我沒有得到Kelsey的“Kubernetes the hard way”教程的好處，因為它們不存在。
構建基礎架構的方式：如果單個故障斷路器的風險很高，則構建兩個斷路器。如果出現都故障，則要減少爆炸半徑。這就是為什麼資料中心的每臺伺服器都連線到2個電源電路的原因。
所有事情放在一個大叢集裡是壞的，與K8s無關！
如果你沒有很強的技巧，那麼控制太複雜了。你需要先掌握k8s的強大技能。╮（╯_╰）╭或等isotio 2.0？
它是為大規模系統而構建的，我可以意識到為什麼它是如此複雜了，我也不會使用它。成本高於收入。
需要執行藍/綠群集部署。我們建立一個新的叢集，然後我們轉移流量。我們讓舊叢集執行幾個小時，而我們檢查新叢集是否都很好。
由於Kubernetes的特點，我看到使用單位由此遭遇停電。這並不是說Kube是壞的或是有缺陷的，只是需要大量的知識來有效地執行Kube並避免意外停機。現在用它很時髦，但我認為如果有成熟的運營部門則會做得更好。
不可否認，這是幾年前的事情，但我對k8s進行了評估並將其刪除，因為它帶來的複雜性超出了我的需要。我有信心我可以堅持下去，但不是我能在它失敗時除錯它。我並不自豪，但我們仍在使用ECS。
公平地說，istio本身就是一頭野獸。我不認為把k8s和istio等同起來是非常謹慎的事情，或者將它們混為一談也不是很合適！
在GKE上每個月執行20萬+一個月的Pod，18個月沒有停機。Kube並不是一件壞事 - 但沒有理由嘗試自己執行它
相關文章
- 請查收，本週刷屏的兩大熱點「GitHub 熱點速覽」Github
- 堅持原則，但是不要做無所謂的爭吵
- 熱點塊競爭與解決
- 查詢熱點快和熱點塊的操作
- 服務網格社群爭吵最近新動向！ - Christian Posta
- 熱點塊競爭和解決--cache buffers chainsAI
- 上週熱點回顧（6.3-6.9）
- 上週熱點回顧（4.1-4.7）
- 上週熱點回顧（7.1-7.7）
- 上週熱點回顧（5.27-6.2）
- 上週熱點回顧（9.2-9.8）
- 強化學習的一週「GitHub 熱點速覽」強化學習Github
- 微軟稱本週將力爭推送win10 Mobile新版本微軟Win10
- Android每週熱點第二十期Android
- Android每週熱點第十九期Android
- Android每週熱點第十八期Android
- Android每週熱點第十六期Android
- Android每週熱點第十七期Android
- 上週熱點回顧（6.17-6.23）
- 上週熱點回顧（6.24-6.30）
- 上週熱點回顧（4.22-4.28）
- 上週熱點回顧（2.26-3.3）
- 上週熱點回顧（3.4-3.10）
- 上週熱點回顧（3.11-3.17）
- 上週熱點回顧（4.15-4.21）
- 上週熱點回顧（3.18-3.24）
- 上週熱點回顧（3.25-3.31）
- 上週熱點回顧（4.8-4.14）
- 上週熱點回顧（5.6-5.12）
- 上週熱點回顧（5.13-5.19）
- 上週熱點回顧（7.15-7.21）
- 上週熱點回顧（7.22-7.28）
- 上週熱點回顧（8.5-8.11）
- 上週熱點回顧（9.9-9.15）
- 小紅圈之爭 本週智慧手機圈頭條資訊彙總
- 資料緩衝區熱鏈和熱塊爭用及解決方法
- 上週熱點回顧（6.10-6.16）
- 上週熱點回顧（9.30-10.6）