Upgrading Kubernetes Ingress Rules and Adding TLS Certificates with Jenkins

It usually starts with a simple requirement: “We need HTTPS.” Then it quickly evolves into, “We also need to update routing rules without downtime.” If you're managing Kubernetes workloads with Jenkins, upgrading Ingress rules and adding TLS certificates becomes a repeatable, automatable task—but only if you wire things correctly.

Let’s walk through how to evolve your Ingress setup safely while integrating TLS using a Jenkins pipeline.

Where things typically break

A common mistake developers make is manually editing Ingress resources in production clusters. This leads to:

• Configuration drift
• Broken TLS setups
• Downtime during rule changes

The goal is to move all of this into version-controlled, automated pipelines.

A quick look at a basic Ingress (before upgrade)

Here’s a minimal Ingress definition without TLS:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  rules:
7  - host: example.com
8    http:
9      paths:
10      - path: /
11        pathType: Prefix
12        backend:
13          service:
14            name: app-service
15            port:
16              number: 80
17

This works—but it's HTTP-only and limited in flexibility.

Upgrading Ingress rules

Let’s say you want to:

• Add a new route
• Split traffic between services
• Prepare for TLS

Here’s an upgraded version:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    nginx.ingress.kubernetes.io/rewrite-target: /
7spec:
8  rules:
9  - host: example.com
10    http:
11      paths:
12      - path: /api
13        pathType: Prefix
14        backend:
15          service:
16            name: api-service
17            port:
18              number: 80
19      - path: /
20        pathType: Prefix
21        backend:
22          service:
23            name: frontend-service
24            port:
25              number: 80
26

This upgrade introduces routing flexibility. But we’re still missing HTTPS.

Adding TLS certificates

To enable HTTPS, you need two things:

• A TLS certificate (manually created or via cert-manager)
• A reference to that certificate in your Ingress

Here’s what the Ingress looks like with TLS:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  tls:
7  - hosts:
8    - example.com
9    secretName: example-tls
10  rules:
11  - host: example.com
12    http:
13      paths:
14      - path: /
15        pathType: Prefix
16        backend:
17          service:
18            name: app-service
19            port:
20              number: 80
21

The secretName points to a Kubernetes Secret containing your certificate.

Using cert-manager (recommended)

Instead of manually handling certificates, cert-manager automates issuance and renewal.

1apiVersion: cert-manager.io/v1
2kind: Certificate
3metadata:
4  name: example-cert
5spec:
6  secretName: example-tls
7  issuerRef:
8    name: letsencrypt-prod
9    kind: ClusterIssuer
10  commonName: example.com
11  dnsNames:
12  - example.com
13

Once applied, cert-manager handles the rest.

Automating everything with Jenkins

Here’s where Jenkins ties it all together. Instead of applying YAML manually, you push changes and let the pipeline handle deployment.

Example Jenkinsfile

1pipeline {
2  agent any
3
4  environment {
5    KUBECONFIG = credentials('kubeconfig')
6  }
7
8  stages {
9    stage('Checkout') {
10      steps {
11        git 'https://github.com/your-repo/k8s-configs.git'
12      }
13    }
14
15    stage('Validate Manifests') {
16      steps {
17        sh 'kubectl apply --dry-run=client -f ingress.yaml'
18      }
19    }
20
21    stage('Deploy Ingress') {
22      steps {
23        sh 'kubectl apply -f ingress.yaml'
24      }
25    }
26
27    stage('Verify Deployment') {
28      steps {
29        sh 'kubectl get ingress app-ingress'
30      }
31    }
32  }
33}
34

This pipeline ensures:

• Ingress updates are validated before deployment
• Changes are applied consistently
• TLS configuration is version-controlled

Zero-downtime upgrades

Ingress updates are generally safe, but there are a few nuances:

• Use rolling updates for backend services
• Avoid deleting and recreating Ingress—always use kubectl apply
• Test TLS separately before switching traffic

If you're changing hosts or certificates, DNS propagation can introduce delays—plan for that.

Debugging common issues

When something goes wrong, it's usually one of these:

• Certificate not found
  Check if the secret exists:
  TEXT

  Copy

  1kubectl get secret example-tls

• Ingress not picking up TLS
  Verify annotations and controller logs
• HTTPS redirect loops
  Check ingress annotations like:
  TEXT

  Copy

  1nginx.ingress.kubernetes.io/ssl-redirect: "true"

A subtle but important detail

Ingress controllers (like NGINX) behave differently depending on annotations. When upgrading rules and adding TLS together, test incrementally:

1. Apply routing changes first
2. Verify traffic flow
3. Add TLS configuration
4. Validate HTTPS endpoints

Bundling everything into a single change increases the blast radius if something breaks.

When Jenkins really shines

Once this pipeline is in place, you can:

• Promote Ingress configs across environments
• Automate certificate renewals indirectly via cert-manager
• Track every change through version control

That’s the shift—from “editing configs” to “shipping infrastructure.”

If your Ingress changes aren’t going through CI/CD, they’re probably going to bite you later.

Upgrading Ingress rules and adding TLS certificates doesn’t have to be risky. With Jenkins orchestrating deployments and cert-manager handling certificates, you get a setup that’s both secure and maintainable.