Service/Ingress FAQ

最近更新时间：2023-11-10 17:39:24
我的收藏
本页目录：

如何判断更新配置后是否成功下发？
您可以先查看资源的 Event 信息，然后根据资源同步的返回码或错误码来判断资源同步是否遇到问题。如果返回码或错误码表明同步失败，您可以参考 Service&Ingress 常见报错和处理 进一步查看错误信息并采取相应的措施来解决问题。
负载均衡监听器上没有绑定任何后端，应该怎么排查问题？
您可以根据接入方式分情况进行排查：
通过 NodePort 接入：
检查 Service 是否使用了后端选择能力，导致没有节点匹配上。
检查 Node 是否配置了 node.kubernetes.io/exclude-from-external-load-balancers 注解，声明节点不被用作外部流量接入。
检查 Service 是否开启了 Local 绑定的能力，或是 Ingress 引用了 Local 模式的 Service，同时没有健康的工作负载。
检查 Ingress，注意检查 Service 类型是否为 ClusterIP，ClusterIP 类型的 Service 不能作为 Ingress 后端使用。
用户是一个独立集群，只包含 Master 节点，默认 Master 节点不会作为后端承接入口流量。如果用户不添加普通节点，将会导致没有可用的后端节点，从而无法访问集群中的应用程序。
通过直连方式接入：
检查工作负载是否采用了 HostNetwork 网络。
Ingress 注意检查 Service 是否存在，指定的 Service 端口是否存在。
Service 注意检查 Endpoint 是否为空，以此来判断 Service 的 LabelSelector 是否出现错误。
Pod 滚动更新卡住，Pod Status 中显示 cloud.tencent.com/load-balancer-backendgroup-ready 不能更新到正常状态，如何排查问题？
您可以按照以下流程进行排查：
1. 根据失败的工作负载 Pod，查询 Status 中的 Condition Message。目前 Pod 的 Condition 信息中会包含健康检查失败的负载均衡实例以及监听器等信息。
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-12-14T07:54:33Z"
    message: readinessGate cloud.tencent.com/load-balancer-backendgroup-ready is False, Readiness check failed according to l4 listener: lbl-ro8ixxxx UDP:21000) of CLB lb-qvnrxxxx. Service: ns-production/gz3-service
    reason: LoadBalancerNetworkGroupNotReady
    status: "False"
    type: cloud.tencent.com/load-balancer-backendgroup-ready
例如上面这个 Case，我们就可以关注到 Pod 关联的 Service(ns-production/gz3-service)，流量接入不正确，Pod 没有绑定到 lb-qvnrxxxx 或是健康检查不通过。
2. 确认后端是否正确绑定了负载均衡上。
2.1 用户负载均衡绑定数量达到上限，导致工作负载没有绑定到 CLB 上，健康检查不通过。（默认 CLB 后端上限为200）
2.2 用户工作负载使用了 HostNetwork 的网络模式，或非弹性网卡网络模式。工作负载的网络模式不支持直连，导致没有绑定为后端。
2.3 查询 Service(ns-production/gz3-service) 同步的其他错误信息，解决配置错误等原因导致后端未绑定问题。
# 以下命令都可以查询到Event信息
kubectl describe service -n ns-production gz3-service
kubectl get event -n ns-production | grep gz3-service
3. 当后端已经绑定在负载均衡时：
3.1 在负载均衡控制台，确认监听器下的 Pod 的健康状态是否正常。当负载均衡健康检查失败时，可以通过请求后端服务，判断后端服务是否可用。（根据 CLB 运营平台上查询到的健康检查配置进行请求）
		curl -H "Host: gz3.service.com" -X HEAD "9.148.100.100:80/checkServiceStatus"
		curl -H "Host: gz3.service.com" -X GET "9.148.100.100:80/checkServiceStatus"
3.2 确认 Pod 所在的子机的安全组是否有拦截，Pod 所在的子网的 ACL 是否有拦截，在 CLB 控制台可以针对后端进行连通性探测。
开启直连之后，Pod 的请求来源被改成了节点 IP，应该怎么解决？
您可以注意检查 IpMasq 配置，避免来自负载均衡的直连请求被进行 IP 伪装。这个问题会影响 GlobalRoute 直连和 RouteENI 弹性网络直连。
当前通过 NodePort 转发的工作负载，可以直接更新成直连 Pod 吗？
可以，您可以通过控制台表单或者修改资源注解的方式，直接将流量转发的方式切换成直连。
需要注意以下几点：
1. 直连转发相较于 NodePort 转发，会避免流量进行 FullNAT，而直接从负载均衡转发到 Pod 的网卡。这个区别会导致来源 IP、会话保持等特性出现一些区别。
2. 当用户 NodePort 切换成直连时，组件会优先绑定新的直连后端，然后删除原有的 NodePort 后端，不会造成断流。但是要注意集群的规模，如果用户 NodePort 的数量已经达到或超过 CLB 的后端限制（默认为200），那么就只能先删除原有的绑定后端再绑定，可能会出现短时间的断流。
相关文档：
1. 直连功能介绍与使用文档：使用 LoadBalancer 直连 Pod 模式 Service﻿
2. NodePort 转发示意图：Service 后端选择﻿
集群节点超200了，导致负载均衡上有的节点没有绑定，会有问题吗？
如果是部分节点没有绑定，不会存在问题。负载均衡监听器后端数量默认限制200个。区分以下两种接入方式来理解这个问题。
NodePort 接入。
默认的接入方式。当用户发现负载均衡上绑定的是节点，并且端口是 Service 上的 NodePort 端口时，基本可以确认您使用的是该接入方式。
每一个节点上的 NodePort 都会收到来自负载均衡的流量，然后随机转发给工作负载。所以并不一定需要绑定集群所有节点。
直连接入。
弹性网卡网络常见的接入方式。当用户发现负载均衡上绑定的是 Pod 的 IP 和服务端口时，基本可以确认您使用的是该接入方式。
绕过了 NodePort 转发，负载均衡会直接将流量转发到工作负载上，这就需要 Pod 全部绑定在负载均衡后端。
再考虑到滚动更新会导致副本数量有额外增加，用户需要保证工作负载最大的副本数小于200（例如工作负载副本数150个，每批滚动最多新增工作负载50个）。如果业务需要工作负载的规模需要超过这个值，需要及时通过 工单 方式联系客服为您开通白名单。
相关文档：
1. Kubernetes Service NodePort：https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport﻿
2. 直连功能介绍与使用文档：使用 LoadBalancer 直连 Pod 模式 Service﻿
﻿