feat(containerd): Support containerd 2.0 #1658
Conversation
k8s-ci-robot
added
the
do-not-merge/work-in-progress
k8s-ci-robot
added
the
cncf-cla: no
|
Welcome @ffais! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @ffais. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
size/M
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
|
/test pull-azure-sigs |
1 similar comment
|
/test pull-azure-sigs |
|
Azure tests keep failing randomly, I did some tests locally and everything works perfectly. Could it be related to this #1656 ? |
|
In the last case, it was this: �[0;32m azure-arm.sig-ubuntu-2404-gen2: TASK [kubernetes : Install Kubernetes] *****************************************�[0m
�[0;32m azure-arm.sig-ubuntu-2404-gen2: fatal: [default]: FAILED! => {"cache_update_time": 1735390377, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\" install 'kubelet=1.30.5-1.1' 'kubeadm=1.30.5-1.1' 'kubectl=1.30.5-1.1' 'kubernetes-cni=1.4.0-1.1'' failed: E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 18541 (apt)\nE: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?\n", "rc": 100, "stderr": "E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 18541 (apt)\nE: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?\n", "stderr_lines": ["E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 18541 (apt)", "E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?"], "stdout": "", "stdout_lines": []}�[0m
�[0;32m azure-arm.sig-ubuntu-2404-gen2:�[0mI've never seen an The failure in #1656 manifests at a higher level and fails all the builds, so I don't think this is related. :-| |
|
/test pull-azure-sigs |
1 similar comment
|
/test pull-azure-sigs |
|
/retest |
|
fmm 🤔 |
|
@drew-viles Let me know if you prefer to have version containerd 2.0 configured as default before merging. |
| @@ -30,6 +30,19 @@ | |||
| dest: /tmp/containerd.tar.gz | |||
| mode: "0600" | |||
|
|
|||
| - name: Download containerd.service | |||
There was a problem hiding this comment.
Would be great if this goes behind flag? We can default the flag to download.
If not mistaken, containerd as a artifact does not publish the bundle anymore, but the scripts to generate them still exists. So if any provider/anyone still wants to use the bundle to do things, the can set the flag to false and continue to use older way.
There was a problem hiding this comment.
If we want to keep support for containerd bundles we have to put behind flag runc as well. I don't know how long the generation script is kept updated.
|
/retest |
|
Sorry I'm absolutely slammed at the moment so I'm just not getting the time to sit with this properly just yet. I'll try asap. |
|
ok, finally getting around to testing this! Sorry it's taken so long. I can only test it from the OpenStack side though and we will need consensus across a number of people since it change every single provider. With that in mind, to make sure an approval doesn't just force a merge, I'll be tagging it with "do-not-merge" Bear in mind this isn't a rejection, just a safety measure - once we've had an acceptable number of people approve this from across the different providers, we can remove this and get it merged. I'll let you know shortly how my testing gets on. |
drew-viles
added
the
do-not-merge/hold
|
ok this has allowed me to build an image in OpenStack successfully and deploy a Kubernetes cluster. Sorry it took so long but from my side it looks good. As I say, we'll need other from other providers to confirm all is well for them before pushing it in due to the wide reaching nature of this change. /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: drew-viles The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
Why is the version still 1.7.25 🤔 ? |
@akhilerm I opened this issue 5 months ago when Containerd 2.0 had just been released. Given the short time since the release and the lack of testing, I preferred not to set 2.0 as default. I have been using images created with image-builder and with Containerd 2.0 on azure, OpenStack and bare-metal for several months now without problems. Let me know if you would prefer to bump to 2.0 in this PR or if it would be more appropriate to do it in a separate PR. PS: @drew-viles if you want to test also Containerd 2.0 this is my setup. {
"containerd_version": "2.0.4",
"containerd_sha256": "e1c64c5fd60ecd555e750744eaef150b6f78d7f750da5c08c52825aa6b791737",
"crictl_version": "1.32.0",
"kubernetes_deb_version": "1.31.6-1.1",
"kubernetes_semver": "v1.31.6",
"kubernetes_series": "v1.31",
"kubernetes_cni_semver": "v1.6.2",
"runc_version": "1.2.6",
"runc_sha256": "0774f49d1b1eebb5849e644db5e4dc6f2b06cee05f13b3d17d5d6ba62d6f2ebc"
} |
|
Yeah it just defaults to 1.7.25 still as mentioned. I'm personally happy either way. Maybe it's something we can check through in a future PR and look at bumping it up once more demand comes in? We need to know flipping everyone over to it isn't going to have a massive impact. Whilst I doubt it will, it's not beyond the realms of possibility. I'd be keen to see how others feel about changing it to v2.0 to be honest. @mboersma @AverageMarcus @jsturtevant - what is your take on this? |
k8s-ci-robot
added
needs-rebase
…ainerd.service Signed-off-by: ffais <[email protected]>
ffais
force-pushed
the
support-containerd-2-0
branch
from
8b777e9 to
857eb5c
Compare
|
What is the release plan for this? |
There was a problem hiding this comment.
Change is needed in https://github.com/kubernetes-sigs/image-builder/blob/main/images/capi/packer/goss/goss-command.yaml#L179 as containerd 2.0 now uses sandbox instead of sandbox_image
|
@akhilerm you're right. The only way I see to fix this problem is to implement in image builder the support for both config.toml versions. We can add both template (version 2 and 3) and automatically select the proper one based on the containerd version. If containerd version is lower than 2 then use Implementing this feature would save the configuration migration at every daemon startup. As discussed in #1708 I don't know if adding this new functionality in this PR is a good idea. |
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
the
needs-rebase
Change description
The cri-containerd-*.tar.gz release bundles have been deprecated since containerd v1.6, and from containerd v2.0 this bundle is no longer available.
Related issues
GOSS log