- Keep the blog content the same. If there are changes, they should be made to the original article first, and then to the mirrored article. - The mirrored blog should have a `canonicalUrl`, that is, essentially the url of the original blog after it has been published. <del> - [Kubernetes contributor blogs](https://kubernetes.dev/blog) have their authors mentioned in the YAML header, while the Kubernetes blog posts mention authors in the blog content itself. This should be changed when mirroring the content. </del> <ins> - Same as [Kubernetes contributor blogs](https://kubernetes.dev/blog), Kubernetes blog posts also mention authors in the YAML header as per the new guidelines. This should be ensured. </ins> - Publication dates stay the same as the original blog. All of the other guidelines and expectations detailed above apply as well.


for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release! ## Helpful Resources <ins> Refer to the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) resources for key information on roles and the release process. </ins>


<ins> apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very --- apiVersion: v1 kind: ConfigMap metadata: name: env-config namespace: default data: log_level: INFO </ins>


<ins> --- title: Prácticas Recomendadas de Configuración content_type: concept weight: 10 --- <!-- overview --> Este documento destaca y consolida las prácticas recomendadas de configuración que se presentan a lo largo de la guía del usuario, la documentación de Introducción y los ejemplos. Este es un documento vivo. Si se te ocurre algo que no está en esta lista pero que puede ser útil a otros, no dudes en crear un _issue_ o enviar un PR. <!-- body --> ## Consejos Generales de Configuración - Al definir configuraciones, especifica la última versión estable de la API. - Los archivos de configuración deben almacenarse en el control de versiones antes de enviarse al clúster. Este le permite revertir rápidamente un cambio de configuración si es necesario. También ayuda a la recreación y restauración del clúster. - Escribe tus archivos de configuración usando YAML en lugar de JSON. Aunque estos formatos se pueden utilizarse indistintamente en casi todos los escenarios, YAML tiende a ser más amigable con el usuario. - Agrupa los objetos relacionados en un solo archivo siempre que tenga sentido. Un archivo suele ser más fácil de administrar que varios. Ver el archivo [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) como un ejemplo de esta sintaxis. - Ten en cuenta también que se pueden llamar muchos comandos `kubectl` en un directorio. Por ejemplo, puedes llamar `kubectl apply` en un directorio de archivos de configuración. - No especifiques valores predeterminados innecesariamente: una configuración simple y mínima hará que los errores sean menos probables. - Coloca descripciones de objetos en anotaciones, para permitir una mejor introspección. ## "Naked" Pods vs ReplicaSets, Deployments y Jobs {#naked-pods-vs-replicasets-deployments-and-jobs} - No usar "Naked" Pods (es decir, Pods no vinculados a un [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) o a un [Deployment](/docs/concepts/workloads/controllers/deployment/)) si puedes evitarlo. Los Naked Pods no se reprogramará en caso de falla de un nodo. Un Deployment, que crea un ReplicaSet para garantizar que se alcance la cantidad deseada de Pods está siempre disponible y especifica una estrategia para reemplazar los Pods (como [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), es casi siempre preferible a crear Pods directamente, excepto por algunos explícitos [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) escenarios. Un [Job](/docs/concepts/workloads/controllers/job/) también puede ser apropiado. ## Servicios - Crea un [Service](/docs/concepts/services-networking/service/) antes de tus cargas de trabajo de backend correspondientes (Deployments o ReplicaSets) y antes de cualquier carga de trabajo que necesite acceder a él. Cuando Kubernetes inicia un contenedor, proporciona variables de entorno que apuntan a todos los _Services_ que se estaban ejecutando cuando se inició el contenedor. Por ejemplo, si existe un _Service_ llamado `foo`, todos los contenedores obtendrán las siguientes variables en su entorno inicial: ```shell FOO_SERVICE_HOST=<el host en el que se ejecuta el Service> FOO_SERVICE_PORT=<el puerto en el que se ejecuta el Service> ``` * Esto implica un requisito de ordenamiento - cualquier `Service` al que un `Pod` quiera acceder debe ser creado antes del `Pod` en sí mismo, de lo contrario, las variables de entorno no se completarán. El DNS no tiene esta restricción. - Un [cluster add-on](/docs/concepts/cluster-administration/addons/) opcional (aunque muy recomendable) es un servidor DNS. El servidor DNS observa la API de Kubernetes en busca de nuevos `Servicios` y crea un conjunto de registros DNS para cada uno. Si el DNS se ha habilitado en todo el clúster, todos los `Pods` deben ser capaces de hacer la resolución de nombres de `Services` automáticamente. - No especifiques un `hostPort` para un Pod a menos que sea absolutamente necesario. Cuando vinculas un Pod a un `hostPort`, limita la cantidad de lugares en los que se puede agendar el Pod, porque cada combinación <`hostIP`, `hostPort`, `protocol`> debe ser única. Si no especificas el `hostIP` y `protocol` explícitamente, Kubernetes usará `0.0.0.0` como el `hostIP` predeterminado y `TCP` como el `protocol` por defecto. Si solo necesitas acceder al puerto con fines de depuración, puedes utilizar el [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) o [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). Si necesitas exponer explícitamente el puerto de un Pod en el nodo, considera usar un [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service antes de recurrir a `hostPort`. - Evita usar `hostNetwork`, por las mismas razones que `hostPort`. - Usa [headless Services](/docs/concepts/services-networking/service/#headless-services) (que tiene un `ClusterIP` de `None`) para el descubrimiento de servicios cuando no necesites balanceo de carga `kube-proxy`. ## Usando Labels - Define y usa [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquen __atributos semánticos__ de tu aplicación o Deployment, como `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`. Puedes utilizar estas labels para seleccionar los Pods apropiados para otros recursos; por ejemplo, un Service que selecciona todo los Pods `tier: frontend`, o todos los componentes `phase: test` de `app.kubernetes.io/name: MyApp`. Revisa el [libro de visitas](https://github.com/kubernetes/examples/tree/master/guestbook/) para ver ejemplos de este enfoque. Un Service puede hacer que abarque múltiples Deployments omitiendo las labels específicas de la versión de su selector. Cuando necesites actualizar un servicio en ejecución sin downtime, usa un [Deployment](/docs/concepts/workloads/controllers/deployment/). Un estado deseado de un objeto se describe mediante una implementación, y si los cambios a esa especificación son _aplicados_, el controlador de implementación cambia el estado actual al estado deseado en un ritmo controlado. - Use las [labels comunes de Kubernetes](/docs/concepts/overview/working-with-objects/common-labels/) para casos de uso común. Estas labels estandarizadas enriquecen los metadatos de una manera que permite que las herramientas, incluyendo `kubectl` y el [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), trabajen de forma interoperable. - Puedes manipular las labels para la depuración. Debido a que los controladores de Kubernetes (como ReplicaSet) y los Services coinciden con los Pods usando labels de selector, se detendrá la eliminación de las labels relevantes de un Pod que sea considerado por un controlador o que un Service sirva tráfico. si quitas las labels de un Pod existente, su controlador creará un nuevo Pod para ocupar su lugar. Esto es un forma útil de depurar un Pod previamente "vivo" en un entorno de "cuarentena". Para eliminar interactivamente o agregar labels, usa [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label). ## Usando kubectl - Usa `kubectl apply -f <directorio>`. Esto busca la configuración de Kubernetes en todos los `.yaml`, `.yml`, y `.json` en `<directorio>` y lo pasa a `apply`. - Usa selectores de labels para las operaciones `get` y `delete` en lugar de nombres de objetos específicos. Ve las secciones en [selectores de labels](/docs/concepts/overview/working-with-objects/labels/#label-selectors) y [usar labels de forma eficaz](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). - Usa `kubectl create deployment` y `kubectl expose` para crear rápidamente un contenedor único Deployments y Services. Consulta [Usar un Service para Acceder a una Aplicación en un Clúster](/docs/tasks/access-application-cluster/service-access-application-cluster/) para un ejemplo. </ins>


card: name: concepts weight: 10 <ins> sitemap: priority: 0.9 </ins> --- <!-- overview -->


<ins> --- title: 静的な処理の割り当てを使用した並列処理のためのインデックス付きJob content_type: task min-kubernetes-server-version: v1.21 weight: 30 --- {{< feature-state for_k8s_version="v1.21" state="alpha" >}} <!-- overview --> この例では、複数の並列ワーカープロセスを使用するKubernetesのJobを実行します。各ワーカーは、それぞれが自分のPod内で実行される異なるコンテナです。Podはコントロールプレーンが自動的に設定する*インデックス値*を持ち、この値を利用することで、各Podは処理するタスク全体のどの部分を処理するのかを特定できます。 Podのインデックスは、{{< glossary_tooltip text="アノテーション" term_id="annotation" >}}内の`batch.kubernetes.io/job-completion-index`を整数値の文字列表現として利用できます。コンテナ化されたタスクプロセスがこのインデックスを取得できるようにするために、このアノテーションの値は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)の仕組みを利用することで公開できます。利便性のために、コントロールプレーンは自動的にdownward APIを設定して、`JOB_COMPLETION_INDEX`環境変数にインデックスを公開します。 以下に、この例で実行するステップの概要を示します。 1. **completionのインデックスを使用してJobのマニフェストを定義する**。downward APIはPodのインデックスのアノテーションを環境変数またはファイルとしてコンテナに渡してくれます。 2. **そのマニフェストに基づいてインデックス付き(Indexed)のJobを開始する**。 ## {{% heading "prerequisites" %}} あらかじめ基本的な非並列の[Job](/docs/concepts/workloads/controllers/job/)の使用に慣れている必要があります。 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} インデックス付きJobを作成できるようにするには、[APIサーバー](/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)上で`IndexedJob`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしていることを確認してください。 <!-- steps --> ## アプローチを選択する ワーカープログラムから処理アイテムにアクセスするには、いくつかの選択肢があります。 1. `JOB_COMPLETION_INDEX`環境変数を読み込む。Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、この変数をcompletion indexを含むアノテーションに自動的にリンクします。 1. completion indexを含むファイルを読み込む。 1. プログラムを修正できない場合、プログラムをスクリプトでラップし、上のいずれかの方法でインデックスを読み取り、プログラムが入力として使用できるものに変換する。 この例では、3番目のオプションを選択肢して、[rev](https://man7.org/linux/man-pages/man1/rev.1.html)ユーティリティを実行したいと考えているとしましょう。このプログラムはファイルを引数として受け取り、内容を逆さまに表示します。 ```shell rev data.txt ``` `rev`ツールは[`busybox`](https://hub.docker.com/_/busybox)コンテナイメージから利用できます。 これは単なる例であるため、各Podはごく簡単な処理(短い文字列を逆にする)をするだけです。現実のワークロードでは、たとえば、シーンデータをもとに60秒の動画を生成するというようなタスクを記述したJobを作成するかもしれません。ビデオレンダリングJobの各処理アイテムは、ビデオクリップの特定のフレームのレンダリングを行うものになるでしょう。その場合、インデックス付きの完了が意味するのは、クリップの最初からフレームをカウントすることで、Job内の各Podがレンダリングと公開をするのがどのフレームであるかがわかるということです。 ## インデックス付きJobを定義する 以下は、completion modeとして`Indexed`を使用するJobのマニフェストの例です。 {{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} 上記の例では、Jobコントローラーがすべてのコンテナに設定する組み込みの`JOB_COMPLETION_INDEX`環境変数を使っています。[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)がインデックスを静的な値にマッピングし、その値をファイルに書き込み、ファイルを[emptyDir volume](/docs/concepts/storage/volumes/#emptydir)を介してワーカーを実行しているコンテナと共有します。オプションとして、インデックスとコンテナに公開するために[downward APIを使用して独自の環境変数を定義する](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)こともできます。[環境変数やファイルとして設定したConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)から値のリストを読み込むという選択肢もあります。 他には、以下の例のように、直接[downward APIを使用してアノテーションの値をボリュームファイルとして渡す](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)こともできます。 {{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} ## Jobを実行する 次のコマンドでJobを実行します。 ```shell # このコマンドでは1番目のアプローチを使っています ($JOB_COMPLETION_INDEX に依存しています) kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml ``` このJobを作成したら、コントロールプレーンは指定した各インデックスごとに一連のPodを作成します。`.spec.parallelism`の値が同時に実行できるPodの数を決定し、`.spec.completions`の値がJobが作成するPodの合計数を決定します。 `.spec.parallelism`は`.spec.completions`より小さいため、コントロールプレーンは別のPodを開始する前に最初のPodの一部が完了するまで待機します。 Jobを作成したら、少し待ってから進行状況を確認します。 ```shell kubectl describe jobs/indexed-job ``` 出力は次のようになります。 ``` Name:              indexed-job Namespace:         default Selector:          controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 Labels:            controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 job-name=indexed-job Annotations:       <none> Parallelism:       3 Completions:       5 Start Time:        Thu, 11 Mar 2021 15:47:34 +0000 Pods Statuses:     2 Running / 3 Succeeded / 0 Failed Completed Indexes: 0-2 Pod Template: Labels:  controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 job-name=indexed-job Init Containers: input: Image:      docker.io/library/bash Port:       <none> Host Port:  <none> Command: bash -c items=(foo bar baz qux xyz) echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt Environment:  <none> Mounts: /input from input (rw) Containers: worker: Image:      docker.io/library/busybox Port:       <none> Host Port:  <none> Command: rev /input/data.txt Environment:  <none> Mounts: /input from input (rw) Volumes: input: Type:       EmptyDir (a temporary directory that shares a pod's lifetime) Medium: SizeLimit:  <unset> Events: Type    Reason            Age   From            Message ----    ------            ----  ----            ------- Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-njkjj Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-9kd4h Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-qjwsz Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-fdhq5 Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-ncslj ``` この例では、各インデックスごとにカスタムの値を使用してJobを実行します。次のコマンドでPodの1つの出力を確認できます。 ```shell kubectl logs indexed-job-fdhq5 # これを対象のJobのPodの名前に一致するように変更してください。 ``` 出力は次のようになります。 ``` xuq ``` </ins>


Kubernetesはオープンソースなので、オンプレミスやパブリッククラウド、それらのハイブリッドなどの利点を自由に得ることができ、簡単に移行することができます。 <ins> Kubernetesをダウンロードするには、[ダウンロード](/releases/download/)セクションを訪れてください。 </ins> {{% /blocks/feature %}} {{< /blocks/section >}}


<button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>

  2022年5月16日〜20日のKubeCon EUバーチャルに参加する   2023年4月18日〜21日のKubeCon + CloudNativeCon Europeに参加する

  2022年10月24日-28日のKubeCon NAバーチャルに参加する   2023年11月6日〜9日のKubeCon + CloudNativeCon North Americaに参加する


Details of the metric data that Kubernetes components export. --- <del> ## Metrics (v1.26) <!-- (auto-generated 2022 Nov 09) --> <!-- (auto-generated v1.26) --> </del> <ins> ## Metrics (auto-generated 2022 Nov 01) </ins> This page details the metrics that different Kubernetes components export. You can query the metrics endpoint for these components using an HTTP scrape, and fetch the current metrics data in Prometheus format.


* `kubectl debug` automatically generates the name of the new Pod based on the name of the Node. <del> * The container runs in the host IPC, Network, and PID namespaces. </del> * The root filesystem of the Node will be mounted at `/host`. <ins> * The container runs in the host IPC, Network, and PID namespaces, although the pod isn't privileged, so reading some process information may fail, and `chroot /host` will fail. * If you need a privileged pod, create it manually. </ins> Don't forget to clean up the debugging Pod when you're finished with it:


