本文摘要：观点Kubernetes Service是一种资源工具，我们可以使用它对一组提供相同服务的pod建立一个统一的、牢固的会见入口。

观点Kubernetes Service是一种资源工具，我们可以使用它对一组提供相同服务的pod建立一个统一的、牢固的会见入口。每个service在存续期间都有一个不会改变的IP地址和端口。

客户端可以与这个IP和端口建设毗连，然后这些毗连会被路由到这个service后面的其中一个pod上。通过这种方式，service的客户端就不需要知道提供该服务的每个pod的地址，这样这些pod在集群中就可以随时被建立或者移除。假定我们现在有一个前端的web服务器和一个后端的数据库服务器。

可以有多个pod充当前端服务器，可是只能有一个pod充当后端数据库。要想这样的一个系统正常运转，我们需要解决如下两个问题：外部客户端需要毗连到前端web服务器的pod，不需要体贴web服务器的数量前端web服务器pod需要毗连到后端数据库。由于数据库运行在一个pod中，随着时间的推移，它可能在集群中不停地变换所在的节点，导致IP地址不停变化。我们肯定不希望数据库服务器被移动后就重新设置前端pod。

通过为前端pod建立一个service以及将其设置成从集群外部可会见，我们可以对外袒露一个单一的、稳定的IP地址，外部客户端可以通过这个IP地址毗连到pod。同样地，通过为后端pod建立一个service，我们可以为后端pod建立一个牢固的地址。

纵然pod的IP地址变了，service的地址也不会变化。除此之外，通过建立service，前端pod能够轻易地通过情况变量或者DNS凭据名称找到后端服务。

如下图显示了两个service、支持这些service的两组pod以及它们之间的相互依赖关系：上图中，内部和外部客户端通过service毗连到pod。建立service服务的后端可以不止一个pod。毗连到该服务的请求可以通过负载平衡的方式分发到服务后面的pod上。

可是要如何准确地界说哪些pod是服务的一部门哪些不是呢？在之前的章节中我们学习过标签选择器，知道怎样在ReplicationController以及其他pod控制器中指定哪些pod属于相同的荟萃。service也使用与此相同的机制，如下图：标签选择器用于决议哪些pod属于相同的服务。

在之前的章节中，我们建立了一个ReplicationController，它会运行包罗Node.js应用的三个pod实例。本节中我们再次建立这个ReplicationController，然后验证是否有三个pod实例启动并运行。在此之后，我们再为这三个pod建立一个service。

我们通过YAML文件来手动建立一个service。vim test-svc.yamlapiVersion: v1kind: Servicemetadata:name: test-svcspec:ports:- port: 80 targetPort: 8080selector: app: test1上面的文件界说了一个名为test-svc的service，它会在端口80上吸收毗连，并将每个毗连路由到匹配标签选择器app=test1的所有pod中的某个pod的8080端口。

然后执行：kubectl create -f test-svc.yaml从上图可以看到分配给test-svc服务的IP地址是10.106.143.212。由于这是一个集群IP，所以只能在集群内部会见。服务的主要目的是将一组pod袒露给集群中的其他pod，可是我们通常也希望将服务袒露给外部，这点在后面会讲到。

从集群内部会见服务现在我们先从集群内部来使用刚刚建立的服务并相识服务的功效。可以通过如下几种方式从集群内部向服务发送请求：建立一个pod，它将请求发送到服务的集群IP并记载响应。

然后可以通过pod的日志来检察服务的详细响应信息。可以通过ssh远程登录到其中一个Kubernetes节点上，然后使用curl下令。可以在某个已经存在的pod中通过kubectl exce下令来执行curl下令。

我们接纳第三种方式并演示如何在已有的pod中运行下令。kubectl exec下令使我们能够在已有pod的容器中远程运行任意下令。这很是有助于我们检察容器的内容、状态以及情况。从现有的pod中选取某一个pod:kubectl exec test-rc-8n2b8 -- curl -s http://10.106.143.212上面下令中的（--）代表kubectl下令选项的竣事。

双破折号之后的所有下令都应该在pod中执行。如果下令中没有使用单破折号（-）指定参数，那么就可以不用指定双破折号，可是在上面的例子中，如果我们不使用折号，-s 选项就会被解释为kubectl exec下令的选项：kubectl exec test-rc-8n2b8 curl -s http://10.106.143.212kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.在上面的例子中，我们以独立历程的方式执行curl下令，可是是在pod的主容器中。这与容器中真正的主历程和服务通信并没有什么区别。

设置会话绑定（Session Affinity）在上面的实验中，我们执行了多次相同的下令，可以看到每次挪用后消息发送给了差别的pod，这是因为服务署理通常将每个毗连转发给一个随机选择的后端pod。如果希望某个客户端每次发送的请求都被转发到同一个pod，可以将服务的sessionAffinity属性设置成ClientIP（默认None）：vim test-svc2.yamlapiVersion: v1kind: Servicemetadata:name: test-svc1spec:sessionAffinity: ClientIPports:- port: 80 targetPort: 8080selector: app: test1kubectl create -f test-svc2.yaml基于该YAML文件建立的服务署理会未来自于同一个客户端IP的所有请求重定向到同一个pod。

kubectl exec test-rc-8n2b8 -- curl -s http://10.107.168.13通过上图可以看到，重复挪用5次，每次请求都指向同一个pod。Kubernetes仅支持两种类型的服务会话绑定：None和ClientIP。可能你会惊讶它居然没有基于cookie的会话绑定选项，不外我们需要知道Kubernetes服务并不是在HTTP层面上事情。

服务处置惩罚TCP和UDP包，并不体贴它的载荷内容。由于cookie是HTTP协议中的一种结构，服务并不知道它们，这就解释了为什么不能基于cookie举行会话绑定。一个服务袒露多个端口Kubernetes中service支持多个端口。例如，如果pod监听两个端口：好比HTTP监听8080端口，HTTPS监听8443端口，我们可以使用一个服务将80和443端口划分转发到pod的8080和8443端口，完全没须要建立两个差别的服务。

通过一个集群IP，使用一个多端口的服务就能将服务的所有端口全部袒露出来。需要注意的是，当建立多端口服务时，必须为每个端口指定一个名字。

多端口服务的YAML界说如下：apiVersion: v1kind: Servicemetadata:name: test-svcspec:ports:- name: http port: 80 targetPort: 8080- name: https port: 443 targetPort: 8443selector: app: test1使用命名端口在之前的例子中我们都是通过端口号来引用端口自己的，还可以为每个pod的端口取一个名字并在service的spec区段中通过名称来引用端口。这对于不常用的端口号来说就比力容易区分。

例如，假设我们为pod的每个端口界说了一个名称，如下所示：apiVersion: v1kind: Podspec:containers:- name: test1 ports: - name: http containersPort: 8080 - name: https containersPort: 8443然后在服务的界说文件中就可以通过名称引用端口：apiVersion: v1kind: Servicespec:ports:- name: http port: 80 targetPort: http- name: https port: 443 targetPort: https使用命名端口最大的利益就是纵然更改了pod中的端口号也不用修改服务的spec。如果pod当前将8080用于http，可是如果后面决议将端口号换成80呢？如果使用了命名端口，我们所需要做的就是在pod的spec中更改端口号（同时保持端口名稳定）。当启动新端口的pod时，客户毗连就会被转发到相应的端口号上，这取决于pod收到的毗连（8080端口在旧pod上，80端口在新pod上）。

如果以为本文对您有资助，接待关注我的头条号订阅更新，我会不停推出更多学习教程、视频以及偏实战的文章！。

返回首页