Releases: kubewarden/kubewarden-controller
Release v0.3.2
Update CHANGELOG.md
Release v0.3.1
This release includes a correct aarch64
controller binary in the published container images on the GitHub registry.
Release v0.3.0
This version has removed support of v1alpha1
ClusterAdmissionPolicy
custom resource. You should migrate to v1alpha2
before upgrading to this version.
Release v0.2.3
Update CHANGELOG.md
Release v0.2.2
Update CHANGELOG.md
Release v0.2.1
Do not complain about kubebuilder annotation long lines
Release v0.2.0
The v0.2.0
release of kubewarden-controller introduces a new version of the ClusterAdmissionPolicy
custom resource.
Starting from this release, only ClusterAdmissionPolicy
of version v1alpha2
are going to be reconciled by the controller.
Upgrade process
This section describes how to migrate a kubewarden deployment from v0.1.4
to
v0.2.0
.
Pre-requisites
You must port the v1alpha1
definitions to the v1alpha2
format. We don't offer an automated process for that,
but the operation is pretty straightforward.
The apiGroups
, apiVersions
, resources
and operations
are no longer top-level attributes, but rather items under the
new rules
attribute.
Consider the following v1alpha1
resource definition:
apiVersion: policies.kubewarden.io/v1alpha1
kind: ClusterAdmissionPolicy
metadata:
name: psp-capabilities
spec:
module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3
resources:
- pods
operations:
- CREATE
- UPDATE
mutating: true
settings:
allowed_capabilities:
- CHOWN
required_drop_capabilities:
- NET_ADMIN
The v1alpha2
equivalent would be:
apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
name: psp-capabilities
spec:
module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3
rules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations:
- CREATE
- UPDATE
mutating: true
settings:
allowed_capabilities:
- CHOWN
required_drop_capabilities:
- NET_ADMIN
Some considerations worth of note:
- With
v1alpha1
,apiGroups
,apiVersions
,resources
were optional string attributes. Now they are array of
strings that must have at least one element. - With
v1alpha1
,apiGroups
,apiVersions
,resources
were optional string attributes.
When left empty they would default to the"*"
value.
This is reflected in the example above, as you can see the v1alpha2
resource explicitly defines all these attributes.
Upgrade steps
This is a list of steps to perform the upgrade to the v0.2.0
release.
We assume the deployment of Kubewarden has been done using our official helm charts inside of the kubewarden
Namespace.
Delete old controller
As a first step, start by deleting the current kubewarden-controller
deployment.
This can be done with the following command:
kubectl delete deployment --namespace kubewarden kubewarden-controller
Note well: Existing policies will continue to work as expected, even while the controller is not running. Removal, creation and update of policies won't be reconciled until the controller is restarted.
Install new Custom Resource Definitions
To install the new CRD definition execute the following commnad:
kubectl apply -f https://raw.githubusercontent.com/kubewarden/helm-charts/kubewarden-controller-0.1.12/charts/kubewarden-controller/crds/clusteradmissionpolicies.yaml
Upgrade your policies
Upgrade all the currently defined ClusterAdmissionPolicy
resources to use the v1alpha2
version.
This can be done via:
kubectl apply -f <upgrade-policy.yaml>
Upgrade the helm release
It's time to upgrade the helm release, this can be done via:
helm upgrade kubewarden-controller --version 0.1.12 kubewarden/kubewarden-controller
Once this is done, the new version of the kubewarden-controller
will be running on our cluster. The policy-server
instance will keep operating as expected during the whole time. It won't even be restarted, unless you
changed some details about the ClusterAdmissionPolicy
resource apart from the version itself.
Release v0.1.4
Update CHANGELOG.md
Release v0.1.3
Forward all parameters to the admission reconciler
Release v0.1.2
webhook registration: always set side effects