本週熱點：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
- 上週熱點回顧（3.4-3.10）
- 上週熱點回顧（4.15-4.21）
- 上週熱點回顧（5.6-5.12）
- 上週熱點回顧（3.11-3.17）
- 上週熱點回顧（2.26-3.3）
- 上週熱點回顧（4.1-4.7）
- 上週熱點回顧（11.20-11.26）
- 上週熱點回顧（11.6-11.12）
- 上週熱點回顧（9.25-10.1）
- 上週熱點回顧（11.13-11.19）
- 上週熱點回顧（12.4-12.10）
- 上週熱點回顧（10.23-10.29）
- 上週熱點回顧（5.8-5.14）
- 上週熱點回顧（5.1-5.7）
- 上週熱點回顧（3.25-3.31）
- 上週熱點回顧（4.22-4.28）
- 上週熱點回顧（3.18-3.24）
- 上週熱點回顧（5.13-5.19）
- 上週熱點回顧（5.20-5.26）
- 上週熱點回顧（4.8-4.14）
- 上週熱點回顧（12.11-12.17）
- 上週熱點回顧（11.27-12.3）
- 上週熱點回顧（12.18-12.24）
- 上週熱點回顧（10.30-11.5）
- 上週熱點回顧（4.24-4.30）
- 上週熱點回顧（7.29-8.4）
- 上週熱點回顧（6.8-6.14）
- 上週熱點回顧（5.18-5.24）
- 上週熱點回顧（6.22-6.28）
- 上週熱點回顧（5.25-5.31）
- 上週熱點回顧（6.1-6.7）
- 上週熱點回顧（8.10-8.16）
- 上週熱點回顧（8.31-9.6）
- 上週熱點回顧（8.17-8.23）
- 上週熱點回顧（8.3-8.9）