Kubernetes:Service
标签:代理 转换 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对象。
标签:代理 转换 src 调度 负载均衡 改变 lang nali cidr
原文地址:https://www.cnblogs.com/koktlzz/p/14410329.html