标签：代理   转换   src   调度   负载均衡   改变   lang   nali   cidr   

概述

• Kubernetes使用Service解决服务发现问题：每个Pod在创建后都会被分配一个IP地址，然而它会随着Pod的重启而改变；
• Service可以通过标签选择器选择一组Pod，然后作为它们共同的对外访问接口。这样我们的应用便可以在不知道Pod的IP地址的情况下，与其通信；
• 当Service的标签选择器选择了多个Pod时，还可以在它们之间做负载均衡；
• 众所周知，Service的中文意为“服务”。但就其功能而言，更像是一个Proxy（代理）或Router（路由）。

配置

一个典型的Service对象配置如下：

kind: Service
apiVersion: v1
metadata:
  name: nginx-server
spec:
  clusterIP: 192.168.1.0
  selector:
    app: nginx
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

• 每个Service都会由系统分配一个虚拟IP作为访问Service的入口IP地址，然后监听spec.ports.port字段指定的端口;
• Service的IP也可以通过spec.clusterIP字段指定，且必须是APIServer中的配置字段 service-cluster-ip-range CIDR 范围内的合法 地址；
• 标签选择器spec.selector能够根据labels选择目标Pod，而Service会将外部流量转发到目标Pod的spec.ports.targetPort端口；
• 该Service开放了多个端口（80/443），因此必须定义端口的名称spec.ports.name（http/https），以避免歧义；
• 当Service被创建后，系统随之创建一个同名的Endpoints对象，它保存了所有匹配标签选择器的Pod的IP地址和端口。

无标签选择器的Service

上文提到，Service常用于对Pod的流量调度，但也可以用于访问：

• 同一集群不同namespace中的或其他集群中的Service
• 其他的一些后端程序或数据库

此时需要定义一个没有标签选择器的Service，如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

因为该Service没有标签选择器，相应的Endpoint对象便无法自动创建。因此我们需要手动创建一个Endpoint对象，以便将到达该Service监听的端口的请求映射到后端程序或其他Service的IP地址和端口：

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

在上述例子中，Service 将请求路由到 Endpoint：192.0.2.42:9376 (TCP)。另外，目标IP不能是本机回环地址或虚拟IP地址。

Headless Services

Headless Service不提供负载均衡的特性，也没有自己的 IP 地址，kube-proxy并不会处理这类Service。只需要指定 spec.clusterIP字段值为 "None"，便可以创建一个Headless Service对象。

代理模式

• iptables：由kube-proxy负责为每一个Service创建和维护iptables的路由规则，其余工作由内核的iptables完成。iptables承担了从 Service的IP地址到Pod的IP地址的负载均衡工作。在默认情况下，iptables会将请求随机重定向到由Service代理的一组Pod中的某个Pod上。

• IPVS：kube-proxy监视Service和Endpoint对象的改变，调用netlink接口相应地创建IPVS规则， 并定期地将IPVS规则与Service和Endpoint对象同步。IPVS可以转发TCP / UDP请求到实际的服务器上，使得一组实际的服务器（Pod）看起来像是只通过一个单一IP 地址（Service）访问的服务一样。

服务发现模式

Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS。

环境变量

kubelet会为节点上活跃的Service对象创建一组环境变量（包括Service的clusterIP、监听的端口等），并在创建Pod时这些环境它们注入其中。使用这种服务发现模式要求Service先于Pod创建，因此有一定的局限性。

DNS

集群中的DNS服务器（例如CoreDNS）使用Kubernetes的watch api不断监测Service的创建并为每一个Service创建一条DNS记录，从而使Pod可以解析该Service的域名。对于不同类型的Service，其DNS记录的分配方式有所不同：

Headless Service以外的Service

• Service将被分配一个A记录，格式为：

< service-name>.<namespace-name>.svc.cluster.local

? 其中，cluster.local为，该DNS记录解析到Service的ClusterIP。

• 若Servic存在一个已被命名的端口（spec.ports.name字段不为空），则该端口将被分配一个SRV记录，其格式为:

  <_port-name>.<_port-protocol>.< service-name>.<namespace-name>.svc.cluster.local

? 则可根据该SRV记录发现该Service的命名端口及IP地址。

Headless Service

