Releases: bluek8s/kubedirector
KubeDirector v0.11.0
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
One of the primary motivators for this release is to update the minimum version of go required for compiling KubeDirector, to 1.18 instead of 1.16. This lets us close three critical CVEs. We have a couple of other features/fixes ready to ship so they are included in this release as well.
Changes in order of issue number:
- report progress for persistent storage initialization; cf. the 0.11.0 additions to the MemberStateDetail in kdcluster status
- validate that mount paths are unique within a statefulset
- require golang 1.18 for KD build
KubeDirector v0.10.1
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
This is a targetted bugfix release for the issue of the new (stricter-schema) v1 CRDs incorrectly discarding custom labels/annotations for kdcluster member pods/services.
The only functional change is in the CRDs; however the KD image has also been updated so that it logs itself as version 0.10.1.
KubeDirector v0.10.0
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
The main focus of this release is to remove the usage of some deprecated K8s APIs. As a result of this change, KubeDirector can now be deployed on K8s version 1.22 and later. Also, KubeDirector is dropping support for deploying on K8s versions before 1.16.
We're also starting to qualify KubeDirector for deployment on OpenShift, so you can start experimenting with that environment as of this release.
See the release notes for v0.10.0-beta.1 for more details. There is only one further change in this final release, as follows:
The new API version for CRDs is by default more strict about whether CRs can accept properties that are not present in the CRD's schema. By default such out-of-schema properties will be ignored and not stored in the CR. Depending on your version of kubectl, kubectl may not even allow you to submit a CR with out-of-schema properties unless you use the "--validate=false" flag. This is generally good for reasons described here: https://kubernetes.io/blog/2019/06/20/crd-structural-schema/
KD-related CRDs will be adopting this new stricter behavior. For VERY old legacy reasons however, some of the example kdapp CRs previously included some out-of-schema properties like "categories". These properties are not required for any of KD's own functionality, but some other clients might still look for such properties in a kdapp. Also if a kdapp CR was created from a copy of one of our example CRs, it might still contain such properties even if they are not actually used, creating issues when applying the CR with kubectl as mentioned above.
So for now the kdapp CRD will include declarations to allow and preserve out-of-schema properties in "spec", "spec.label", and the items of the "spec.services" list. This is purely to avoid causing near-term issues with existing kdapp CRs. If you have a kdapp CR that includes out-of-schema properties, please work to remove them. If those properties contain useful information that some client is consuming, consider moving that information to an annotation or label in the CR metadata instead.
These "relaxations" of strictness for out-of-schema properties will be removed for the 1.0.0 release of KubeDirector.
(Note that there is one other instance of allowed out-of-schema properties in the kdapp CRD, and that is in the minResources declaration for a role. This allowance is needed to support extended resource types, and it will not be removed.)
KubeDirector v0.10.0-beta.1
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
Note that this is a BETA release. It is being made available so that it can be more easily/widely tested.
The main focus of this release is to remove the usage of some deprecated K8s APIs. As a result of this change, KubeDirector can now be deployed on K8s version 1.22 and later. Also, KubeDirector is dropping support for deploying on K8s versions before 1.16.
We're also starting to qualify KubeDirector for deployment on OpenShift, so you can start experimenting with that environment as of this release.
The final non-beta v0.10.0 release (expected before end-of-month) will therefore move the supported-K8s-version window as described above. It will also contain any changes for the initial experimental support of KubeDirector on OpenShift, but it will not yet make OpenShift a recommended environment for deploying KubeDirector.
The specific changes included in this beta:
KubeDirector v0.9.0
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
A collection of kdcluster features and bugfixes here. In order of issue number:
- allow requesting PV storage for kdcluster role members; cf. the 0.9.0 additions to the role spec
- don't put owner ref on MutatingWebhookConfiguration since K8s no longer honors this; the kubedirector-webhook needs to be explicitly remove if uninstalling KD (which "make teardown" now does)
- make configscript error info available in member status; cf. the 0.9.0 additions to the memberStateDetail in per-member status and to the kdapp spec
- fix application of the NVIDIA_VISIBLE_DEVICES environment var to properly set this to "void" when no NVidia GPU resources are requested
- stop using a deprecated method of setting PVC storage class; this also fixes some PV backup issues when using Velero
- make the pod-unschedulable reason available in member status; cf. the 0.9.0 additions to the memberStateDetail in per-member status
- give init containers the same resources as app containers to avoid locking down excess resources
- mark that the KD webhooks support "dry run"
KubeDirector v0.8.1
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
Happy Valentine's Day! This dot-release is for showing some love to kdapp developers who want to transition to the "new layout" introduced in the prior release, but who will need more time to transition to the more restrictive permissions on /etc/guestconfig. The app-filesystem-layout.md doc has been updated with tips. PR 557 describes the corresponding functional change in KubeDirector.
KubeDirector v0.8.0
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
The primary focus of this release is to add a new option for kdapp CRs that changes the processes and file layout around "app setup script" installation and use: the "useNewSetupLayout" boolean in the default and per-role config package objects. This option can speed up the deployment of PVs in the kdclusters for those apps; it also makes certain directory contents readable only by the container user, for increased security in apps that support login by other user accounts. See the app-filesystem-layout.md doc for more info about using this option in your kdapp definitions. Two of the example kdapps (cassandra and jupyter-notebook) have been updated to use this option.
Another new kdapp feature is the ability to optionally specify a minimum valid persistent storage size for each role: the "minStorage" attribute. This helps to prevent cases where a kdcluster requesting a too-small PV cannot come up successfully.
Other changes in this release:
- remove CentOS 8 example kdapp due to EOL
- handle container images where "rm" is aliased to "rm -i"
- handle a race in "make deploy" where kdapp creation is attempted too soon
KubeDirector v0.7.1
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
This dot-release doesn't contain any new features or bugfixes within the KubeDirector code. It updates the base image of the KubeDirector deployment (from UBI7 to UBI8), raises the minimum allowed version of golang for compilation (from 1.13 to 1.16), and updates several of the module dependencies.
If you build KD yourself, the only action required on your part is to make sure you are now using go 1.16 (or later) to compile. Otherwise this update should be transparent to everyone.
As a result of this update, the Trivy report for vulnerabilities in the base image changes from "Total: 655 (LOW: 366, MEDIUM: 284, HIGH: 3, CRITICAL: 2)" to "Total: 96 (LOW: 44, MEDIUM: 48, HIGH: 1, CRITICAL: 3)". The increase in CRITICAL count there is the same CVE-2019-1010022 for glibc. In UBI7 that CVE gets counted against glibc and glibc-common; in UBI8 it's counted against glibc, glibc-common, and glibc-minimal-langpack.
As for Trivy-reported vulnerabilities against the KD binary, those go from "MEDIUM: 3, HIGH: 4" to "MEDIUM: 2, HIGH: 2". Specifically, this update closes out CVE-2020-29652 and CVE-2020-9283 for golang.org/x/crypto, and CVE-2019-11254 for gopkg.in/yaml.v2.
KubeDirector v0.7.0
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
The big Q2 release is here! Along with some general documentation-cleaning and a new roadmap, the following features and fixes are included:
Kubedirector v0.6.2
If you reached this page through a direct link, please check to see what the latest release is before proceeding, just in case this version is outdated.
Maintenance release to address the following bugs: