Question: 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`:

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.


Question: image: nginx:1.16-alpine ``` <del> 上記2つのDeploymentが生成されると、3つのノードは以下のようになります。 </del> <ins> 上記2つのDeploymentが生成されると、以下のようなクラスター構成になり、各ウェブサーバーはキャッシュと同位置に、3つの別々のNodeに配置されます。 </ins> |       node-1         |       node-2        |       node-3       | |:--------------------:|:-------------------:|:------------------:| | *webserver-1*        |   *webserver-2*     |    *webserver-3*   | |  *cache-1*           |     *cache-2*       |     *cache-3*      | <del> このように、3つの`web-server`は期待通り自動的にキャッシュと共存しています。 ``` kubectl get pods -o wide ``` 出力は以下のようになります: ``` NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3 redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1 redis-cache-1450370735-z73mh   1/1       Running   0          8m        10.192.3.1   kube-node-2 web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1 web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3 web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2 ``` ##### 同じNodeに共存させない場合 上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 </del> <ins> 全体的な効果として、各キャッシュインスタンスは、同じNode上で実行している単一のクライアントによってアクセスされる可能性が高いです。この方法は、スキュー(負荷の偏り)とレイテンシーの両方を最小化することを目的としています。 Podアンチアフィニティを使用する理由は他にもあります。 この例と同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeperチュートリアル](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 </ins> ## nodeName <del> `nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 `nodeName`はPodSpecのフィールドです。 ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。 そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。 </del> <ins> `nodeName`はアフィニティや`nodeSelector`よりも直接的なNode選択形式になります。`nodeName`はPod仕様(spec)内のフィールドです。`nodeName`フィールドが空でない場合、スケジューラーはPodを考慮せずに、指定されたNodeにあるkubeletがそのNodeにPodを配置しようとします。`nodeName`を使用すると、`nodeSelector`やアフィニティおよびアンチアフィニティルールを使用するよりも優先されます。 </ins> <del> `nodeName`を使用することによる制約は以下の通りです: </del> <ins> `nodeName`を使ってNodeを選択する場合の制約は以下の通りです: </ins> <del> -   その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 -   クラウド上のNodeの名前は予期できず、変更される可能性があります。 </del> <ins> -   指定されたNodeが存在しない場合、Podは実行されず、場合によっては自動的に削除されることがあります。 -   指定されたNodeがPodを収容するためのリソースを持っていない場合、Podの起動は失敗し、OutOfmemoryやOutOfcpuなどの理由が表示されます。 -   クラウド環境におけるNode名は、常に予測可能で安定したものではありません。 </ins> <del> `nodeName`を指定したPodの設定ファイルの例を示します: </del> <ins> {{< note >}} `nodeName`は、カスタムスケジューラーや、設定済みのスケジューラーをバイパスする必要がある高度なユースケースで使用することを目的としています。 スケジューラーをバイパスすると、割り当てられたNodeに過剰なPodの配置をしようとした場合には、Podの起動に失敗することがあります。 [Nodeアフィニティ](#node-affinity)または[`nodeSelector`フィールド](#nodeselector)を使用すれば、スケジューラーをバイパスせずに、特定のNodeにPodを割り当てることができます。 {{</ note >}} 以下は、`nodeName`フィールドを使用したPod仕様(spec)の例になります: </ins> ```yaml apiVersion: v1

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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


Question:
 ## `BootstrapToken`     {#BootstrapToken} **Appears in:** - [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration)
BootstrapToken describes one bootstrap token, stored as a Secret in the cluster

Field	Description

token [Required]
 BootstrapTokenString
token is used for establishing bidirectional trust between nodes and control-planes. Used for joining nodes in the cluster.

description
 string
description sets a human-friendly message why this token exists and what it's used for, so other administrators can know its purpose.

ttl
 meta/v1.Duration
ttl defines the time to live for this token. Defaults to 24h. expires and ttl are mutually exclusive.

expires
 meta/v1.Time
