如何判断更新配置后是否成功下发？
您可以先查看资源的 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-servicekubectl 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 模式 Service2. 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-nodeport2. 直连功能介绍与使用文档：使用 LoadBalancer 直连 Pod 模式 Service
容器服务官网1折活动，限时活动，即将结束，速速收藏
同尘科技为腾讯云授权服务中心。
购买腾讯云产品享受折上折，更有现金返利。同意关联立享优惠
转转请注明出处：https://www.yunxiaoer.com/148892.html
