使用Kubernetes三年，我们从中学到了什么？( 二 ) 全文共3963字

4.存活和就绪探针（双刃剑）
Kubernetes的存活和就绪探针是能自动解决系统问题的出色功能点。可以在发生故障时重新启动容器，并将流量从异常事故中转移。但在某些故障情况下，探针可能是双刃剑，并影响应用程序的启动和恢复，尤其是有状态应用程序，例如消息平台或数据库。
Kafka系统就是受害者。我们运行了一个有replicationFactor of 3 和minInSyncReplica of 2的 3 Broker 3 Zookeeper状态集，当系统意外故障或崩溃导致Kafka启动时会发生此问题。这导致它在启动期间运行其他脚本来修复损坏的索引，根据严重程度不同，该过程可能需要10到30分钟。
由于时间耗费增加，存活探针将不断失败，从而向Kafka发出终止信号以重新启动，这一并阻止了Kafka系统修改索引和完全启动。
唯一的解决方案是在存活探针设置中设置 initialDelaySeconds ，从而在容器启动后延迟探针评估。但是问题在于当然很难给出具体时间，有些恢复甚至需要一个小时，因此我们需要留足空间来计算时间。但是initialDelaySeconds增加的时间越多，速度就越慢，因为启动失败时Kubernetes需要更长的时间来重新启动容器。
最新的几个版本中， Kubernetes引入了第三种探针“启动探针”来解决这个问题。在alpha from 1.16 和 beta from 1.18 中都可用。启动探针可以使存活和就绪探针在容器启动前停止运行，保证应用程序的启动不受干扰。
5.公开外部IP
文章插图
图源：unsplash
我们了解到，使用静态外部IP公开服务会极大损害内核的连接跟踪机制。除非详细计划，否则它只会大规模崩溃。
集群在Calico for CNI和BGP运行，作为Kubernetes内部路由协议，并与边缘路由器搭配。而Kubeproxy ，我们使用IP Tables模式。我们在Kubernetes有着庞大的服务，该服务通过外部IP公开，每天处理数百万个连接。
所有的源网络地址转换（NAT）和伪装来自软件定义网络， Kubernetes需要一个机制来跟踪所有逻辑流。为此，它使用内核的Conntrack and netfilter工具来管理与静态IP的外部连接，接着将其转换为内部服务IP ，再转为pod IP 。这些都通过conntrack表和IP表完成。
但这个conntrack表有限制。当达到极限时， Kubernetes集群(下有OS内核)将不能接受新连接。在RHEL上，可以通过这种方式进行检查：
$sysctlnet.netfilter.nf_conntrack_countnet.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012net.netfilter.nf_conntrack_max = 262144解决该问题的方法是匹配带有边缘路由器的多个节点，使你的静态IP的传入连接遍及整个群集。因此，如果集群中有大量虚拟机，累积起来就可以拥有一个大的conntrack表来处理大量的传入连接。
在2017年刚开始使用的时候，这个问题完全难住了我们。但2019年Calico发布了一份相关的详尽研究，题目就是《为什么conntrack不再友好》。
我们是否一定需要Kubernetes？
文章插图
图源：debian
三年来，我们仍在每天继续探索和学习新东西。这个复杂的平台中存在着一系列挑战，尤其是构建和维护环境的开销很大。这会改变你设计、思考、构建的方式，并且会需要团队不断提升扩充来契合转变。
然而，如果你在云端并且使用Kubernetes作为“服务” ，那么大部分平台维护的开销都可以下降，例如“如何扩展内部网络CIDR？”或“如何升级我的Kubernetes版本？”
应该问的第一个问题是：“是否一定需要Kubernetes？”这可以帮助你评估问题，判断用Kubernetes来解决它们是否必要。 Kubernetes的升级转换等并不便宜。你的用例一定要真正配得上这笔支出并且值得使用这个平台。如果值得，那么Kubernetes可以极大地提高生产力。
记住，为了使用科技而使用是没有意义的。
文章插图
留言点赞关注
我们一起分享AI学习与发展的干货
【使用Kubernetes三年，我们从中学到了什么？】如转载，请后台留言，遵守转载规范