Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Whe using an ALB Ingress in front of a ClusterIP gateway service, the controller doesn't pick the right Load Balancer Address #13806

Open
1 task done
aamattos opened this issue Oct 29, 2024 · 2 comments
Labels
area/ingress-controller Issues where Kong is running as a Kubernetes Ingress Controller area/kubernetes Issues where Kong is running on top of Kubernetes

Comments

@aamattos
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Kong version ($ kong version)

Kong 3.7

Current Behavior

Whe using an AWS ALB Ingress in front of a ClusterIP gateway service, the controller doesn't pick the right Load Balancer Address.
Instead of using the DNS of the ALB Load Balancer created by the ALB Ingress, It picks the internal IP of the Cluster IP service.
As a workaround I had to set (On a second step) the PUBLISH_STATUS_ADDRESS environment variable with the value of the ALB Load Balancer endpoint.

Expected Behavior

When using an Ingress in front of the gateway service (proxy.ingress.enabled = true) the controller should look at the ingress load balancer instead of the service's load balancer

Steps To Reproduce

Enable the proxy ingress and set the proxy type to Cluster IP
Add the proper ingress annotations to create an ALB.
Wait for Kong to reconcile the ingresses with type kong (or whatever ingress class you defined)

Anything else?

No response

@xianghai2 xianghai2 added area/kubernetes Issues where Kong is running on top of Kubernetes area/ingress-controller Issues where Kong is running as a Kubernetes Ingress Controller labels Nov 5, 2024
@randmonkey
Copy link
Contributor

randmonkey commented Nov 7, 2024

Can you dump the full status of your load balancer service by kubectl get service <lb-service> -n <service-namespace>? Kong Ingress Controller (KIC) will choose the first ingress IP of loadbalancer (status.loadBalancer.ingress.ip[0]) of the publish service as the IP of ingresses, if there are multiple ingress IPs in the LB service. KIC cannot detect which IP is actually used for traffic if there are many IPs attached to your LB service so it can only use the first one if not specified.

@randmonkey randmonkey added the pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... label Nov 8, 2024
@aamattos
Copy link
Author

this is the status of my Service:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/instance: kong-alb-internal
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: gateway
    app.kubernetes.io/version: "3.6"
    argocd.argoproj.io/instance: kong-prd
    enable-metrics: "true"
    helm.sh/chart: gateway-2.41.1
  name: kong-alb-internal-gateway-proxy
  namespace: kong
  resourceVersion: "3281033579"
  uid: 651b052f-028e-4862-8944-c964f16ad318
spec:
  clusterIP: 172.20.27.136
  clusterIPs:
  - 172.20.27.136
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: kong-proxy
    port: 80
    protocol: TCP
    targetPort: 8000
  selector:
    app.kubernetes.io/component: app
    app.kubernetes.io/instance: kong-alb-internal
    app.kubernetes.io/name: gateway
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

The problem is that the KIC is picking the service private IP (172.20.27.136) Instead of using the ALB Ingress address that's pointing to the ClusterIP Service

@xianghai2 xianghai2 removed the pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ingress-controller Issues where Kong is running as a Kubernetes Ingress Controller area/kubernetes Issues where Kong is running on top of Kubernetes
Projects
None yet
Development

No branches or pull requests

4 participants
@aamattos @xianghai2 @randmonkey and others