服务
服务
pod
需要一种寻找其他pod
的方法来使用其他pod
提供的服务, 不想在没有Kubernetes
的世界, 系统管理员要在用户端配置文件中明确指出服务的精确IP地址或主机名来配置每个服务短应用.
介绍服务
Kubernetes
服务是一种为一组功能相同的pod
提供单一不变的接入点的资源. 当服务存在是, 它的IP
地址和端口不会改变. 客户端通过IP
地址和端口号建立连接, 这些连接会被路由到提供该服务的任意一个pod
上. 通过这种方式, 客户端不需要知道每个单独的提供服务的pod
的地址, 这样这些pod
就可以在集群中随时被创建或移除.
创建服务
服务的后端可以有不止一个pod
. 服务的连接对所有的后端pod
是负载均衡的.
CLUSTER-IP
只能在集群内部可以被访问, 是为了让集群内部的其他pod
可以访问当前这组pod
.
在运行的容器中远程执行命令
嗯可以使用kubectl exec
命令远程地在一个已经存在的pod
容器上执行任何命令. 这样就可以很方便地了解pod
的内容, 状态及环境. --
代表着命令项的结束.
配置服务的回话亲和性
如果希望特定客户端产生的所有请求每次都指向同一个pod
, 可以设置服务的sessionAffinity
属性为ClientIP
(而不是None
, None
是默认值).
同一个服务暴露多个端口
在创建一个有多个端口的服务的时候, 必须给每个端口指定名字.
使用命名的端口
服务中可以通过数字来指定端口, 也可以通过名称来指定.
服务发现
客户端pod
如何知道服务的IP
和端口. Kubernetes
为客户端提供了发现服务的IP
和端口的方式.
通过环境变量发现服务
在pod
开始运行的时候, Kubernetes
会初始化一系列的环境变量指向现在存在的服务. 如果你创建的服务中早于客户端pod
的创建, pod
上的进程可以根据环境变量获得服务的IP
地址和端口号.
通过DNS
发现服务
kube-dns
运行DNS
服务, 在集群中的其他pod
都被配置成使用其作为dns
(Kubernetes
通过修改每个容器的/etc/resolv.conf
文件实现). 运行在pod
上的进程DNS
查询都会被Kubernetes
自身的DNS
服务器响应, 该服务器知道系统中运行的所有服务.
pod
是否使用内部的DNS
服务器是根据pod
中的spec
的dnsPolicy
属性来决定的.
每个服务从内部DNS
服务器中获得一个DNS
条目, 客户端的pod
在知道服务名称的情况下可以通过全限定域名来访问, 而不是诉诸于环境变量.
通过全限定域名连接服务
1 | <服务名>.<服务的命名空间>.svc.cluster.local |
客户端仍然必须知道服务的端口后. 如果不是标准端口, 客户端可以从环境变量中获取端口号.
连接集群外部的服务
介绍服务endpoint
服务并不是和pod
直接相连的. 相反, 有一种资源介于两者之间--
它就是Endpoint
资源.
1 | kubectl get endpoints <服务名> |
手动配置服务的endpoint
服务的endpoint
与服务解耦后, 可以分别配置和更新它们.
Endpoint
对象需要与服务具有相同的名称.
将服务暴露给外部客户端
使用NodePort
类型的服务
通过创建NodePort
服务, 可以让Kubernetes
在其所有节点上保留一个端口(所有节点都使用相同的端口), 并将传入的连接转发给作为服务部分的pod
.
通过负载均衡器将服务暴露出来
回话亲和性和Web
浏览器
浏览器使用keep-alive
连接, 并通过单个连接发送所有请求, 而curl
每次都会打开一个新连接. 服务在连接级别工作, 所以当首次打开服务的连接时, 会选择一个随机集群, 然后将属于该连接的所有网络数据包全部发送到单个集群. 即使会话亲和性设置为None
, 用户也会始终使用相同的pod
(直到连接关闭).
通过Ingress
暴露服务
为什么需要Ingress
一个重要的原因是每个LoadBalancer
服务都需要自己的负载均衡器, 以及独有的公有IP
地址, 而Ingress
只需要一个公网IP
就能为许多服务提供访问. 当客户端向Ingress
发送HTTP
请求时, Ingress
会根据请求的主机名和路径决定请求转发到的服务.
了解Ingress
的工作原理
Ingress
控制器不会将请求转发给该服务, 只用它来选择一个pod
.
pod
就绪后发出信号
介绍就绪探针
就绪探针器会定期调用, 并确定特定的pod
是否接收客户端请求. 当容器的准备就绪探测返回成功时, 表示容器已经准备好接收请求.
了解就绪探针的操作
启动容器时, 可以为Kubernetes
配置一个等待时间, 经过等待时间后才可以执行第一次就绪检查. 之后, 它会周期性地调用探针, 并根据就绪探针的结果采取行动. 如果某个pod
报告它尚未准备就绪, 则会从该服务中删除该pod
. 如果pod
再次准备就绪, 则重新添加pod
.