Control versions of CRI and CNI installed in KIC

[afbjorklund]

Currently installing random versions from the cri-o repository:

containernetworking-plugins cri-tools

docker@minikube:~$ sudo crictl --version
crictl version v1.21.0
docker@minikube:~$ sudo /opt/cni/bin/portmap --version
CNI portmap plugin version unknown

cri-tools/now 1.21.0~2 amd64 [installed,local]
containernetworking-plugins/now 100:1.1.1~1 amd64 [installed,local]

https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable

These should be matched, with what Kubernetes (kubeadm) requires:

cri-tools/kubernetes-xenial,now 1.25.0-00 amd64 [installed]
kubernetes-cni/kubernetes-xenial,now 1.1.1-00 amd64 [installed]

https://apt.kubernetes.io (repackaged, from the original github binaries)

---

Also needs to be decoupled from the container runtime installation.

So that you can install only docker or only containerd, without cri-o:

• Separate container runtimes from the image #9989

Therefore it would be better to not install them from the Kubic repository.

[afbjorklund]

Versions used for ISO image:

• Upgrade cri-tools from 1.21.0 to 1.24.2 #14831
• Upgrade cni-plugins from 0.8.5 to 0.8.7 #14829

Installed from upstream binaries.

• https://github.com/kubernetes-sigs/cri-tools
• https://github.com/containernetworking/plugins

[afbjorklund]

Needs to be bumped:

• cri-tools 1.25.0
• cni-plugins 1.1.1

CRICTL_VERSION="v1.25.0"
CNI_PLUGINS_VERSION="v1.1.1"

[afbjorklund]

/remove-lifecycle stale

[afbjorklund]

Should just remove the package installation, and install from tarballs (like with containerd/buildkit)

Unfortunately this also means installing the systemd files manually, instead of just using a package.

[jonathan-albrecht-ibm]

I've been running minikube on s390x and came across this issue while debugging a problem with the cri-tools installed from the kubic repos in the kicbase image. I wanted to mention it here because it looks like switching to cri-tools installed from the tarballs from https://github.com/kubernetes-sigs/cri-tools will fix the issue.

I found when using minikube v1.29.0 and kubernetes-version > 1.23.* that minikube start --driver=docker fails with:

❌  Exiting due to RUNTIME_ENABLE: Temporary Error: sudo /usr/bin/crictl version: Process exited with status 2              stdout:                                                                                                                                                                                                                                                 stderr:                                                                                                                     panic: runtime error: invalid memory address or nil pointer dereference [recovered]                                                 panic: runtime error: invalid memory address or nil pointer dereference                                             [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x6b3332]                                                                                                                                                                                  goroutine 1 [running]:                                                                                                      github.com/kubernetes-sigs/cri-tools/vendor/gopkg.in/yaml%2ev3.handleErr(0xc000111b18)
        github.com/kubernetes-sigs/cri-tools/vendor/gopkg.in/yaml.v3/yaml.go:294 +0xb2
panic(0x120e440, 0x2382800)                                                                                                         runtime/panic.go:679 +0x1d4
github.com/kubernetes-sigs/cri-tools/vendor/gopkg.in/yaml%2ev3.yaml_parser_parse_node(0xc000446400, 0xc0004466b0, 0x100000000000000, 0x0)
        github.com/kubernetes-sigs/cri-tools/vendor/gopkg.in/yaml.v3/parserc.go:564 +0x4c2
github.com/kubernetes-sigs/cri-tools/vendor/gopkg.in/yaml%2ev3.yaml_parser_state_machine(0xc000446400, 0xc0004466b0, 0xc000393c20)
<... more stacktrace ...>

I built a local kicbase image with cri-tools from tarball from https://github.com/kubernetes-sigs/cri-tools on s390x as the only change and minikube start --driver=docker --base-image=local/kicbase:v0.0.37 was successful and I didn't hit any further issues while running that minikube cluster. I used the v1.21.0 version of cri-tools to match the version installed from the kubic repos.

I haven't created a separate issue since this one should fix it and wouldn't require a special case for s390x in the kicbase image. I'm happy to create one if it would help for tracking or any other reason.

[k8s-triage-robot]

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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/test-infra repository.