• 已定义标签选择器的Headless Service：Endpoints Controller 在Kubernetes API中创建Endpoints对象，并修改 DNS 配置返回一个A记录（格式与普通的Service相同），指向该Service选取的一组Pod的IP地址。

• 无标签选择器的Headless Service：Endpoints Controller不再创建Endpoints对象。若Service类型为ExternalName，DNS服务返回其CNAME 记录；若 Service为其他类型，返回与该Service同名的Endpoints对象的A记录。Service的类型将在下一节中进行介绍。

外部访问

集群中的节点（虚拟机）可以通过网关访问互联网，但Pod的IP地址与其所在节点的IP地址显然不同。由于网关的NAT功能只能转换节点（虚拟机）的IP地址，而无法转换Pod的IP地址。毕竟网关根本无法知晓节点上运行了什么样的Pod，因此Pod是无法访问外网的。而我们常希望将集群中的一些运行前端应用的Pod暴露给集群外部的IP地址，这时便需要改变spec.type字段定义特殊类型的Service了。

ClusterIP

默认的Service类型，通过集群中的内部IP暴露Service，这种方式的 Service只能在集群内部访问。

NodePort

通过每个节点上的 IP 和静态端口（spec.ports.nodePort）暴露服务，其配置如下：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
      # 默认情况下，为了方便起见，targetPort与port字段值相同
    - port: 80
      targetPort: 80
      # 如不指定，则会从30000-32767范围内分配一个端口号
      nodePort: 30007

该类型的Service在集群外部可以通过<NodeIP>:<spec.ports.nodePort> 访问，同时也会自动创建一个ClusterIP类型的访问方式：<spec.clusterIp>:<spec.ports.port>可供集群内部访问。

LoadBalancer

使用云提供商的负载均衡器向集群外部暴露服务，同时也会自动创建ClusterIP和NodePort类型的访问方式：

• 在集群内部通过 <spec.clusterIp>:<spec.ports.port>访问；
• 在集群外部通过<NodeIP>:<spec.ports.nodePort>访问；
• 在集群外部通过负载均衡器的IP和port访问。

负载均衡器是异步创建的。当LoadBalancer类型的Service创建完成后，负载均衡器的信息将被回写到 Service 的 status.loadBalancer 字段中，例如：

  apiVersion: v1
  kind: Service
  metadata:
    name: example-service
  spec:
    selector:
      app: example
    clusterIP: 10.84.206.2
    externalIPs:
    - 172.29.245.25
    ports:
    - nodePort: 31688
      port: 8765
      protocol: TCP
      targetPort: 9376
    type: LoadBalancer
  status:
    loadBalancer:
      ingress:
      - ip: 172.29.245.25

Loadbalancer类型的Service处理外网入方向流量的流程如下：

• Loadbalancer 类型的 Service 创建后，Cloud Controller（云服务商提供）将为其创建一个负载均衡器；
• 负载均衡器只能直接和节点（虚拟机）沟通，并不知晓Pod的存在。当数据包从请求方（互联网）到达负载均衡器之后，将被分发到集群中的某一节点上；
• kube-proxy在节点上安装的iptables规则（或IPVS）将数据包的目的地址转换为合适的Pod的IP地址（所谓“合适”，即集群内的负载均衡）；
• iptables将数据包转发到对应的Pod。

ExternalName

ExternalName类型的Service将Service映射到DNS名称，而非标签选择器选取的一组Pod上，其配置如下：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

当查找域名：my-service.prod.svc.cluster.local时，集群内的DNS服务将返回一条CNAME记录， 即spec.externalName字段的值 my.database.example.com。访问该服务的方式与其他类型的Service相同，但主要区别在于重定向发生在DNS级别，而不是通过代理或转发。

External IP

如果有外部 IP 路由到 Kubernetes 集群的一个或多个节点，任意类型的Service可以通过<spec.externalIPs>:<spec.ports.port> 进行访问。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

在上面的例子中，客户端即可通过80.11.12.10:80访问名为my-service的Service对象。

Kubernetes：Service

标签：代理   转换   src   调度   负载均衡   改变   lang   nali   cidr   

原文地址：https://www.cnblogs.com/koktlzz/p/14410329.html