cannot install kubelet on Raspbian using apt

[SlyMarbo]

What happened?

I'm trying to install kubelet, kubeadm, and kubectl, using apt on Raspbian, following the instructions in the documentation.

I've successfully downloaded the signing key and APT list and I'm not getting any errors from sudo apt update or sudo apt upgrade. But trying sudo apt install -y kubelet kubeadm kubectl gives the following:

$ sudo apt install -y kubelet kubeadm kubectl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
kubectl:arm64 is already the newest version (1.30.3-1.1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 kubelet:arm64 : Depends: socat:arm64 but it is not installable
                 Depends: ethtool:arm64 but it is not installable
                 Depends: conntrack:arm64 but it is not installable
                 Depends: libc6:arm64 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I've manually installed socat, ethtool, conntrack, and libc6 successfully, but the error continues. It looks like the cause is that kubelet depends explicitly on socat:arm64 (which I can't install) and not the more generic socat (which is installed).

This is on a pretty fresh Raspbian install, so I don't believe I've done anything custom.

What did you expect to happen?

APT to install the three packages successfully.

How can we reproduce it (as minimally and precisely as possible)?

Install Raspbian, then follow the instructions in the documentation:

$ sudo apt update
$ sudo apt install -y apt-transport-https ca-certificates curl gpg
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ sudo apt update
$ sudo apt install -y kubelet kubeadm kubectl

Note that I've used apt instead of apt-get, but there's no difference in effect.

Anything else we need to know?

No response

Kubernetes version

1.30 (but doesn't seem relevant)

Cloud provider

N/A

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
NAME="Raspbian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
$ uname -a
Linux zeus 6.6.31+rpt-rpi-v8 kubernetes/kubernetes#1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:

• /sig <group-name>
• /wg <group-name>
• /committee <group-name>

Please see the group list for a listing of the SIGs, working groups, and committees available.

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]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[T-Lakshmi]

/kind support

[T-Lakshmi]

@SlyMarbo,
Please try to ask in the support channels for resolution as Github is not the right place to ask support queries.
https://github.com/kubernetes/kubernetes/blob/master/SUPPORT.md

[neolit123]

/transfer release

[neolit123]

@SlyMarbo, Please try to ask in the support channels for resolution as Github is not the right place to ask support queries. https://github.com/kubernetes/kubernetes/blob/master/SUPPORT.md

+1
seems like distro problem that we can't do much about.
you have the option to install "without a package manager"
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl

/close

[k8s-ci-robot]

@neolit123: Closing this issue.

In response to this:

@SlyMarbo, Please try to ask in the support channels for resolution as Github is not the right place to ask support queries. https://github.com/kubernetes/kubernetes/blob/master/SUPPORT.md

+1
seems like distro problem that we can't do much about.
you have the option to install "without a package manager"
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl

/close

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.

[neolit123]

/reopen
actually given these package names let's get feedback from the deb/rpm experts.

Depends: socat:arm64 but it is not installable

parhaps that's something that can be fixed on the pkg side.

[k8s-ci-robot]

@neolit123: Reopened this issue.

In response to this:

/reopen
actually given these package names let's get feedback from the deb/rpm experts.

Depends: socat:arm64 but it is not installable

parhaps that's something that can be fixed on the pkg side.

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.

[SlyMarbo]

I think I've diagnosed part of the cause. It turns out that the Raspbian installation I received has a 64-bit kernel but a 32-bit userspace. So presumably the package is using the wrong logic to determine which version of the package to install and is picking arm64, which then fails to install because there's no 64-bit libc, etc. I'm going to build a new Raspbian image that's entirely 64-bit.

[aojea]

/remove-kind bug
/sig release

to chime in for the artifacts

I don't know if these are the official packages, but the socat dependency was removed long time ago kubernetes/kubernetes#100679

[SlyMarbo]

Yes, that was my mistake; I discovered subsequently that I was installing 1.28 for some reason. Changing to 1.31 doesn't seem to have changed things. Separately, I've now reinstalled the Raspberry Pi with a fully 64-bit installation and that's working. So I think the issue remains that a 64-bit kernel with a 32-bit userspace results in an attempt to install the 64-bit packages, resulting in the error shown.

[xmudrii]

So I think the issue remains that a 64-bit kernel with a 32-bit userspace results in an attempt to install the 64-bit packages, resulting in the error shown.

@kubernetes/release-engineering @neolit123 I think this sounds reasonable, i.e. we shouldn't support a 32-bit userspace on the 64-bit operating system. That said, I don't think we should change anything on our side, but looking for some feedback on that from y'all.

@aojea We indeed require socat in our kubelet package. Just to confirm, kubelet doesn't require it any longer and we should be able to remove it?

[saschagrunert]

The issue seems more general than #3722 as outlined by @SlyMarbo. I assume that other dependencies are still throwing an error after that PR got merged:

ethtool:arm64 but it is not installable
conntrack:arm64 but it is not installable
libc6:arm64 but it is not going to be installed

[xmudrii]

@saschagrunert That's correct, but my point was that I'm not sure if we should support this case at all. If I understand correctly, this is happening only if you use a 32-bit userspace. I don't see it being a good idea to mix and match 64-bit kernel and 32-bit packages unless I'm missing something. And we don't provide support for 32-bit at all.

[aojea]

@aojea We indeed require socat in our kubelet package. Just to confirm, kubelet doesn't require it any longer and we should be able to remove it?

socat neither ebtables since the dockershim deprecation that I'm aware of, containerd and crio has a native socat implementation for port-forwarding and ebtables was a kubenet legacy thing IIRC