|
| 1 | +--- |
| 2 | +title: Add-on compatibilities |
| 3 | +description: Keep your add-ons compatible with next Kubernetes version |
| 4 | +--- |
| 5 | + |
| 6 | +Ensuring add-on compatibility across different Kubernetes versions can be challenging as it requires careful planning, |
| 7 | +thorough testing, and continuous maintenance to address the evolving nature of Kubernetes and its ecosystem. |
| 8 | +Learn how Plural can assist you in that process. |
| 9 | + |
| 10 | +# Compatibility scraping |
| 11 | +Plural helps in ensuring that all known third-party add-ons are compatible with the next Kubernetes version |
| 12 | +by systematically scraping multiple sources for compatibility information. This includes gathering data from |
| 13 | +official documentations, GitHub repositories, and other relevant sources. By consolidating this information, |
| 14 | +we create a comprehensive database of add-on compatibility details. |
| 15 | + |
| 16 | +# Checking add-on compatibilities |
| 17 | +Add-on compatibility data is then made accessible through the Plural Console, where you can easily check |
| 18 | +the compatibility status of your add-ons with upcoming Kubernetes versions. This proactive approach helps |
| 19 | +to avoid potential issues caused by API changes and other version-specific nuances, ensuring a smoother |
| 20 | +transition to newer Kubernetes releases. |
| 21 | + |
| 22 | +  |
| 23 | + |
| 24 | +  |
| 25 | + |
| 26 | +# Automating Deployments on Newly Discovered Add-On Versions |
| 27 | + |
| 28 | +Plural's [Observer](https://docs.plural.sh/getting-started/how-to-use/pipelines#use-an-observer-to-automate-pipeline-context-creation-extra-credit) has the ability to automatically scrape our compatibility tables and generate PRs or Pipeline Runs whenever a new version is discovered that is compatible with a provided kubernetes version set. It's probably easiest to simply look at an example: |
| 29 | + |
| 30 | +```yaml |
| 31 | +apiVersion: deployments.plural.sh/v1alpha1 |
| 32 | +kind: Observer |
| 33 | +metadata: |
| 34 | + name: ingress-nginx |
| 35 | +spec: |
| 36 | + crontab: "*/5 * * * *" |
| 37 | + initial: 4.8.0 |
| 38 | + target: |
| 39 | + order: SEMVER |
| 40 | + type: ADDON |
| 41 | + addon: |
| 42 | + name: ingress-nginx |
| 43 | + kubernetesVersions: |
| 44 | + - "1.28" |
| 45 | + - "1.29" |
| 46 | + - "1.30" |
| 47 | + actions: |
| 48 | + - type: PIPELINE |
| 49 | + configuration: |
| 50 | + pipeline: |
| 51 | + pipelineRef: |
| 52 | + name: ingress-nginx |
| 53 | + namespace: infra |
| 54 | + context: |
| 55 | + name: ingress-nginx |
| 56 | + version: $value |
| 57 | +``` |
| 58 | +
|
| 59 | +This will scrape the tables for (Ingress NGINX)[https://github.com/kubernetes/ingress-nginx] that are compatible with all of kubernetes versions 1.28, 1.29, and 1.30 and create a pipeline context to bounce the pipeline we've defined to deploy it across dev and prod. This makes it very easy to trace an upgrade path across multiple versions with very little manual effort besides at most approving PRs. |
| 60 | +
|
| 61 | +Observers are a lot more flexible, and can also call PR automations that can trigger your own deployment automation on merge as well. |
0 commit comments