Traefik Patching Example
This document covers a high level patching example for Traefik.
Traefik should be patched per environment because it is crucial for providing network access to our applications.
It is important to understand what changes are in the version upgrade, especially if there are any breaking changes.
Usually, there will be a renovate pull request in the flux repo that will contain release notes that show you the breaking changes.
For this example concerning Traefik, the latest version was 26.0.0 and our existing version was 23.1.0.
The breaking changes in the pull request were reviewed and the traefik-helm-chart/releases page was cross checked.
This was necessary to ensure there were no ill effects from the upgrade.
For example, in v25 there was a change in the syntax for the use of “redirectTo”.
After searching GitHub for redirectTo we found that we were not using this feature in our configuration so there was no impact.
If you are unsure whether a breaking change will affect us or our application teams, shout out on your standup or send a message on slack to #platform-operations.
Check existing configuration
In SDS, check traefik pods are running
kubectl get pods -n admin | grep traefik
Ensure Toffee application is accessible.
Note: check Plum application for CFT.
Updating - start with sandbox
In order to allow patching of sbox only, a new directory was created for the updated crd URLs.
apps/admin/traefik-crds-upgrade-v26/kustomization.yaml
&
apps/admin/traefik-crds-upgrade-v26/kustomize.yaml
See example PR containing these files
This enables us to target specific environments at this new crd version.
We can do this by pointing the desired cluster at this new directory via a patch in the base kustomization file.
Eg: clusters/sbox/base/kustomization.yaml
With the new crds version now available, a version selector block can be added to the sbox 00 & 01 config
Example:
chart:
spec:
chart: traefik
# update the crd version in traefik-crds when updating this
version: 26.0.0
sourceRef:
kind: HelmRepository
name: traefik
namespace: admin
Update the cluster kustomization file pointing to the new crd directory created earlier.
Raise a pull request to upgrade the version.
See Example PR
There are checks that take place when you raise a PR to validate the kustomization is valid.
These can be found in the tests folder
Review the pipeline checks for errors. If there are no errors and the PR has been approved, merge the PR.
Checks to see if upgrade worked correctly
Check the pods have come back up:
kubectl get pods -n admin | grep traefik
The uptime should be fairly recent, i.e., the pods should have been redeployed in the last few minutes.
Check pods have the correct chart version:
kubectl describe pod {pod-name} -n admin | grep helm.sh/chart=traefik
Also, you can check on the Helm release to see if it has got correct version in the log.
kubectl get hr -n admin
Review pods for any new errors:
kubectl logs {pod-name} -n admin -f
Traefik does have a UI but it’s not usually exposed.
However, you should be able to reach other applications on the cluster such as plum or toffee that rely on traefik being operational.
Ensure Toffee application is accessible on SDS.
Check Plum application on CFT.
You could also delete the Toffee or Plum HRs to make sure they come back up and they are reachable via Traefik.
The example commands below are for SDS using toffee:
kubectl get hr -n toffee
kubectl delete hr toffee-recipe-backend -n toffee
kubectl delete hr toffee-frontend -n toffee
Ensure to monitor the status for the HRs and pods to ensure they come back successfully.
Repeat steps in CFT
Non-prod environments
Now you’ve completed sandbox, move onto the nonprod environments.
Prod environments
You will want to test the PTL environments on their own before upgrading prod as this cluster hosts Jenkins, Start with SDS then move onto CFT.
PR examples:
For Prod you want to remove the previous patches you did for the other environments and just update the application yaml file see the examples below: