Usando AWS re:Post, accetti AWS re:Post Termini di utilizzo

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.

posta un anno fa558 visualizzazioni
1 Risposta
1
Risposta accettata

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.

con risposta un anno fa
  • 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.

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande