【K8S in Action】服务：让客户端发现pod 并与之通信（1）

服务是一种为一组功能相同的 pod 提供单一不变的接入点的资源。当服务存在时，它的 IP 地址和端口不会改变。客户端通过 IP 地址和端口号建立连接，

这些连接会被路由到提供该服务的任意一个 pod 上。

pod 是短暂，会删除增加，调度到其他节点，数量变更。
在 pod 启动前会给已经调度到节点上的pod 分配 IP 地址，即客户端提前不知道Pod的IP地址。
水平仲缩意味着多个 pod 可能会提供相同的服务。无需关注提供服务 pod 的数量，以及每个Pod的IP。

1 服务与服务发现

1 创建Service 服务

创建了一个名叫kubia的服务，它将在端口80接收请求并将连接路由到具有标签选择器是app=kubia的pod的8080端口上。 Kubernetes服务代理截取的该连接，在根据标签选择器选中的Pod 中，任意选择了一个pod, 然后将请求转发给它。

bash 复制代码

apiVersion: vl 
kind: Service 
metadata：
  name: kubia
spec: 
  ports: 
	- name: http      		
	  port: 80
	  targetPort: 8080     转发到容器端口
	- name: https          同一服务暴露多个端口
	  port: 443
	  targetPort: 8443
  selector:            标签选择器适用的服务
	app: kubia
  sessionAffinity: ClientIP        会话亲和性,统一客户端产生的所有请求每次都指向同一个pod

bash 复制代码

kubectl get svc

NAME         CLUSTER-IP 	EXTERNAL-IP    PORT(S)    AGE 
kubernetes   10.111.240.1      <none>       443/TCP   30d 
kubia       10.111.249.153 		<none>       80/TCP   6m     分配给服务的IP地址是10.111.249.153

kubectl exec kubia-7nogl -- curl -s http: //10 .111. 249 .153       双横杠(--)代表着kubectl命令项的结束。 之后的内容是指在pod内部需要执行的命令

2 使用命名的端口

通过数字来指定端口，但是在服务中也可以给不同的端口号命名，通过名称来指定。是即使更换端口号无须更改服务的spec，通过改变Pod 中的 spec pod 端口号。

bash 复制代码

kind : Pod 
spec : 
  containers: 
   - name: kubia 
	 ports :  
		- name : http    将8080端口命名为http
		  containerPort: 8080 
		- name ： https 
		  containerPort: 8080 


apiVersion: vl 
kind: Service 
metadata：
  name: kubia
spec: 
  ports: 
	- name: http      		
	  port: 80
	  targetPort: http   将80端口映射到容器被称为http 的端口
	- name: https          
	  port: 443
	  targetPort: https

3 服务发现

集群内客户端 pod 如何知道服务的 IP 和端口？

通过环境变量发现服务

pod 开始运行的时候，会初始化环境变量指向现在存在服务。服务创建早于Pod的创建， pod 上的进程可以根据环境变量获得服务 IP 地址和端口号。所以的Pod 都可以看到该服务。

bash 复制代码

kubectl delete po --all   #在无须知道 pod 的名字的情况下就能删除所有 pod
kubectl get po            # 后面创建的服务，所以先删除pod, pod 会自动重建
kubectl exec kubia-3inly env   

KUBIA SERVICE HOST=l0.111.249.153    服务的集群Ip
KUBIA SERVICE PORT=80                 服务所在的端口

服务名称中的横杠被转换为下画线，并且当服务名称用作环境变量名称中

的前级时，所有的字母都是大写的。

环境变量是获得服务 IP 地址和端口种方式。

通过 DNS 发现服务

一个pod 被称作 kube-dns ，这个 pod 运行 DNS 服务，在集群中的其他 pod 都被配置成使用其作为 dns (通过修改每容器的／ etc/reso conf 实现), pod 是否使用内部的 DNS 服务器是根据 pod 中 spec dnsPolicy 属性来决定的。

每个服务从内部 DNS 服务器中获得 DNS 条目，客户端 pod 在知道服务名称的情况下通过全限定域名（FQDN ）来访问，而不是诉诸于环境变量。

FQDN 的连接来访后端数据库服务： backend-database.default.svc.cluster.local

backend-database 对应于服务名称，
default 表示服务在其中定义的名称间，
svc.cluster.local 是在所有集群本地服务名称中使用的可配置集群域后缀。

尝试使用 FQDN 来代替 IP 去访问 kubia 服务。另外，必须在一个存在的 pod 上才能这样做。客户端仍然必须知道服务的端口号，如果并不是标准端口，客户端可以从环境变量中获取端口号。

2 连接集群外部的服务

不要让服务将连接重定向到集群中的 pod ，而是让它重定向到外部 IP 和端口。

2.1 介绍服务 endpoint

服务并不是和 pod 直接相连的。相反，有一种资源介于两者之间－----它就是 Endpoint 资源。

bash 复制代码

kubectl describe svc kubia

kubectl get endpoints kubia
NAME 	ENDPOINTS 									     AGE 
kubia  10.108.l.4:8080,10.108.2.5:8080,10.108.2.6:8080    lh

服务的 endpoint 与服务解耦后，可以分别手动配置和更新他们。

2.2 手动配置服务的 endpoint

