k8s 四层代理 Service

Posted 2021-12-08 笨小孩@GF 知行合一

• 为什么要有 Service？

• 在 kubernetes 中，Pod 是有生命周期的，如果 Pod 重启它的 IP 很有可能会发生变化
• 如果服务都是将 Pod 的 IP 地址写死，Pod 挂掉或者重启，和刚才重启的 pod 相关联的其他服务将会找不到它所关联的 Pod
• 为了解决这个问题，在 kubernetes 中定义了 service 资源对象，Service 定义了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例
• service 是一组 Pod 的逻辑集合，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现。
   
• 可以看下面的图：

  

• pod ip 经常变化，service 是 pod 的代理，客户端访问，只需要访问 service，就会把请求代理到 Pod

• pod ip 在 k8s 集群之外无法访问，所以需要创建 service，这个 service 可以在 k8s 集群外访问

• Service 概述

• service 是一个固定接入层，客户端可以通过访问 service 的 ip 和端口访问到 service 关联的后端pod，这个 service 工作依赖于在 kubernetes 集群之上部署的一个附件，就是 kubernetes 的 dns 服务（不同 kubernetes 版本的 dns 默认使用的也是不一样的，1.11 之前的版本使用的是 kubeDNs，较新的版本使用的是 coredns），service 的名称解析是依赖于 dns 附件的，因此在部署完 k8s 之后需要再部署 dns 附件，kubernetes 要想给客户端提供网络功能，需要依赖第三方的网络插件（flannel，
  calico 等）。
• 每个 K8s 节点上都有一个组件叫做 kube-proxy，kube-proxy 这个组件将始终监视着apiserver 中有关 service 资源的变动信息，需要跟 master 之上的 apiserver 交互，随时连接到apiserver 上获取任何一个与 service 资源相关的资源变动状态，这种是通过 kubernetes 中固有的一种请求方法 watch（监视）来实现的，一旦有 service 资源的内容发生变动（如创建，删除），kubeproxy 都会将它转化成当前节点之上的能够实现 service 资源调度，把我们请求调度到后端特定的 pod资源之上的规则，这个规则可能是 iptables，也可能是 ipvs，取决于 service 的实现方式。

• Service 工作原理

• k8s 在创建 Service 时，会根据标签选择器 selector(lable selector)来查找 Pod，据此创建与Service 同名的 endpoint 对象，当 Pod 地址发生变化时，endpoint 也会随之发生变化，service 接收前端 client 请求的时候，就会通过 endpoint，找到转发到哪个 Pod 进行访问的地址。(至于转发到哪个节点的 Pod，由负载均衡 kube-proxy 决定)

• Kubernetes 集群中有三类 IP 地址

• Node Network（节点网络）：物理节点或者虚拟节点的网络，如 ens33 接口上的网路地址
  
• Pod network（pod 网络），创建的 Pod 具有的 IP 地址

  

  Node Network 和 Pod network 这两种网络地址是实实在在配置的，其中节点网络地址是配置在节点接口之上，而 pod 网络地址是配置在 pod 资源之上的，因此这些地址都是配置在某些设备之上的，这些设备可能是硬件，也可能是软件模拟
• Cluster Network（集群地址，也称为 service network），这个地址是虚拟的地址（virtual ip），没有配置在某个接口上，只是出现在 service 的规则当中。
  

• 创建 Service 资源

