kubernetes的timeout问题

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: kubernetes+alpine+php特别容易出现访问外网/解析外网地址的时候出现超时的问题.

kubernetes+alpine+php特别容易出现访问外网/解析外网地址的时候出现超时的问题.

原因

docker容器访问外网的时候,整个完整路径是这样的.

容器-->主机-->外网-->主机-->容器

容器到主机之间的流量要经过源地址转换(SNAT)才能顺利流通.

SNAT就像是一个搬运工,把砖(流量)从容器搬到主机

如果一个主机上面运行多个容器,并发访问外网(特别是PHP这种没有连接池的)时向系统申请可用端口(nf_nat_l4proto_unique_tuple),不可用时+1,然后再申请,再校验.这个过程一多,最终就会导致寻址超时.

说白了是个系统内核问题.

详细的解释见

记一次Docker/Kubernetes上无法解释的连接超时原因探寻之旅

解决方案

最优解

节点升级到 5.1的Linux内核.

iptables升级到1.6.2以上

用基于IPVS模式,尽量少做SNAT/DNAT,支持随机端口SNAT的网络插件启动kubernetes

或者用绕过SNAT的网络插件插件方案,比如阿里云的terway.但这个插件跟阿里云绑定得比较深入,需要每台机器额外购买一个弹性网卡.

次优解

用ds部署name sever,所有节点的DNS解析走节点上的name server,通过最小程度的SNAT+dns cache缓解此类问题.

伪解决方案(不能解决根本问题)

默认的pod的/etc/resolv.conf一般长这样

sh-4.2# cat /etc/resolv.conf
nameserver <kube-dns-vip>
search <namespace>.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

这个配置的意思是,默认nameserver指向kube-dns/core-dns,所有查询中,如果.的个数少于5个,则会根据search中配置的列表依次搜索,如果没有返回,则最后再直接查询域名本
身。ndots就是n个.(dots)的意思

举个例子

sh-4.2# host -v baidu.com
Trying "baidu.com.<namespace>.svc.cluster.local"
Trying "baidu.com.svc.cluster.local"
Trying "baidu.com.cluster.local"
Trying "baidu.com.localdomain"
Trying "baidu.com"
......

重开socket

        lifecycle:
          postStart:
            exec:
              command:
              - /bin/sh
              - -c 
              - "/bin/echo 'options single-request-reopen' >> /etc/resolv.conf"

设置重开socket是规避容器并发A,AAAA查询

2级域名直接走上层解析

参考kubernetes 使用基于 alpine 镜像无法正常解析外网DNS 做的

直接运行 sed -i 's/options ndots:5/#options ndots:5/g' /etc/resolv.conf 会报错

alpine的echo命令会吞换行符,而resolv.conf格式不对DNS解析会报错

  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: single-request-reopen

去掉了options ndots:5,变会默认值1,这样的话,容器内部直接访问还是没问题的,走search列表,<svc>.<namespace>.svc.cluster.local,还是能够访问。

而解析Google.com,实际上是解析Google.com.,.的数量超过1个,这时不走search列表,直接用上层DNS

综上所述,去掉ndots/ndots设为1 降低了频繁DNS查询的可能性。对于外网IP的解析有“奇效”。

但如果该主机运行其他容器(这不废话吗,一个节点不跑多个容器那还用啥kubernetes),其他容器也会并发地请求,SNAT的问题还是会出现,所以说修改/etc/resolv.conf文件并不能解决根本问题

歪门邪道1

          lifecycle:
            postStart:
              exec:
                command:
                - /bin/sh
                - -c 
                - "head -n 2 /etc/resolv.conf > /etc/temp.conf;cat /etc/temp.conf > /etc/resolv.conf;rm -rf /etc/temp.conf"

歪门邪道2

      initContainers:
      - name: alpine
        image: alpine
        command:
         - /bin/sh
         - -c 
         - "head -n 2 /etc/resolv.conf > /etc/temp.conf;cat /etc/temp.conf > /etc/resolv.conf;rm -rf /etc/temp.conf"

衍生的问题

DNAT

容器访问clusterIP(因为是虚拟IP所以需要DNAT)也有可能出现这类超时的问题

注意Virtual domain的问题

