[kicbase] Proposal: install containerd (and docker) from binary tgz, not from deb

[AkihiroSuda]

minikube/deploy/kicbase/Dockerfile

Lines 110 to 114 in c31bd57

	# install docker
	RUN sh -c "echo 'deb https://download.docker.com/linux/ubuntu focal stable' > /etc/apt/sources.list.d/docker.list" && \
	curl -L https://download.docker.com/linux/ubuntu/gpg -o docker.key && \
	apt-key add - < docker.key && \
	clean-install docker-ce docker-ce-cli containerd.io

Currently, kicbase uses containerd.io deb maintained by Docker, Inc.
This makes impossible to update kicbase to use containerd 1.5.0, as contained 1.5.0 is not available in the apt repo: https://download.docker.com/linux/ubuntu/dists/focal/pool/stable/amd64/

So I suggest installing containerd (and also docker) from binary tgz, not from deb.

The binary tgz of containerd can be fetched from https://github.com/containerd/containerd/releases .
The binary tgz of docker is available at https://download.docker.com/linux/static/stable/x86_64/ .

[afbjorklund]

Why is containerd and buildkitd not available as regular (apt/deb) packages ?

That would make them easier to install and update, than using the tarballs. (#10068 #11195)

But otherwise I think we just follow the container runtime documentation:

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

[AkihiroSuda]

Why is containerd and buildkitd not available as regular (apt/deb) packages ?

Mostly, it is simply because we do not know how to provide apt repo, without maintaining a web server, nor subscribing a paid service 😓 .
It would be great if GitHub or CNCF can provide free apt service.

[afbjorklund]

Actually containerd is available as a system package:

https://packages.ubuntu.com/focal-updates/containerd

Not that it actually helps going to containerd 1.5.0

containerd/focal-updates,focal-security 1.3.3-0ubuntu2.3 amd64

More creating a testing liability, with vendor package vs. system packages:

#10089

Also we do use binary tarballs (and source), when building our own ISO.

But it is better if the distribution does it, and integrates it properly and so on...

[afbjorklund]

We do create deb and rpm for minikube (just packaging the exact same binary)

But trying to get Kubernetes or Google to host the apt and yum repositories...

That has been a long and sad story. (#3110 #4716)

Just hoping that we could still use it for the basics, like container runtimes.

[medyagh]

Two things, we could either install containerd with binary on a the current kic base and measure the performance and the test failures and see how it performs

@AkihiroSuda if we install containerd from binaries, do we need to install systemd files ourselfes and do configruations ? is there an example of doing it correclty ?

I would accept a PR that does a prototype on kic base with containerd from binary

and if it performs better, we maybe could do a prototype of including the containerd Binary in the Preload Tar

[BenTheElder]

KIND (origin of kic base) is installing these from binary because of how incredibly old the packaged versions are. There are extremely useful improvements in more recent versions.

if we install containerd from binaries, do we need to install systemd files ourselfes and do configruations ?

Yes.

is there an example of doing it correclty ?

There's a systemd unit in the containerd repo. https://github.com/containerd/containerd/blob/master/containerd.service

You can see also https://github.com/kubernetes-sigs/kind/tree/main/images/base which is still doing this of course.

But trying to get Kubernetes or Google to host the apt and yum repositories...

Kubernetes will not be relying on the Google cloud's APT / YUM hosting long term, the Google package hosting can only be maintained by Googlers (Google is not going to give external users access to sign and upload packages to this infrastructure) and is not available as a product. Source: I lead the team currently ensuring the Kubernetes packages are built and uploaded (amongst other things), also this is tracked in kubernetes/release#281

We're definitely not adding more projects to this.

[afbjorklund]

@medyagh : we would have to add our own configuration and our own systemd units. See "kind" for example

images/base/files/etc/
├── containerd
│   └── config.toml
├── crictl.yaml
└── systemd
    └── system
        ├── containerd.service

https://github.com/kubernetes-sigs/kind/tree/main/images/base/files/etc

Same thing for buildkitd

[afbjorklund]

This also needs to be synched with the installation in the VM, which currently has a mix of binary and source

https://github.com/kubernetes/minikube/tree/master/deploy/iso/minikube-iso/package/containerd-bin

https://github.com/kubernetes/minikube/tree/master/deploy/iso/minikube-iso/package/buildkit-bin

If/when we upgrade containerd, we probably have to bundle the old containerd and runc with docker again ?

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[AkihiroSuda]

/remove-lifecycle stale

[medyagh]

I would like to see more feature parity between our ISO and KIC image so I would +1 for installing containerd using binary as opposed to deb package.

@AkihiroSuda I would happily accept a PR that implements this

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[AkihiroSuda]

We have containerd 1.6 dpkgs now, so no need to use tgz atm

[afbjorklund]

Couldn't find any deb from containerd.io, only the docker ones ?

[AkihiroSuda]

Couldn't find any deb from containerd.io, only the docker ones ?

Docker, Inc. provides RPM/DPKG packages named containerd.io, but the containerd project (https://containerd.io) does not provide such packages (mostly because of lack of APT/DNF repo infra)