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到input，output和forward。这意味着针对任何给定的数据包，只有可能有一个地方可以过滤它。

NAT表：主要作用是在 PREROUTING 和 POSTROUNTING的钩子中，修改目标地址和 源地址。

与filter表稍有不同的是，该表中只有新连接的第一个包会被修改，修改的结果会自动apply到同一连接的后续包中。

kube-proxy 对 iptables 的链进行了扩充：自定义了 KUBE-SERVICES，KUBE-NODEPORTS，KUBE-POSTROUTING，KUBE-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 nat

Kube-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 Robin，RR）：依次将请求分配到后端服务器，循环往复。
加权轮询（Weighted Round Robin，WRR）：根据服务器的权重分配请求，权重越高的服务器被分配到的请求越多。
最少连接（Least Connections，LC）：将请求分配到当前连接数最少的服务器。
源地址哈希（Source Hashing，SH）：根据请求来源的 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 DNS）
CoreDNS

在 Kubernetes 1.11 及其以后版本中，推荐使用 CoreDNS

Kube-DNS

GitHub项目地址：https://github.com/kubernetes/dns

kube-dns 的 pod 中包含了 3 个容器

kube-dns
dns-dnsmasq
dns-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: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Corefile 配置包括以下 CoreDNS 插件：

errors：错误记录到标准输出。

health：在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。在这个扩展语法中，lameduck 会使此进程不健康，等待 5 秒后进程被关闭。

ready：在端口 8181 上提供的一个 HTTP 端点，当所有能够表达自身就绪的插件都已就绪时，在此端点返回 200 OK。

kubernetes：CoreDNS 将基于服务和 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 选项。

prometheus：CoreDNS 的度量指标值以 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 不同，无头Service（Headless 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.example

DNS 配置策略

参阅：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: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: 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:5

Default

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: 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.2

None

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   dnsPolicy: None
   dnsConfig:
     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.local
     options:
       - name: ndots
         value: "5"

kubectl 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:5

ClusterFirstWithHostNet

apiVersion: v1
kind: Pod
metadata:
   name: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   hostNetwork: 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: mypod
   labels:
      app: mypod
spec:
   containers:
     - name: mynginx
       image: mynginx:v1
   hostNetwork: true
   dnsPolicy: 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:5

Pod 的主机名设置优先级

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 Controller，Ingress Controller根据Ingress的路由规则，查找到对应的Service，进而通过Endpoint查询到Pod的IP地址，然后将请求转发给Pod。

参阅：

k8s中的endpoint

k8s 理解Service工作原理

K8s 核心组件讲解——kube-proxy

详解k8s 4种类型Service

kubernetes集群内部DNS解析原理、域名解析超时问题记录

CoreDNS简介

Kubernetes网络

Service