1. Service

每个pod都有⾃⼰的IP地址，客户端⽆须关⼼后端提供服务pod的数量，以及各⾃对应的IP地址。它们⽆须记录每个pod的IP地址。相反，所有的pod可以通过⼀个单⼀的IP地址进⾏访问。为了解决上述问题，Kubernetes提供了⼀种资源类型——服务（service）

创建了⼀个名叫kubia的服务，它将在端⼜80接收请求并将连接路由到具有标签选择器是app=kubia的pod的8080端⼜上。

如果希望特定客户端产⽣的所有请求每次都指向同⼀个 pod ，可以设置服务的 sessionAfﬁnity 属性为ClientIP。

1.1 Endpoint

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

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

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

将服务的类型设置成 NodePort——每个集群节点都会在节点上打开⼀个端口，对于NodePort服务，每个集群节点在节点本⾝（因此得名叫NodePort）上打开⼀个端口，并将在该端口上接收到的流量重定向到基础服务。

将服务的类型设置成 LoadBalance，NodePort类型的⼀种扩展——这使得服务可以通过⼀个专⽤的负载均衡器来访问。

创建⼀个Ingress资源，这是⼀个完全不同的机制，通过⼀个IP地址公开多个服务——它运⾏在HTTP层（⽹络协议第7层）上，因此可以提供⽐⼯作在第4层的服务更多的功能。

1.3 NodePort

可以通过以下地址访问该服务：

10.11.254.223:80 （这个IP是这个Service的IP）
<1stnode＇sIP>:30123 ，<2ndnode＇sIP>:30123，等等

现在整个互联⽹可以通过任何节点上的30123端⼜访问到你的pod。客户端发送请求的节点并不重要。但是，如果只将客户端指向第⼀个节点，那么当该节点发⽣故障时，客户端⽆法再访问该服务。这就是为什么将负载均衡器放在节点前⾯以确保发送的请求传播到所有健康节点，并且从不将它们发送到当时处于脱机状态的节点的原因。

1.4 LoadBalancer(NodePort之上)

2. Ingress

为什么需要Ingress? ⼀个重要的原因是每个LoadBalancer 服务都需要⾃⼰的负载均衡器，以及独有的公有IP地址，⽽Ingress只需要⼀个公⽹IP就能为许多服务提供访问。当客户端向Ingress发送HTTP请求时，Ingress会根据请求的主机名和路径决定请求转发到的服务

Ingress在⽹络栈（HTTP）的应⽤层操作，并且可以提供⼀些服务不能实现的功能，诸如基于cookie的会话亲和性（session afﬁnity）等功能。

2.1 创建

apiVersion:extensions/vlbetal 
kind:Ingress
metadata:
	name:kubia
spec:
	rules:
	- host:kubia.example.com 
	  http:
			paths:
			- path: /
				backend:
				serviceName:kubia-nodeport 
				servicePort:80

Ingress控制器收到的所有请求主机kubia.example.com的HTTP请求，将被发送到端口80上的kubia-nodeport服务。

2.2 访问

要通过http://kubia.example.com访问服务，需要确保域名解析为 Ingress控制器的IP。

客户端⾸先对kubia.example.com执⾏DNS查找，DNS服务器（或本地操作系统）返回了Ingress控制器的IP。

客户端然后向Ingress控制器发送 HTTP请求，并在Host头中指定kubia.example.com。控制器从该头部确定客户端尝试访问哪个服务，通过与该服务关联的Endpoint对象查看 pod IP，并将客户端的请求转发给其中⼀个pod。

Levon's Blog

k8s教程03-Service和Ingress