tencent cloud

容器服务

动态与公告
产品动态
公告
产品发布记录
产品简介
产品概述
产品优势
产品架构
应用场景
产品功能
基本概念
原生 Kubernetes 名词对照
容器服务高危操作
地域和可用区
开源组件
购买指南
购买指引
购买 TKE 标准集群
购买原生节点
购买超级节点
快速入门
新手指引
快速创建一个标准集群
入门示例
容器应用部署 Check List
集群配置
标准集群概述
集群管理
网络管理
存储管理
节点管理
GPU 资源管理
远程终端
应用配置
工作负载管理
服务和配置管理
组件和应用管理
弹性伸缩
容器登录方式
可观测配置
运维可观测性
成本洞察和优化
调度配置
调度组件概述
资源利用率优化调度
业务优先级保障调度
Qos 感知调度
安全和稳定性
容器服务安全组设置
身份验证和授权
应用安全
多集群管理
计划升级
备份中心
云原生服务指南
云原生 etcd
Prometheus 监控服务
TKE Serverless 集群指南
TKE 注册集群指南
实践教程
集群
Serverless 集群
调度
安全
服务部署
网络
发布
日志
监控
运维
Terraform
DevOps
弹性伸缩
容器化
微服务
成本管理
混合云
AI
故障处理
节点磁盘爆满排障处理
节点高负载排障处理
节点内存碎片化排障处理
集群 DNS 解析异常排障处理
集群 Kube-Proxy 异常排障处理
集群 API Server 网络无法访问排障处理
Service&Ingress 网络无法访问排障处理
Service&Ingress 常见报错和处理
Nginx Ingress 偶现 Connection Refused
CLB Ingress 创建报错排障处理
Pod 网络无法访问排查处理
Pod 状态异常与处理措施
授权腾讯云售后运维排障
CLB 回环问题
API 文档
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
常见问题
TKE 标准集群
TKE Serverless 集群
运维类
隐患处理
服务类
镜像仓库类
远程终端类
事件类
资源管理类
服务协议
TKE Service Level Agreement
TKE Serverless Service Level Agreement
联系我们
词汇表

Service 后端选择

PDF
聚焦模式
字号
最后更新时间: 2024-12-23 11:41:09

默认后端选择

默认情况下,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 将无法提供服务。

注意事项

负载均衡的同步是需要时间的。当 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


帮助和支持

本页内容是否解决了您的问题?

填写满意度调查问卷,共创更好文档体验。

文档反馈