最近一位大牛玩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并不是一件坏事 - 但没有理由尝试自己运行它