本週熱點：K8s的爭吵和抱怨

banq發表於2019-06-13
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並不是一件壞事 - 但沒有理由嘗試自己執行它

相關文章