Alauda Container Platform
  • 简体中文

    • 配置 Alauda Container Platform 节点 DNS 缓存

    目录

    概述主要功能重要说明安装通过 Marketplace 安装工作原理架构配置网络策略配置已知风险和临时解决方法风险 1：主机网络端口冲突风险 2：节点级 DNS 依赖风险 3：通过节点 IP 收集指标商标声明

    概述

    NodeLocal DNSCache 是一种集群插件，通过在集群节点上运行 DNS 缓存代理来提升集群 DNS 性能。此插件通过在每个节点上本地缓存 DNS 响应，减少 DNS 查询延迟并降低中心 DNS 服务的负载，从而提升集群稳定性。

    主要功能

    • 本地 DNS 缓存：在每个节点上本地缓存 DNS 响应，以减少查询延迟
    • 性能提升：显著减少应用程序的 DNS 查找时间

    重要说明

    WARNING

    部署注意事项：

    1. Kube-OVN Underlay 模式：此插件不支持在 Kube-OVN Underlay 模式下部署。若进行部署，可能会导致 DNS 查询失败。

    2. Kubelet 重启：部署此插件会导致 Kubelet 重启。

    3. 需要重启 Pod：插件成功部署后，不会影响正在运行的 Pod，但只会对新创建的 Pod 生效。当 CNI 为 Kube-OVN 时，需要手动向 kube-ovn-controller 添加参数 "--node-local-dns-ip=(本地 DNS 缓存服务器的 IP 地址)"。

    4. NetworkPolicy 配置：如果集群中配置了 NetworkPolicy，则需要在 networkPolicy 中额外允许节点 CIDR 和 nodeLocalDNSIP 的入方向和出方向，以确保正常通信。

    5. 通过重建进行集群升级：如果通过重建节点（重新置备）来升级集群，Kubelet 配置更改将会丢失。要使 NodeLocal DNS 配置在升级过程中保持持久化，需要在集群模板的以下三个位置，将参数 --cluster-dns 添加到 kubeletExtraArgs 中：

      • KubeadmControlPlane → initConfiguration → nodeRegistration → kubeletExtraArgs
      • KubeadmControlPlane → joinConfiguration → nodeRegistration → kubeletExtraArgs
      • KubeadmConfigTemplate → template → spec → joinConfiguration → nodeRegistration → kubeletExtraArgs

      将以下参数添加到上述每个 kubeletExtraArgs 部分：

      cluster-dns: "<NodeLocal_DNS_IP>"  # e.g., 169.254.20.10
    WARNING

    4.2.x 升级说明

    将此插件从低于 4.2.0 的版本（不包括 4.2.0）升级到 4.2.x 时，由于 ResourcePatch 兼容性问题，需要执行以下步骤：

    升级前：

    • 记录 kube-ovn-controller ResourcePatch 配置中的 --node-local-dns-ip 参数值
    • 删除 deploy/kube-ovn-controller 资源对应的 ResourcePatch

    升级后：

    • 将记录的 --node-local-dns-ip 参数手动添加回 kube-ovn-controller 配置

    注意：此兼容性问题已在 4.3 及更高版本中解决，因此升级到 4.3+ 时无需手动干预。

    安装

    通过 Marketplace 安装

    1. 导航至 管理员 > Marketplace > 集群插件。

    2. 在插件列表中搜索 "Alauda Container Platform Node DNS Cache"。

    3. 单击 安装，打开安装配置页面。

    4. 配置所需参数：

      参数描述示例值
      IP节点本地 DNS 缓存服务器的 IP 地址。对于 IPv4，建议使用 169.254.0.0/16 范围内的地址，最好使用 169.254.20.10。对于 IPv6，建议使用 fd00::/8 范围内的地址，最好使用 fd00::10。169.254.20.10

    5. 查看部署说明，并确保您的环境满足要求。

    6. 单击 安装 完成安装。

    7. 等待插件状态变为 "就绪"。

    工作原理

    架构

    Pod → NodeLocal DNSCache → [Cache Hit] → Pod
           ↓
    [Cache Miss] → CoreDNS → Response → Cache & Pod

    配置

    网络策略配置

    重要：如果您的集群启用了 NetworkPolicy，则必须配置适当的规则，以允许 DNS 流量访问 NodeLocal DNSCache。如果没有这些规则，Pod 可能无法解析 DNS 查询。

    使用 NetworkPolicy 时，请确保允许以下 DNS 流量：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-cache
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - ipBlock:
            cidr: 169.254.20.10/32 # NodeLocal DNS IP address
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
  egress:
    - to:
        - ipBlock:
            cidr: 169.254.20.10/32 # NodeLocal DNS IP address
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

    已知风险和临时解决方法

    请将此功能视为尚未达到生产就绪状态的 Alpha 功能。建议在测试或预生产环境中使用。对于生产集群或类似生产环境的集群，启用 NodeLocal DNSCache 前请评估以下风险。如果这些风险对于您的工作负载不可接受，请继续直接使用 CoreDNS。

    在插件安装页面公开相关参数之前，仅在目标环境中完成验证后，才能使用以下临时解决方法。

    风险 1：主机网络端口冲突

    node-cache Pod 在主机网络命名空间中运行。其健康检查端点使用主机网络端口，可能与使用相同端口的工作负载或节点级进程发生冲突。例如，默认健康检查端点监听端口 8080。

    安装前，请确认目标节点上的工作负载不依赖相同的主机网络端口，例如端口 8080：

    ss -lntp | grep ':8080'

    编辑 NodeLocal DNSCache ConfigMap：

    kubectl -n <namespace> edit cm <configmap-name>

    将 Corefile health 端口更改为相同的未使用端口，例如：

    health 127.0.0.1:18080

    编辑 NodeLocal DNSCache DaemonSet：

    kubectl -n <namespace> edit ds <daemonset-name>

    将 node-cache 容器探针端口更改为相同端口：

    livenessProbe:
  httpGet:
    host: 127.0.0.1
    path: /health
    port: 18080

    等待 DaemonSet 滚动更新完成：

    kubectl -n <namespace> rollout status ds/<daemonset-name>

    如果当前插件版本未在安装页面公开健康检查端口参数，请使用站点级补丁，确保 Corefile health 端口与 DaemonSet 探针端口保持一致。

    WARNING

    重要：这是临时的站点补丁，不是持久化的插件配置。插件升级、重新安装或平台协调可能会重新生成 ConfigMap 和 DaemonSet，并覆盖您的自定义端口设置。如果在这些操作后仍需要使用非默认健康检查端口，请重新应用补丁，然后再将插件视为就绪。

    风险 2：节点级 DNS 依赖

    NodeLocal DNSCache 生效后，节点上的 Pod 会使用本地 node-cache Pod 进行 DNS 解析。如果该 Pod 在插件升级、驱逐或崩溃期间不可用，则同一节点上 Pod 的 DNS 解析可能失败。请为 node-cache 就绪状态配置监控和告警。

    如果 DNS 解析已经失败，且之前未配置备用 DNS 服务器，请暂时将 kubelet cluster-dns 指向 CoreDNS ClusterIP，然后重新创建受影响的 Pod。

    您可以同时使用 NodeLocal DNSCache IP 和 CoreDNS ClusterIP 配置 kubelet cluster-dns。在需要进行更改的每个节点上，编辑 kubelet 参数文件：

    vi /var/lib/kubelet/kubeadm-flags.env

    将 --cluster-dns 从单个 NodeLocal DNSCache IP 更改为同时包含 NodeLocal DNSCache IP 和 CoreDNS ClusterIP：

    --cluster-dns=169.254.20.10,10.96.0.10

    保存文件后重启 kubelet：

    systemctl restart kubelet

    此更改仅影响新创建的 Pod。请重新创建受影响的 Pod，使其 /etc/resolv.conf 重新生成，例如：

    kubectl -n <namespace> rollout restart deployment/<deployment-name>

    当 NodeLocal DNSCache 不可用时，可以使用 CoreDNS 作为备用，但这不是透明故障转移。对于 glibc resolver，在使用下一个 DNS 服务器之前，DNS 故障转移可能会在多个 search 查询期间等待超时。基于 musl 的镜像（例如 Alpine Linux）通常不会出现此延迟，因为 musl 可以并行查询名称服务器。

    如果工作负载对 DNS 解析延迟敏感，请针对该工作负载调整 resolver timeout 和 attempts。例如：

    spec:
  dnsConfig:
    options:
      - name: timeout
        value: "1"
      - name: attempts
        value: "1"
    WARNING

    重要：编辑节点上的 kubelet 文件同样属于临时的站点更改。节点重建、重新预配或任何会重新生成 kubelet 配置的工作流，都可能完全丢弃多 DNS 设置。如果在这些操作后仍需要 CoreDNS 备用配置，请重新应用 kubelet 更改，然后再次重新创建受影响的 Pod。

    风险 3：通过节点 IP 收集指标

    如果外部监控无法通过节点 IP 收集 node-cache 指标，请编辑 NodeLocal DNSCache ConfigMap：

    kubectl -n <namespace> edit cm <configmap-name>

    在 Corefile 中，从 prometheus 指令中移除 IP 绑定。请勿更改 DNS 服务端口。

    prometheus 169.254.20.10:9253
    prometheus :9253

    重启 node-cache Pod，或滚动更新 DaemonSet，使更新后的 Corefile 生效。

    WARNING

    重要：这同样是临时的站点补丁，不是持久化的插件配置。如果直接修补生成的 ConfigMap，插件升级、重新安装或平台协调可能会覆盖 prometheus 绑定，并将指标端点恢复为之前的默认值。如果仍需要通过节点 IP 收集外部指标，请在这些操作后重新应用更改。

    商标声明

    CoreDNS™ 是 The Linux Foundation 的商标。

    Kubernetes® 是 The Linux Foundation 在美国及其他国家/地区的注册商标。

    Alauda 是独立供应商。本产品与 The Linux Foundation 无关联，也未获其认可或赞助。所有商标均归其各自所有者所有，此处仅用于标识。