分布式存储环境 Kubernetes节点扩容规模至2500的历程(3)

我们最后一个Docker问题是由于Google Container Registry造成的。 默认情况下，kubelet从gcr.io获取特殊的镜像（由--pod-infra-container-image标志控制）gcr.io经常用于创建一个新的容器。 如果因为任何原因（例如超过配额）而导致失败，该节点将无法启动任何容器。 由于我们的节点通过NAT到达gcr.io而不是拥有自己的公有IP，所以我们很可能会达到这个每IP配额的限制。 为了解决这个问题，我们通过使用docker image save -o /opt/preloaded_docker_images.tar和docker image load -i /opt/preloaded_docker_images.tar，简单地在我们的Kubernetes worker的机器镜像中预先加载了Docker镜像。 为了提高性能，我们对于像Dota镜像这样的常见OpenAI内部图像的白名单也是这样做的。

Networking

随着我们的实验规模越来越大，它们也变得越来越复杂，这些系统在很大程度上依赖于网络的运作。当我们第一次开始运行分布式实验时，很明显我们的网络并没有被很好地配置。分布式存储环境在机器之间，我们得到了10-15Gbit/s的吞吐量，但是我们使用Flannel的Kube Pod在~2Gbit/s上是最大的。机器区域的公共基准测试[4]显示了类似的数字，这意味着这个问题不太可能是糟糕的配置，而是我们的环境所固有的一些东西。(相比之下，Flannel并没有在我们的物理机器上增加这个开销。）

为了解决这个问题，用户可以添加两个不同的设置来禁用他们的Pod：hostNetwork: true和dnsPolicy: ClusterFirstWithHostNet。(在此之前，请阅读Kubernetes文档中的警告[5]。）

ARP Cache

尽管我们进行了DNS调优，但我们仍然看到DNS解析的间歇性问题。有一天，一位工程师报告说，nc -v到他们的Redis服务器上花了30秒的时间才打印出连接。我们跟踪这个问题到内核的ARP堆栈。对Redis pod主机的初步调查显示，该网络出现了严重的问题：任何端口上的通信都被挂了好几秒钟，而且没有DNS名称可以通过本地的dnsmasq守护进程来解决，而dig命令只是打印一个加密的失败消息:socket。socket.c:1915: internal_send: 127.0.0.1#53: Invalid argument.。dmesg日志信息更丰富：neior table overflow！这意味着ARP缓存已经耗尽了空间。ARP用于将网络地址（比如IPv4地址）映射到物理地址，比如MAC地址。幸运的是，通过在/etc/sysctl.conf中设置一些选项，这很容易解决。

net.ipv4.neigh.default.gc_thresh1 = 80000

net.ipv4.neigh.default.gc_thresh2 = 90000

net.ipv4.neigh.default.gc_thresh3 = 100000

在HPC集群中调优这个设置是很常见的，并且在Kubernetes集群中尤其重要，因为每个Pod都有自己的IP地址，它占用了ARP缓存中的空间。

我们的Kubernetes集群已经有3个月的历史了，我们计划在2018年扩展到更大的集群。我们最近升级到1.8.4版本，并且很高兴看到它现在正式支持5000。

https://github.com/axboe/fio

https://github.com/DataDog/dd-agent/issues/3381

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

https://kubernetes.io/docs/concepts/configuration/overview/

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-85241-3.html