---
title: OpenShift 4.4: Operator SDK supports Kubernetes 1.17
authors:
- "@joelanford"
reviewers:
- TBD
approvers:
- TBD
creation-date: 2019-12-19
last-updated: 2019-12-19
status: implementable
see-also:
- https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md
replaces: []
superseded-by: []
---
- Enhancement is
implementable - Design details are appropriately documented from clear requirements
- Test plan is defined
- Graduation criteria for dev preview, tech preview, GA
- User-facing documentation is created in operator-sdk/doc
The release of Kubernetes 1.17 brings new features, enhancements, and bug fixes to the Kubernetes API and Kubernetes libraries that support operator development. The focus of this enhancement is to bring Kubernetes 1.17 support to Operator SDK.
See the Kubernetes 1.17.0 CHANGELOG for details.
The motivation for this enhancement is to give operator developers access to the latest Kubernetes features and so that existing operator projects have a continued upgrade path to ensure their compatibility with the latest versions of Kubernetes.
The goal is to update the Kubernetes dependencies of the Operator SDK to use 1.17.
N/A
As an operator developer, I want to take advantage of the features of Kubernetes 1.17 and ensure that my operator is compatible with any API changes and removals in Kubernetes 1.17.
The biggest risk with this proposal, as always, is that Operator SDK depends on other projects that depend on Kubernetes, so it is typically not possible to upgrade Operator SDK's Kubernetes dependencies until these other projects have releases that also include the Kubernetes dependency updates.
The two projects that fall into this category are:
To mitigate these risks, the Operator SDK contributors must work with these projects to make the necessary upstream dependency changes and to make releases containing these changes.
Note: Section not required until targeted at a release.
Operator SDK's existing e2e suite will be used to verify these changes. At a minimum, the e2e suite will need to be updated to run the tests against a Kubernetes 1.17 cluster.
Since our tests make use of Kubernetes utilities and APIs, other changes may be necessary depending on the specific changes in Kubernetes 1.17.
To help users upgrade their projects, Operator SDK provides a migration guide that documents the steps that operator develoeprs must take to migrate their project to a new version of the SDK.
The migration guide for the version containing the Kubernetes 1.17 dependency
update will document the changes necessary in the project's go.mod file, and
it will call out any specific breaking changes that may impact operator projects
along with specific instructions for mitigating the breaking change, if applicable.
With Operator SDK, Version skew is typically a concern when deploying an operator to a Kubernetes cluster where the operator's Kubernetes client libraries are at a different version than the Kubernetes API server with which it is interacting.
The Kubernetes API compatibility matrix documents which clients and APIs are supported by which API server versions and vice versa.
See the kubernetes/client-go documentation about versioning, which describes the supported version skew between clients and servers.
Major milestones in the life cycle of a proposal should be tracked in Implementation History.
The only drawback is the potential for breaking changes in client code due to breaking changes introduced by the Kubernetes 1.17 version update. However, this is unavoidable since Kubernetes minor versions almost always contain breaking changes that impact controller-runtime and Operator SDK.
None
N/A