如果创建了不包含 pod选择器的服务，Kubemetes 将不会创建 Endpoint 资源（毕竟，缺少选择器，将不会知道服务中包含哪些 pod)。这样就需要创建 Endpoint 资源来指定该服务的 endpoint 列表。

Endpoint是一个单独的资源并不是服务的一个属性。由于创建的资源中并不包含选择器，相关的Endpoints 资源并没有自动创建，所以必须手动创建。

Endpoint对象需要与服务具有相同的名称，并包含该服务的目标IP地址和端口

列表。服务和Endpoint资源都发布到服务器。

在服务创建后创建的容器将包含服务的环境变量，并且与其IP : port对的所有连接都将在服务端点之间进行负载均衡。

bash 复制代码

apiVersion: vl 
kind: EndpointS                Endpoint的名称必须和服务的名称相匹配
metadata:
	name: external-service
subsets: 
	- addresses:
		- ip: 11. 11. 11. 11    服务将连接重定向到endpoint的IP地址 (集群外部地址）
		- ip: 22.22.22.22
	ports: 
		- port: 80      endpoint的目标端口


apiVersion: vl 
kind: Service 
metadata: 
	name: exernal-service
spec: 
	ports: 
	- port： 80     服务中没有定义选择器

2.3 为外部服务创建别名

手动配置服务的Endpoint来代替公开外部服务方法，有一种更简单的方法，

就是通过其完全限定域名(FQDN)访问外部服务。

服务创建完成后，pod可以通过external-service.default.svc.cluster.loca l域名（甚至是external-service)连接到外部服务。

bash 复制代码

apiVersion: vl 
kind: Service 
metadata: 
	name: external-service 
spec: 
	type: ExternalName              type 为ExternalName
	externalName: someapi.somecompany.com     实际服务的完全限定域名
	ports: 
	- port: 80

3 将服务暴露给外部客户端

将服务的类型设置成NodePort

-- 每个集群节点都会在节点上打开一个端口，对于NodePort服务，每个集群节点在节点本身（因此得名叫NodePort)上打开一个端口，并将在该端口上接收到的流量重定向到基础服务。

-- 该服务仅在内部集群 IP 和端口上才可访间，但也可通过所有节点上的专用端口访问。
将服务的类型设置成LoadBalance, NodePort类型的一种扩展。

-- 这使得服务可以通过一个专用的负载均衡器来访问，这是由Kubernetes中正在运行的云基础设施提供的。负载均衡器将流量重定向到跨所有节点的节点端口。

客户端通过负载均衡器的 IP 连接到服务。
创建一个Ingress资源，这是一个完全不同的机制，通过一个IP地址公开多

个服务------它运行在 HTTP 层（网络协议第7 层）上，因此可以提供比工作

在第4层的服务更多的功能。

3.1 使用 NodePort 类型的服务

将一组pod公开给外部客户端的第一种方法是创建一个服务并将其类型设置为NodePort。通过创建NodePort服务，可以让Kubemetes在其所有节点上保留一个端口（所有节点上都使用相同的端口号），并将传入的连接转发给作为服务部分的pod。

bash 复制代码

apiVersion: vl 
kind: Service 
metadata: 
	name: kubia-nodeport
spec: 
	type: NodePort       服务类型
	ports: 
	- port: 80           服务集群端口号
	  targetPort: 8080   背后Pod 的端口号
	  nodePort: 30123   通过集群节点的30123端口访问该服务
	selector: 
	  app: kubia

kubectl get svc kubia-nodeport 

NAME            CLUSTER-IP       EXTERNAL-IP  PORT(S)      AGE 
kubia-nodeport 10.111.254.223    <nodes>       80:30123/TCP  2m

EXTERNAL-IP列。它显示nodes,表明服务可通过任何集群节点的IP地址访问。 PORT(S)列显示集群IP (8 0) 的内部端口和节点端口(30123), 可以通过以下地址访问该服务：

10.11.254.223:80
<lst node's IP>:30123
<2nd node's IP>:30123, 等等

3.2 通过负载均衡器将服务暴露出来

云提供商上提供负载平衡器。负载均衡器拥有自己独一无二的可公开访问的 IP 地址，并将所有连接重定向到服务。可以通过负载均衡器的 IP 地址访问服务

bash 复制代码

apiVersion: vl 
kind: Service 
metadata:
	name: kubia-loadbalancer 
spec: 
	type: LoadBalancer 
	portS:
	- port: 80 
	  targetPort: 8080
	selector:
	  app: kubia

kubectl get svc kubia-loadbalancer

NAME              CLUSTER-IP       EXTERNAL-IP     PORT(S)       AGE 
kubia-loadbalancer 10.111.241.153  130.211.53.173  80:32143/TCP  lm

3.3 了解外部连接的特性

防止不必要的网络跳数，服务配置为仅将外部通信重定向到接收连接的节点上运行的pod来阻止此额外跳数。

bash 复制代码

spec: 
	exernalTrafficPolicy: Local

如果服务定义包含此设置，并且通过服务的节点端口打开外部连接，则服务代理将选择本地运行的pod。如果没有本地pod存在，则连接将挂起。
使用local外部流量策略的服务可能会导致跨pod的负载分布不均衡。