kubernetes - configure haproxy ingress on k8s v19 for jenkins application on Redhat Linux 7.9 server

Question

I am deploying the Jenkins application using k8s v19 on Redhat 7.9 machine.I could able to connect to an application URL with port number(jenkins-test-ci.xyz.com:32419(node port).) but not able to log in via jenkins-test-ci.xyz.com.

I have configured Nodeport service and Ingress rule as below

---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: jenkins-test-svc
  name: jenkins-test-svc
  namespace: ci-cd
spec:
  type: NodePort
  ports:
    - name: webui
      port: 8080
      protocol: TCP
      targetPort: 8080
    - name: jnlp
      port: 50000
      protocol: TCP
      targetPort: 50000
  selector:
    app: jenkins-test
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jenkins-test
  namespace: ci-cd
spec:
  tls:
  - hosts:
    - jenkins-test-ci.xyz.com
    secretName: qa-pss-ci
  rules:
  - host: jenkins-test-ci.xyz.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: jenkins-test-svc
            port:
              number: 8080

[root@xyz deployments]# kubectl logs haproxy-ingress-snkjc -n ingress-controller

I0105 09:13:06.968207       6 launch.go:142]
Name:       HAProxy
Release:    v0.7.1
Build:      git-5dc0d6f
Repository: https://github.com/jcmoraisjr/haproxy-ingress
I0105 09:13:06.968268       6 launch.go:145] Watching for ingress class: haproxy
I0105 09:13:06.969008       6 launch.go:345] Creating API client for https://x.x.x.x:443
I0105 09:13:06.977711       6 launch.go:357] Running in Kubernetes Cluster version v1.19 (v1.19.6) - git (clean) commit fbf646b339dc52336b55d8ec85c181981b86331a - platform linux/amd64
I0105 09:13:06.979849       6 launch.go:169] validated ingress-controller/ingress-default-backend as the default backend
I0105 09:13:06.984382       6 controller.go:1496] starting Ingress controller
I0105 09:13:06.992673       6 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ci-cd", Name:"jenkins-test", UID:"b06bb11c-427c-4fe6-a543-8f6d1705237c", APIVersion:"extensions", ResourceVersion:"1230711", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress ci-cd/jenkins-test
I0105 09:13:12.322064       6 controller.go:1504] running initial sync of secrets
I0105 09:13:12.323590       6 backend_ssl.go:71] adding secret ci-cd/qa-pss-ci to the local store
I0105 09:13:12.323760       6 leaderelection.go:174] attempting to acquire leader lease...
W0105 09:13:12.325376       6 controller.go:521] service ingress-controller/ingress-default-backend does not have any active endpoints
I0105 09:13:12.325579       6 controller.go:332] backend reload required
I0105 09:13:12.330463       6 leaderelection.go:184] successfully acquired lease ingress-controller/ingress-controller-leader-haproxy
I0105 09:13:12.330511       6 status.go:199] new leader elected: haproxy-ingress-snkjc
I0105 09:13:12.358898       6 controller.go:341] ingress backend successfully reloaded...
I0105 09:13:16.360882       6 controller.go:332] backend reload required
I0105 09:13:16.394526       6 controller.go:341] ingress backend successfully reloaded...

Please suggest to fix this issue.Thank you

Answer 1

Without additional information regarding (like i the actual setup of your HAProxy Ingress controller it could be hard to pinpoint the actual issue.

There are conflicting information in your question related to the provisioning of your HAProxy Ingress Controller:

• Logs from your question are pointing to:
  • Github.com: Jcmoraisjr: Haproxy-ingress
• A comment that you made is pointing to:
  • Github.com: Haproxytech: Kubernetes-ingress

---

The most probable cause that you are getting connection refused is that the Service of your HAProxy Ingress Controller is configured in a way that doesn't allow you to just hit the: http://jenkins-test-ci.xyz.com (port 80).

Assuming that you followed the documentation (either one), both solutions use Service of type NodePort to allow the inbound traffic to hit the controller. This is inherently forcing your Ingress resources to be available on node_ip:nodeport (nodeport port range: 30000-32767):

You can check how your Ingress controller is exposed by running:

• $ kubectl get svc -n NAMESPACE

The output of above command should be similar to:

NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                     AGE
haproxy-ingress           NodePort    10.233.39.4     <none>        80:32149/TCP,443:30011/TCP,1024:31532/TCP   3h56m
ingress-default-backend   ClusterIP   10.233.18.215   <none>        8080/TCP                                    3h56m

Following this example if you have an app exposed with an Ingress resource and you would like to connect to it, you would need to connect to node_ip:32149 (see the ports on the haproxy-ingress).

To be able to expose your Jenkins on ports like 80 and/or 443 with an Ingress resource you will need to use Service of type LoadBalancer. The Service that is used to expose your HAProxy Ingress Controller will need to be changed from NodePort to LoadBalancer type.

This Service (LoadBalancer) will require you to "provide" an IP address that could be allocated for this specific reason. With provider managed Kubernetes solution like GKE, EKS or AKS this process is automated. For solutions that are on premise you will need to use MetalLB:

Kubernetes does not offer an implementation of network load-balancers (Services of type LoadBalancer) for bare metal clusters. The implementations of Network LB that Kubernetes does ship with are all glue code that calls out to various IaaS platforms (GCP, AWS, Azure…). If you’re not running on a supported IaaS platform (GCP, AWS, Azure…), LoadBalancers will remain in the “pending” state indefinitely when created.

Bare metal cluster operators are left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare metal clusters second class citizens in the Kubernetes ecosystem.

MetalLB aims to redress this imbalance by offering a Network LB implementation that integrates with standard network equipment, so that external services on bare metal clusters also “just work” as much as possible.

• Metallb.universe.tf (you can find in this link the configuration and usage examples)

---

Additional resources:

• Kubernetes.io: Docs: Concepts: Services networking: Service
• Banzaicloud.com: Blog: Load balancer services in on-prem environment