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年前562ビュー
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.

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

質問に答えるためのガイドライン

関連するコンテンツ