Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crictl must work with containerd 1.5 - allow the fallback logic to CRI API v1alpha2 #883

Closed
SergeyKanzhelev opened this issue Jan 26, 2022 · 10 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. sig/node Categorizes an issue or PR as relevant to SIG Node.

Comments

@SergeyKanzhelev
Copy link
Member

This is a follow up from #878 (comment)

Containerd 1.5 only implements CRI API v1alpha2 and cri tools must support the same runtimes k8s supports. So there should be a fallback logic to v1alpha2.

@SergeyKanzhelev SergeyKanzhelev added kind/bug Categorizes issue or PR as related to a bug. sig/node Categorizes an issue or PR as relevant to SIG Node. labels Jan 26, 2022
@SergeyKanzhelev
Copy link
Member Author

@saschagrunert what is the versioning story of CRI tools for CRI-O? How many versions back customers will expect to be supported?

@SergeyKanzhelev
Copy link
Member Author

cc: @qiutongs

@saschagrunert
Copy link
Member

@saschagrunert what is the versioning story of CRI tools for CRI-O? How many versions back customers will expect to be supported?

Since CRI-O versionizes together with Kubernetes, we would have any issue with a breaking change here. We also support CRI v1 since a couple of releases (v1.21 I guess), so we're already good to go.

@saschagrunert saschagrunert changed the title circtl must work with containerd 1.5 - allow the fallback logic to CRI API v1alpha2 crictl must work with containerd 1.5 - allow the fallback logic to CRI API v1alpha2 Jan 27, 2022
@saschagrunert
Copy link
Member

saschagrunert commented Jan 27, 2022

One way to approach this would be to switch to the internal runtime and image services completely:

func getRuntimeService(context *cli.Context) (internalapi.RuntimeService, error) {
return remote.NewRemoteRuntimeService(RuntimeEndpoint, Timeout)
}

This service already features the conversion of the types, but it would mean that we bound the kubelet code tighter to crictl.

I provided an example there: #884

If we agree that this is the right path forward, then I can take care of the other conversion as well.

@afbjorklund
Copy link
Contributor

afbjorklund commented Feb 13, 2022

Same problem with Docker (cri-dockerd), I guess it deserves a special issue.

docker@minikube:~$ crictl --version
crictl version v1.21.0
docker@minikube:~$ crictl version
Version:  0.1.0
RuntimeName:  docker
RuntimeVersion:  20.10.12
RuntimeApiVersion:  1.41.0
docker@minikube:~$ cri-dockerd --version
cri-dockerd 0.2.0 (a4d1895)
docker@minikube:~$ crictl info
{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
      },
      {
        "type": "NetworkReady",
        "status": true,
        "reason": "",
        "message": ""
      }
    ]
  }
}

When upgrading cri-tools to latest/greatest (i.e. 1.24 pre-release), it no longer works:

docker@minikube:~$ ./crictl-1.23.0 --version
crictl version v1.23.0
docker@minikube:~$ ./crictl-1.23.0 info
{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
      },
      {
        "type": "NetworkReady",
        "status": true,
        "reason": "",
        "message": ""
      }
    ]
  }
}
docker@minikube:~$ ./crictl --version
crictl version 1.23.0-18-g0871ebbc
docker@minikube:~$ ./crictl info
FATA[0000] getting status of runtime: rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService 

https://github.com/Mirantis/cri-dockerd/tree/a4d1895a2659ea9974bd7528a706592ab8b74181/src

EDIT: The suggested PR (#883) seems to work OK.

@afbjorklund
Copy link
Contributor

afbjorklund commented Feb 13, 2022

@saschagrunert

Since CRI-O versionizes together with Kubernetes, we would have any issue with a breaking change here. We also support CRI v1 since a couple of releases (v1.21 I guess), so we're already good to go.

I guess you mean "we would not have any" ? Normally CRI-O lags the Kubernetes releases for some time, but if it has already been implemented in a release version then I suppose you could* use cri-o v1.23.1 with kubernetes v1.24.0 ?

* I think we are currently using crio 1.22.1 with k8s 1.23.3.

docker@minikube:~$ ls /etc/apt/sources.list.d/
devel:kubic:libcontainers:stable.list  devel:kubic:libcontainers:stable:cri-o:1.22.list  docker.list

@afbjorklund
Copy link
Contributor

@SergeyKanzhelev : Do you know when Kubernetes will switch to recommending containerd 1.5 ?

Currently still recommends 1.4:

https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd

Install the containerd.io package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the containerd.io package can be found at Install Docker Engine.

containerd.io | 1.4.12-1 | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages

Maybe it will happen with k8s 1.24

@saschagrunert
Copy link
Member

I guess you mean "we would not have any" ?

Yes, sorry for the confusion.

@afbjorklund
Copy link
Contributor

afbjorklund commented Mar 20, 2022

Docker now installs containerd 1.5, fwiw

containerd.io |   1.5.10-1 | https://download.docker.com/linux/ubuntu focal/stable amd64 Packages

@saschagrunert
Copy link
Member

Fixed with #889

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. sig/node Categorizes an issue or PR as relevant to SIG Node.
Projects
None yet
Development

No branches or pull requests

3 participants