k8s教程(service篇)-Node本地DNS缓存

简介: k8s教程(service篇)-Node本地DNS缓存

01 引言

声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记

由于在Kubernetes集群中配置的DNS服务 是一个名为 “kube-dns” 的Service, 所以容器应用都通过其ClusterIP地址(例如169.169.0.100)去执行服务名的DNS域名解析。这对于大规模集群可能引起以下两个问题:

  • 集群DNS服务压力增大(这可以通过自动扩容缓解)
  • 由于DNS服务的IP地址是ServiceClusterIP地址,所以会通过kube- proxy设置的iptables规则进行转发,可能导致域名解析性能很差,原因是Netfilter 在做DNAT转换时可能会引起conntrack冲突,从而导致DNS查询产生5s的延时

为了解决这两个问题,Kubernetes引入了Node本地DNS缓存NodeLocal DNSCache)来提高整个集群的DNS域名解析的性能,本文来讲解下。

02 Node本地DNS缓存

使用Node本地DNS缓存的好处如下

  • 在没有本地DNS缓存时,集群DNS服务的Pod很可能在其他节点上,跨主机访问会增加网络延时,使用Node本地DNS缓存可 显著减少跨主机查询的网络延时
  • 跳过iptables DNAT和连接跟踪将有助于 减少conntrack竞争,并避免UDP DNS记录填满conntrack表
  • 本地缓存到集群DNS服务的连接协议可以升级为TCP。TCP conntrack条目将在连接关闭时被删除;默认使用UDP时,conntrack条目只能等到超时时间过后才被删除,操作系统的默认超时时间(nf_conntrack_udp_timeout),为30s;
  • 将DNS查询从UDP升级为TCP,将减少由于丢弃的UDP数据包和DNS超时而引起的尾部延迟(tail latency),UDP超时时间可能会长达30s(3次重试, 每次10s);
  • 提供Node级别DNS解析请求的度量 (Metrics)和可见性 (visibility) 可以重新启用负缓存(Negative caching)功能,减少对集群DNS服务的查询数量

2.1 工作流程

Node本地DNS缓存(NodeLocal DNSCache)的工作流程如图所示,客户端Pod首先会通过本地DNS缓存进行域名解析,当缓存中不存在域名时,会将请求转发到集群DS服务进行解析

2.2 部署Node本地DNS缓存工具

配置文件nodelocaldns.yaml的内容如下,主要包括 ServiceAccount、Daemonset、ConfigMap和Service 几个资源对象。

2.2.1 资源对象配置


Service Account的定义如下:

apiVersion: v1
kind: ServiceAccount
metadata: 
  name: node-local-dns
  namespace: kube-system 
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile

Service的定义如下:

apiVersion: v1
kind: Service
metadata:
  name: kube-dns-upstream
  namespace: kube-system 
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile 
    kubernetes.io/name: "KubeDNSUpstream"
spec:
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns

ConfigMap的定义如下:

apiversion: v1
kind: ConfigMap
metadata:
  name: node-local-dns
  namespace: kube-system 
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
data:
Corefile: |
  cluster.local:53 {
    errors
    cache{
      success 9984 30 
      denial 9984 5
    }
    reload
    loop
    bind169.254.20.10
    forward.169.169.0.100{
      force tcp
    }
    prometheus 9253
    hea1th169.254.20.10:8081 
    }
  in-addr.arpa:53 {
    errors 
    cache 30 
    reload
    loop
    bind 169.254.20.10
    forward . 169.169.0.100{
      force tcp
    }
    prometheus 9253 
    }
  ip6.arpa:53 {
    errors 
    cache 30 
    reload
    loop
      bind 169.254.20.10
      forward . 169.169.0.100{
      force tcp
      }
    prometheus 9253
    }
  .:53 {
    errors 
    cache 30 
    reload
    loop
    bind 169.254.20.10
    forward . 169.169.0.100{
      force tcp
    }
    prometheus 9253 
    }

ConfigMap Corefile的主要配置参数如下:

  • bind 169.254.20.10 :node-local-dns需要绑定的本地IP地址,建议将其设置为169.254.0.0/16范围,确保不与集群内的其他IP冲突;
  • forward.169.169.0.100:在node-local-dns缓存中不存在域名记录时, 将转发到的上游DNS服务器IP设置为Kubernetes集群DNS服务(kube-dns)的IP,例如169.169.0.100;
  • health169.254.20.10:8081:健康检查端口号设置与Daemonset的livenessProbe一致,需要注意,node-local-dns网络模式设置了 hostNetwork=true,这个端口号也会被直接绑定到宿主机上,需要确保不与宿主机的其他应用冲突。

DaemonSet的定义如下:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-local-dns 
  namespace: kube-system 
  labels:
    k8s-app: node-local-dns
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile 
spec:
  updatestrategy:
    rollingUpdate:
      maxUnavai1able: 10% 
  selector:
    matchLabels:
      k8s-app: node-local-dns 
  template:
    metadata:
      labels:
        k8s-app: node-local-dns 
      annotations:
        prometheus.io/port: "9253" 
        prometheus.io/scrape: "true" 
    spec:
      priorityclassName: system-node-critical 
      serviceAccountName: node-local-dns 
      hostNetwork: true
      dnsPolicy: Default Don't use cluster DNS. 
      tolerations:
      - key: "CriticalAddonsOnly" 
        operator: "Exists"
      - effect: "NoExecute"
        operator: "Exists"
      - effect: "NoSchedule"
        operator: "Exists"
    containers:
    - name: node-cache
      image: k8s.gcr.io/k8s-dns-node-cache: 1.15.13 
      resources:
        requests:
        cpu: 25m
        memory: 5Mi
        args: ["-localip","169.254.20.10","-conf","/etc/Corefile","-upstreamsvc","kube-dns-upstream"]
      securityContext:
        privileged: true
      ports:
      - containerPort: 53
        name: dns
          protocol: UDP
        - containerPort: 53
          name: dns-tcp
          protocol: TCP
        - containerPort: 9253
          name: metrics
          protocol: TCP
        livenessProbe:
        httpGet:
          host: 169.254.20.10
          path: /health
          port: 8081
        initialDelaySeconds: 60 
        timeoutSeconds: 5
      volumeMounts:
      - mountPath: /run/xtables.lock 
        name: xtables-lock
          readonly: false
        - name: config-volume 
        mountPath: /etc/coredns 
      - name: kube-dns-config 
        mountPath: /etc/kube-dns
    volumes:
    - name: xtables-lock
      hostPath:
        path: /run/xtables.lock 
        type: FileorCreate 
    - name: kube-dns-config 
      configMap:
      name: coredns
      optional: true
    - name: config-volume
      configMap:
        name: node-local-dns
        items:
          - key: Corefile
            path: Corefile.base

Daemonset node-local-dns的主要配置参数如下:

  • args: [“-localip” , “169.254.20.10” , “-conf” , “/etc/Corefile” , “upstreamsvc” , “kube-dns-upstream”]:将-localip参数设置为node-local-dns绑定的本地IP地址,对其他参数无须修改;
  • livenessProber中的健康检查端口号与ConfigMap中的一致;

另外,如果kube-proxy代理模式(-proxy-mode)使用的是ipvs模式,则还需要修改kubelet的启动参数-cluster-dns为node-local-dns绑定的本地IP地169.254.20.10。

2.2.2 部署

通过kubectl create命令创建node-local-dns服务:

kubectl create -f nodelocaldns.yaml 
serviceaccount/node-local-dns created 
service/kube-dns-upstream created 
configmap/node-local-dns created 
daemonset.apps/node-local-dns created

确认在每个Node上都运行了一个node-local-dns Pod:

在客户端Pod内对服务名的解析没有变化,仍然可以直接通过服务名访问其他服务,例如:

03 文末

本文主要讲解Node本地DNS缓存相关的概念,希望能帮助到大家,谢谢大家的阅读,本文完!

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
1月前
|
存储 并行计算 前端开发
【C++ 函数 基础教程 第五篇】C++深度解析:函数包裹与异步计算的艺术(二)
【C++ 函数 基础教程 第五篇】C++深度解析:函数包裹与异步计算的艺术
39 1
|
1月前
|
数据安全/隐私保护 C++ 容器
【C++ 函数 基础教程 第五篇】C++深度解析:函数包裹与异步计算的艺术(一)
【C++ 函数 基础教程 第五篇】C++深度解析:函数包裹与异步计算的艺术
47 0
|
1月前
|
缓存 网络协议 Linux
【Shell 命令集合 网络通讯 】Linux 配置DNS dnsconf 命令 使用教程
【Shell 命令集合 网络通讯 】Linux 配置DNS dnsconf 命令 使用教程
39 0
|
2天前
|
C语言
循坏语句解析(C语言零基础教程)
循坏语句解析(C语言零基础教程)
|
12天前
|
人工智能 并行计算 PyTorch
Stable Diffusion 本地部署教程:详细步骤与常见问题解析
【4月更文挑战第12天】本教程详细介绍了如何在本地部署Stable Diffusion模型,包括安装Python 3.8+、CUDA 11.3+、cuDNN、PyTorch和torchvision,克隆仓库,下载预训练模型。配置运行参数后,通过运行`scripts/run_diffusion.py`生成图像。常见问题包括CUDA/CuDNN版本不匹配、显存不足、API密钥问题、模型加载失败和生成质量不佳,可按教程提供的解决办法处理。进阶操作包括使用自定义提示词和批量生成图像。完成这些步骤后,即可开始Stable Diffusion的AI艺术创作。
31 2
|
30天前
|
Kubernetes Java 测试技术
ChaosBlade常见问题之创建k8s node-cpu fullload 提示无法找到node如何解决
ChaosBlade 是一个开源的混沌工程实验工具,旨在通过模拟各种常见的硬件、软件、网络、应用等故障,帮助开发者在测试环境中验证系统的容错和自动恢复能力。以下是关于ChaosBlade的一些常见问题合集:
21 0
|
1月前
|
算法 编译器 C语言
【C++ 函数 基本教程 第六篇 】深度解析C++函数符号:GCC与VS的名称修饰揭秘
【C++ 函数 基本教程 第六篇 】深度解析C++函数符号:GCC与VS的名称修饰揭秘
42 1
|
1月前
|
算法 Serverless 数据安全/隐私保护
【C++ 函数 基本教程 第三篇 】深度解析C++函数类型:探寻全局函数、成员函数与静态函数的奥秘
【C++ 函数 基本教程 第三篇 】深度解析C++函数类型:探寻全局函数、成员函数与静态函数的奥秘
40 1
|
1天前
|
XML 人工智能 Java
Spring Bean名称生成规则(含源码解析、自定义Spring Bean名称方式)
Spring Bean名称生成规则(含源码解析、自定义Spring Bean名称方式)
|
10天前
yolo-world 源码解析(六)(2)
yolo-world 源码解析(六)
19 0

推荐镜像

更多