有奖捉虫:云通信与企业服务文档专题,速来> HOT

默认后端选择

默认情况下,Service 会配置负载均衡的后端到集群节点的 NodePort,如下图 TKE 接入层组件部分。此方案具有非常高的容错性,流量从负载均衡到任何一个 NodePort 之后,NodePort 会再一次随机选择一个 Pod 将流量转发过去。同时这也是 Kubernetes 官方提出的最基础的网络接入层方案。如下图所示:
A.png


TKE Service Controller 默认不会将以下节点作为负载均衡后端:
Master 节点(不允许 Master 节点参与网络接入层的负载)。
节点状态为 NotReady (节点不健康)。
注意
TKE Service Controller 可以绑定状态为 Unschedulable 的节点。Unschedulable 的节点也可以作为流量的入口,因为流量进入到节点之后,会再做一层容器网络里的流量转发,流量在 Unschedulable 的节点里面不会被丢弃,如上图所示。

指定接入层后端

对于一些规模很大的集群,Service 管理的负载均衡会挂载几乎所有集群节点的 NodePort 作为后端。此场景存在以下问题:
负载均衡的后端数量有数量限制。
负载均衡会对每一个 NodePort 进行健康检查,所有健康检查都会请求到后端的工作负载上。
此类问题可通过以下方式进行解决: 在一些大规模集群的场景中,用户可以通过 service.kubernetes.io/qcloud-loadbalancer-backends-label 指定一部分节点进行绑定。service.kubernetes.io/qcloud-loadbalancer-backends-label 的内容是一个标签选择器,用户可以通过在集群节点上标记 Label,然后在 Service 中通过该注解描述的标签选择器,选择匹配的节点进行绑定。这个同步会持续进行,当节点发生变化导致其被选择或是不再被选择时,Service Controller 会对应添加或删除负载均衡上的对应后端。详情请参见 Kubernetes 标签与选择器

注意事项

service.kubernetes.io/qcloud-loadbalancer-backends-label 的选择器没有选取到任何节点的时候,服务的后端将会被排空,会使得服务中断。使用此功能时,需要对集群节点的 Label 有一定的管理。
新增符合要求的节点或变更存量节点也会触发 controller 更新。

使用场景

大规模集群下的测试应用

在一个大规模集群下,部署一个仅包含一两个 Pod 的测试应用。通过 Service 进行服务暴露时,负载均衡将对所有的后端 NodePort 进行健康检查,此健康检查的请求量对测试应用有很大影响。此时可以在集群中通过 Label 指定一小部分节点作为后端,缓解健康检查带来的压力。详情请参见 关于健康检查探测频率过高的说明

示例

apiVersion: v1
kind: Service
metadata:
annotations:
service.kubernetes.io/qcloud-loadbalancer-backends-label: "group=access-layer"
name: nginx-service
spec:
ports:
- name: 80-80-no
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
该示例包含以下配置:
描述了一个公网类型负载均衡的服务暴露。
service.kubernetes.io/qcloud-loadbalancer-backends-label 注解声明了后端选择器,仅支持集群节点上有 group=access-layer Label 的节点才会作为这个负载均衡的后端。

Service Local 模式

Kubernetes 提供了 Service 特性 ExternalTrafficPolicy。当 ExternalTrafficPolicy 设置为 Local 时,可以避免流量通过 NAT 在节点间的转发,减少了 NAT 操作也使得源 IP 得到了保留。NodePort 仅会将流量转发到当前节点的 Pod。Local 模式特点如下:

优点:

避免了 NAT 与节点间转发带来的性能损失。
为服务端保留了请求来源 IP。

缺点:

没有工作负载的节点,NodePort 将无法提供服务。

注意事项

Service Local 模式本身就具有节点选择能力,所以:
请不要在 Service Local 模式下,使用指定接入层后端的能力。
请不要在 Service Local 模式下,在 Node 上使用 node.kubernetes.io/exclude-from-external-load-balancers Label驱逐后端节点。
负载均衡的同步是需要时间的。当 Local 类型的服务工作负载数量很少时,工作负载的飘移或滚动更新会很快。此时后端如未来得及同步,后端的服务可能会出现不可用的情况。
仅适用于处理低流量、低负载的业务,不建议在生产环境中使用。

示例:Service 开启 Local 转发(externalTrafficPolicy: Local)

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
externalTrafficPolicy: Local
ports:
- name: 80-80-no
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer

Local 默认后端选择

默认情况下,当 Service 开启 Local 模式之后,仍会按默认方式挂载几乎所有节点的 NodePort 作为后端。负载均衡会根据健康检查的结果,避免流量进入没有工作负载的后端节点。为了避免这些没有工作负载的后端被绑定,用户可以通过 service.kubernetes.io/local-svc-only-bind-node-with-pod: "true" 注解,在 Local 模式下指定绑定有工作负载节点作为后端。更多信息请参考 Kubernetes Service Local

示例:Service 开启 Local 转发并开启 Local 绑定

apiVersion: v1
kind: Service
metadata:
annotations:
service.kubernetes.io/local-svc-only-bind-node-with-pod: "true"
name: nginx-service
spec:
externalTrafficPolicy: Local
ports:
- name: 80-80-no
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
由于 Local 模式下,进入节点的请求流量不会在节点间转发。所以当节点上的工作负载数量不一致的时候,同样的后端权重可能会使得每一个节点上的负载不平均。此时用户可以通过 service.cloud.tencent.com/local-svc-weighted-balance: "true" 进行加权平衡。使用此注解时,NodePort 后端的权重将由节点上工作负载的数量决定,从而避免不同节点上工作负载数量不同带来的负载不均的问题。其中,Local 加权平衡必须和 Local 绑定同时使用。示例如下:

示例:Service 开启 Local 转发,并开启 Local 绑定与 Local 加权平衡

apiVersion: v1
kind: Service
metadata:
annotations:
service.kubernetes.io/local-svc-only-bind-node-with-pod: "true"
service.cloud.tencent.com/local-svc-weighted-balance: "true"
name: nginx-service
spec:
externalTrafficPolicy: Local
ports:
- name: 80-80-no
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer