update service

pull/405/head
Jimmy song 2020-06-22 22:59:42 +08:00
parent 9a0db52e33
commit 91be4a47a8
1 changed files with 54 additions and 87 deletions

View File

@ -1,21 +1,15 @@
# Service
Kubernetes [`Pod`](https://kubernetes.io/docs/user-guide/pods) 是有生命周期的,它们可以被创建,也可以被销毁,然而一旦被销毁生命就永远结束。
通过 [`ReplicationController`](https://kubernetes.io/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`
每个 `Pod` 都会获取它自己的 IP 地址,即使这些 IP 地址不总是稳定可依赖的。
这会导致一个问题:在 Kubernetes 集群中,如果一组 `Pod`(称为 backend为其它 `Pod` (称为 frontend提供服务那么那些 frontend 该如何发现,并连接到这组 `Pod` 中的哪些 backend 呢?
通过 [`ReplicationController`](https://kubernetes.io/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`。 每个 `Pod` 都会获取它自己的 IP 地址,即使这些 IP 地址不总是稳定可依赖的。这会导致一个问题:在 Kubernetes 集群中,如果一组 `Pod`(称为 backend为其它 `Pod` (称为 frontend提供服务那么那些 frontend 该如何发现,并连接到这组 `Pod` 中的哪些 backend 呢?
关于 `Service`
## 关于 `Service`
Kubernetes `Service` 定义了这样一种抽象:一个 `Pod` 的逻辑分组,一种可以访问它们的策略 —— 通常称为微服务。
这一组 `Pod` 能够被 `Service` 访问到,通常是通过 [`Label Selector`](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors)(查看下面了解,为什么可能需要没有 selector 的 `Service`)实现的。
Kubernetes `Service` 定义了这样一种抽象:一个 `Pod` 的逻辑分组,一种可以访问它们的策略 —— 通常称为微服务。这一组 `Pod` 能够被 `Service` 访问到,通常是通过 [`Label Selector`](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors)(查看下面了解,为什么可能需要没有 selector 的 `Service`)实现的。
举个例子,考虑一个图片处理 backend它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。
然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化frontend 客户端不应该也没必要知道,而且也不需要跟踪这一组 backend 的状态。
`Service` 定义的抽象能够解耦这种关联。
举个例子,考虑一个图片处理 backend它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化frontend 客户端不应该也没必要知道,而且也不需要跟踪这一组 backend 的状态。`Service` 定义的抽象能够解耦这种关联。
对 Kubernetes 集群中的应用Kubernetes 提供了简单的 `Endpoints` API只要 `Service` 中的一组 `Pod` 发生变更,应用程序就会被更新。
对非 Kubernetes 集群中的应用Kubernetes 提供了基于 VIP 的网桥的方式访问 `Service`,再由 `Service` 重定向到 backend `Pod`
对 Kubernetes 集群中的应用Kubernetes 提供了简单的 `Endpoints` API只要 `Service` 中的一组 `Pod` 发生变更,应用程序就会被更新。对非 Kubernetes 集群中的应用Kubernetes 提供了基于 VIP 的网桥的方式访问 `Service`,再由 `Service` 重定向到 backend `Pod`
## 定义 Service
@ -37,18 +31,11 @@ spec:
targetPort: 9376
```
上述配置将创建一个名称为 “my-service” 的 `Service` 对象,它会将请求代理到使用 TCP 端口 9376并且具有标签 `"app=MyApp"``Pod` 上。
这个 `Service` 将被指派一个 IP 地址(通常称为 “Cluster IP”它会被服务的代理使用见下面
`Service` 的 selector 将会持续评估,处理结果将被 POST 到一个名称为 “my-service” 的 `Endpoints` 对象上。
上述配置将创建一个名称为 “my-service” 的 `Service` 对象,它会将请求代理到使用 TCP 端口 9376并且具有标签 `"app=MyApp"``Pod` 上。这个 `Service` 将被指派一个 IP 地址(通常称为 “Cluster IP”它会被服务的代理使用见下面。该 `Service` 的 selector 将会持续评估,处理结果将被 POST 到一个名称为 “my-service” 的 `Endpoints` 对象上。
需要注意的是, `Service` 能够将一个接收端口映射到任意的 `targetPort`
默认情况下,`targetPort` 将被设置为与 `port` 字段相同的值。
可能更有趣的是,`targetPort` 可以是一个字符串,引用了 backend `Pod` 的一个端口的名称。
但是,实际指派给该端口名称的端口号,在每个 backend `Pod` 中可能并不相同。
对于部署和设计 `Service` ,这种方式会提供更大的灵活性。
例如,可以在 backend 软件下一个版本中,修改 Pod 暴露的端口,并不会中断客户端的调用。
需要注意的是, `Service` 能够将一个接收端口映射到任意的 `targetPort`。默认情况下,`targetPort` 将被设置为与 `port` 字段相同的值。更有趣的是,`targetPort` 可以是一个字符串,引用了 backend `Pod` 的一个端口的名称。但是,实际指派给该端口名称的端口号,在每个 backend `Pod` 中可能并不相同。对于部署和设计 `Service` ,这种方式会提供更大的灵活性。例如,可以在 backend 软件下一个版本中,修改 Pod 暴露的端口,并不会中断客户端的调用。
Kubernetes `Service` 能够支持 `TCP``UDP` 协议,默认 `TCP` 协议。
Kubernetes `Service` 支持 `TCP``UDP` 协议,默认 `TCP` 协议。
### 没有 selector 的 Service
@ -71,6 +58,7 @@ spec:
port: 80
targetPort: 9376
```
由于这个 `Service` 没有 selector就不会创建相关的 `Endpoints` 对象。可以手动将 `Service` 映射到指定的 `Endpoints`
```yaml
@ -89,8 +77,7 @@ subsets:
访问没有 selector 的 `Service`,与有 selector 的 `Service` 的原理相同。请求将被路由到用户定义的 Endpoint该示例中为 `1.2.3.4:9376`)。
ExternalName `Service``Service` 的特例,它没有 selector也没有定义任何的端口和 Endpoint。
相反地,对于运行在集群外部的服务,它通过返回该外部服务的别名这种方式来提供服务。
ExternalName `Service``Service` 的特例,它没有 selector也没有定义任何的端口和 Endpoint。相反地对于运行在集群外部的服务它通过返回该外部服务的别名这种方式来提供服务。
```yaml
kind: Service
@ -103,27 +90,28 @@ spec:
externalName: my.database.example.com
```
当查询主机 `my-service.prod.svc.CLUSTER`时,集群的 DNS 服务将返回一个值为 `my.database.example.com``CNAME` 记录。
访问这个服务的工作方式与其它的相同,唯一不同的是重定向发生在 DNS 层,而且不会进行代理或转发。
如果后续决定要将数据库迁移到 Kubernetes 集群中,可以启动对应的 Pod增加合适的 Selector 或 Endpoint修改 `Service``type`
当查询主机 `my-service.prod.svc.CLUSTER`时,集群的 DNS 服务将返回一个值为 `my.database.example.com``CNAME` 记录。访问这个服务的工作方式与其它的相同,唯一不同的是重定向发生在 DNS 层,而且不会进行代理或转发。如果后续决定要将数据库迁移到 Kubernetes 集群中,可以启动对应的 Pod增加合适的 Selector 或 Endpoint修改 `Service``type`
## VIP 和 Service 代理
在 Kubernetes 集群中,每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP虚拟 IP的形式而不是 `ExternalName` 的形式。
在 Kubernetes v1.0 版本,代理完全在 userspace。在 Kubernetes v1.1 版本,新增了 iptables 代理,但并不是默认的运行模式。
在 Kubernetes v1.0 版本,代理完全在 userspace`Service` 是 “4层”TCP/UDP over IP概念。
在 Kubernetes v1.1 版本,新增了 iptables 代理,但并不是默认的运行模式。新增了 `Ingress` APIbeta 版),用来表示 “7层”HTTP服务。
从 Kubernetes v1.2 起,默认就是 iptables 代理。
在Kubernetes v1.8.0-beta.0中添加了ipvs代理。
在 Kubernetes v1.0 版本,`Service` 是 “4层”TCP/UDP over IP概念。
在 Kubernetes v1.1 版本,新增了 `Ingress` APIbeta 版),用来表示 “7层”HTTP服务。
在 Kubernetes v1.8.0-beta.0 中添加了ipvs代理。
### userspace 代理模式
这种模式kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
对每个 `Service`,它会在本地 Node 上打开一个端口(随机选择)。
任何连接到“代理端口”的请求,都会被代理到 `Service` 的backend `Pods` 中的某个上面(如 `Endpoints` 所报告的一样)。
使用哪个 backend `Pod`,是基于 `Service``SessionAffinity` 来确定的。
最后,它安装 iptables 规则,捕获到达该 `Service``clusterIP`(是虚拟 IP`Port` 的请求,并重定向到代理端口,代理端口再代理请求到 backend `Pod`
网络返回的结果是,任何到达 `Service` 的 IP:Port 的请求,都会被代理到一个合适的 backend不需要客户端知道关于 Kubernetes、`Service`、或 `Pod` 的任何信息。
@ -138,13 +126,12 @@ spec:
### iptables 代理模式
这种模式kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
对每个 `Service`,它会安装 iptables 规则,从而捕获到达该 `Service``clusterIP`(虚拟 IP和端口的请求进而将请求重定向到 `Service` 的一组 backend 中的某个上面。
对于每个 `Endpoints` 对象,它也会安装 iptables 规则,这个规则会选择一个 backend `Pod`
对每个 `Service`,它会安装 iptables 规则,从而捕获到达该 `Service``clusterIP`(虚拟 IP和端口的请求进而将请求重定向到 `Service` 的一组 backend 中的某个上面。对于每个 `Endpoints` 对象,它也会安装 iptables 规则,这个规则会选择一个 backend `Pod`
默认的策略是,随机选择一个 backend。
实现基于客户端 IP 的会话亲和性,可以将 `service.spec.sessionAffinity` 的值设置为 `"ClientIP"` (默认值为 `"None"`)。
默认的策略是,随机选择一个 backend。实现基于客户端 IP 的会话亲和性,可以将 `service.spec.sessionAffinity` 的值设置为 `"ClientIP"` (默认值为 `"None"`)。
和 userspace 代理类似,网络返回的结果是,任何到达 `Service` 的 IP:Port 的请求,都会被代理到一个合适的 backend不需要客户端知道关于 Kubernetes、`Service`、或 `Pod` 的任何信息。
这应该比 userspace 代理更快、更可靠。然而,不像 userspace 代理,如果初始选择的 `Pod` 没有响应iptables 代理不能自动地重试另一个 `Pod`,所以它需要依赖 [readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#defining-readiness-probes)。
![iptables代理模式下Service概览图](../images/services-iptables-overview.jpg)
@ -234,30 +221,26 @@ REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
### DNS
一个可选(尽管强烈推荐)[集群插件](http://releases.k8s.io/master/cluster/addons/README.md) 是 DNS 服务器。
DNS 服务器监视着创建新 `Service` 的 Kubernetes API从而为每一个 `Service` 创建一组 DNS 记录。
如果整个集群的 DNS 一直被启用,那么所有的 `Pod` 应该能够自动对 `Service` 进行名称解析。
DNS 服务器监视着创建新 `Service` 的 Kubernetes API从而为每一个 `Service` 创建一组 DNS 记录。如果整个集群的 DNS 一直被启用,那么所有的 `Pod` 应该能够自动对 `Service` 进行名称解析。
例如,有一个名称为 `"my-service"``Service`,它在 Kubernetes 集群中名为 `"my-ns"``Namespace` 中,为 `"my-service.my-ns"` 创建了一条 DNS 记录。
在名称为 `"my-ns"``Namespace` 中的 `Pod` 应该能够简单地通过名称查询找到 `"my-service"`
在另一个 `Namespace` 中的 `Pod` 必须限定名称为 `"my-service.my-ns"`
这些名称查询的结果是 Cluster IP。
Kubernetes 也支持对端口名称的 DNS SRVService记录。
如果名称为 `"my-service.my-ns"``Service` 有一个名为 `"http"``TCP` 端口,可以对 `"_http._tcp.my-service.my-ns"` 执行 DNS SRV 查询,得到 `"http"` 的端口号。
在名称为 `"my-ns"``Namespace` 中的 `Pod` 应该能够简单地通过名称查询找到 `"my-service"`。在另一个 `Namespace` 中的 `Pod` 必须限定名称为 `"my-service.my-ns"`。这些名称查询的结果是 Cluster IP。
Kubernetes 也支持对端口名称的 DNS SRVService记录。如果名称为 `"my-service.my-ns"``Service` 有一个名为 `"http"``TCP` 端口,可以对 `"_http._tcp.my-service.my-ns"` 执行 DNS SRV 查询,得到 `"http"` 的端口号。
Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。
更多信息可以查看 [DNS Pod 和 Service](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)。
## Headless Service
有时不需要或不想要负载均衡,以及单独的 Service IP。
遇到这种情况,可以通过指定 Cluster IP`spec.clusterIP`)的值为 `"None"` 来创建 `Headless` Service。
有时不需要或不想要负载均衡,以及单独的 Service IP。遇到这种情况可以通过指定 Cluster IP`spec.clusterIP`)的值为 `"None"` 来创建 `Headless` Service。
这个选项允许开发人员自由寻找他们自己的方式,从而降低与 Kubernetes 系统的耦合性。
应用仍然可以使用一种自注册的模式和适配器,对其它需要发现机制的系统能够很容易地基于这个 API 来构建。
这个选项允许开发人员自由寻找他们自己的方式,从而降低与 Kubernetes 系统的耦合性。应用仍然可以使用一种自注册的模式和适配器,对其它需要发现机制的系统能够很容易地基于这个 API 来构建。
对这类 `Service` 并不会分配 Cluster IPkube-proxy 不会处理它们,而且平台也不会为它们进行负载均衡和路由。
DNS 如何实现自动配置,依赖于 `Service` 是否定义了 selector。
对这类 `Service` 并不会分配 Cluster IPkube-proxy 不会处理它们而且平台也不会为它们进行负载均衡和路由。DNS 如何实现自动配置,依赖于 `Service` 是否定义了 selector。
### 配置 Selector
@ -297,8 +280,7 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service默认
### LoadBalancer 类型
使用支持外部负载均衡器的云提供商的服务,设置 `type` 的值为 `"LoadBalancer"`,将为 `Service` 提供负载均衡器。
负载均衡器是异步创建的,关于被提供的负载均衡器的信息将会通过 `Service``status.loadBalancer` 字段被发布出去。
使用支持外部负载均衡器的云提供商的服务,设置 `type` 的值为 `"LoadBalancer"`,将为 `Service` 提供负载均衡器。负载均衡器是异步创建的,关于被提供的负载均衡器的信息将会通过 `Service``status.loadBalancer` 字段被发布出去。
```yaml
kind: Service
@ -323,7 +305,9 @@ status:
```
来自外部负载均衡器的流量将直接打到 backend `Pod` 上,不过实际它们是如何工作的,这要依赖于云提供商。
在这些情况下,将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。
某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`,将会给负载均衡器指派一个临时 IP。
如果设置了 `loadBalancerIP`,但云提供商并不支持这种特性,那么设置的 `loadBalancerIP` 值将会被忽略掉。
### AWS 内部负载均衡器
@ -343,7 +327,7 @@ metadata:
### AWS SSL 支持
对运行在 AWS 上部分支持 SSL 的集群,从 1.3 版本开始,可以为 `LoadBalancer` 类型的 `Service` 增加两个 annotation
```
```yaml
metadata:
name: my-service
annotations:
@ -359,6 +343,7 @@ metadata:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
```
第二个 annotation 指定了 `Pod` 使用的协议。
对于 HTTPS 和 SSLELB 将期望该 `Pod` 基于加密的连接来认证自身。
HTTP 和 HTTPS 将选择7层代理ELB 将中断与用户的连接,当转发请求时,会解析 Header 信息并添加上用户的 IP 地址(`Pod` 将只能在连接的另一端看到该 IP 地址)。
@ -367,12 +352,9 @@ TCP 和 SSL 将选择4层代理ELB 将转发流量,并不修改 Header 信
### 外部 IP
如果外部的 IP 路由到集群中一个或多个 Node 上Kubernetes `Service` 会被暴露给这些 `externalIPs`
通过外部 IP作为目的 IP 地址)进入到集群,打到 `Service` 的端口上的流量,将会被路由到 `Service` 的 Endpoint 上。
`externalIPs` 不会被 Kubernetes 管理,它属于集群管理员的职责范畴。
如果外部的 IP 路由到集群中一个或多个 Node 上Kubernetes `Service` 会被暴露给这些 `externalIPs`。通过外部 IP作为目的 IP 地址)进入到集群,打到 `Service` 的端口上的流量,将会被路由到 `Service` 的 Endpoint 上。`externalIPs` 不会被 Kubernetes 管理,它属于集群管理员的职责范畴。
根据 `Service` 的规定,`externalIPs` 可以同任意的 `ServiceType` 来一起指定。
在下面的例子中,`my-service` 可以在 80.11.12.10:80外部 IP:端口)上被客户端访问。
根据 `Service` 的规定,`externalIPs` 可以同任意的 `ServiceType` 来一起指定。在下面的例子中,`my-service` 可以在 `80.11.12.10:80`(外部 IP:端口)上被客户端访问。
```yaml
kind: Service
@ -393,20 +375,15 @@ spec:
## 不足之处
为 VIP 使用 userspace 代理,将只适合小型到中型规模的集群,不能够扩展到上千 `Service` 的大型集群。
查看 [最初设计方案](http://issue.k8s.io/1107) 获取更多细节。
为 VIP 使用 userspace 代理,将只适合小型到中型规模的集群,不能够扩展到上千 `Service` 的大型集群。查看 [最初设计方案](http://issue.k8s.io/1107) 获取更多细节。
使用 userspace 代理,隐藏了访问 `Service` 的数据包的源 IP 地址。
这使得一些类型的防火墙无法起作用。
iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址,但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
使用 userspace 代理,隐藏了访问 `Service` 的数据包的源 IP 地址。这使得一些类型的防火墙无法起作用。iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址,但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
`Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
不会严格要求所有云提供商例如GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`,但是 AWS 需要 ),但当前 API 是强制要求的。
`Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。不会严格要求所有云提供商例如GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`,但是 AWS 需要 ),但当前 API 是强制要求的。
## 未来工作
未来我们能预见到,代理策略可能会变得比简单的 round-robin 均衡策略有更多细微的差别,比如 master 选举或分片。
我们也能想到,某些 `Service` 将具有 “真正” 的负载均衡器,这种情况下 VIP 将简化数据包的传输。
未来我们能预见到,代理策略可能会变得比简单的 round-robin 均衡策略有更多细微的差别,比如 master 选举或分片。我们也能想到,某些 `Service` 将具有 “真正” 的负载均衡器,这种情况下 VIP 将简化数据包的传输。
我们打算为 L7HTTP`Service` 改进我们对它的支持。
@ -414,51 +391,41 @@ iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址,但却要求
## VIP 的那些骇人听闻的细节
对很多想使用 `Service` 的人来说,前面的信息应该足够了。
然而,有很多内部原理性的内容,还是值去理解的。
对很多想使用 `Service` 的人来说,前面的信息应该足够了。然而,有很多内部原理性的内容,还是值去理解的。
### 避免冲突
Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。
这种场景下,让我们来看一下网络端口 —— 用户不应该必须选择一个端口号,而且该端口还有可能与其他用户的冲突。
这就是说,在彼此隔离状态下仍然会出现失败。
Kubernetes 最主要的哲学之一,是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。这种场景下,让我们来看一下网络端口 —— 用户不应该必须选择一个端口号,而且该端口还有可能与其他用户的冲突。这就是说,在彼此隔离状态下仍然会出现失败。
为了使用户能够为他们的 `Service` 选择一个端口号我们必须确保不能有2个 `Service` 发生冲突。
我们可以通过为每个 `Service` 分配它们自己的 IP 地址来实现。
为了使用户能够为他们的 `Service` 选择一个端口号我们必须确保不能有2个 `Service` 发生冲突。我们可以通过为每个 `Service` 分配它们自己的 IP 地址来实现。
为了保证每个 `Service` 被分配到一个唯一的 IP需要一个内部的分配器能够原子地更新 etcd 中的一个全局分配映射表,这个更新操作要先于创建每一个 `Service`
为了使 `Service` 能够获取到 IP这个映射表对象必须在注册中心存在否则创建 `Service` 将会失败,指示一个 IP 不能被分配。
一个后台 Controller 的职责是创建映射表(从 Kubernetes 的旧版本迁移过来,旧版本中是通过在内存中加锁的方式实现),并检查由于管理员干预和清除任意 IP 造成的不合理分配,这些 IP 被分配了但当前没有 `Service` 使用它们。
### IP 和 VIP
不像 `Pod` 的 IP 地址,它实际路由到一个固定的目的地,`Service` 的 IP 实际上不能通过单个主机来进行应答。
相反,我们使用 `iptables`Linux 中的数据包处理逻辑来定义一个虚拟IP地址VIP它可以根据需要透明地进行重定向。
当客户端连接到 VIP 时,它们的流量会自动地传输到一个合适的 Endpoint。
环境变量和 DNS实际上会根据 `Service` 的 VIP 和端口来进行填充。
不像 `Pod` 的 IP 地址,它实际路由到一个固定的目的地,`Service` 的 IP 实际上不能通过单个主机来进行应答。相反,我们使用 `iptables`Linux 中的数据包处理逻辑来定义一个虚拟IP地址VIP它可以根据需要透明地进行重定向。当客户端连接到 VIP 时,它们的流量会自动地传输到一个合适的 Endpoint。环境变量和 DNS实际上会根据 `Service` 的 VIP 和端口来进行填充。
#### Userspace
作为一个例子,考虑前面提到的图片处理应用程序。
当创建 backend `Service`Kubernetes master 会给它指派一个虚拟 IP 地址,比如 10.0.0.1。
假设 `Service` 的端口是 1234`Service` 会被集群中所有的 `kube-proxy` 实例观察到。
当代理看到一个新的 `Service` 它会打开一个新的端口,建立一个从该 VIP 重定向到新端口的 iptables并开始接收请求连接。
当一个客户端连接到一个 VIPiptables 规则开始起作用,它会重定向该数据包到 `Service代理` 的端口。
`Service代理` 选择一个 backend并将客户端的流量代理到 backend 上。
当创建 backend `Service`Kubernetes master 会给它指派一个虚拟 IP 地址,比如 10.0.0.1。假设 `Service` 的端口是 1234`Service` 会被集群中所有的 `kube-proxy` 实例观察到。当代理看到一个新的 `Service` 它会打开一个新的端口,建立一个从该 VIP 重定向到新端口的 iptables并开始接收请求连接。
这意味着 `Service` 的所有者能够选择任何他们想使用的端口,而不存在冲突的风险。
客户端可以简单地连接到一个 IP 和端口,而不需要知道实际访问了哪些 `Pod`
当一个客户端连接到一个 VIPiptables 规则开始起作用,它会重定向该数据包到 `Service代理` 的端口。`Service代理` 选择一个 backend并将客户端的流量代理到 backend 上。
这意味着 `Service` 的所有者能够选择任何他们想使用的端口,而不存在冲突的风险。客户端可以简单地连接到一个 IP 和端口,而不需要知道实际访问了哪些 `Pod`
#### Iptables
再次考虑前面提到的图片处理应用程序。
当创建 backend `Service`Kubernetes master 会给它指派一个虚拟 IP 地址,比如 10.0.0.1。
假设 `Service` 的端口是 1234`Service` 会被集群中所有的 `kube-proxy` 实例观察到。
当代理看到一个新的 `Service` 它会安装一系列的 iptables 规则,从 VIP 重定向到 per-`Service` 规则。
该 per-`Service` 规则连接到 per-`Endpoint` 规则,该 per-`Endpoint` 规则会重定向(目标 NAT到 backend。
当创建 backend `Service`Kubernetes master 会给它指派一个虚拟 IP 地址,比如 10.0.0.1。假设 `Service` 的端口是 1234`Service` 会被集群中所有的 `kube-proxy` 实例观察到。当代理看到一个新的 `Service` 它会安装一系列的 iptables 规则,从 VIP 重定向到 per-`Service` 规则。该 per-`Service` 规则连接到 per-`Endpoint` 规则,该 per-`Endpoint` 规则会重定向(目标 NAT到 backend。
当一个客户端连接到一个 VIPiptables 规则开始起作用。一个 backend 会被选择(或者根据会话亲和性,或者随机),数据包被重定向到这个 backend。
不像 userspace 代理数据包从来不拷贝到用户空间kube-proxy 不是必须为该 VIP 工作而运行,并且客户端 IP 是不可更改的。
当流量打到 Node 的端口上,或通过负载均衡器,会执行相同的基本流程,但是在那些案例中客户端 IP 是可以更改的。