Kubernetes（k8s）浅谈 Service 和 DNS

简单了解 k8s Service

为什么需要Service

• 云原生，指的就是快速扩缩容，适应动态变化等，这样的机制就会使得pod的IP不是固定的，每次重启，都会变动

• 由于pod对应的IP容易变动，因为pod的重启，其IP就会和原来不同，如果相关联服务，采用pod IP，那每次pod 重启就需要修改使用此服务的IP

• 因此 k8s Service 提供了一个稳定访问的机制，提供稳定的IP

Service 的机制

• Service的命名机制{service name}.{service namespace}.svc.{domin}
  • domin部分可由kubelet配置，参数为--cluster-dns=<dns service ip\>，此可配置集群域名后缀，默认为cluster.local
• Service 提供的 IP 成为 cluster IP，是个虚拟 IP，直接访问是无法访问的，必须要结合 端口port
• Service 是一组逻辑上关联的 pod
  • 利用 selector，将label为 app:MyApp 的 pod 聚合在一起，形成个组，我们可以称为 Endpoints，这也是一种k8s资源
  • EndPoints 在 Service 有 selector时会自动创建，在没有selecotr时则不会创建
  • 所以现在的关系是 Service（Cluster IP）–> Endpoints --> 一组Pod（Pod ip）
  • 就是Service是个空头司令，Endpoints 相当于个小班长，Pod才是干活的，这样的管理机制，这是管理层（备注：Service 和 Endpoints 是同名的，这样才知道我们都是三连或几连的）
  • 如何从Service下发指令到Pod呢？kube-proxy出来啦，其相当于一个通讯兵，通过iptables或ipvs规则，架设通讯线路，这样就完成了命令的下发
  • 此种Service的DNS 映射关系为{service name}.{service namespace}.svc.{domin} --> Cluster IP
• 特殊的Service（Headless Service）
  • 这种Service没有selector，就是没有聚合器
  • 此种 Service 不会产生 Cluster IP，但是还是具有自己的名字my-service，可通过dns进行域名访问，但目前无工作pod
  • 不过目前就是光杆司令，连个小弟都没有
  • 但是若创建同名的Endpoints，则会自动关联上，就相当于找到了失散的兄弟
  • Endpoints会带有selector，也就是有一组关联的Pod，也就是更好消息，好兄弟还领着一帮人一起
  • 此种Service的DNS 映射关系为{service name}.{service namespace}.svc.{domin} --> 后端Pod IP 列表

# 普通service
# 下面就是说访问 Service 就会 访问到对应容器的 9376端口
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80 # service 端口
      targetPort: 9376 # 容器端口

-----

# 无头service（headless service）
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---     
apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

简单了解Service类型

类型
普通服务	Cluster IP	四层负载均衡，就是 ip+port 到某个具体pod
Load Balancer	外部负载均衡	通过loadBalancerSourceRanges 限制 哪些范围IP可访问此服务
NodePort	开启一个端口，供外部访问	但要保证所在主机的IP的外部可以访问的
无头Service	没有NodeSecltor
Ingress	七层负载均衡，就是url+端点到不同服务	这个不属于Service，k8s有Ingress资源 七层负载均衡举例： host：www.example.com path: /foo --> service1 path:/bar --> service2

为什么需要 DNS

因为最早采用环境变量注入pod方式，有很多不便之处

环境变量注入（服务发现）

最早时候，为了让Pod可以访问集群内的服务，kubelet会预先将系统当前所有服务的IP和端口信息，以环境变量的形式注入到容器中。这样Pod中的应用可通过读取环境变量，从而获得所需服务的地址信息。

简单举例，Kubelet为每个Pod注入如下环境变量信息

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
...
...
目前所有已启动的Service的信息

缺点

1. 容易环境变量泛滥，Docker启动参数过长，影响性能，甚至直接导致容器启动失败
2. Pod想要访问的任何Service，必须要在Pod被创建前创建，否则这些环境变量就不会被注入

