Home > Blockchain >  How to point K8s load balancer to pods in a different namespace
How to point K8s load balancer to pods in a different namespace

Time:12-03

I have an ingress pod deployed with Scaleway on a Kubernetes cluster and it exists in the kube-system namespace. I accidentally created a load balancer service on the default namespace and I don't want to delete and recreate it a new one on the kube-system namespace so I want my Load balancer in the default namespace to have the ingress pods as endpoints:

apiVersion: v1
kind: Service
metadata:
  name: ecom-loadbalancer
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - port: 443
      targetPort: 443
  type: LoadBalancer

Is that possible? Is there something I should add in the selector fields?


I tried creating a clusterIP service in the kube-system namespace that communicates with the ingress pods, it worked.

apiVersion: v1
kind: Service
metadata:
  name: ecom-loadbalancer
  namespace: kube-system
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - port: 443
      targetPort: 443
  type: ClusterIP

Then, I tried referencing that service to my loadbalancer in the default namespace like that:

apiVersion: v1
kind: Service
metadata:
  name: ecom-loadbalancer
spec:
  type: ExternalName
  externalName: ecom-loadbalancer.kube-system.svc.cluster.local
  ports:
    - port: 443
      targetPort: 443
  type: LoadBalancer

But no result. The clusterIP points to the Ingress pods, but the load balancer remains without endpoints.

CodePudding user response:

At least three reasons why you need to re-create it properly (2 technical and advice):

  1. ExternalName is used for accessing external services or services in other namespaces. The way it works is when looking up the service's name happens, CNAME will be returned. So in other words it works for egress connections when requests should be directed somewhere else.

    See service - externalname type and use cases Kubernetes Tips - Part 1 blog post from Alen Komljen.

    Your use case is different. You want to get requests from outside the kubernetes cluster to exposed loadbalancer and then direct traffic from it to another service within the cluster. It's not possible by built-in kubernetes terms, because service can be either LoadBalancer or ExternalName. You can see in your last manifest there are two types which will not work at all. See service types.

  2. Avoid unnecessary complexity. It will be hard to keep track of everything since there will be more and more services and other parts.

  3. Based on documentation it's generally possible to have issues using ExternalName with some protocols:

    Warning: You may have trouble using ExternalName for some common protocols, including HTTP and HTTPS. If you use ExternalName then the hostname used by clients inside your cluster is different from the name that the ExternalName references.

    For protocols that use hostnames this difference may lead to errors or unexpected responses. HTTP requests will have a Host: header that the origin server does not recognize; TLS servers will not be able to provide a certificate matching the hostname that the client connected to.

    Reference - Warning

  • Related