• #查看定义 Service 资源需要的字段有哪些？
  
  [~]# kubectl explain service
  
  KIND: Service
  VERSION: v1
  DESCRIPTION:
   Service is a named abstraction of software service (for example, mysql) consisting of local port (for example 3306) that the proxy listens on, and the selector that determines which pods will answer requests sent through
   the proxy.
  FIELDS:
   apiVersion <string> #service 资源使用的 api 组
   kind <string> #创建的资源类型
   metadata<Object> #定义元数据
   spec <Object> 
  
  
  #查看 service 的 spec 字段如何定义？
  
  [~]# kubectl explain service.spec
  
  KIND: Service
  VERSION: v1
  RESOURCE: spec <Object>
  DESCRIPTION:
   Spec defines the behavior of a service.
   https://git.k8s.io/community/contributors/devel/sig-architecture/apiconventions.md#spec-and-status
   ServiceSpec describes the attributes that a user creates on a service.
  FIELDS:
   allocateLoadBalancerNodePorts <boolean>
   clusterIP <string> #动态分配的地址，也可以自己在创建的时候指定，创建之后就改不了了
   clusterIPs <[]string>
   externalIPs <[]string>
   externalName<string>
   externalTrafficPolicy <string>
   healthCheckNodePort <integer>
   ipFamilies <[]string>
   ipFamilyPolicy <string>
   loadBalancerIP <string>
   loadBalancerSourceRanges <[]string>
   ports <[]Object> #定义 service 端口，用来和后端 pod 建立联系
   publishNotReadyAddresses <boolean>
   selector <map[string]string> #通过标签选择器选择关联的 pod 有哪些
   sessionAffinity <string>
   sessionAffinityConfig <Object> #service 在实现负载均衡的时候还支持 sessionAffinity
  
  sessionAffinity 什么意思？会话联系，默认是 none，随机调度的（基于 iptables 规则调度的）；如果我们定义sessionAffinity 的 client ip，那就表示把来自同一客户端的 IP 请求调度到同一个 pod 上
   topologyKeys <[]string>
   type <string> #定义 service 的类型 
  
  
  Service 的四种类型
  
  #查看定义 Service.spec.type 需要的字段有哪些？
  
  [~]# kubectl explain service.spec.type
  KIND: Service
  VERSION: v1
  FIELD: type <string>
  DESCRIPTION:
   type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object or EndpointSlice objects. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a virtual IP. "NodePort" builds on ClusterIP and allocates a port on every node which
   routes to the same endpoints as the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the same endpoints as the clusterIP. "ExternalName"
   aliases this service to the specified externalName. Several other fields do not apply to ExternalName services. More info:
   https://kubernetes.io/docs/concepts/services-networking/service/#publishingservices-service-types
  
  
  1、ExternalName：
  适用于 k8s 集群内部容器访问外部资源，它没有 selector，也没有定义任何的端口和 Endpoint。
  
  以下 Service 定义的是将 prod 名称空间中的 my-service 服务映射到 my.database.example.com
  kind: Service
  apiVersion: v1
  metadata:
   name: my-service
   namespace: prod
  spec:
   type: ExternalName
   externalName: my.database.example.com
  
  当查询主机 my-service.prod.svc.cluster.local 时，群集 DNS 将返回值为my.database.example.com 的 CNAME 记录。
  
  
  2、ClusterIP：
  通过 k8s 集群内部 IP 暴露服务，选择该值，服务只能够在集群内部访问，这也是默认的ServiceType。
   
  3、NodePort:
  通过每个 Node 节点上的 IP 和静态端口暴露 k8s 集群内部的服务。通过请求<NodeIP>:<NodePort>可以把请求代理到内部的 pod。Client----->NodeIP:NodePort----->Service Ip:ServicePort----->PodIP:ContainerPort。
  
  4、LoadBalancer:
  使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
  
  
  Service 的端口
  
  #查看 service 的 spec.ports 字段如何定义？
  
  [~]# kubectl explain service.spec.ports
  KIND: Service
  VERSION: v1
  RESOURCE: ports <[]Object>
  DESCRIPTION:
   The list of ports that are exposed by this service. More info:
   https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ipsand-service-proxies
   ServicePort contains information on service's port.
  FIELDS:
   appProtocol <string>
   name <string> #定义端口的名字
  
   nodePort <integer> #宿主机上映射的端口，比如一个 Web 应用需要被 k8s 集群之外的其他用户访问，那么需要配置
  type=NodePort，若配置 nodePort=30001，那么其他机器就可以通过浏览器访问 scheme://k8s 集群中的任何一个节点 ip:30001 即可访问到该服务，例如 http://192.168.1.63:30001。如果在 k8s 中部署 MySQL 数据库，MySQL 可能不需要被外界访问，只需被内部服务访问，那么就不需要设置NodePort
  
   port <integer> -required- #service 的端口，这个是 k8s 集群内部服务可访问的端口
   protocol <string>
   targetPort <string># targetPort 是 pod 上的端口，从 port 和 nodePort 上来的流量，经过 kube-proxy 流入到后端pod 的 targetPort 上，最后进入容器。与制作容器时暴露的端口一致（使用 DockerFile 中的EXPOSE），例如官方的 nginx 暴露 80 端口。

---

• 创建 Service 服务 type 类型 ClusterIP

• vim  pod_test.yaml

  

  

  需要注意的是，pod 虽然定义了容器端口，但是不会使用调度到该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。 这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。
  
  误删除其中一个 Pod：

  

  通过上面可以看到重新生成了一个 pod ：my-nginx-69f769d56f-tfznv，ip 是 10.244.179.16，在 k8s 中创建 pod，如果 pod 被删除了，重新生成的 pod ip 地址会发生变化，所以需要在 pod 前端加一个固定接入层。
  
  接下来创建 service：
  vim service_test.yaml 

  

  上述 yaml 文件将创建一个 Service，具有标签 run=my-nginx 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（targetPort：容器接收流量的端口；port：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。

  

  

  #通过上面可以看到请求 service IP:port 跟直接访问 pod ip:port 看到的结果一样，这就说明service 可以把请求代理到它所关联的后端 pod
  
  注意：上面的 10.110.38.52:80 地址只能是在 k8s 集群内部可以访问，在外部无法访问，比方说想要通过浏览器访问，那么是访问不通的，如果想要在 k8s 集群之外访问，是需要把 service type类型改成 nodePort 
  
  #查看 service 详细信息

  

  service 可以对外提供统一固定的 ip 地址，并将请求重定向至集群中的 pod。
  
  其中“将请求重定向至集群中的 pod”就是通过 endpoint 与 selector 协同工作实现。selector 是用于选择 pod，由selector 选择出来的 pod 的 ip 地址和端口号，将会被记录在 endpoint 中。endpoint 便记录了所有pod 的 ip 地址和端口号。
  
  当一个请求访问到 service 的 ip 地址时，就会从 endpoint 中选择出一个 ip地址和端口号，然后将请求重定向至 pod 中。具体把请求代理到哪个 pod，需要的就是 kube-proxy 的轮询实现的。
  
  service 不会直接到 pod，service 是直接到 endpoint 资源，就是地址加端口，再由endpoint 再关联到 pod。
  
  service 只要创建完成，就可以直接解析它的服务名，每一个服务创建完成后都会在集群 dns 中动态添加一个资源记录，添加完成后我们就可以解析了，资源记录格式是：SVC_NAME.NS_NAME.DOMAIN.LTD.服务名.命名空间.域名后缀
  
  集群默认的域名后缀是 svc.cluster.local.
  
  就像上面创建的 my-nginx 这个服务，它的完整名称解析就是 my-nginx.default.svc.cluster.local
  

• 创建 Service 服务 type 类型 NodePort

• vim pod_nodeport.yaml

  

  

  创建 service，代理 pod
  [~]# vim service_nodeport.yaml

  

  

  服务请求走向：Client-→node ip:30380->service ip:80-→pod ip:container port
                           Client -->192.168.2.30:30380-->10.97.113.39:80-->pod ip:80

• 创建 Service-type 类型 ExternalName

• 应用场景：跨名称空间访问
  需求：default 名称空间下的 client 服务想要访问 nginx-ns 名称空间下的 nginx-svc 服务
  
  vim client.yaml

  

  

   vim client_svc.yaml 
  集群默认的域名后缀: svc.cluster.local.
  
  
  #该文件中指定了到 nginx-svc 的软链，让使用者感觉就好像调用自己命名空间的服务一样。
  kubectl apply -f client_svc.yaml
  kubectl create namespace nginx-ns
  vim server_nginx.yaml 

  

  

   vim nginx_svc.yaml

  

  

  

  

   上面两个请求的结果一样

