如果你非要在 Kubernetes 集群中用 nscd

2022-04-04 22:37:32

前言

我写了一篇文档《Kubernetes 集群中的 DNS 最佳实践》，其中提到你可以使用 nscd 作为容器内的 DNS 缓存。对，只写了这简单一句话，但没有提到其具体的实现方案。原因是 nscd 方案可能是我最不推荐的方案，本文将阐述你应该优先考虑的方案、为什么不推荐 nscd、以及如何合理地在 Kubernetes 集群中使用 nscd。

更好的方案

连接池

在 Kubernetes 集群中 DNS 域名解析经常会出问题，原因各种各样，有因为内核问题的，有因为负载问题的，而你一定是遇到了这些烦人的域名解析问题才打开了这篇文章。在很多时候，我们不一定有精力找到问题根因，但我们可以尽可能地避免使用 DNS 域名解析。怎么做？连接池！引入连接池的方式无需赘述，除了可以节省掉 DNS 域名解析开销之外，可以直接避免每个 TCP 链接握手挥手的额外开销。

无论是微服务之间互访还是直连数据库都可以使用连接池管理长连接，几乎所有 Web、RPC 框架都可以支持连接池。关于 PHP 如何支持连接池，可以参考官方文档。

节点 DNS 缓存

Kubernetes 集群中容器一般是高密度部署的，单个集群节点上会运行多个业务 Pod，我们可以在每个集群节点上运行节点级 DNS 缓存组件，代理本地所有容器的 DNS 解析并做缓存。我们在 ACK 产品上提供了 NodeLocal DNSCache 缓存组件和对应 Webhook 控制器。这个缓存组件也是一个 DNS 服务器，监听于节点上的一个接口，通过一个本地 IP 地址暴露 DNS 服务。Webhook 控制器则在 Pod 调度之前，将这个本地 DNS 服务器 IP 地址写入到 Pod 配置中，这样 Pod 启动后就默认使用了缓存组件当 DNS 服务器了。

该缓存组件以下几个优点：

每个节点只运行一个缓存组件，降低资源损耗
缓存组件就是一个 DNS 服务器，对业务透明，没有兼容性问题

业务 Pod 连接至缓存组件不消耗 Conntrack 表项，比起直接请求 CoreDNS 绕过了大量 iptables 规则
缓存组件连接至 CoreDNS 使用 TCP 协议，提升可用性

NodeLocal DNSCache 原理图

为什么不推荐 nscd 方案

兼容性

nscd 是一个 Daemon 程序，也提供 DNS 缓存能力，但事实上它并不算是一个 DNS 服务器，它甚至不是以 TCP/IP 方式工作的。nscd 默认会监听在 /var/run/nscd/socket 下，当你的应用通过 glibc 库调用例如 getaddrinfo 这样的方法时，这个方法会去检查该 socket 是否存在，如果存在，glibc 会让 nscd 会代理发送 DNS 请求并缓存结果。

关键问题是，并不是所有应用都在用 glibc 做域名解析，例如 Golang 默认就用了自己的 DNS Resolver，根本不会去理会 nscd 的 socket。再例如，在常见的 Alpine 镜像中，系统用了 musl 替代 glibc，musl 原生根本不支持 nscd 做域名解析。

另外值得一提的是，网络上有一些挂载 /var/run/nscd/socket 目录进容器内提供容器内 DNS 缓存的方案。这种方案一旦 ECS 和容器的 glibc 版本出现差异，将会导致缓存功能失效甚至解析异常。

准确性

如果你依赖于多条 A 记录做 Round-Robin 类型的负载均衡，nscd 仅会缓存第一条 A 记录，并做返回。因此在缓存失效的周期内，负载仅会转发到其中一条 A 记录上。如果使用 NodeLocal DNSCache，缓存结果在返回时也会进行 random 打散，不存在这个问题。

时效性

DNS 变更的生效时间通常应小于其 TTL，nscd 缓存机制中的默认参数允许其在 TTL + CACHE_PRUNE_INTERVAL（15 秒）以后才刷新。

使用合理的姿势

阅读到了这里，看起来你是执意要使用 nscd 方案了。在网络上流传着两种方案：

方案一：宿主机启动 nscd

思想：宿主机 ECS 上启动 nscd，Pod 里挂载宿主机路径 /var/run/nscd/socket

缺点：需严格保证 glibc 版本在宿主机和容器之间一致，否则会遇到兼容性问题

方案二：容器内启动 nscd

思想：修改容器镜像，在单个容器启动业务进程前，先启动 nscd 作为后台进程

缺点：

需重新打镜像
违背容器的单一职责原则，业务进程不再是容器主进程，较难处理优雅退出逻辑

推荐方案：SideCar 启动 nscd

思想：修改容器部署 YAML，运行业务容器时，同时启动一个独立 nscd 容器，通过挂载同目录的形式共享 nscd socket 给业务容器。

优点：

业务侵入少，可以不用重新制作容器镜像
业务容器和 Cache 容器使用同样的容器镜像，避免 glibc 版本不一致

我以 Wordpress 应用举个例子，你可以在 artifacthub.io 下载到这个 Helm Chart。应用中有一个 Deployment 如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ack-wordpress-sample-default
  namespace: default
spec:
  replicas: 1
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/plugins/wordpress:5.4.2-debian-10-r36
        name: wordpress
        volumeMounts:
        - mountPath: /bitnami/wordpress
          name: wordpress-data
          subPath: wordpress
      volumes:
      - emptyDir: {}
        name: wordpress-data

以上我省略了所有无关的属性，YAML 中 wordpress 名字的容器即代表你的业务容器。我们在同一个 Pod 中注入以下 nscd 容器，注意：

nscd 容器建议采用同样的业务镜像
创建一个公共的 emptyDir 类型的目录，同时挂载到业务容器和 nscd 容器
务必给 nscd 做好资源限制，避免影响主容器
nscd 可以提前在容器镜像中安装好，也可以启动后安装，以下例子是启动后安装，nscd 容器的 YAML 如下：

      - image: registry.cn-hangzhou.aliyuncs.com/plugins/wordpress:5.4.2-debian-10-r36
        command:
        - /bin/bash
        - -c
        - apt update; apt install -y nscd; nscd -F
        name: nscd
        resources:
          requests:
            cpu: 300m
            memory: 512Mi
        volumeMounts:
        - mountPath: /var/run/nscd
          name: nscd

与业务容器，整合在一起后，YAML 如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ack-wordpress-sample-default
  namespace: default
spec:
  replicas: 1
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/plugins/wordpress:5.4.2-debian-10-r36
        name: wordpress
        volumeMounts:
        - mountPath: /bitnami/wordpress
          name: wordpress-data
          subPath: wordpress
        - mountPath: /var/run/nscd
          name: nscd
      - image: registry.cn-hangzhou.aliyuncs.com/plugins/wordpress:5.4.2-debian-10-r36
        command:
        - /bin/bash
        - -c
        - apt update; apt install -y nscd; nscd -F
        name: nscd
        resources:
          requests:
            cpu: 300m
            memory: 512Mi
        volumeMounts:
        - mountPath: /var/run/nscd
          name: nscd
      volumes:
      - emptyDir: {}
        name: wordpress-data
      - emptyDir: {}
        name: nscd

nscd 容器和业务主容器会一同启动，待 nscd 容器中 nscd 完成初始化后，会自动创建 nscd socket 至公告的 emptyDir 目录中，在下一次业务域名解析请求时，nscd 就可以被成功用起来了。