本周热点:K8s的争吵和抱怨

19-06-13 banq
                   

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

                   

1