• k8s 集群引用外部的 mysql 数据库

• 在 k8s-01 上安装 mysql 数据库
  
• vim mysql_service.yaml

  

  

  注意这里还没有 endpoint
  vim mysql_endpoint.yaml 

  

  

  Endpoints:         192.168.2.40:3306    定义的为外部数据库
  上面配置就是将外部 IP 地址和服务引入到 k8s 集群内部，由 service 作为一个代理来达到能够访问外部服务的目的。
   

• Kube-proxy 组件介绍

• Kubernetes service 只是把应用对外提供服务的方式做了抽象，真正的应用跑在 Pod 中的 container 里，我们的请求转到 kubernetes nodes 对应的 nodePort 上，那么 nodePort 上的请求是如何进一步转到提供后台服务的 Pod 的呢？ 就是通过 kube-proxy 实现的：
   
• kube-proxy 部署在 k8s 的每一个 Node 节点上，是 Kubernetes 的核心组件，我们创建一个 service 的时候，kube-proxy 会在 iptables 中追加一些规则，为我们实现路由与负载均衡的功能。在k8s1.8 之前，kube-proxy 默认使用的是 iptables 模式，通过各个 node 节点上的 iptables 规则来实现 service 的负载均衡，但是随着 service 数量的增大，iptables 模式由于线性查找匹配、全量更新等特点，其性能会显著下降。
  
  从 k8s 的 1.8 版本开始，kube-proxy 引入了 IPVS 模式，IPVS 模式与iptables 同样基于 Netfilter，但是采用的 hash 表，因此当 service 数量达到一定规模时，hash 查表的速度优势就会显现出来，从而提高 service 的服务性能。
  
  
  service 是一组 pod 的服务抽象，相当于一组 pod 的 LB，负责将请求分发给对应的 pod。service会为这个 LB 提供一个 IP，一般称为 cluster IP。kube-proxy 的作用主要是负责 service 的实现，具体来说，就是实现了内部从 pod 到 service 和外部的从 node port 向 service 的访问。
  1、kube-proxy 其实就是管理 service 的访问入口，包括集群内 Pod 到 Service 的访问和集群外访问 service。
  2、kube-proxy 管理 sevice 的 Endpoints，该 service 对外暴露一个 Virtual IP，也可以称为是Cluster IP, 集群内通过访问这个 Cluster IP:Port 就能访问到集群内对应的 serivce 下的 Pod。

• Kube-proxy 三种工作模式

• Userspace 方式：

  

  Client Pod 要访问 Server Pod 时，它先将请求发给内核空间中的 service iptables 规则，由它再将请求转给监听在指定套接字上的 kube-proxy 的端口，kube-proxy 处理完请求，并分发请求到指定Server Pod 后,再将请求转发给内核空间中的 service ip，由 service iptables 将请求转给各个节点中的 Server Pod。
  这个模式有很大的问题，客户端请求先进入内核空间的，又进去用户空间访问 kube-proxy，由kube-proxy 封装完成后再进去内核空间的 iptables，再根据 iptables 的规则分发给各节点的用户空间的 pod。由于其需要来回在用户空间和内核空间交互通信，因此效率很差。在 Kubernetes 1.1 版本之前，userspace 是默认的代理模型。

• iptables 方式：
   

  

  客户端 IP 请求时，直接请求本地内核 service ip，根据 iptables 的规则直接将请求转发到到各pod 上，因为使用 iptable NAT 来完成转发，也存在不可忽视的性能损耗。另外，如果集群中存上万的Service/Endpoint，那么 Node 上的 iptables rules 将会非常庞大，性能还会再打折iptables 代理模式由 Kubernetes 1.1 版本引入，自 1.2 版本开始成为默认类型。

