Skip to content

Add a new preflight check to the deprecation for the containerd 1.y and kubernetes 1.34+ integration. #3229

Open
Open
Add a new preflight check to the deprecation for the containerd 1.y and kubernetes 1.34+ integration.#3229
Labels
area/kubeletkind/featureCategorizes issue or PR as related to a new feature.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone
Next

Description

@carlory
carlory
opened on Aug 15, 2025

Timeline:

  1. kubenretes 1.34+ and containerd 1.y is deprecated since 1.34+
  2. kubernetes 1.37 is last version that supports containerd 1.y

related link: kubernetes/website#51447

cc @neolit123 @pacoxu

Activity

  1. neolit123 commented on Aug 15, 2025

    @neolit123
    neolit123
    on Aug 15, 2025
    Member

    should we can just print a warning, like we do for containerd pause version mismatch in the CRI configuration or introduce a complete preflight check e.g. ContainerdVersion?

  2. neolit123 commented on Aug 15, 2025

    @neolit123
    neolit123
    on Aug 15, 2025
    Member

    Timeline:

    1. kubenretes 1.34+ and containerd 1.y is deprecated since 1.34+
    2. kubernetes 1.36 is last version that supports containerd 1.y

    it's the kubelet version that should be checked and not kubernetesVersion, correct?

  3. carlory commented on Aug 15, 2025

    @carlory
    carlory
    on Aug 15, 2025
    MemberAuthor

    Yes, it is kubelet.

  4. carlory commented on Aug 15, 2025

    @carlory
    carlory
    on Aug 15, 2025
    MemberAuthor

    before 1.37, it should be a warnning, but since 1.37, it should be an error. kubelet calls cri to get cgroup driver name.

  5. carlory commented on Aug 15, 2025

    @carlory
    carlory
    on Aug 15, 2025
    MemberAuthor

    There is a fallback to use cgroupDriver from kubelet config https://github.com/kubernetes/kubernetes/blob/master/cmd/kubelet/app/server.go#L1400. If the fallback is removed, it should be an error.

    Image

  6. neolit123 commented on Aug 15, 2025

    @neolit123
    neolit123
    on Aug 15, 2025
    Member

    are there plans to remove the fallback as per the kep? that's an important detail.

    should we can just print a warning, like we do for containerd pause version mismatch in the CRI configuration or introduce a complete preflight check e.g. ContainerdVersion?

    i am leaning towards having a ContainerdVersion which somewhat aligns with the Swap check that we have.

  7. neolit123 commented on Aug 15, 2025

    @neolit123
    neolit123
    on Aug 15, 2025
    Member

    There is a fallback to use cgroupDriver from kubelet config https://github.com/kubernetes/kubernetes/blob/master/cmd/kubelet/app/server.go#L1400. If the fallback is removed, it should be an error.

    ok, in that case we need to carefully plan everything. FWIW removing the flag and config option will break a lot of setups.

  8. neolit123
    added
    priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.
    kind/featureCategorizes issue or PR as related to a new feature.
    area/kubelet
    on Aug 15, 2025

  9. carlory commented on Aug 15, 2025

    @carlory
    carlory
    on Aug 15, 2025
    MemberAuthor

    are there plans to remove the fallback as per the kep? that's an important detail.

    KEP indicates that the related fallback behavior will be removed in 1.36. but the blog said 1.36 is the last version which support containerd 1.y. I'm a little confused

  10. neolit123
    added this to the v1.35 milestone on Aug 15, 2025

  11. carlory commented on Aug 15, 2025

    @carlory
    carlory
    on Aug 15, 2025
    MemberAuthor

    i am leaning towards having a ContainerdVersion which somewhat aligns with the Swap check that we have.

    +1

  12. carlory commented on Aug 19, 2025

    @carlory
    carlory
    on Aug 19, 2025
    MemberAuthor

    are there plans to remove the fallback as per the kep? that's an important detail.

    KEP indicates that the related fallback behavior will be removed in 1.36. but the blog said 1.36 is the last version which support containerd 1.y. I'm a little confused

    the blog is updated. 1.35 is last version.

  13. neolit123
    changed the title [-]Add a new preflight check to the deprecation for the containerd 1.y and kubenretes 1.34+ integration.[/-] [+]Add a new preflight check to the deprecation for the containerd 1.y and kubernetes 1.34+ integration.[/+] on Aug 28, 2025

  14. 4 remaining items

  15. carlory commented on Oct 31, 2025

    @carlory
    carlory
    on Oct 31, 2025
    MemberAuthor

    We shouldn't set the cgroupDriver field in 1.36 or higher.

    https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/componentconfigs/kubelet.go#L193-L198

    Should kubeadm remove the cgroupDriver field from configmap during the upgrade phase?

    cc @pacoxu @neolit123

    It seems to depend on how the kubelet handles the cgroupDriver field when it is provided in the kubelet configuration.
    cc @marquiz @haircommander

  16. neolit123 commented on Oct 31, 2025

    @neolit123
    neolit123
    on Oct 31, 2025
    Member

    We shouldn't set the cgroupDriver field in 1.36 or higher.

    IIUC, for 1.36 you want to make kubeadm fail on preflight if the RuntimeConfig is missing.
    but what happens if the user ignores the error (--ignore-preflight-error), would the kubelet still run on an older CRI implementation that doesn't have RuntimeConfig? if so, the cgroup driver from config would matter, no?

    Should kubeadm remove the cgroupDriver field from configmap during the upgrade phase?

    i think it's better for kubeadm to stop setting this field only if the field gets deprecated / removed from the KubeletConfiguration and/or if it starts causing errors.

  17. marquiz commented on Oct 31, 2025

    @marquiz
    marquiz
    on Oct 31, 2025

    IIUC, for 1.36 you want to make kubeadm fail on preflight if the RuntimeConfig is missing. but what happens if the user ignores the error (--ignore-preflight-error), would the kubelet still run on an older CRI implementation that doesn't have RuntimeConfig? if so, the cgroup driver from config would matter, no?

    Yes, it matters if the preflight check is ignored/skipped. In that case (the CRI runtime does provide the cgroupDriver setting for kubelet) the kubelet falls back to using the cgroupDriver field from kubelet config.

    Should kubeadm remove the cgroupDriver field from configmap during the upgrade phase?

    i think it's better for kubeadm to stop setting this field only if the field gets deprecated / removed from the KubeletConfiguration and/or if it starts causing errors.

    I'm inclined to agree with this, don't remove until it's removed (or made nop)from kubelet. OTOH, kubeadm wouldn't need to set the field for containerd => 2.0.

    Thoughts @haircommander

  18. haircommander commented on Oct 31, 2025

    @haircommander
    haircommander
    on Oct 31, 2025

    though if containerd 2.0 is running the field is already a no-op, and from 1.36 it will be a no-op for any running cluster, so maybe it does make sense to stop setting it in 1.36

  19. pacoxu commented on Nov 3, 2025

    @pacoxu
    pacoxu
    on Nov 3, 2025
    Member

    though if containerd 2.0 is running the field is already a no-op, and from 1.36 it will be a no-op for any running cluster, so maybe it does make sense to stop setting it in 1.36

    +1.
    For v1.35, we may keep the cgroupDriver in kubelet configmap.

  20. neolit123
    modified the milestones: v1.35, v1.36 on Nov 11, 2025
  21. HirazawaUi
    modified the milestones: v1.36, v1.37 on Mar 26, 2026
  22. carlory
    modified the milestones: v1.37, Next on May 18, 2026

  23. k8s-triage-robot commented on Oct 18, 2026

    @k8s-triage-robot
    k8s-triage-robot
    on Oct 18, 2026

    The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

    This bot triages un-triaged issues according to the following rules:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Mark this issue as fresh with /remove-lifecycle stale
    • Close this issue with /close
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /lifecycle stale

  24. kubernetes-prow
    added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
    on Oct 18, 2026

  25. carlory commented on Oct 20, 2026

    @carlory
    carlory
    on Oct 20, 2026
    MemberAuthor

    /remove-lifecycle stale

  26. kubernetes-prow
    removed
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
    on Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/kubeletkind/featureCategorizes issue or PR as related to a new feature.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions