May 02, 2020
Chris Gaun
D2iQ
6 min read
NOTE: The following information is for release and versioning guidance, which may change based on business and user needs. For customers with a license who are looking for the T&Cs for support services and licenses, please see the D2iQ Support Terms.
The Ksphere platforms and products (Konvoy, Kommander, KUDO Operators like Kafka, Dispatch and Conductor) are architected of independent components that allow users flexibility for upgrading. With that flexibility comes different life cycles and release guidance.
Product independence means it is possible to upgrade Kubernetes without touching the Konvoy CLI or to upgrade the Kubernetes Base Addons (e.g., the monitoring stack) without upgrading either Konvoy or Kubernetes. It is possible to upgrade Dispatch without touching your production cluster. You can also use the products separately from each other. For example, you can federate the Day 2 Kubernetes Base Addons and use them with 3rd party Kubernetes clusters. This disaggregated structure allows D2iQ to release patches, security releases and generally available products at different times, as needed.
Upstream Base Technology Leadership
D2iQ can, and has, submitted enhancements and fixes for the underlying components included in all platforms and products. This work has included triage, root cause analysis and fixes for upstream open source projects. Our engineering teams are actively contributing to a wide range of these projects, from both a code and technical leadership perspective. These efforts include:
- Kubernetes
- Tekton
- Argo CD
- Kubefed
- Krew
- Controller-runtime
- Cluster API
- Kubecost
- Container Storage Interface (CSI)
- Helm Charts
- Minio
- Traefik
- Istio
We are also actively involved in many Kubernetes and CNCF Special Interest Groups (SIG’s), which set the technical direction for related projects. These include Release, Testing, App Delivery, Multi-tenancy, Contribex, Contributor Strategy, Cluster Lifecycle, Multi Cluster, Architectural Conformance and many others, giving us technical and strategic influence on the roadmap and direction of the projects which we consume downstream into our products.
It is important to remember that many components are community-run efforts, so no upstream bug fix can be guaranteed. Our strategy is to avoid forking components whenever practicable, and instead work to contribute needed features and patches to upstream. However, forks are possible where unavoidable and D2iQ can maintain them, in those extreme circumstances where the upstream community will not fix a bug or security vulnerability in an acceptable time frame for the needs of our customers.
Konvoy Versioning and Release Guidance
Konvoy includes the following components:
- Konvoy CLI for lifecycle management
- Upstream Kubernetes
- Core kubernetes cluster components required for Kubernetes (e.g. container runtime)
- Day 2 Kubernetes Base Addons (KBAs)
- Ksphere products (e.g. Dispatch, Conductor, and Kommander)
Each one of the above can be, and often are, released independently. The following information covers each of the lifecycle and versioning variations for the above items.
Konvoy CLI versions are tied to one or more Kubernetes versions. For any current Konvoy version, D2iQ will also have at least one previous CLI version that allows an upgrade path from the previous version.
Konvoy CLI Versioning and Release Guidance
Konvoy follows the version scheme below:
- Major (x.0.0)
- Minor (x.x.0)
- Patch (x.x.x)
Konvoy CLI Major Release Schedule
Similar to Kubernetes, Konvoy does not commit to any date for a major release. A major release would be driven by fundamental architecture changes.
Konvoy CLI Minor Release Schedule
Konvoy has a new generally available (GA) version about every 3 months.
Konvoy CLI Patch Release Schedule
Konvoy CLI includes a new, non-security-related, patch version approximately every few weeks as needed.
Konvoy CLI Beta Versions and Release Guidance
Konvoy has a new Beta release for the N+1 version of the product every two weeks.
Konvoy Beta versions follow a x.x.0-Beta.A scheme where x.x.0 will be the N+1 of the current GA version and the A will be the current iteration of the Beta (starting at 0 and incrementing by 1 each release).
New Beta versions of Konvoy CLI will often include new defaults for the Betas of Kommander, Dispatch, and other products as well.
The documentation for the Beta versions are public (example) and the release can be downloaded by existing customers in the support portal. D2iQ will soon have a dedicated site for anyone to download the Betas but in the meantime, you can obtain the Beta by contacting D2iQ.
Kubernetes Release Guidance
D2iQ relies on the upstream Kubernetes, which maintains community support for up to N-2 versions currently. This time period tends to equate to nine months of upstream support for any given minor version of Kubernetes, or a new minor release of Kubernetes every three months. You can read about Kubernetes upstream support at the kubernetes.io page here. If the community increases its lifecycle of supported versions, so will D2iQ.
D2iQ releases new, tested and approved patches monthly, aligned with the upstream patch release cadence.
Kubernetes Long Term Support
Many enterprise customers, even while adopting a faster cloud native pattern of development, cannot upgrade the cluster every nine months. If the N-2 level of community support is insufficient, D2iQ offers additional support to help triage and do root cause analysis (RCA) of issues for longer contractual terms.
Note that D2iQ has released a lot of Konvoy features to make upgrades easier from small remote edge clusters to very large clusters in cloud and on premises. Some examples:
- kcl (“k” cluster lifecycle) - This is a Kubernetes control plane for managing the clusters themselves and gives users a single API used to interact with and upgrade multiple clusters.
- Inplace Non-Disruptive Patching - D2iQ has performed extensive testing of patching Kubernetes with inplace upgrades with or without draining a node. The upstream approach is to bring on a new node and then destroy the old node. D2iQ allows for the workloads to continue to run without the need to drain the node and reschedule the workloads.
- Parallel Worker Node Upgrades - Konvoy can perform parallel node upgrades and batch upgrades. A user can upgrade all the worker nodes at once or in batches.
- Node Pool Upgrades - A user can upgrade specific node pools - e.g. GPU nodes or Kafka nodes. This allows users to test new nodes with either different underlying infrastructure or a new version of the Kubernetes kubelet. This process can also be done in batches as well.
Core Kubernetes Cluster Components
Core Components in Konvoy include:
- etcd
- Kubernetes control plane (api-server, controller-manager, Guidancer)
- Kubernetes node (kubelet, kube-proxy)
- kubeadm
- CoreDNS
- Calico
- containerd
- kubeaddons
The Core Kubernetes Cluster Components are tied to a Kubernetes minor release version. For example, if using Kubernetes 1.6.x, you must use the specified version of containerd in the Konvoy documentation.
Core Kubernetes Cluster Components minor versions are not incremented between Minor Kubernetes versions unless a CVE is determined to affect users.
Stability is given priority over the newest version. The Core Kubernetes Cluster Components will always be a supported upstream version without open critical CVEs. However, every Core Kubernetes Cluster Component is also not necessarily incremented to the latest minor or major version with every Konvoy minor or major release. For example, to ensure stability, Calico may be an upstream supported but older version than the latest.
This process means that core components might not be n-2, since they are on a different cadence from Kubernetes, but they will usually be upgraded when we upgrade k8s.
Kubernetes Security Vulnerabilities (i.e. CVEs)
D2iQ are a part of the k8s embargo community, meaning we are given early builds of k8s under confidentiality to test and package in advance of the official release. This status gives us the opportunity to give you critical CVE patches very quickly—usually the day they are announced.
You can read more about security releases here.
You can join the mailing list for security vulnerabilities in Kubernetes here and an RSS feed for security vulnerabilities is available here.
A history of CVEs for other Core Kubernetes Cluster Components can be found in the links below:
Technology | Security Release Information
Calico | Security Bulletins
containerd | CVE and Release Notes
CoreDNS | Security Release Process
etcd | CVE details
Calico | Security Bulletins
containerd | CVE and Release Notes
CoreDNS | Security Release Process
etcd | CVE details
Day 2 - Kubernetes Base Addons
The Kubernetes Base Addons (KBAs) are addons that are managed by our kubeaddons controller and kubefed instead of kubeadm. We’ve got a whole separate blog on this topic. Check it out here.
The KBAs are considered “non essential” to workloads running on Kubernetes. The KBAs are complementary and operational add-ons that add Day 2 robustness to any Kubernetes cluster.
Because of the KBAs’ secondary role, they are able to be upgraded on a more aggressive cadence.
New, generally available versions of KBAs are upgraded every two weeks after undergoing two weeks of testing.
KBAs are tied to the Kubernetes version only. KBA functionality has no underlying dependency on any D2iQ technology.
KBA releases typically include patches or CVE fixes for each technology. They might not include new minor or major versions of each technology, as stability is prioritized over the newest, bleeding edge, version.
New minor or major versions of technologies in the KBAs are upgraded based on customer needs or the lifecycle of the base technology.
If you really want to drill down, please see our Release Documentation for more information on the latest KBA release here.
Kommander
Kommander uses the Kubernetes primitives to transform a Kubernetes cluster into a command center for infrastructure, clusters and workloads.
Kommander Versioning and Release Guidance
Kommander follows the version scheme below:
- Major (x.0.0)
- Minor (x.x.0)
- Patch (x.x.x)
Kommander Major Release Guidance
Kommander does not commit to any date for a major release. A major release would be driven by fundamental architecture changes.
Kommander CLI Minor Release Guidance
Kommander has a new generally available (GA) version about every three months.
Kommander Patch Release Guidance
Kommander includes a new, non security related, patch version every few weeks as needed.
Kommander Beta Versions and Release Guidance
Kommander has a new Beta release for the N+1 version of the product every two weeks.
Kommander Beta versions follow an x.x.0-Beta.A scheme where x.x.0 will be the N+1 of the current GA version and the A will be the current iteration of the Beta (startion at 0 and incrementing by 1 each release).
The documentation for the Beta versions are public (example) and the release can be downloaded by existing customers in the support portal by downloading and installing the newest Beta of Konvoy. D2iQ will soon have a dedicated page for downloading the Betas (including for non-customers), but in the meantime, you can obtain the Beta by contacting D2iQ support or your representative.
Dispatch Versioning and Release Cycle
Dispatch provides a cloud native CI/CD platform for enabling enterprises to adopt GitOps processes.
Dispatch Versioning and Release Guidance
Dispatch follows the version scheme below:
- Major (x.0.0)
- Minor (x.x.0)
- Patch (x.x.x)
Dispatch Major Release Guidance
Dispatch does not commit to any date for a major release. A major release would be driven by fundamental architectural changes.
Dispatch Minor Release Guidance
Dispatch has a new generally available minor release version about every 3 months.
Dispatch Patch Release Guidance
Dispatch includes a new, non-security related patch version every few weeks or as needed.
KUDO Operators Versioning and Release Cycle
We currently provide and maintain operators for the following OSS packages:
- Kafka
- Spark
- Cassandra
Most of the time these packages integrate unmodified "base technology" with KUDO. The integration with KUDO itself is coded and is version controlled. There are situations where the integration code is revved and the base tech stays the same, and vice versa. To accommodate revving just the integration or just the base tech, we release version operators with a compound version number. The advantage of a compound number is that users can easily understand what is being revved in the new package.
KUDO Operators follow the version scheme below:
<integration-version>-<base-tech-version>
e.g., KUDO Kafka 1.3.0-2.5.0 where 1.3.0 represents the KUDO Kafka version and 2.5.0 represents the Apache Kafka version.
- Major (x.0.0)
- Minor (x.x.0)
- Patch (x.x.x)
KUDO Operator Release Guidance
All of these technologies have their own release cadence and we are responsible for maintaining version currency—that is, being as close to the latest version of the underlying OSS package as possible.
- If there is a minor/dot release, we will release an updated package within one month.
- If there is a major release, we will release an updated package within two months. This extra interval is because major version updates often introduce breaking changes.
- These package updates are strictly for maintaining version currency. When it comes to new features, bumping the KUDO, resolving customer requests, bug fixes, or anything not related to updating the base-tech version, we will release separate packages at their own discretion.
- Not every base-tech technology follows semver. Sometimes a minor version update in a base-tech introduces breaking changes. In these situations, we will operate under the same policy as for a major version update and will strive to release our updated package in two months.
Security Based Releases for All Products
Of course, ensuring security to the best of our abilities underlies everything we do. D2iQ will perform both OSS licensing and container image security scanning for releases.
Image vulnerability scanning is performed on a continuous basis as part of D2iQ’s standard CI/CD process. D2iQ will publish new-found vulnerabilities and fixes as part of its regular release notes and has links to CVE feeds, where possible, in this document.
Note that some OSS security vulnerabilities do not have full or even partial upstream fixes. In these cases, D2iQ will monitor for fixes as part of above mentioned scanning and work independently to mitigate vulnerabilities.
When a vulnerability is identified and an OSS fix is available, D2iQ will perform a best commercially reasonable effort to effect a fix according to the Guidance communicated to the customer
We hope you found this information useful. If you have any questions left unanswered, please reach out to us—we’d be happy to answer them.