non-headservice的域名格式是<svc>.<namespace>.svc.cluster.local

如果我们容器直接访问<svc>.<namespace>.svc.cluster.local,因为默认DNS设置的问题,解析的次数反而更多。正确的方式是访问<svc>

例子:假设test下面有个s的svc

host -v s 
# 解析1次
host -v s.test.svc.cluster.local
# 解析4次

所以,访问同namespace其他svc,直接用svc名去访问即可,没必要装逼使用<svc>.<namespace>.svc.cluster.local这种格式。

其他知识

dns记录类型

  1. A记录:地址记录,用来指定域名的IPv4地址(如:8.8.8.8),如果需要将域名指向一个IP地址,就需要添加A记录。
  2. CNAME: 如果需要将域名指向另一个域名,再由另一个域名提供ip地址,就需要添加CNAME记录。
  3. TXT:在这里可以填写任何东西,长度限制255。绝大多数的TXT记录是用来做SPF记录(反垃圾邮件)。
  4. NS:域名服务器记录,如果需要把子域名交给其他DNS服务商解析,就需要添加NS记录。
  5. AAAA:用来指定主机名(或域名)对应的IPv6地址(例如:ff06:0:0:0:0:0:0:c3)记录。
  6. MX:如果需要设置邮箱,让邮箱能收到邮件,就需要添加MX记录。
  7. 显性URL:从一个地址301重定向到另一个地址的时候,就需要添加显性URL记录(注:DNSPod目前只支持301重定向)。
  8. 隐性URL:类似于显性URL,区别在于隐性URL不会改变地址栏中的域名。
  9. SRV:记录了哪台计算机提供了哪个服务。格式为:服务的名字、点、协议的类型,例如:_xmpp-server._tcp。

用到的命令

安装方法:

  yum install -y bind-utils
  sudo apt-get install -y dnsutils
  apk add bind-tools

dig

dig +trace +ndots=5 +search $host

host

host -v $host

参考链接:

  1. iptables中DNAT、SNAT和MASQUERADE的理解
  2. linux根文件系统 /etc/resolv.conf 文件详解
  3. kube-dns per node #45363
  4. DNS intermittent delays of 5s #56903
  5. /etc/resolv.conf
  6. /etc/resolv.conf search和ndots配置
  7. DNS for Services and Pods
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
存储 Kubernetes 监控
|
4月前
|
Kubernetes API 容器
[kubernetes]安装metrics-server
[kubernetes]安装metrics-server
123 0
|
负载均衡 Kubernetes 网络协议
kubernetes--kube-proxy组件深入理解
每台机器上都运行一个kube-proxy服务’它监听API server中service和endpoint的变化情 况,并通过iptables等来为服务配置负载均衡(仅支持TCP和UDP)
419 0
|
7月前
|
Kubernetes 负载均衡 算法
kubernetes—Service详解
kubernetes—Service详解
87 0
|
Kubernetes 监控 程序员
kubernetes部署metrics-server
原有的kubernetes容器监控服务heapster,从kubernetes 1.11版本开始逐渐退休,新的监控服务是metrics-server
1100 0
kubernetes部署metrics-server
|
运维 Kubernetes 负载均衡
kubernetes Cluster Overiview
kubernetes Cluster Overiview
kubernetes Cluster Overiview
|
Kubernetes 负载均衡 网络协议
Kubernetes 【网络组件】kube-proxy使用详解
Kubernetes 【网络组件】kube-proxy使用详解
Kubernetes 【网络组件】kube-proxy使用详解
|
Kubernetes 容器
Kubernetes【升级】 CKS 2021【11】---Cluster Hardening - Upgrade Kubernetes
Kubernetes【升级】 CKS 2021【11】---Cluster Hardening - Upgrade Kubernetes
Kubernetes【升级】 CKS 2021【11】---Cluster Hardening - Upgrade Kubernetes
minikube addons enable ingress 报错waiting for app.kubernetes.io/name=ingress-nginx pods: timed out
minikube addons enable ingress 报错waiting for app.kubernetes.io/name=ingress-nginx pods: timed out
|
存储 Kubernetes 前端开发
kubernetes kubelet 配置
kubernetes kubelet 配置