expires specifies the timestamp when this token expires. Defaults to being set dynamically at runtime based on the ttl. expires and ttl are mutually exclusive.

usages
 []string
usages describes the ways in which this token can be used. Can by default be used for establishing bidirectional trust, but that can be changed here.

groups
 []string
groups specifies the extra groups that this token will authenticate as when/if used for authentication

 ## `BootstrapTokenString`     {#BootstrapTokenString} **Appears in:** - [BootstrapToken](#BootstrapToken)
BootstrapTokenString is a token of the format abcdef.abcdef0123456789 that is used for both validation of the practically of the API server from a joining node's point of view and as an authentication method for the node in the bootstrap phase of "kubeadm join". This token is and should be short-lived.

Field	Description

- [Required]
 string 	  No description provided.

- [Required]
 string 	  No description provided.

  ## `ClusterConfiguration`     {#kubeadm-k8s-io-v1beta3-ClusterConfiguration}

file: kubeadm- ignorePreflightErrors need to under nodeRegistration.
That is exactly what the reference is saying.
I think you're suggesting a clarification to Have I got that right?
In the example:
Hi I'm going to edit your follow-up for readability - to make the YAML formatting more obvious.
That YAML from the email message is equivalent to:
It looks like the rest of your follow-up message is missing I can see the start of a sentence, “In the example:”, but not the remainder. /triage needs-information.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : It looks like the rest of your follow-up message is missing I can see the start of a sentence, “In the example:”, but not the remainder. 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
/triage needs-information
Okay, that makes sense. The example might be wrong. I'll look into it.
/sig cluster-lifecycle
looks like both and have some minor indentation issues. i though that we fixed these (apparently not). i can send PR for k/k later today.
PR for k/k is here:
/triage accepted /kind bug /remove-triage needs-information
/assign Reference is being regenerated using the updated doc comments.


Question: PLEASE title the FIRST commit appropriately, so that if you squash all your commits into one, the combined commit message makes sense. For overall help on editing and submitting pull requests, visit: <del> https://kubernetes.io/docs/contribute/suggest-improvements/ </del> <ins> https://kubernetes.io/docs/contribute/suggesting-improvements/ </ins> Use the default base branch, “main”, if you're documenting existing features in the English localization.

This is a Bug Report Hi Team, Hope you're all doing well. Problem: When raising a PR for kubernetes/website, the guiding text is as follows - The URL listed, sadly, gives a 404. Proposed Solution: Either we fix the target url or update to an alternative location. Thoughts? Best Regards James Spurin
The URL works. Fixes welcome.
/triage accepted
I would like to work on this issue. Thanks. /assign


Question:
 {{ $p := . }}  Release Information   {{ i18n "release_information_navbar" . }}  {{ range .Site.Params.versions }} {{ .version }} {{ end }}
   No newline at end of file

You can only get to the localized version of the page by going to the English version, and then clicking on the language dropdown to find a translation. If you are already on a localized version of the site, and the page exists in the selected language, it redirects you to the English version. See this comment for more info: Originally posted by in /area web-development
/area localization
/triage accepted
/priority important-longterm
/assign


Question: #### Spécifier la version de Kubernetes Vous pouvez spécifier la version de Kubernetes pour Minikube à utiliser en ajoutant la chaîne `--kubernetes-version` à la commande `minikube start`. <del> Par exemple, pour exécuter la version {{< param "fullversion" >}}, procédez comme suit: </del> <ins> Par exemple, pour exécuter la version {{< skew currentPatchVersion >}}, procédez comme suit: </ins> ```shell <del> minikube start --kubernetes-version {{< param "fullversion" >}} </del> <ins> minikube start --kubernetes-version v{{< skew currentPatchVersion >}} </ins> ``` #### Spécification du pilote de machine virtuelle

This is a Bug Report Problem: The param is deprecated. Proposed Solution: Replace the shortcode (French pages), for example with when possible and append when needed. Part of /language fr /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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