• ipvs 方式：
   

  

  Kubernetes 自 1.9-alpha 版本引入了 ipvs 代理模式，自 1.11 版本开始成为默认设置。客户端请求时到达内核空间时，根据 ipvs 的规则直接分发到各 pod 上。kube-proxy 会监视KubernetesService 对象和 Endpoints，调用 netlink 接口以相应地创建 ipvs 规则并定期与KubernetesService 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。与 iptables 类似，ipvs 基于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：
  rr：轮询调度
  lc：最小连接数
  dh：目标哈希
  sh：源哈希
  sed：最短期望延迟
  nq：不排队调度
  如果某个服务后端 pod 发生变化，标签选择器适应的 pod 又多一个，适应的信息会立即反映到apiserver 上,而 kube-proxy 一定可以 watch 到 etc 中的信息变化，而将它立即转为 ipvs 或者iptables 中的规则，这一切都是动态和实时的，删除一个 pod 也是同样的原理。如图：

  

   注:
  以上不论哪种，kube-proxy 都通过 watch 的方式监控着 apiserver 写入 etcd 中关于 Pod 的最新状态信息,它一旦检查到一个 Pod 资源被删除了或新建了，它将立即将这些变化，反应再 iptables 或ipvs 规则中，以便 iptables 和 ipvs 在调度 Clinet Pod 请求到 Server Pod 时，不会出现 Server Pod不存在的情况。自 k8s1.11 以后,service 默认使用 ipvs 规则，若 ipvs 没有被激活，则降级使用iptables 规则. 但在 1.1 以前，service 使用的模式默认为 userspace。Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的 Pod，不断刷新 iptables 规则，会消耗大量的CPU 资源。

• Kube-proxy 生成的 iptables 规则分析

• 在 k8s 创建的 service，虽然有 ip 地址，但是 service 的 ip 是虚拟的，不存在物理机上的，是在iptables 或者 ipvs 规则里的

  

  通过上面可以看到之前创建的 service，会通过 kube-proxy 在 iptables 中生成一个规则，来实现流量路由，有一系列目标为 KUBE-SVC-xxx 链的规则，每条规则都会匹配某个目标 ip 与端口。也就是说访问某个 ip:port 的请求会由 KUBE-SVC-xxx 链来处理。这个目标 IP 其实就是 service ip。

• coredns 组件详解

• DNS 是什么？
  DNS 全称是 Domain Name System：域名系统，是整个互联网的电话簿，它能够将可被人理解的域名翻译成可被机器理解 IP 地址，使得互联网的使用者不再需要直接接触很难阅读和理解的 IP 地址。域名系统在现在的互联网中非常重要，因为服务器的 IP 地址可能会经常变动，如果没有了 DNS，那么可能 IP 地址一旦发生了更改，当前服务器的客户端就没有办法连接到目标的服务器了，如果我们为 IP 地址提供一个『别名』并在其发生变动时修改别名和 IP 地址的关系，那么我们就可以保证集群对外提供的服务能够相对稳定地被其他客户端访。DNS 其实就是一个分布式的树状命名系统，它就像一个去中心化的分布式数据库，存储着从域名到 IP 地址的映射。

• CoreDNS？
  CoreDNS 其实就是一个 DNS 服务，而 DNS 作为一种常见的服务发现手段，所以很多开源项目以及工程师都会使用 CoreDNS 为集群提供服务发现的功能，Kubernetes 就在集群中使用 CoreDNS 解决服务发现的问题。 作为一个加入 CNCF（Cloud Native Computing Foundation）的服务，CoreDNS 的实现非常简单。

• 验证 coredns
  vim  dig.yaml
  

   kubernetes.default.svc.cluster.local
       服务名.名称空间.默认后缀
  在 k8s 中创建 service 之后，service 默认的 FQDN 是<service name>.<namespace>.svc.cluster.local，那么 k8s 集群内部的服务就可以通过 FQDN 访问

•  k8s DNS 解析步骤

      普通Pod的dnsPolicy属性是默认值ClusterFirst，也就是会指向集群内部的DNS服务器，kube-dns负责解析集群内部的域名

      kube-dns Pod的dnsPolicy值是Default，意思是从所在Node继承DNS服务器，对于无法解析的外部域名，kube-dns会继续向集群外部的dns进行查询

      kube-dns只能解析集群内部地址，而集群外部地址应该发给外部DNS服务器进行解析