<ins> apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: SPECIAL_LEVEL: very SPECIAL_TYPE: charm </ins>


{{< note >}} 如果集群中正在运行任何 API 服务器，则不应尝试还原 etcd 的实例。相反，请按照以下步骤还原 etcd： <del> - 停止 *所有* kube-apiserver 实例 </del> <ins> - 停止 *所有* API 服务实例 </ins> - 在所有 etcd 实例中恢复状态 <del> - 重启所有 kube-apiserver 实例 </del> <ins> - 重启所有 API 服务实例 </ins> <del> 我们还建议重启所有组件（例如 kube-scheduler、kube-controller-manager、kubelet），以确保它们不会 </del> <ins> 我们还建议重启所有组件（例如 `kube-scheduler`、`kube-controller-manager`、`kubelet`），以确保它们不会 </ins> 依赖一些过时的数据。请注意，实际中还原会花费一些时间。 在还原过程中，关键组件将丢失领导锁并自行重启。 <del> {{< note >}} <!-- ## Upgrading and rolling back etcd clusters As of Kubernetes v1.13.0, etcd2 is no longer supported as a storage backend for new or existing Kubernetes clusters. The timeline for Kubernetes support for etcd2 and etcd3 is as follows: - Kubernetes v1.0: etcd2 only - Kubernetes v1.5.1: etcd3 support added, new clusters still default to etcd2 - Kubernetes v1.6.0: new clusters created with `kube-up.sh` default to etcd3, and `kube-apiserver` defaults to etcd3 - Kubernetes v1.9.0: deprecation of etcd2 storage backend announced - Kubernetes v1.13.0: etcd2 storage backend removed, `kube-apiserver` will refuse to start with `--storage-backend=etcd2`, with the message `etcd2 is no longer a supported storage backend` Before upgrading a v1.12.x kube-apiserver using `--storage-backend=etcd2` to v1.13.x, etcd v2 data MUST by migrated to the v3 storage backend, and kube-apiserver invocations changed to use `--storage-backend=etcd3`. The process for migrating from etcd2 to etcd3 is highly dependent on how the etcd cluster was deployed and configured, as well as how the Kubernetes cluster was deployed and configured. We recommend that you consult your cluster provider's documentation to see if there is a predefined solution. If your cluster was created via `kube-up.sh` and is still using etcd2 as its storage backend, please consult the [Kubernetes v1.12 etcd cluster upgrade docs](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) --> ## 升级和回滚 etcd 集群 从 Kubernetes v1.13.0 开始，不在支持 etcd2 作为新的或现有 Kubernetes 集群的后端。Kubernetes 支持 etcd2 和 etcd3 的时间表如下： - Kubernetes v1.0: 仅限 etcd2 - Kubernetes v1.5.1: 添加了 etcd3 支持，新的集群仍默认为 etcd2 - Kubernetes v1.6.0: 使用 `kube-up.sh` 创建的新集群默认为 etcd3，而 `kube-apiserver` 默认为 etcd3 - Kubernetes v1.9.0: 宣布弃用 etcd2 存储后端 - Kubernetes v1.13.0: 删除了 etcd2 存储后端，`kube-apiserver` 将拒绝以 `--storage-backend = etcd2` 开头，消息 `etcd2 不再是支持的存储后端` 在使用 `--storage-backend = etcd2` 升级 v1.12.x kube-apiserver 到 v1.13.x 之前，etcd v2 数据必须迁移到 v3 存储后端，并且 kube-apiserver 调用改为使用 `--storage-backend=etcd3`。 从 etcd2 迁移到 etcd3 的过程在很大程度上取决于部署和配置 etcd 集群的方式，以及如何部署和配置 Kubernetes 集群。 我们建议您查阅集群提供商的文档，以了解是否存在预定义的解决方案。 如果您的集群是通过 `kube-up.sh` 创建的并且仍然使用 etcd2 作为其存储后端，请参阅 [Kubernetes v1.12 etcd 集群升级文档](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) <!-- ## Known issue: etcd client balancer with secure endpoints The etcd v3 client, released in etcd v3.3.13 or earlier, has a [critical bug](https://github.com/kubernetes/kubernetes/issues/72102) which affects the kube-apiserver and HA deployments. The etcd client balancer failover does not properly work against secure endpoints. As a result, etcd servers may fail or disconnect briefly from the kube-apiserver. This affects kube-apiserver HA deployments. The fix was made in [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) (and backported to v3.3.14 or later): the new client now creates its own credential bundle to correctly set authority target in dial function. Because the fix requires gRPC dependency upgrade (to v1.23.0), downstream Kubernetes [did not backport etcd upgrades](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978). Which means the [etcd fix in kube-apiserver](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) is only available from Kubernetes 1.16. To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-apiserver. You can make local changes to [`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) with [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab). See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). --> ## 已知问题：具有安全端点的 etcd 客户端均衡器 在 etcd v3.3.13 或更早版本的 etcd v3 客户端有一个[严重的错误](https://github.com/kubernetes/kubernetes/issues/72102)，会影响 kube-apiserver 和 HA 部署。etcd 客户端平衡器故障转移不适用于安全端点。结果是，etcd 服务器可能会失败或短暂地与 kube-apiserver 断开连接。这会影响 kube-apiserver HA 的部署。 该修复程序是在 [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) 中进行的（并反向移植到 v3.3.14 或更高版本）：现在，新客户端将创建自己的凭证捆绑包，以在拨号功能中正确设置授权目标。 因为此修复程序要求将 gRPC 依赖升级（到 v1.23.0 ），因此，下游 Kubernetes [未反向移植 etcd 升级](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978)。这意味着只能从 Kubernetes 1.16 获得 [kube-apiserver 中的 etcd 修复](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab)。 要紧急修复 Kubernetes 1.15 或更早版本的此错误，请构建一个自定义的 kube-apiserver 。 您可以使用[`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) 和 [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) 来进行本地更改。 请看  ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). </del> <ins> {{< note >}} </ins>  No newline at end of file


