The renovate configuration can be validated as described here. A custom manager is used to handle the provider generation script.
This repository contains the files necessary to install cert-manager.
Until we have improved the ugly JSON
detect-undead config cilium | yq 'select(.metadata.name == "cilium-envoy-config") | .data."bootstrap-config.json"' | jqThe official quickstart instructions instructions here work by just downloading a bunch of resources and applying them on the cluster. These resources are generated using kustomize for each release. The helm chart developers say that they want to be as close as possible to this in their notes on upgrading the helmchart.
This repo contains the deployments for various Container Storage Interfaces (CSIs). Their job is to make the various volumes we create as kubernetes resources actually appear in the respective backends.
CSI plugins can either be in-tree (i.e. in the K8s source code) or out-of-tree (i.e. outside of the code and usually deployed using Kubernetes resources). See here for a list of supported in-tree CSI plugins as well as deprecated plugins which will need to be migrated in the future! This is worth taking a look at in future releases, because we will need to migrate away from deprecated in-tree plugins and deploy the relevant out-of-tree plugin before we roll out the update that completely removes the in-tree version.
There are many components that cooperate, to make each csi-plugin work. Other than the plugin itself, which handles the communication to the storage backend, there are multiple components responsible for the kubernetes side of things. So when we create, resize, create a snapshot of, attach, ..., a volume, they are going to talk to the csi-plugin using a standardised interface, and then the plugin can do its idiosyncratic backend magic, which Kubernetes does not know about. The generic componentes like the attacher, provisioner, and so on, are provided by SIG-Storage. A storage backend maintainer only needs to implement the specific csi-plugin with the correct interface.
Here's a figure displaying this. It's from the Openshift documentation, but it's close enough:
The Openshift documentation (owned by Red Hat) is licensed under the Apache 2.0 License.
Creates snapshots when users create VolumeSnapshot objects. The contents of those snapshots live in VolumeSnapshotContent objects, like PVs and PVCs.
Each CSI has these, usually. See here for their repos. Here's what each one does:
Responsible for attaching and detaching external volumes to nodes.
Responsible for creating volumes in the storage backend when users create PVCs.
Contains the CSI specific logic for creating snapshots
Resizes PVs when users modify the respective PVC.
This thing registers the CSI driver with kubelet because microservices.
This thing serves the /healthz endpoint of the CSI driver. Because microservices, that's why.
The actual plugin offering the functionality for the respective backend.