使用AWS re:Post即您表示您同意 AWS re:Post 使用条款

Why the Target group is empty when I create a NLB point to a custom end-point

0

I am creating a pod, and together in the same helm package, I have a service NLB pointing to an endpoint object, which is not the same IP as from the pod. I am able to execute the command helm install, I can see the pod is up, the NLB gets created, and the endpoint gets created, however, the target group used in the NLB has no registered target.

If I execute it in two steps, first the POD and later the service with the endpoint, it will work as should.

已提问 1 年前558 查看次数
1 回答
1
已接受的回答

When you create a Kubernetes Service of type 'LoadBalancer', the Network Load Balancer (NLB) is provisioned and assigned an external IP address. The NLB forwards traffic to the backend Pods based on the rules defined in the Service.

In this case, a custom endpoint object that has a different IP address from the Pod is being used. This custom endpoint is likely a separate resource in your cluster that is not directly associated with the pods

When you install the Helm chart in a single step, which includes both the Pod and the Service with the endpoint, it's possible that the NLB starts directing traffic to the Pod before the custom endpoint is fully ready and registered as a target.

However, when you install them in two steps, first the Pod and then the Service with the endpoint, it provides more time for the custom endpoint to become fully available and registered as a target in the target group of the NLB.

To ensure that the custom endpoint is registered as a target before traffic is directed to the Pods, you can try the following approaches:

Add readiness probes to your Pod: By specifying a readiness probe in the Pod's configuration, you can delay the Pod's readiness until the custom endpoint is fully available. This will prevent traffic from being directed to the Pod before the endpoint is ready [1].

Use an initializer or a sidecar container: You can create an initializer or a sidecar container that waits for the custom endpoint to become available before allowing traffic to the Pod. The initializer/sidecar can periodically check the readiness of the endpoint and update a status that the Pod's readiness probe can monitor.

Use an operator or a custom controller: You can develop a custom operator or controller that ensures the proper synchronization between the Pod, the custom endpoint, and the Service with the NLB. The operator/controller can handle the ordering and dependencies between the resources to ensure that the NLB only starts directing traffic once the endpoint is registered.

By employing one of these approaches, you can ensure that the custom endpoint is fully registered as a target before traffic is directed to the Pods, even when deploying everything in a single step using Helm.

已回答 1 年前
  • Thank you for sharing those strategies. The sidecar container works. However, I implement it in a different way, here is how: when I am creating the endpoint, I am adding targetRef to the POD like this:

    apiVersion: v1 kind: Endpoints metadata: name: vrouter-service-load-balance subsets:

    • addresses:
      • ip: 10.0.4.12 targetRef: kind: Pod name: my-pod-xrd-0

    It worked like a charm. Thanks again for responding so fast.

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则