Change:
By looking at the documentation: we see an option to install the kubeadm without the package manager. However, it is not a static compilation. In this way: a) Should it not describe what libs should be present in the host before installation?b) Could the binaries be static so they could be entirely self-contained? c) Is that an option recommended for prod envs, or is it more like installing from the source for testing purposes? d) When/and for what situations would it be recommended install kubeadm via binaries? Would that address more needs of toolings and other projects that use kubeadm to do the installation against many OSs and do not want to care about the target OS? It would be great to have further information regards the above questions. PS.: It also might to be related to:
/sig docs /sig release
/transfer website
Hi Thank you for looking on this one. However, you transfered this issue to the docs. However, will the docs team be able to answer the questions for them we are able to add the info there? Or would this info better gathered checked by the kubeadm maintainers?
This is the right repo. SIGs including cluster lifecycle work in this repo and do see issues against the pages they maintain.
/sig cluster-lifecycle
if you want to request that the binaries for Kubernetes are static with no dynamically linked dependencies, I recommend that you open a separate new issue against . However even for those static binaries we would still need to document system-level prerequisites (a common example is a mechanism to discover the expected means of name resolution).
Hi! I was curious so I took a look; some binaries (like ) are static, while others (like ) are dynamic. This seems to be controlled by in (with some overrides in a few lines below). As an experiment, I tried to add to , and then gave me a static binary which seemed to run fine. That being said, I didn't run any extensive tests on it, and I don't know what's the rationale for having some binaries linked dynamically vs statically. (In my experience, with Go binaries, dynamic linking is necessary when enabling CGO, which is used by some dependencies; for instance to use a custom DNS resolver using avahi/bonjour configured through nsswitch instead of Go's built-in resolver; but again, I don't know the rationale for kubelet.) From my perspective, it would be acceptable to mention in the docs something like the following: WDYT?
The (fake) libraries you listed are all from the glibc package on Linux. The glibc package is there to be able to parse and load all Linux standard binaries (ELF format). They are not real dependencies to any add-on type of libraries or packages. I would not see them as an extra dependency for installation. For example, without ld-, the operating system won't be able to load your binary from disk into memory for execution. That library is a parser for your ELF binary. It knows how to layout your code, you data and your stack in memory. It knows how to make the 'open' syscalls linked to the OS kernel so that when your binary (kubelet) wants to open a file, the kernel is properly invoked to get it done.
I agree - has alternatives, but , and are unavoidably part of the OS.
as dates from January 1997. You won't be able to run Kubernetes on computers running an older Linux. Do we need to document this?
is a generic symbol for portability's purpose. Is there a real scenario where we a Linux doesn't support ? My understanding is that all Linux distributions (including their minimal install variants) have to have a library (which in theory doesn't have to be ) that provides the symbol. By Linux distribution, I'm also referring to those base OS images built for a cloud environment.
I'd like to know why we should do this. /priority awaiting-more-evidence
What and wrote above is mostly correct, but not totally correct, in the sense that , , and are not unavoidably part of the OS, and they are not necessary to run Linux binaries. They are necessary to run dynamic Linux binaries, and 99% of the binaries shipping with 99% of the distros are dynamic, so it's mostly correct; but these files are not necessary to run static binaries (see all the -based container images for examples; or the fact that some distros ship a static , which you can use as an replacement for troubleshooting/salvage purposes, in case your libc or linker are corrupted). Furthermore, the linker ( and ) are libc-specific; i.e. the glibc one won't work with musl dynamic binaries and vice-versa (although I've read that there are compatibility things that can be done on the musl side to let the musl linker load glibc binaries with some limitations). Some folks building custom Kubernetes distributions (e.g. based on Alpine, to be more space-efficient, e.g. to load the whole system in RAM and operate without a local disk) might want binaries that don't rely on glibc. But, I'd argue that these folks should usually know what they're doing - in the sense that they should know that they're using Alpine (or a glibc-less system) and they should know how to figure out if the binaries are static or dynamic, and which steps to follow to obtain static builds, for instance. I don't have a particular opinion about what should be included in the install docs. I think it's fair to mention that some binaries rely on glibc, but it's also fair to leave that out since it might confuse more folks than it will help :-)
Hi Everybody, Thank you a lot for all info provided. So, I think we have a conclusion for the raised questions. Please, let me know if I misunderstand something. We could add a small note to help out advanced users without bringing confusion. Something like: (Following a suggestion) NOTE: This installation is done via binaries that use dynamic linking and assumes that your system provides glibc. This is a reasonable assumption on many Linux distributions (including Debian, Ubuntu, Fedora, CentOS, and many others) but it is not the case of custom and light distributions which are glibc-less systems such as Alphine._ We raise an issue to check that: and can leave the discussion there. I think we can assume that it is supported for production env, and we do not need to change the docs. If that were not supported, then we would expect the docs to have a WARNING saying that it should not be used on those. I do not think that we need to address it in the docs. However, I would assume that the big motivation for we provide binaries and does not use the package manager is when we want to automate the installation. Please, let me know if I need to correct something. Thank you a lot for all your input and time so far.
+1 for adding a note.
I'd add that note in the “Before you begin” section: and then maybe have a couple of words (maybe four or five) linking back to that, just at the point we tell people to download binaries.
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /triage accepted /remove-lifecycle rotten /priority backlog please consider updating the issue description to either: link to summarize that thinking
Reopened this issue. <detailsIn response to : /reopen /triage accepted /remove-lifecycle rotten /priority backlog link to summarize that thinking Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would add that we document We can clarify, if we want, that we expect a Linux distribution that provides glibc or a compatibility layer providing the expected symbols. Remember, the docs explain how Kubernetes works now and not how we might hope it works in the future. Right now at last some release binaries do assume that glibc is available.
/assign
commented on the linked website PR: before merging the note, this thread needs feedback from a kubelet maintainer to confirim if the CGO / dynamic linking is expected. IIRC, in the past the kubelet had a CGO dependency by mistake, it was resolved, and more recently it may have re-appeared.

Discussion:
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly. * For example, `sudo swapoff -a` will disable swapping temporarily. To make this change persistent across reboots, make sure swap is disabled in config files like `/etc/fstab`, `systemd.swap`, depending how it was configured on your system. <ins> {{< note >}} The `kubeadm` installation is done via binaries that use dynamic linking and assumes that your target system provides `glibc`. This is a reasonable assumption on many Linux distributions (including Debian, Ubuntu, Fedora, CentOS, etc.) but it is not always the case with custom and lightweight distributions which don't include `glibc` by default, such as Alpine Linux. The expectation is that the distribution either includes `glibc` or a [compatibility layer](https://wiki.alpinelinux.org/wiki/Running_glibc_programs) that provides the expected symbols. {{< /note >}} </ins> <!-- steps --> ## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}

curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` <ins> {{< note >}} Please refer to the note in the [Before you begin](#before-you-begin) section for Linux distributions that do not include `glibc` by default. {{< /note >}} </ins> Install `kubectl` by following the instructions on [Install Tools page](/docs/tasks/tools/#kubectl). Enable and start `kubelet`: