Add long term stable release branches #7454
Conversation
|
Skipping CI for Draft Pull Request. |
dmcgowan
force-pushed
the
add-lts-release
branch
from
75f7f78
to
a265d28
Compare
dmcgowan
force-pushed
the
add-lts-release
branch
from
a265d28
to
7b5cb62
Compare
|
Removed the 1.5 updates, still ongoing discussion of how we want to extend the timeline |
Signed-off-by: Derek McGowan <derek@mcg.dev>
dmcgowan
force-pushed
the
add-lts-release
branch
from
7b5cb62
to
8162e04
Compare
| patches than non-_LTS_ releases to support the longer term maintainability of the | ||
| branch, including library dependency, toolchain (including Go) and other version updates | ||
| which are needed to ensure each release is built with fully supported dependencies and | ||
| remains usable by containerd clients. There should be at least a 6 month overlap between |
There was a problem hiding this comment.
remains usable by containerd clients
this may create an interesting challenge with k8s versions that are out of OSS support. When backporting changes for the active k8s versions, old k8s versions compatibility with containerd may degrade. I'd suggest to phrase something like:
| remains usable by containerd clients. There should be at least a 6 month overlap between | |
| remains usable by supported containerd clients. Note, LTS version of containerd may stop working for the containerd clients which are not up to date - you need to seek support from these clients authors. There should be at least a 6 month overlap between |
There was a problem hiding this comment.
Also in the table in the next section "Kubernetes Support", the list of recommended k8s versions for 1.6 will be fluid now. Bu 2025 recommendation will be different. I think this needs to be specified
There was a problem hiding this comment.
old k8s versions compatibility with containerd may degrade
Not our intention.
k8s versions, and container runtimes, out of OSS support are already a cloud provider issue... non-cve bugs / issues that will not be back ported to n-3 for k8s, and same for container runtimes at EOL, for example.
Wrt. CRI, this change will allow us to back port certain selected non-breaking type changes and extend the span of versions of k8s we can support where the api changes for CRI do not include breaking changes. As an aside breaking changes should require a CRI version change and thus won't, as a practice, be back ported to a prior api version, we currently support 2 versions of CRI and I don't remember off hand if any changes have been breaking. If a breaking change does occur to a version of the api and we have a need to back port it we can work together to figure out a way to disable the breaking behavior for older versions of k8s.. e.g. config switch, identify kubelet version/pod spec as a switch, or some other suitable mechanism.
Obvious statement of the day: Optional apis that are not called by an older version of k8s and optional fields not used by an older version of k8s won't break an older version of k8s.
As you mentioned, we keep a table for k8s support, and if necessary we can expand that table to have a level of detail for optional k8s cri features showing where said cri feature gates/apis may be configured in kubelet and/or containerd..
IOW do the right thing, exercise discretion and care, but have some flexibility. Practice is showing many cloud providers and other container runtime clients, are moving much slower than k8s's quarterly cycle.
the text in RELEASES.md is being left somewhat broad to leave discretion to the maintainers..
There was a problem hiding this comment.
My main point is that in the table of suggested k8s versions there should be a note saying that the list will change over time as we cannot suggest that older (out of support) k8s versions is something containerd recommends to use with containerd 1.6
There was a problem hiding this comment.
Agree in principle from a k/k project support view and not sure we are 100% in sync just yet wrt. containerd recommendation statements in view of this new LTS idea :-) I'll make sure to flag the right k8s people, including you, when we update the containerd k8s support table as we are, of course, integration partners on that statement. We'll definitely want to be clear about what's been tested, what hasn't been tested, the EOL status wrt the k8s versions that are officially EOL/out of support, and possibly where to go for out of support release help, at least in a conceptual way...
k8s versions which are officially out of support by k8s may still be in use, and supported by cloud/platform providers... containerd should continue to run some tests for each branch pr/release even against out of support versions of k8s / CRI, even if just to verify a prior version of the CRI api dropped in a newer version of k8s but not yet removed in the containerd branch.
Having a long term release that goes on as much as 2.5years beyond kubernetes support will definitely expose the support gap more than today's six months to year or so gap between the length of time an old version of containerd is supported and k8s support by the n-3 rule. Gap example in the below table.. we support 1.5.11 with k8s 1.20 even though that version of k8s is out of support.
Cheers.
There was a problem hiding this comment.
Y'all can figure out the clearest way to convey K8s support in a follow up or when we add the next K8s release into the list.
|
Great! I left couple suggestions on clarifying how LTS will be compatible or not compatible with k8s versions. |
The main motivation behind this addition is to support innovative work going on in containerd while continuing to maintain the most stable version of the software today. The 1.7 release will include new interfaces and implementations of core components of containerd, and while some of these may not be enabled by default in the 1.7 release, they are planned to be either enabled by default or the only options for the following 2.0 release. We expect these implementations to quickly be just as stable and reliable as what exists today, but we recognize the risk of any significant software change to core components. As a project, we must adapt and innovate along with the wider ecosystem, while continuing to be that boring stable component that everyone relies on.