电子书网站建设,做直发网站,德州做网站公司电话,湘潭建设网站的公司K8s Service网络详解#xff08;二#xff09; Kube Proxy调度模式Kube-proxy IptablesKube-proxy IPVS Service SelectorPod DNS种常见的 DNS 服务Kube-DNSCoreDNSCorefile 配置 DNS 记录DNS 记录 ServiceDNS 记录 PodDNS 配置策略 Pod 的主机名设置优先级 Ingress Kube Pro… K8s Service网络详解二 Kube Proxy调度模式Kube-proxy IptablesKube-proxy IPVS Service SelectorPod DNS种常见的 DNS 服务Kube-DNSCoreDNSCorefile 配置 DNS 记录DNS 记录 ServiceDNS 记录 PodDNS 配置策略 Pod 的主机名设置优先级 Ingress Kube Proxy
Kubernetes 在设计之初就充分考虑了针对容器的服务发现与负载均衡机制。 Service 资源可以通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。
Service相关的事情都由Node节点上的 kube-proxy处理。在Service创建时Kubernetes会分配IP给Service同时通过API Server通知所有kube-proxy有新Service创建了kube-proxy收到通知后通过 Iptables/IPVS 记录 Service和IP/端口 对应的关系从而让Service在节点上可以被查询到。
kube-proxy还会监控Service和 Endpoint的变化从而保证Pod重建后仍然能通过Service访问到Pod。
kube-proxy存在于各个node节点上
kube-proxy老版本默认使用的是 iptables模式通过各个node节点上的iptables规则来实现service的负载均衡但是随着service数量的增大iptables模式由于线性查找匹配、全量更新等特点其性能会显著下降
从k8s的1.8版本开始kube-proxy引入了IPVS模式IPVS模式与iptables同样基于Netfilter但是采用的hash表因此当service数量达到一定规模时hash查表的速度优势就会显现出来从而提高service的服务性能。
目前kubernetes 中的负载均衡大致可以分为以下几种机制每种机制都有其特定的应用场景 Service直接用 Service 提供 cluster 内部的负载均衡并借助 cloud provider 提供的 LB 提供外部访问 Ingress Controller还是用 Service 提供 cluster 内部的负载均衡但是通过自定义 Ingress Controller 提供外部访问 Service Load Balancer把 load balancer 直接跑在容器中实现 Bare Metal 的 Service Load Balancer Custom Load Balancer自定义负载均衡并替代 kube-proxy一般在物理部署 Kubernetes 时使用方便接入公司已有的外部服务 Service 与 Endpoints和 Pod的关系 调度模式
基于Linux下的kube-proxy支持的3种调度模式 用户空间Userspace k8s 1.1版本前 iptables k8s 1.10版本以前 IPVS k8s 1.11版本之后如果没有开启ipvs则自动降级为iptables
Windows 上的 kube-proxy 只有一种模式可用
kernelspace
kube-proxy 在 Windows 内核中配置数据包转发规则的一种模式
ipvs和iptables都是基于netfilter的两者差别如下 ipvs 为大型集群提供了更好的可扩展性和性能 ipvs 支持比 iptables 更复杂的负载均衡算法最小负载、最少连接、加权等等 ipvs 支持服务器健康检查和连接重试等功能 Kube-proxy Iptables
kube-proxy监听Kubernetes API Server一旦Service 和 EndpointSlice 对象有变化service创建删除和修改, pod的扩张与缩小就将需要新增的规则添加到 iptables中。
kube-proxy只是作为controller而不是server真正服务的是内核的netfilter体现在用户态则是iptables。
kube-proxy的 iptables方式支持的负载分发策略 RoundRobin默认模式 SessionAffinity
kubernetes只操作了filter和nat表
Filter表中一个基本原则是只过滤数据包而不修改他们。
filter table的优势是小而快可以hook到inputoutput和forward。这意味着针对任何给定的数据包只有可能有一个地方可以过滤它。
NAT表主要作用是在 PREROUTING 和 POSTROUNTING的钩子中修改目标地址和 源地址。
与filter表稍有不同的是该表中只有新连接的第一个包会被修改修改的结果会自动apply到同一连接的后续包中。
kube-proxy 对 iptables 的链 进行了扩充自定义了 KUBE-SERVICESKUBE-NODEPORTSKUBE-POSTROUTINGKUBE-MARK-MASQ和KUBE-MARK-DROP 五个链并主要通过为KUBE-SERVICES chain 增加 规则rule 来配制traffic routing 规则。
查看nat表的OUTPUT链存在kube-proxy创建的KUBE-SERVICE链
iptables -nvL OUTPUT -t nat
iptables -nvL KUBE-SERVICES -t nat |grep service-demo接着是查看这条链以1/3的概率跳转到其中一条
iptables -nvL KUBE-SVC-EJUV4ZBKPDWOZNF4 -t nat最后KUBE-SEP-BTFJGISFGMEBGVUF链终于找到了DNAT规则
iptables -nvL KUBE-SEP-BTFJGISFGMEBGVUF -t natKube-proxy IPVS
IPVS 模式在工作时当我们创建了前面的 Service 之后kube-proxy 首先会在宿主机上创建一个虚拟网卡kube-ipvs0并为它分配 Service VIP 作为 IP 地址。
接着kube-proxy通过Linux的IPVS模块为这个 IP 地址添加三个 IPVS 虚拟主机并设置这三个虚拟主机之间使用轮询模式 来作为负载均衡策略。
kube-proxy监听API Server中service和endpoint的变化情况调用netlink 接口创建相应的ipvs 规则并定期将ipvs规则与 Services和 Endpoints同步。
IPVS代理模式基于netfilter hook函数该函数类似于iptables模式但使用hash表作为底层数据结构在内核空间中工作。这意味着IPVS模式下的kube-proxy使用更低的重定向流量。其同步规则的效率和网络吞吐量也更高。
IPVS 模式支持更多的负载均衡策略
轮询Round RobinRR依次将请求分配到后端服务器循环往复。加权轮询Weighted Round RobinWRR根据服务器的权重分配请求权重越高的服务器被分配到的请求越多。最少连接Least ConnectionsLC将请求分配到当前连接数最少的服务器。源地址哈希Source HashingSH根据请求来源的 IP 地址进行散列将相同 IP 地址的请求分配到同一台后端服务器上。永不排队never queue
Service Selector
Service 通过标签来选取服务后端一般配合 Replication Controller 或者 Deployment 来保证后端容器的正常运行。这些匹配标签的 Pod IP 和端口列表组成 endpoints由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
在Kubernetes中Selector是用于标识一组资源的标签选择器。这些资源可以是Pod、Service或者其他Kubernetes对象通过在资源上定义标签可以将它们组织成为相互关联的逻辑单元。Selector是访问这些逻辑单元的关键方式。 Selector的语法形式类似于CSS选择器在Kubernetes中我们可以通过使用逗号运算符和括号运算符对多个Selector进行组合以实现更加复杂的选择方式。
如何使用Selector
在Kubernetes中Selector常被用于指定需要操作的对象例如在创建Service时需要通过Selector指定它所要代理的Pod。
以下是一个Service的例子它通过Selector选择标签键为app值为nginx的Pod
apiVersion: v1
kind: Service
metadata:
name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 在以上的配置文件中selector字段用于指定Service所要代理的Pod。在这个例子中Service将会代理所有标签键为app值为nginx的Pod并将它们对外暴露在端口80上。
Pod DNS
种常见的 DNS 服务
kube-dns 也是Cluster DNSCoreDNS
在 Kubernetes 1.11 及其以后版本中推荐使用 CoreDNS
Kube-DNS
GitHub项目地址https://github.com/kubernetes/dns kube-dns 的 pod 中包含了 3 个容器
kube-dnsdns-dnsmasqdns-sidecar
各个容器功能
kube-dns容器功能 提供service name域名的解析(用于k8s集群内部的域名解析)监视k8s Service资源并更新DNS记录替换etcd使用TreeCache数据结构保存DNS记录并实现SkyDNS的Backend接口接入SkyDNS对dnsmasq提供DNS查询服务 dnsmasq容器功能 对集群提供DNS查询服务设置kubedns为upstream提供DNS缓存降低kubedns负载提高性能 dns-sidecar容器功能 定期检查kubedns和dnsmasq的健康状态 为k8s活性检测提供HTTP API CoreDNS
项目官网https://coredns.io/
CoreDNS使用Go语言编写。What is CoreDNS?
CoreDNS实现非常灵活几乎所有功能都是以插件的方式实现插件可以是独立使用也可以协同完成 “DNS 功能”。
有一些插件与Kubernetes通信以提供服务发现这些插件可以从文件或数据库中读取数据。
Miek Gieben 在 2016 年编写了 CoreDNS 的初始版本在此之前他还写过一个叫作 SkyDNS 的 DNS 服务器以及一个用 Go 语言写的 DNS 函数库 Go DNS。
可以通过维护 Corefile即 CoreDNS 配置文件 来配置 CoreDNS 服务器。与 BIND 的配置文件的语法相比CoreDNS 的 Corefile 使用起来非常简单。作为一个集群管理员你可以修改 CoreDNS Corefile 的 ConfigMap 以更改 DNS 服务发现针对该集群的工作方式。
CoreDNS的限制
目前 CoreDNS 仍然有一些特别的限制使得它并不适合所有的 DNS 服务器场景。其中最主要的是CoreDNS 不支持完整的递归recursion功能即CoreDNS 不能从根 DNS 命名空间开始处理查询。查询根 DNS 服务器并跟踪引用直到从某个权威 DNS 服务器返回最终结果需要依赖其他 DNS 服务器通常称为转发器forwarder来实现。
Corefile 配置
在 Kubernetes 中CoreDNS 安装时使用如下默认 Corefile 配置
apiVersion: v1
kind: ConfigMap
metadata:name: corednsnamespace: kube-system
data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . /etc/resolv.confcache 30loopreloadloadbalance} Corefile 配置包括以下 CoreDNS 插件 errors错误记录到标准输出。 health在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。 在这个扩展语法中lameduck 会使此进程不健康等待 5 秒后进程被关闭。 ready在端口 8181 上提供的一个 HTTP 端点 当所有能够表达自身就绪的插件都已就绪时在此端点返回 200 OK。 kubernetesCoreDNS 将基于服务和 Pod 的 IP 来应答 DNS 查询。 你可以在 CoreDNS 网站找到有关此插件的更多细节。 你可以使用 ttl 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟 最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。 pods insecure 选项是为了与 kube-dns 向后兼容。 你可以使用 pods verified 选项该选项使得仅在相同名字空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。 如果你不使用 Pod 记录则可以使用 pods disabled 选项。 prometheusCoreDNS 的度量指标值以 Prometheus 格式也称为 OpenMetrics在 http://localhost:9153/metrics 上提供。 forward: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf)。 cache启用前端缓存。 loop检测简单的转发环如果发现死循环则中止 CoreDNS 进程。 reload允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后请等待两分钟以使更改生效。 loadbalance这是一个轮转式 DNS 负载均衡器 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。 DNS 记录
DNS 记录 Service
A/AAAA 记录
普通Service 和 没有集群 IP 的Headless Service 都会被赋予一个形如 my-svc.my-namespace.svc.cluster-domain.example 的 DNS A 和/或 AAAA 记录
与普通 Service 不同无头ServiceHeadless Service的DNS记录会被解析成对应 Service 所选择的 Pod IP 的集合。 客户端要能够使用这组 IP或者使用标准的轮转策略从这组 IP 中进行选择。
SRV 记录
Kubernetes 根据 Service普通 Service 或无头 Service 均可 中的命名端口创建 SRV 记录。每个命名端口 SRV 记录格式为 _port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example。
普通 Service该记录会被解析成端口号和域名my-svc.my-namespace.svc.cluster-domain.example。
无头 Service该记录会被解析成多个结果及该服务的每个后端 Pod 各一个 SRV 记录 其中包含 Pod 端口号和格式为 hostname.my-svc.my-namespace.svc.cluster-domain.example 的域名。
DNS 记录 Pod
A/AAAA 记录
一般而言Pod 会对应如下 DNS 名字解析
pod-ip-address.my-namespace.pod.cluster-domain.example例如对于一个位于 default 名字空间IP 地址为 172.17.0.3 的 Pod 如果集群的域名为 cluster.local则 Pod 会对应 DNS 名称
172-17-0-3.default.pod.cluster.local通过 Service 暴露出来的所有 Pod 都会有如下 DNS 解析名称可用
pod-ip-address.service-name.my-namespace.svc.cluster-domain.exampleDNS 配置策略
参阅Pod 的 DNS 策略
每个Pod所使用的DNS策略是通过pod.spec.dnsPolicy字段设置的共有4种DNS策略
ClusterFirst默认策略表示使用集群内部的CoreDNS来做域名解析Pod内/etc/resolv.conf文件中配置的nameserver是集群的DNS服务器即kube-dns的地址。Default“Default” 不是默认的 DNS 策略。Pod直接继承集群node节点的域名解析配置也就是Pod会直接使用宿主机上的/etc/resolv.conf文件内容。None忽略k8s集群环境中的DNS设置Pod会使用其dnsConfig字段所提供的DNS配置dnsConfig字段的内容要在创建Pod时手动设置好。ClusterFirstWithHostNet宿主机与 Kubernetes 共存,这种情况下的POD既能用宿主机的DNS服务又能使用kube-dns的Dns服务,需要将hostNetwork打开。
ClusterFirst
apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: ClusterFirst # 字段设置为ClusterFirst(该值为默认值不设置也是该值)
# namserver指向kube-dns service地址
$ kubectl exec mypod -- cat /etc/resolv.conf
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5Default
apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: Default
# pod内的resolv.conf与宿主机的resolv.conf一致
$ kubectl exec mypod -- cat /etc/resolv.conf
nameserver 192.168.234.2
search localdomain$ cat /etc/resolv.conf
search localdomain
nameserver 192.168.234.2None
apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1dnsPolicy: NonednsConfig:nameservers: [192.168.234.1,192.168.234.2] # 最多可指定3个IP当Pod的dnsPolicy设置为None时列表必须至少包含一个IP地址searches: # Pod中主机名查找的DNS搜索域列表- default.svc.cluster.local- svc.cluster.local- cluster.localoptions:- name: ndotsvalue: 5kubectl exec mypod -- cat /etc/resolv.conf
nameserver 192.168.234.1
nameserver 192.168.234.2
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5ClusterFirstWithHostNet
apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1hostNetwork: true # hostNetwork为true时表示与宿主机共享网络空间dnsPolicy: ClusterFirst # 即使dnsPolicy设置为集群优先由于hostNetwork: true也会强制将dnsPolicy设置为Default# 所以Pod内resolv.conf与宿主机相同
$ kubectl exec mypod -- cat /etc/resolv.conf
nameserver 192.168.234.2
search localdomain对于以 hostNetwork 方式运行的 Pod应将其 DNS 策略显式设置为 “ClusterFirstWithHostNet”。否则以 hostNetwork 方式和 ClusterFirst 策略运行的 Pod 将会做出回退至 Default 策略的行为。
apiVersion: v1
kind: Pod
metadata:name: mypodlabels:app: mypod
spec:containers:- name: mynginximage: mynginx:v1hostNetwork: truednsPolicy: ClusterFirstWithHostNet#只有dnsPolicy: ClusterFirstWithHostNet此时pod既可以使用宿主机网络也可以使用kube-dns网络
$ kubectl exec -it mypod -- cat /etc/resolv.conf
nameserver 241.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5Pod 的主机名设置优先级
Pod 规约中包含一个可选的 hostname 字段可以用来指定一个不同的主机名。当这个字段被设置时它将优先于 Pod 的名字成为该 Pod 的主机名同样是从 Pod 内部观察。
例如给定一个 spec.hostname 设置为 “my-host” 的 Pod 该 Pod 的主机名将被设置为 “my-host”。
Pod的子域名
Pod 规约还有一个可选的 subdomain 字段可以用来表明该 Pod 是名字空间的子组的一部分。
例如某 Pod 的 spec.hostname 设置为 “foo”spec.subdomain 设置为 “bar” 在名字空间 “my-namespace” 中主机名称被设置成 “foo” 并且对应的完全限定域名FQDN为 “foo.bar.my-namespace.svc.cluster-domain.example”还是从 Pod 内部观察。
Ingress
Service是基于四层TCP和UDP协议转发的而Ingress可以基于七层的HTTP和HTTPS协议转发可以通过域名和路径做到更细粒度的划分如下图所示。 https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/
Ingress 是对集群中服务的外部访问进行管理的 API 对象
Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 Ingress工作机制
要想使用Ingress功能必须在Kubernetes集群上安装Ingress Controller。Ingress Controller有很多种实现最常见的就是Kubernetes官方维护的NGINX Ingress Controller
对于所有 Kubernetes API一旦它们被正式发布GA就有一个创建、维护和最终弃用它们的过程。Ingress-NGINX 将拥有独立的分支和发布版本来支持这个模型与 Kubernetes 项目流程相一致。 Ingress-NGINX 项目的未来版本将跟踪和支持最新版本的 Kubernetes。
团队目前正在升级 Ingress-NGINX 以支持向 v1 的迁移 你可以在此处跟踪进度。
同时团队会确保没有兼容性问题 更新到最新的 Ingress-NGINX 版本 目前是 controller-v1.8.1。 Kubernetes 1.22 发布后请确保使用的是支持 Ingress 和 IngressClass 稳定 API 的最新版本的 Ingress-NGINX。 使用集群版本 1.19 测试 Ingress-NGINX 版本 v1.0.0-alpha.2并将任何问题报告给项目 GitHub 页面。
外部请求首先到达Ingress ControllerIngress Controller根据Ingress的路由规则查找到对应的Service进而通过Endpoint查询到Pod的IP地址然后将请求转发给Pod。
参阅
k8s中的endpoint
k8s 理解Service工作原理
K8s 核心组件讲解——kube-proxy
详解k8s 4种类型Service
kubernetes集群内部DNS解析原理、域名解析超时问题记录
CoreDNS简介
Kubernetes网络
Service