### Linux {{< note >}} <del> Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://github.com/kubernetes/minikube#other-ways-to-install) im offiziellen Minikube-GitHub-Repository. </del> <ins> Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://minikube.sigs.k8s.io/docs/start/) im offiziellen Minikube-GitHub-Repository. </ins> {{< /note >}} Sie können Minikube unter Linux installieren, indem Sie eine statische Binärdatei herunterladen:


쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, 개별 컨테이너들이 DNS 네임을 해석할 때 <del> DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. </del> <ins> DNS 서비스의 IP를 사용하도록 kubelet을 구성한다. </ins> 클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. 기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와


body.cid-community .community-section.community-frame { <del> width: 100vw; </del> <ins> width: 100%; </ins> } body.cid-community .community-section.community-frame .twittercol1 {


--- title: コンテンツの構造化 content_type: concept <del> weight: 40 </del> <ins> weight: 90 </ins> --- <!-- overview -->


## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:


<ins> apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-nginx spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: access: "true" </ins>


[thirdparty_message] other = """Ta sekcja przekierowuje do projektów osób trzecich, które udostępniają funkcjonalność wymaganą przez Kubernetesa. Autory projektu Kubernetes nie są odpowiedzialni za te projekty. Ta strona podąża za wytycznymi CNCF dla stron internetowych aby pokazać projekty w kolejności alfabetycznej. Aby dodać projekt na tę listę przeczytaj wytyczne dla zawartości przed wysyłaniem zmian."""  [thirdparty_message_edit_disclaimer] other="""Zastrzeżenie dotyczące zawartości zewnętrznej""" [thirdparty_message_single_item] other = """🛇 Ta pozycja przekierowuje do projektu lub produktu osób trzecich, będących poza projektem Kubernetes. Więcej informacji""" [thirdparty_message_disclaimer] other = """
Niektóre elementy na tej stronie odnoszą się do zewnętrznych produktów lub projektów, które dostarczają funkcjonalności wymagane przez Kubernetesa. Autorzy projektu Kubernetes nie ponoszą odpowiedzialności za te produkty oraz projekty. Zajrzyj na stronę CNCF website guidelines po więcej informacji.

Zapoznaj się także z  content guide zanim zaproponujesz zmianę dodającą odnośnik do zewnętrznej strony.
"""  [ui_search_placeholder] other = "Szukaj"


<ins> --- title: Adding Windows worker nodes content_type: task weight: 50 --- <!-- overview --> This page explains how to add Windows worker nodes to a kubeadm cluster. ## {{% heading "prerequisites" %}} * A running [Windows Server 2022](https://www.microsoft.com/cloud-platform/windows-server-pricing) (or higher) instance with administrative access. * A running kubeadm cluster created by `kubeadm init` and following the steps in the document [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). <!-- steps --> ## Adding Windows worker nodes {{< note >}} To facilitate the addition of Windows worker nodes to a cluster, PowerShell scripts from the repository https://sigs.k8s.io/sig-windows-tools are used. {{< /note >}} Do the following for each machine: 1. Open a PowerShell session on the machine. 1. Make sure you are Administrator or a privileged user. Then proceed with the steps outlined below. ### Install containerd {{% thirdparty-content %}} To install containerd, first run the following command: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/Install-Containerd.ps1 `````` Then run the following command, but first replace `CONTAINERD_VERSION` with a recent release from the [containerd repository](https://github.com/containerd/containerd/releases). The version must not have a `v` prefix. For example, use `1.7.22` instead of `v1.7.22`: ```PowerShell .Install-Containerd.ps1 -ContainerDVersion CONTAINERD_VERSION ``` * Adjust any other parameters for `Install-Containerd.ps1` such as `netAdapterName` as you need them. * Set `skipHypervisorSupportCheck` if your machine does not support Hyper-V and cannot host Hyper-V isolated containers. * If you change the `Install-Containerd.ps1` optional parameters `CNIBinPath` and/or `CNIConfigPath` you will need to configure the installed Windows CNI plugin with matching values. ### Install kubeadm and kubelet Run the following commands to install kubeadm and the kubelet: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/PrepareNode.ps1 .PrepareNode.ps1 -KubernetesVersion v{{< skew currentVersion >}} ``` * Adjust the parameter `KubernetesVersion` of `PrepareNode.ps1` if needed. ### Run `kubeadm join` Run the command that was output by `kubeadm init`. For example: ```bash kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash> ``` #### Additional information about kubeadm join {{< note >}} To specify an IPv6 tuple for `<control-plane-host>:<control-plane-port>`, IPv6 address must be enclosed in square brackets, for example: `[2001:db8::101]:2073`. {{< /note >}} If you do not have the token, you can get it by running the following command on the control plane node: ```bash kubeadm token list ``` The output is similar to this: ```console TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS 8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system: signing          token generated by     bootstrappers: 'kubeadm init'.        kubeadm: default-node-token ``` By default, node join tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control plane node: ```bash kubeadm token create ``` The output is similar to this: ```console 5didvk.d09sbcov8ph2amjw ``` If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following commands on the control plane node: ```bash sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey  | openssl rsa -pubin -outform der 2>/dev/null |  openssl dgst -sha256 -hex | sed 's/^.* //' ``` The output is similar to: ```console 8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 ``` The output of the `kubeadm join` command should look something like: ``` [preflight] Running pre-flight checks ... (log output of join workflow) ... Node join complete: * Certificate signing request sent to control-plane and response received. * Kubelet informed of new secure connection details. Run 'kubectl get nodes' on control-plane to see this machine join. ``` A few seconds later, you should notice this node in the output from `kubectl get nodes`. (for example, run `kubectl` on a  control plane node). ### Network configuration CNI setup on clusters mixed with Linux and Windows nodes requires more steps than just running `kubectl apply` on a manifest file. Additionally, the CNI plugin running on control plane nodes must be prepared to support the CNI plugin running on Windows worker nodes. {{% thirdparty-content %}} Only a few CNI plugins currently support Windows. Below you can find individual setup instructions for them: * [Flannel](https://sigs.k8s.io/sig-windows-tools/guides/flannel.md) * [Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/windows-calico/) ### Install kubectl for Windows (optional) {#install-kubectl} See [Install and Set Up kubectl on Windows](/docs/tasks/tools/install-kubectl-windows/). ## {{% heading "whatsnext" %}} * See how to [add Linux worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-linux-nodes/). </ins>


body.cid-community .community-section#meetups p:last-of-type { margin-bottom: 6em; /* extra space for background */ } <ins> } @media only screen and (max-width: 767px) { body.cid-community .community-section h2:before, body.cid-community .community-section h2:after { display: none; } </ins> }  No newline at end of file


$ kubectl attach <podname> -i                             # Attach to Running Container $ kubectl port-forward <podname> <local-and-remote-port>  # Forward port of Pod to your local machine $ kubectl port-forward <servicename> <port>               # Forward port to service <del> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </del> <ins> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </ins> ```


$ kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell $ kubectl attach my-pod -i                            # Attach to Running Container <del> $ kubectl port-forward my-pod 5000:6000               # Forward port 6000 of Pod to your to 5000 on your local machine </del> <ins> $ kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod </ins> $ kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers


[release_date_format] other = "2006-01-02" <ins> # Deprecated. Planned for removal in a future release. # Use [release_full_details_initial_text] instead. [release_complete] other = "完整的" # Replace [release_complete] with [release_full_details_initial_text] [release_full_details_initial_text] other = "完整的" [release_schedule] other = "排期表" [release_changelog] other = "变更记录" </ins> [seealso_heading] other = "另请参见"


<del> You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. </del> <ins> You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. </ins>


Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. <del> In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [Deployments](/docs/concepts/workloads/controllers/deployment/)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management. </del> <ins> In general, users shouldn't need to create pods directly. They should almost always use controllers even for singletons, for example, [Deployments](/docs/concepts/workloads/controllers/deployment/)). Controllers provide self-healing with a cluster scope, as well as replication and rollout management. Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) can also provide support to stateful pods. </ins> The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).


kubectl apply -f <add-on.yaml> ``` <ins> {{< note >}} Only a few CNI plugins support Windows. More details and setup instructions can be found in [Adding Windows worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/#network-config). {{< /note >}} </ins> You can install only one Pod network per cluster. Once a Pod network has been installed, you can confirm that it is working by


convert your old configuration files to a newer version. `kubeadm config images list` and `kubeadm config images pull` can be used to list and pull the images that kubeadm requires. <ins> For more information navigate to [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). </ins> In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used.


<ins> apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh","-c","cat /etc/config/keys" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: special-config items: - key: SPECIAL_LEVEL path: keys restartPolicy: Never </ins>


# i18n strings for the Polish site. # NOTE: Please keep the entries in alphabetical order when editing  # For "and", see [conjunction_1] [auto_generated_edit_notice] other = "(strona utworzona automatycznie)" [auto_generated_pageinfo] other = """
Ta strona została utworzona przez automat.

Jeśli chcesz zgłosić problem dotyczący tej strony, pamiętaj o zaznaczeniu, że została wygenerowana automatycznie. Może być konieczna zmiana w zupełnie innymi miejscu projektu Kubernetes.
"""  [caution] other = "Ostrzeżenie:"


[community_youtube_name] other = "YouTube" <ins> # Avoid using conjunction_1. # Must match the context in layouts/shortcodes/release-data.html # Appears on https://kubernetes.io/releases/ # For example the "and" in "Complete 1.25 Schedule and Changelog" [conjunction_1] other = "i" [cve_id] other = "CVE ID" [cve_issue_url] other = "URL do CVE w GitHubie" [cve_json_external_url] other = "external_url" [cve_json_id] other = "id" [cve_json_summary] other = "podsumowanie" [cve_json_url] other = "url" [cve_summary] other = "Podsumowanie problemu" [cve_table] other = "Oficjalna lista CVE Kubernetesa" [cve_url] other = "CVE URL" </ins> [deprecation_title] other = "Teraz oglądasz dokumentację Kubernetesa w wersji:"


Production likes to run cattle, so let's create some cattle pods. ```shell <del> kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 -n=production </del> <ins> kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production </ins> kubectl get deployment -n=production ```


<ins> --- title: "セキュリティ" weight: 40 --- </ins>


<ins> <?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 19.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  --> <svg version="1.1" id="svg2" inkscape:export-filename="/usr/local/google/home/thockin/src/kubernetes/docs/services-ipvs-overview.png" inkscape:export-xdpi="76.910004" inkscape:export-ydpi="76.910004" inkscape:version="0.48.4 r9939" sodipodi:docname="services-ipvs-overview.svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 656 486" style="enable-background:new 0 0 656 486;" xml:space="preserve"> <style type="text/css"> .st0{fill:none;stroke:#000000;stroke-width:0.8425;} .st1{fill:none;stroke:#000000;stroke-width:2.0786;} .st2{stroke:#000000;stroke-width:2.0786;stroke-linecap:round;} .st3{fill:none;stroke:#000000;stroke-width:5;} .st4{stroke:#000000;stroke-width:4.7036;stroke-linecap:round;} .st5{fill:none;stroke:#000000;stroke-width:4.2928;} .st6{stroke:#000000;stroke-width:4.2928;stroke-linecap:round;} .st7{fill:#85BFF1;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st8{font-family:'ArialMT';} .st9{font-size:32px;} .st10{font-size:24px;} .st11{fill:none;stroke:#000000;stroke-width:5.1965;} .st12{stroke:#000000;stroke-width:5.1965;stroke-linecap:round;} .st13{fill:#F1CB85;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st14{fill:#B9F185;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st15{fill:#EDC1F8;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st16{fill:#FFE680;stroke:#000000;stroke-width:1.7787;} .st17{font-family:'MyriadPro-Regular';} .st18{font-size:40px;} </style> <sodipodi:namedview  bordercolor="#666666" borderopacity="1.0" id="base" inkscape:current-layer="layer1" inkscape:cx="115.9218" inkscape:cy="392.30545" inkscape:document-units="px" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:window-height="822" inkscape:window-maximized="0" inkscape:window-width="1552" inkscape:window-x="203" inkscape:window-y="50" inkscape:zoom="1.0318369" pagecolor="#ffffff" showgrid="false"> </sodipodi:namedview> <g id="layer1" inkscape:groupmode="layer" inkscape:label="Layer 1"> <rect id="rect3116" height="105.80995" width="645.257723" class="st0" y="350.381592" x="5	.318098"/> <rect id="rect3115" x="104.3" y="72.5" class="st0" width="545.8" height="253.1"/> <g id="g4178-3-0" transform="matrix(1,0,0,-0.92578962,15.303948,1193.1996)"> <path id="path4174-3-7" inkscape:connector-curvature="0" class="st1" d="M485.1,1264.5c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-1" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st2" d=" M476.8,1202.5l8.7-15l8.7,15H476.8z"/> </g> <g id="g4178-3-8" transform="matrix(-0.83212211,-1.1231515,0.89570092,-0.89430772,-72.942206,1678.3161)" inkscape:transform-center-x="84.098741" inkscape:transform-center-y="1.4572787e-05"> <path id="path4174-3-4" inkscape:connector-curvature="0" class="st1" d="M501.5,1075.9c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-0" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st2" d=" M493.2,1013.9l8.7-15l8.7,15L493.2,1013.9z"/> </g> <g id="g4324" transform="matrix(0.96592583,0.25881905,0.25881905,-0.96592583,-272.81074,1126.238)"> <path id="path4174-3-2" inkscape:connector-curvature="0" class="st3" d="M362,988.4C260,874.6,260,874.6,260,874.6"/> <path id="path4176-9-9" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st4" d=" M253,881.5l-4.8-18.4l17.8,6.9L253,881.5z"/> </g> <g id="g4324-8" transform="matrix(-0.96592583,0.25881905,-0.25881905,-0.96592583,654.32964,1126.238)"> <path id="path4174-3-2-7" inkscape:connector-curvature="0" class="st3" d="M76.1,911.8C-25.9,798-25.9,798-25.9,798"/> <path id="path4176-9-9-3" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st4" d=" M-32.9,804.9l-4.8-18.4l17.8,6.9L-32.9,804.9z"/> </g> <g id="g4178-3-9" transform="matrix(1,0,0,-1.3566066,-154.75999,1749.5431)"> <path id="path4174-3-8" inkscape:connector-curvature="0" class="st5" d="M485.1,1103.7c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-5" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st6" d=" M476.8,1041.6l8.7-15l8.7,15H476.8z"/> </g> <g id="g3937" transform="translate(-212.35646,769.73074)"> <g id="g3868" transform="matrix(0.88792337,0,0,1,43.50975,6.5250001e-6)"> <rect id="rect2985" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861"> <text transform="matrix(1 0 0 1 203.3918 -377.1545)" class="st8 st9">Backend Pod 1</text> </g> </g> <g id="g3868-7" transform="matrix(0.88792337,0,0,1,262.00231,6.5250001e-6)"> <rect id="rect2985-1" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861-9"> <text transform="matrix(1 0 0 1 203.3919 -377.1545)" class="st8 st9">Backend Pod 2</text> </g> </g> <g id="g3868-3" transform="matrix(0.88792337,0,0,1,480.49489,6.5250001e-6)"> <rect id="rect2985-2" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861-3"> <text transform="matrix(1 0 0 1 203.392 -377.1545)" class="st8 st9">Backend Pod 3</text> </g> </g> </g> <g id="g4178-3" transform="matrix(0.91192623,-0.41035418,-0.37990164,-0.84425184,113.60453,1385.4009)"> <path id="path4174-3" inkscape:connector-curvature="0" class="st11" d="M664.6,1154.3c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st12" d=" M656.2,1092.3l8.7-15l8.7,15H656.2z"/> </g> <g id="g4090" transform="matrix(0.89067003,0,0,1,-194.97295,-142.36286)"> <rect id="rect2985-4" x="388" y="235.5" class="st13" width="224.3" height="58.6"/> <g id="g3861-6" transform="translate(217.6177,652.82516)"> <text transform="matrix(1 0 0 1 233.7419 -377.2347)" class="st8 st9">Client </text> </g> </g> <g id="g4168" transform="matrix(0.89067003,0,0,1,199.65922,-24.251798)"> <rect id="rect2985-4-0" x="216.9" y="119.8" class="st14" width="250" height="58.6"/> <g id="g3861-6-2" transform="translate(34.747433,534.26287)"> <text transform="matrix(1 0 0 1 226.622 -376.7865)" class="st8 st9">kube-proxy</text> </g> </g> <g id="g4168-5" transform="translate(188.04333,-29.041887)"> <g id="g4238" transform="translate(22.087429,-86.34177)"> <rect id="rect2985-4-0-6" x="199.9" y="119.8" class="st15" width="191.8" height="58.6"/> <g id="g3861-6-2-6" transform="translate(39.107429,534.26287)"> <text transform="matrix(1 0 0 1 184.7109 -377.1544)" class="st8 st9">apiserver</text> </g> </g> </g> <path id="path3884" inkscape:connector-curvature="0" class="st16" d="M332.5,202c-14.5,0-27,8.6-33,21.2c-5-0.9-10.3-1.4-15.8-1.4 c-34.3,0-62.2,19.1-62.2,42.6s27.8,42.6,62.2,42.6c16.9,0,32.2-4.6,43.4-12.2c7.4,16.3,34,28.3,65.7,28.3 c33.5,0,61.4-13.4,66.8-31.1c17-5.3,28.6-15.7,28.6-27.7c0-17.3-24.4-31.4-54.4-31.4c-8.5,0-16.5,1.1-23.6,3.1 c-2-10.5-14.8-18.6-30.3-18.6c-5.8,0-11.2,1.2-15.9,3.1C357.7,209.5,345.9,202,332.5,202L332.5,202z"/> <g id="g3861-6-28" transform="matrix(0.89067003,0,0,1,34.810052,629.61733)"> <text transform="matrix(1 0 0 1 259.8564 -379.173)" class="st8 st9">ServiceIP</text> <text transform="matrix(1 0 0 1 240.8564 -339.173)" class="st8 st9" fill="red">(Virtual Server) </text> </g> <text transform="matrix(1 0 0 1 537.5965 317.8163)" class="st17 st18">Node</text> <text transform="matrix(1 0 0 1 230 450)" class="st8 st9" fill="red">(Real Server) </text> </g> </svg> </ins>


<ins> --- title: Adding Linux worker nodes content_type: task weight: 50 --- <!-- overview --> This page explains how to add Linux worker nodes to a kubeadm cluster. ## {{% heading "prerequisites" %}} * Each joining worker node has installed the required components from [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/), such as, kubeadm, the kubelet and a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}}. * A running kubeadm cluster created by `kubeadm init` and following the steps in the document [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). * You need superuser access to the node. <!-- steps --> ## Adding Linux worker nodes To add new Linux worker nodes to your cluster do the following for each machine: 1. Connect to the machine by using SSH or another method. 1. Run the command that was output by `kubeadm init`. For example: ```bash sudo kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash> ``` ### Additional information for kubeadm join {{< note >}} To specify an IPv6 tuple for `<control-plane-host>:<control-plane-port>`, IPv6 address must be enclosed in square brackets, for example: `[2001:db8::101]:2073`. {{< /note >}} If you do not have the token, you can get it by running the following command on the control plane node: ```bash sudo kubeadm token list ``` The output is similar to this: ```console TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS 8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system: signing          token generated by     bootstrappers: 'kubeadm init'.        kubeadm: default-node-token ``` By default, node join tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control plane node: ```bash sudo kubeadm token create ``` The output is similar to this: ```console 5didvk.d09sbcov8ph2amjw ``` If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following commands on the control plane node: ```bash sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey  | openssl rsa -pubin -outform der 2>/dev/null |  openssl dgst -sha256 -hex | sed 's/^.* //' ``` The output is similar to: ```console 8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 ``` The output of the `kubeadm join` command should look something like: ``` [preflight] Running pre-flight checks ... (log output of join workflow) ... Node join complete: * Certificate signing request sent to control-plane and response received. * Kubelet informed of new secure connection details. Run 'kubectl get nodes' on control-plane to see this machine join. ``` A few seconds later, you should notice this node in the output from `kubectl get nodes`. (for example, run `kubectl` on a  control plane node). {{< note >}} As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run on the first control plane node. To provide higher availability, please rebalance the CoreDNS Pods with `kubectl -n kube-system rollout restart deployment coredns` after at least one new node is joined. {{< /note >}} ## {{% heading "whatsnext" %}} * See how to [add Windows worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/). </ins>


| ---------------------------------------- | ---------- | ------- | ----------- | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | <del> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | </del> <ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. | </ins> | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |