将 Kubernetes 扩展到 2,500 个节点

# 将 Kubernetes 扩展到 2,500 个节点 来源：https://openai.com/index/scaling-kubernetes-to-2500-nodes/ 我们的 Dota(https://blog.openai.com/more-on-dota-2/) 项目最初运行在 Kubernetes 上。随着规模扩大，我们发现新的 Kubernetes 节点上的 Pod 经常处于 Pending(https://kubernetes.io/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#my-pod-stays-pending) 状态很长时间。游戏镜像约为 17GB，在新集群节点上拉取通常需要 30 分钟，所以我们理解为什么 Dota 容器会长时间处于 Pending 状态——但这对其他容器也同样成立。经过深入调查，我们发现 kubelet(https://kubernetes.io/docs/admin/kubelet) 有一个 `--serialize-image-pulls` 标志，默认设置为 `true`，这意味着 Dota 镜像拉取会阻塞所有其他镜像。将其改为 `false` 需要将 Docker 从 AUFS 切换到 overlay2。为了进一步加快拉取速度，我们还将 Docker 根目录移到了实例附加的 SSD，就像我们对 etcd 机器所做的那样。 即使优化了拉取速度，我们仍然看到 Pod 启动失败，出现神秘的错误信息：`rpc error: code = 2 desc = net/http: request canceled`。kubelet 和 Docker 日志也显示镜像拉取因进度缺失而被取消的消息。我们追踪到根本原因是大镜像拉取/提取耗时过长，或者我们有大量待拉取镜像的积压。为了解决这个问题，我们将 kubelet 的 `--image-pull-progress-deadline` 标志设置为 30 分钟，并将 Docker 守护进程的 `max-concurrent-downloads` 选项设置为 10。（第二个选项并没有加快大镜像的提取，但允许待拉取镜像队列并行处理。） 我们最后一个 Docker 拉取问题来自 Google Container Registry。默认情况下，kubelet 从 `gcr.io` 拉取一个特殊镜像（由 `--pod-infra-container-image` 标志控制），该镜像在启动任何新容器时使用。如果该拉取因任何原因失败，比如超出配额(https://github.com/kubernetes/kubernetes/issues/50568)，该节点将无法启动任何容器。因为我们的节点通过 NAT 访问 `gcr.io` 而不是有自己的公网 IP，我们很可能会触及这个按 IP 的配额限制。为了解决这个问题，我们通过使用 `docker image save -o /opt/preloaded_docker_images.tar` 和 `docker image load -i /opt/preloaded_docker_images.tar`，简单地在 Kubernetes 工作节点的机器镜像中预加载了该 Docker 镜像。为了提高性能，我们对一个包含 Dota 镜像等常见 OpenAI 内部镜像的白名单也做了同样的处理。