什么是DNS

白话来说，就是集群内启动个DNS服务器，当Pod想访问某个Service却不知道时，直接问该DNS服务器，服务器则会返回给他相应的IP地址

• DNS存储的就是 域名和IP的映射

• Pod去访问时，用的是域名，之后得到相应的IP，因为IP才可以用于网络传输

Pod 如何知道 DNS服务器地址

kubelet会将DNS Server 的 IP地址写到容器的/etc/resolv.conf文件中

具体来说

1. 集群内 DNS 服务启动后，会获得 Cluster IP (就是Service 的IP，但只能在集群内使用)
2. 系统（安装程序）会给kubelet配置 --cluster-dns=<dns service ip>
3. 该 DNS IP 则会在容器启动时传递，写入到每个容器的 /etc/resolv.conf文件中

DNS域名解析原理

对于 Service，K8s DNS服务器会生成三类 DNS 记录，分别是 A 记录、 SRV 记录、 CNAME 记录

A记录

• 用于将域或子域指向某个IP地址，是DNS记录的最基本类型
• 记录包含域名，解析它的IP地址和以秒为单位的TTL，TTL代表生存时间，是此记录的到期时间
• 普通Service的A记录的映射关系
  • {service name}.{service namespace}.svc.{domin} --> Cluster IP
• headless Service 的 A 记录映射关系：
  • {service name}.{service namespace}.svc.{domin} --> 后端Pod IP 列表
• 如果 Pod Spec 指定 hostname 和 subdomin，那么会额外生成 Pod 的 A 记录
  • {hostname}.{subdomain}.{pod namespace}.pod.cluster.local --> Pod IP

SRV 记录

• 通过描述某些服务协议和地址促进服务发现
• 定义一个符号名称和作为域名一部分的传输协议，并定义给定服务的优先级、权重、端口和目标

_sip._tcp.example.com.   3600 IN   SRV 10   70   5060 srvrecord.example.com
_sip._tcp.example.com.   3600 IN   SRV 10   20   5060 srvrecord2.ex

_sip 是服务的符号名称
_tcp 是服务使用的传输协议
两个记录都定义了10的优先级
第一个指定权重70，第二个指定权重20
最后两值定义了要连接的端口和主机名，以便与服务通信

• k8s DNS 的 SRV 记录按照一个约定出城的规定实现了对服务端口的查询
  • _{port name}._{port protocol}.{service name}.{service namespace}.svc.cluster.local --> Service Port
• SRV 记录是为 普通 或 headless 服务的部分指定端口创建的
• 普通服务
  • 被解析的端口号和域名是 my-svc.my-namespace.svc.cluster.local
• Headless 服务
  • 此 name 解析为多个 answer，每个 answer 都支持服务
  • 每个 answer 都包含 auto-generated-name.my-svc.my-namespace.svc.cluster.local 表单的 Pod 端口号和域名

CNAME 记录

• 别名
• 用于将域或子域指向另一个主机名
• 可用于联合服务的跨集群服务发现

K8s 域名解析策略

None

• 没有
• k8s 1.9 版本引入一个新选项值，允许 Pod 忽略 K8s 环境中的 DNS 设置

ClusterFirstWithHostNet

• 对于使用主机网络的 Pod，是可以直接访问宿主机的 /etc/resolv.conf 文件的
• 因此默认会使用宿主机的 DNS 配置，因此会导致集群内的容器无法通过域名访问集群内的服务
• 所以对于使用 hostNetwork 的 Pod，用户应该明确设置其 DNS 策略为 ClusterFirstWithHostNet

ClusterFirst

• 任何与配置的集群域后缀不匹配的 DNS 查询，将转发到从宿主机上集成的上游域名服务器
• 所以集群管理员应根据需要配置上游 DNS 服务器

Default

• Pod 从宿主机上集成名称解析配置