Question: <ins> --- title: トポロジーを意識したルーティング content_type: concept weight: 100 description: >- *Topology Aware Routing*は、ネットワークトラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。クラスター内のPod間で同じゾーンのトラフィックを優先することで、信頼性、パフォーマンス(ネットワークの待ち時間やスループット)の向上、またはコストの削減に役立ちます。 --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< note >}} Kubernetes 1.27より前には、この機能は、*Topology Aware Hint*として知られていました。 {{</ note >}} *Topology Aware Routing*は、トラフィックを発信元のゾーンに維持するようにルーティング動作を調整します。場合によっては、コストを削減したり、ネットワークパフォーマンスを向上させたりすることができます。 <!-- body --> ## 動機 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 *Topology Aware Routing*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 ## Topology Aware Routingを有効にする {{< note >}} Kubernetes 1.27より前には、この動作は`service.kubernetes.io/topology-aware-hints`アノテーションを使用して制御されていました。 {{</ note >}} `service.kubernetes.io/topology-mode`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Routingを有効にすることができます。各ゾーンに十分なendpointがある場合、個々のendpointを特定のゾーンに割り当てるために、トポロジーヒントがEndpointSliceに入力され、その結果、トラフィックは発信元の近くにルーティングされます。 ## 最も効果的なとき この機能は、次の場合に最も効果的に動作します。 ### 1. 受信トラフィックが均等に分散されている トラフィックの大部分が単一のゾーンから発信されている場合、トラフィックはそのゾーンに割り当てられたendpointのサブセットに過負荷を与える可能性があります。受信トラフィックが単一のゾーンから発信されることが予想される場合、この機能は推奨されません。 ### 2. 1つのゾーンに3つ以上のendpointを持つサービス {#three-or-more-endpoints-per-zone} 3つのゾーンからなるクラスターでは、これは9つ以上のendpointがあることを意味します。ゾーン毎のendpointが3つ未満の場合、EndpointSliceコントローラーはendpointを均等に割り当てることができず、代わりにデフォルトのクラスター全体のルーティングアプローチに戻る可能性が高く(約50%)なります。 ## 使い方 {#how-it-works} 「Auto」ヒューリスティックは、各ゾーンに多数のendpointを比例的に割り当てようとします。このヒューリスティックは、非常に多くのendpointを持つサービスに最適です。 ### EndpointSliceコントローラー {#implementation-control-plane} このヒューリスティックが有効な場合、EndpointSliceコントローラーはEndpointSliceにヒントを設定する役割を担います。コントローラーは、各ゾーンに比例した量のendpointを割り当てます。この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。 たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 次の例は、ヒントが入力されたときのEndpointSliceの様子を示しています。 ```yaml apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: example-hints labels: kubernetes.io/service-name: example-svc addressType: IPv4 ports: - name: http protocol: TCP port: 80 endpoints: - addresses: - "10.1.2.3" conditions: ready: true hostname: pod-1 zone: zone-a hints: forZones: - name: "zone-a" ``` ### kube-proxy {#implementation-kube-proxy} kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これはkube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。 ## セーフガード 各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。 1. **endpointの数が不十分です:** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。 2. **バランスの取れた割り当てを実現できません:** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 3. **1つ以上のノードの情報が不十分です:** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを1つも見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 ## 制約事項 * Serviceで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 * このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 * EndpointSliceコントローラーは、`node-role.kubernetes.io/control-plane`または`node-role.kubernetes.io/master`ラベルが設定されたノードを無視します。それらのノードでワークロードが実行されている場合、これは問題になる可能性があります。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="toleration" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 * これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 ## カスタムヒューリスティック {#custom-heuristics} Kubernetesは様々な方法でデブロイされ、endpointをゾーンに割り当てるための単独のヒューリスティックは、すべてのユースケースに通用するわけではありません。 この機能の主な目的は、内蔵のヒューリスティックがユースケースに合わない場合に、カスタムヒューリスティックを開発できるようにすることです。カスタムヒューリスティックを有効にするための最初のステップは、1.27リリースに含まれています。これは限定的な実装であり、関連する妥当と思われる状況をまだカバーしていない可能性があります。 ## {{% heading "whatsnext" %}} * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 </ins>

This is a Feature Request What would you like to be The ja documents should be updated about Topology Aware Routing. (Related: ) Why is this needed The ja documents are outdated about Topology Aware Routing. Comments /language ja /assign
/triage accepted


Question: 1. Apply the frontend Deployment from the `frontend-deployment.yaml` file: <ins> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml --> </ins> ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml ``` <del> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml --> </del> 1. Query the list of Pods to verify that the three frontend replicas are running: ```shell

4 ordered lists have wrong indexes. For example, the number below should be 3. ! Page to update: /language en /kind cleanup
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
/assign


Question: You can renew your certificates manually at any time with the `kubeadm certs renew` command. <del> This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. </del> <ins> This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. </ins> After running the command you should restart the control plane Pods. This is required since dynamic certificate reload is currently not supported for all components and certificates. [Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet and not by the API Server, thus kubectl cannot be used to delete and restart them. <del> To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` </del> <ins> To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` </ins> and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/). The kubelet will terminate the Pod if it's no longer in the manifest directory. You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate

The command only has Cobra (CLI) documentation and there are no pointers on what fields are relevant in the configuration passed with --config to it: Add a minimal example + config for the command usage on this page: /sig cluster-lifecycle /kind feature xref
/triage accepted
/language en


Question: Create a directory named `config-exercise`. In your `config-exercise` directory, create a file named `config-demo` with this content: <del> ```shell </del> <ins> ```yaml </ins> apiVersion: v1 kind: Config preferences: {}

Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign


Question:
 --- api_metadata: apiVersion: "scheduling.k8s.io/v1" import: "k8s.io/api/scheduling/v1" kind: "PriorityClass" content_type: "api_reference" description: "PriorityClass 定义了从优先级类名到优先级数值的映射。" title: "PriorityClass" weight: 14 auto_generated: false ---  `apiVersion: scheduling.k8s.io/v1` `import "k8s.io/api/scheduling/v1"`  ## PriorityClass {#PriorityClass}  PriorityClass 定义了从优先级类名到优先级数值的映射。 该值可以是任何有效的整数。
  - **apiVersion**: scheduling.k8s.io/v1  - **kind**: PriorityClass  - **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta) 标准对象的元数据。 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata  - **value** (int32)，必需 此优先级的值。这是 Pod 在其 Pod 规约中有此类名称时收到的实际优先级。  - **description** (string) description 是一个任意字符串，通常提供有关何时应使用此优先级的指南。  - **globalDefault** (boolean) globalDefault 指定是否应将此 PriorityClass 视为没有任何优先级类的 pod 的默认优先级。 只有一个 PriorityClass 可以标记为 `globalDefault`。 但是，如果存在多个 PriorityClasses 且其 `globalDefault` 字段设置为 true， 则将使用此类全局默认 PriorityClasses 的最小值作为默认优先级。  - **preemptionPolicy** (string) PreemptionPolicy 是抢占优先级较低的 Pod 的策略。 可选值：Never、PreemptLowerPriority。 如果未设置，则默认为 PreemptLowerPriority。  ## PriorityClassList {#PriorityClassList} PriorityClassList 是优先级类的集合。
  - **apiVersion**: scheduling.k8s.io/v1  - **kind**: PriorityClassList  - **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta) 标准列表元数据。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata  - **items** ([]<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass)，必需 items 是 PriorityClasses 的列表  ## 操作 {#Operations}
  ### `get` 读取特定的 PriorityClass  #### HTTP 请求 GET /apis/scheduling.k8s.io/v1/priorityclasses/{name}  #### 参数  - **name** （*路径参数*): string，必需 PriorityClass 名称  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): OK 401: Unauthorized  ### `list` 列出或观察 PriorityClass类的对象  #### HTTP 请求 GET /apis/scheduling.k8s.io/v1/priorityclasses  #### 参数  - **allowWatchBookmarks** （*查询参数*）: boolean <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks  - **continue** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue  - **fieldSelector** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector  - **labelSelector** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector  - **limit** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **resourceVersion** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion  - **resourceVersionMatch** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch  - **timeoutSeconds** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  - **watch** （*查询参数*）: boolean <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch  #### 响应 200 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClassList" >}}">PriorityClassList): OK 401: Unauthorized  ### `create` 创建一个 PriorityClass  #### HTTP 请求 POST /apis/scheduling.k8s.io/v1/priorityclasses  #### 参数  - **body**: <a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass，必需  - **dryRun** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): OK 201 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): Created 202 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): Accepted 401: Unauthorized  ### `update` 替换指定的 PriorityClass  #### HTTP 请求 PUT /apis/scheduling.k8s.io/v1/priorityclasses/{name}  #### 参数  - **name** （*路径参数*): string，必需 PriorityClass 名称  - **body**: <a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass，必需  - **dryRun** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): OK 201 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): Created 401: Unauthorized  ### `patch` 部分更新特定的 PriorityClass  #### HTTP 请求 PATCH /apis/scheduling.k8s.io/v1/priorityclasses/{name}  #### 参数  - **name** （*路径参数*): string，必须 PriorityClass 名称  - **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch，必需  - **dryRun** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **force** （*查询参数*）: boolean <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): OK 201 (<a href="{{< ref "../workload-resources/priority-class-v1#PriorityClass" >}}">PriorityClass): Created 401: Unauthorized  ### `delete` 删除一个 PriorityClass  #### HTTP 请求 DELETE /apis/scheduling.k8s.io/v1/priorityclasses/{name}  #### 参数  - **name** （*路径参数*): string，必需 PriorityClass 名称。  - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions  - **dryRun** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **gracePeriodSeconds** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **propagationPolicy** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 202 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): Accepted 401: Unauthorized  ### `deletecollection` 删除 PriorityClass 集合  #### HTTP 请求 DELETE /apis/scheduling.k8s.io/v1/priorityclasses  #### 参数  - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions  - **continue** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue  - **dryRun** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldSelector** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector  - **gracePeriodSeconds** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds  - **labelSelector** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector  - **limit** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit  - **pretty** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **propagationPolicy** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy  - **resourceVersion** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion  - **resourceVersionMatch** （*查询参数*）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch  - **timeoutSeconds** （*查询参数*）: integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 401: Unauthorized

Problem: do not have chinese docs: Proposed Solution: add chinese docs in website Comments /language zh /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
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
this task has already assigned to me, so do not translate it.
ok, got it, thanks.


Question: The [Container runtimes](/docs/setup/production-environment/container-runtimes) page explains that the `systemd` driver is recommended for kubeadm based setups instead <del> of the `cgroupfs` driver, because kubeadm manages the kubelet as a systemd service. </del> <ins> of the kubelet's [default](/docs/reference/config-api/kubelet-config.v1beta1) `cgroupfs` driver, because kubeadm manages the kubelet as a [systemd service](/docs/setup/production-environment/tools/kubeadm/kubelet-integration). </ins> The page also provides details on how to set up a number of different container runtimes with the `systemd` driver by default.

says the default value for is . says: The latter does not say, that prior to 1.23 (thus 1.22, 1.21, 1.20) the default was and was later changed to . It says, that in the nearly end-of-life 1.22 the default is . Later contains: In the above text, it is nowhere stated, that there is a plan to switch the default value of KubeletConfiguration.cgroupDriver from cgroupfs to systemd. The last citation suggests, that will perform implicit switch from to . This is strengthened by the fact about 1.22, where the implicit (default) value seems to be . All in all, the above information stipulates, that in 1.22 the default value was , not it is and in the future will use as implicit (default) value again . In the lack of discussion in the documentation why the defauls change back and forth, this does not make sense,
the kubelet default is cgroupfs and it's not clear if the kubelet graduates cgroupv2 support to GA the value will change. afaik, cgroupfs does not support v2. in any case this can be a disruptive change. kubeadm changed its default to systemd because the kubelet in kubeadm setups is managed by systemd. the reason is explained here long term, the cgroup driver detail should not be exposed to users, but that is blocked on some cri work. /kind support
Ah, so the default cgroup driver for kubelet is cgroupfs, while for kubeadm the default is systemd. This shall be spelled explicitly, as it is counter-intuitive. My understanding so far is, that the systemd-driver supports kernel’s cgroup v2, while kubernetes’ cgroup-driver does not support kernel’s cgroup v2. This shall also be spelled explicitly, as it is confusing.
It sounds like the thing to call out is that, in the kubeadm docs, we should explicitly say that the setting that kubeadm applies by default is an override to the built-in kubelet default. Does that sound right?
Yes. Ideally kubeadm and kubelet shall explicitly state, that their default is distinct from the default of the other tool.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help </details
/triage accepted
/assign


Question: image again: ```shell <del> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' </del> <ins> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.8"}]' </ins> ``` ``` statefulset.apps/web patched

I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.


Question: prefer responding with the same apiVersion they were sent. --> <p> <del> CredentialProviderRequest 包括 kubelet 需要进行身份验证的镜像。 </del> <ins> CredentialProviderRequest 包含 kubelet 需要进行身份验证的镜像。 </ins> Kubelet 会通过标准输入将此请求对象传递给插件。一般来说，插件倾向于用它们所收到的相同的 apiVersion 来响应。 </p>

Translate Chinese version for reference/config-api/kubelet- Comments /language zh /assign
/triage accepted
I think this issue can be included in next time.


Question: used in this tutorial. Follow the necessary steps, based on your environment, storage configuration, and provisioning method, to ensure that all storage is reclaimed. <del> {{< /note >}} </del>  No newline at end of file <ins> {{< /note >}} </ins>

I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.


Question: `delete`        | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. `describe`    | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | Display the detailed state of one or more resources. `diff`        | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.  --> `convert`    | `kubectl convert -f FILENAME [options]` | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。注意 - 需要安装 `kubectl-convert` 插件。 `cordon`    | `kubectl cordon NODE [options]` | 将节点标记为不可调度。 `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 从容器复制文件、目录或将文件、目录复制到容器。 `create`        | `kubectl create -f FILENAME [flags]` | 从文件或 stdin 创建一个或多个资源。 `delete`        |  kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] |  基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源本身，删除资源。 `describe`    | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 `diff`        | `kubectl diff -f FILENAME [flags]`| 在当前起作用的配置和文件或标准输之间作对比 (**BETA**)

web
/retitle [zh-cn] Fix table formatting errors on the kubectl page
/triage accepted


Question: 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. <del> {{< note >}} 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. 자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. {{</ note >}} </del> <ins> {{< note >}} 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. 자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. {{</ note >}} </ins> <del> 1.  업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. </del> <ins> -  업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. </ins> ```shell # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Broken layout on "kubeadm " ! Proposed Solution: Check and apply upstream changes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
/unassign This issue already has been assigned to .


Question: {{% tab name="Linux" %}} <!-- <del> {{< table >}} </del> | Runtime                            | Path to Unix domain socket                   | |------------------------------------|----------------------------------------------| | containerd                         | `unix:///var/run/containerd/containerd.sock` | | CRI-O                              | `unix:///var/run/crio/crio.sock`             | | Docker Engine (using cri-dockerd)  | `unix:///var/run/cri-dockerd.sock`           | <del> {{< /table >}} </del> --> {{< table >}} | 运行时                              | Unix 域套接字                                     |

(kubeadm) []
/triage accepted /kind bug /assign /language zh


Question: [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <del> It is enabled by default. </del> When enabled, the control plane tracks new Jobs using the behavior described below. Jobs created before the feature was enabled are unaffected. As a user,

Update , job-tracking-with-finalizers section, as k/k PR is disabling by default due to an unresolved bug.
Specifically the note () says that "it is enabled by default."
this feature is currently enabled by default in v1.23 and will be disabled in v1.24, right?
/sig apps /language en
I also proposed to disable it by default in 1.23 , but the release managers haven't approved it yet.
/triage accepted /sig apps
/assign
Thanks


Question: - `nodefs.available<10%` - `imagefs.available<15%` - `nodefs.inodesFree<5%` (Linux nodes) <ins> - `imagefs.inodesFree<5%` (Linux nodes) </ins> These default values of hard eviction thresholds will only be set if none of the parameters is changed. If you changed the value of any parameter,

This is a Feature Request As this is merged now, the EvictionHard docs should be updated to include imagefs.inodesFree What would you like to be Adding default settings of imagefs.inodesFree in Page to update: Why is this needed If the user is using separate filesystem for images, it helps to monitor disk pressure if inodes run out on the ImageFs.
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
/sig node /language en
/assign
/retitle Document default settings for in EvictionHard
This issue is fixed by the PR and hence we can close this one
/close
Closing this issue. <detailsIn response to : /close 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


Question: env: - name: DEMO_GREETING value: "Hello from the environment" <ins> - name: DEMO_FAREWELL value: "Such a sweet sorrow" </ins>

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: Documentation example for environment variables only shows one variable, so it is not clear to users how to add a second or subsequent variables Proposed Solution: Add a second variable to the example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign


Question: <ins> --- title: コンテンツの構造化 content_type: concept weight: 40 --- <!-- overview --> このサイトではHugoを使用しています。Hugoでは、[コンテンツの構造化](https://gohugo.io/content-management/organization/)がコアコンセプトとなっています。 <!-- body --> {{% note %}} **Hugoのヒント:** コンテンツの編集を始めるときは、`hugo server --navigateToChanged`コマンドを使用してHugoを実行してください。 {{% /note %}} ## ページの一覧 ### ページの順序 ドキュメントのサイドメニューやページブラウザーなどでは、Hugoのデフォルトのソート順序を使用して一覧を作成しています。デフォルトでは、weight(1から開始)、日付(最新のものが1番目)、最後にリンクのタイトルの順でソートされます。 そのため、特定のページやセッションを上に移動したい場合には、ページのフロントマター内のweightを設定します。 ```yaml title: My Page weight: 10 ``` {{% note %}} ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。 {{% /note %}} ### ドキュメントのメインメニュー ドキュメントのメインメニューは、`docs/`以下に置かれたセクションのコンテンツファイル`_index.md`のフロントマター内に`main_menu`フラグが設定されたものから生成されます。 ```yaml main_menu: true ``` リンクのタイトルは、ページの`linkTitle`から取得されることに注意してください。そのため、ページのタイトルとは異なるリンクテキストにしたい場合、コンテンツファイル内の値を以下のように設定します。 ```yaml main_menu: true title: ページタイトル linkTitle: リンク内で使われるタイトル ``` {{% note %}} 上記の設定は言語ごとに行う必要があります。メニュー上にセクションが表示されないときは、Hugoからセクションとして認識されていないためである可能性が高いです。セクションフォルダー内に`_index.md`コンテンツファイルを作成してください。 {{% /note %}} ### ドキュメントのサイドメニュー ドキュメントのサイドバーメニューは、`docs/`以下の*現在のセクションツリー*から生成されます。 セクションと、そのセクション内のページがすべて表示されます。 特定のセクションやページをリストに表示したくない場合、フロントマター内の`toc_hide`フラグを`true`に設定してください。 ```yaml toc_hide: true ``` コンテンツが存在するセクションに移動すると、特定のセクションまたはページ(例:`index.md`)が表示されます。それ以外の場合、そのセクションの最初のページが表示されます。 ### ドキュメントのブラウザー ドキュメントのホームページのページブラウザーは、`docs`セクション直下のすべてのセクションとページを使用して生成されています。 特定のセクションやページを表示したくない場合、フロントマターの`toc_hide`フラグを`true`に設定してください。 ```yaml toc_hide: true ``` ### メインメニュー 右上のメニュー(およびフッター)にあるサイトリンクは、page-lookupの機能を使用して実装されています。これにより、ページが実際に存在することを保証しています。そのため、たとえば`case-studies`のセクションが特定の言語のサイトに存在しない場合、メニューにはケーススタディのリンクが表示されません。 ## Page Bundle スタンドアローンのコンテンツページ(Markdownファイル)に加えて、Hugoでは、[Page Bundles](https://gohugo.io/content-management/page-bundles/)がサポートされています。 Page Bundleの1つの例は、[カスタムのHugo Shortcode](/docs/contribute/style/hugo-shortcodes/)です。これは、`leaf bundle`であると見做されます。ディレクトリ内のすべてのファイルは、`index.md`を含めてバンドルの一部となります。これには、ページからの相対リンク、処理可能な画像なども含まれます。 ```bash en/docs/home/contribute/includes ├── example1.md ├── example2.md ├── index.md └── podtemplate.json ``` もう1つのPage Bundleがよく使われる例は、`includes`バンドルです。フロントマターに`headless: true`を設定すると、自分自身のURLを持たなくなり、他のページ内でのみ使用されるようになります。 ```bash en/includes ├── default-storage-class-prereqs.md ├── index.md ├── partner-script.js ├── partner-style.css ├── task-tutorial-prereqs.md ├── user-guide-content-moved.md └── user-guide-migration-notice.md ``` バンドル内のファイルに関して、いくつか重要な注意点があります。 * 翻訳されたバンドルに対しては、コンテンツ以外の見つからなかったファイルは上位の言語から継承されます。これにより重複が回避できます。 * バンドル内のすべてのファイルは、Hugoが`Resources`と呼ぶファイルになり、フロントマター(YAMLファイルなど)をサポートしていない場合であっても、言語ごとにパラメーターやタイトルなどのメタデータを提供できます。詳しくは、[Page Resourcesメタデータ](https://gohugo.io/content-management/page-resources/#page-resources-metadata)を参照してください。 * `Resource`の`.RelPermalink`から取得した値は、ページからの相対的なものとなっています。詳しくは、[Permalinks](https://gohugo.io/content-management/urls/#permalinks)を参照してください。 ## スタイル このサイトのスタイルシートの[SASS](https://sass-lang.com/)のソースは、`assets/sass`に置かれていて、Hugoによって自動的にビルドされます。 ## {{% heading "whatsnext" %}} * [カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)について学ぶ * [スタイルガイド](/docs/contribute/style/style-guide)について学ぶ * [コンテンツガイド](/docs/contribute/style/content-guide)について学ぶ </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close 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


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 Set a banner to announce KubeCon 2024 EU Why is this needed We usually turn on a banner for the upcoming KubeCon about 4 weeks ahead of the event, but I've had a request that we run it a bit earlier. Is 8 weeks possible? Logos are available from: (Note: be sure to copy the logo into this repo) should help with text. Also see the config from a previous year's KubeCon. Comments This change will need approval. I would like to set the banner to start on the Jan 26, 2024 and to end on the March 22, 2024 at 1800 CET (UTC+1). If 8 weeks isn't possible, the 4 week dates are Feb 23, 2024 to March 22, 2024. /priority important-soon
/triage accepted
It's worth noting that the existing banner is scheduled to run until Feb 1. Considering this, we might want to keep the KubeCon EU 2024 banner active after that date. How about initiating the banner from Feb 16? This would give us approximately a month (5 weeks) before KubeCon kicks off on March 19, 2024.
I want to help with this. /assign
PR is created to help with this request. Please do review whenever you have the time. Thanks in advance!
I'd appreciate 5 weeks too


Question: <!-- In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_. --> <del> 在 Kubernetes 中，**名字空间（Namespace）**提供一种机制，将同一集群中的资源划分为相互隔离的组。 </del> <ins> 在 Kubernetes 中，**名字空间（Namespace）** 提供一种机制，将同一集群中的资源划分为相互隔离的组。 </ins> 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等， 这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。

markdown <img width="681" alt="WX20220809- src="https://user-"
page: /triage accepted /assign
namespace


Question: <ins> --- title: kubeconfigファイルを使用してクラスターアクセスを組織する content_type: concept weight: 60 --- <!-- overview --> kubeconfigを使用すると、クラスターに、ユーザー、名前空間、認証の仕組みに関する情報を組織できます。`kubectl`コマンドラインツールはkubeconfigファイルを使用してクラスターを選択するために必要な情報を見つけ、クラスターのAPIサーバーと通信します。 {{< note >}} クラスターへのアクセスを設定するために使われるファイルは*kubeconfigファイル*と呼ばれます。これは設定ファイルを指すために使われる一般的な方法です。`kubeconfig`という名前を持つファイルが存在するという意味ではありません。 {{< /note >}} デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。 kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。 <!-- body --> ## 複数のクラスター、ユーザ、認証の仕組みのサポート 複数のクラスターを持っていて、ユーザーやコンポーネントがさまざまな方法で認証を行う次のような状況を考えてみます。 - 実行中のkubeletが証明書を使用して認証を行う可能性がある。 - ユーザーがトークンを使用して認証を行う可能性がある。 - 管理者が個別のユーザに提供する複数の証明書を持っている可能性がある。 kubeconfigファイルを使用すると、クラスター、ユーザー、名前空間を組織化することができます。また、contextを定義することで、複数のクラスターや名前空間を素早く簡単に切り替えられます。 ## Context kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。 current contextを選択するには、以下のコマンドを使用します。 ``` kubectl config use-context ``` ## KUBECONFIG環境変数 `KUBECONFIG`環境変数には、kubeconfigファイルのリストを指定できます。LinuxとMacでは、リストはコロン区切りです。Windowsでは、セミコロン区切りです。`KUBECONFIG`環境変数は必須ではありません。`KUBECONFIG`環境変数が存在しない場合は、`kubectl`はデフォルトのkubeconfigファイルである`$HOME/.kube/config`を使用します。 `KUBECONFIG`環境変数が存在する場合は、`kubectl`は`KUBECONFIG`環境変数にリストされているファイルをマージした結果を有効な設定として使用します。 ## kubeconfigファイルのマージ 設定ファイルを確認するには、以下のコマンドを実行します。 ```shell kubectl config view ``` 上で説明したように、出力は1つのkubeconfigファイルから作られる場合も、複数のkubeconfigファイルをマージした結果となる場合もあります。 `kubectl`がkubeconfigファイルをマージするときに使用するルールを以下に示します。 1. もし`--kubeconfig`フラグが設定されていた場合、指定したファイルだけが使用されます。マージは行いません。このフラグに指定できるのは1つのファイルだけです。 そうでない場合、`KUBECONFIG`環境変数が設定されていた場合には、それをマージするべきファイルのリストとして使用します。`KUBECONFIG`環境変数にリストされたファイルのマージは、次のようなルールに従って行われます。 * 空のファイルを無視する。 * デシリアライズできない内容のファイルに対してエラーを出す。 * 特定の値やmapのキーを設定する最初のファイルが勝つ。 * 値やmapのキーは決して変更しない。 例: 最初のファイルが指定した`current-context`を保持する。 例: 2つのファイルが`red-user`を指定した場合、1つ目のファイルの`red-user`だけを使用する。もし2つ目のファイルの`red-user`以下に競合しないエントリーがあったとしても、それらは破棄する。 `KUBECONFIG`環境変数を設定する例については、[KUBECONFIG環境変数を設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)を参照してください。 それ以外の場合は、デフォルトのkubeconfigファイル`$HOME/.kube/config`をマージせずに使用します。 1. 以下のチェーンで最初に見つかったものをもとにして、使用するcontextを決定する。 1. `--context`コマンドラインフラグが存在すれば、それを使用する。 1. マージしたkubeconrfigファイルから`current-context`を使用する。 この時点では、空のcontextも許容されます。 1. クラスターとユーザーを決定する。この時点では、contextである場合もそうでない場合もあります。以下のチェーンで最初に見つかったものをもとにして、クラスターとユーザーを決定します。この手順はユーザーとクラスターについてそれぞれ1回ずつ、合わせて2回実行されます。 1. もし存在すれば、コマンドラインフラグ`--user`または`--cluster`を使用する。 1. もしcontextが空でなければ、contextからユーザーまたはクラスターを取得する。 この時点では、ユーザーとクラスターは空である可能性があります。 1. 使用する実際のクラスター情報を決定する。この時点では、クラスター情報は存在しない可能性があります。以下のチェーンで最初に見つかったものをもとにして、クラスター情報の各パーツをそれぞれを構築します。 1. もし存在すれば、`--server`、`--certificate-authority`、`--insecure-skip-tls-verify`コマンドラインフラグを使用する。 1. もしマージしたkubeconfigファイルにクラスター情報の属性が存在すれば、それを使用する。 1. もしサーバーの場所が存在しなければ、マージは失敗する。 1. 使用する実際のユーザー情報を決定する。クラスター情報の場合と同じルールを使用して、ユーザー情報を構築します。ただし、ユーザーごとに許可される認証方法は1つだけです。 1. もし存在すれば、`--client-certificate`、`--client-key`、`--username`、`--password`、`--token`コマンドラインフラグを使用する。 1. マージしたkubeconfigファイルの`user`フィールドを使用する。 1. もし2つの競合する方法が存在する場合、マージは失敗する。 1. もし何らかの情報がまだ不足していれば、デフォルトの値を使用し、認証情報については場合によってはプロンプトを表示する。 ## ファイルリファレンス kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。 ## {{% heading "whatsnext" %}} * [複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted


Question: {{< tabs name="kubectl_retainkeys2_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

example commands are missing Resulting in: I will prepare a patch for this.
/triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help 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


Question: {{< tabs name="kubectl_retainkeys2_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

example commands are missing Resulting in: I will prepare a patch for this.
/triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help 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


Question: - justinsb - quinton-hoole title: Running in multiple zones <del> weight: 10 </del> <ins> weight: 20 </ins> content_type: concept --- <!-- overview --> <del> This page describes how to run a cluster in multiple zones. </del> <ins> This page describes running Kubernetes across multiple zones. </ins> <!-- body --> <del> ## Introduction Kubernetes 1.2 adds support for running a single cluster in multiple failure zones (GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones"). This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)). Full Cluster Federation allows combining separate Kubernetes clusters running in different regions or cloud providers (or on-premises data centers).  However, many users simply want to run a more available Kubernetes cluster in multiple zones of their single cloud provider, and this is what the multizone support in 1.2 allows (this previously went by the nickname "Ubernetes Lite"). Multizone support is deliberately limited: a single Kubernetes cluster can run in multiple zones, but only within the same region (and cloud provider).  Only GCE and AWS are currently supported automatically (though it is easy to add similar support for other clouds or even bare metal, by simply arranging for the appropriate labels to be added to nodes and volumes). ## Functionality When nodes are started, the kubelet automatically adds labels to them with zone information. Kubernetes will automatically spread the pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures.)  With multiple-zone clusters, this spreading behavior is extended across zones (to reduce the impact of zone failures.)  (This is achieved via `SelectorSpreadPriority`).  This is a best-effort placement, and so if the zones in your cluster are heterogeneous (e.g. different numbers of nodes, different types of nodes, or different pod resource requirements), this might prevent perfectly even spreading of your pods across zones. If desired, you can use homogeneous zones (same number and types of nodes) to reduce the probability of unequal spreading. When persistent volumes are created, the `PersistentVolumeLabel` admission controller automatically adds zone labels to them.  The scheduler (via the `VolumeZonePredicate` predicate) will then ensure that pods that claim a given volume are only placed into the same zone as that volume, as volumes cannot be attached across zones. ## Limitations There are some important limitations of the multizone support: * We assume that the different zones are located close to each other in the network, so we don't perform any zone-aware routing.  In particular, traffic that goes via services might cross zones (even if some pods backing that service exist in the same zone as the client), and this may incur additional latency and cost. * Volume zone-affinity will only work with a `PersistentVolume`, and will not work if you directly specify an EBS volume in the pod spec (for example). * Clusters cannot span clouds or regions (this functionality will require full federation support). * Although your nodes are in multiple zones, kube-up currently builds a single master node by default.  While services are highly available and can tolerate the loss of a zone, the control plane is located in a single zone.  Users that want a highly available control plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions. ### Volume limitations The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). * StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with pod affinity or anti-affinity policies. * If the name of the StatefulSet contains dashes ("-"), volume zone spreading may not provide a uniform distribution of storage across zones. * When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass needs to be configured for a specific single zone, or the PVs need to be statically provisioned in a specific zone. Another workaround is to use a StatefulSet, which will ensure that all the volumes for a replica are provisioned in the same zone. ## Walkthrough We're now going to walk through setting up and using a multi-zone cluster on both GCE & AWS.  To do so, you bring up a full cluster (specifying `MULTIZONE=true`), and then you add nodes in additional zones by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`). ### Bringing up your cluster Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a. GCE: ```shell curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash ``` AWS: ```shell curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash ``` This step brings up a cluster as normal, still running in a single zone (but `MULTIZONE=true` has enabled multi-zone capabilities). ### Nodes are labeled View the nodes; you can see that they are labeled with zone information. They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far.  The labels are `failure-domain.beta.kubernetes.io/region` for the region, and `failure-domain.beta.kubernetes.io/zone` for the zone: ```shell kubectl get nodes --show-labels ``` The output is similar to this: ```shell NAME                     STATUS                     ROLES    AGE   VERSION          LABELS kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q ``` ### Add more nodes in a second zone Let's add another set of nodes to the existing cluster, reusing the existing master, running in a different zone (us-central1-b or us-west-2b). We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true` kube-up will not create a new master, but will reuse one that was previously created instead. GCE: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh ``` On AWS we also need to specify the network CIDR for the additional subnet, along with the master internal IP address: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` View the nodes again; 3 more nodes should have launched and be tagged in us-central1-b: </del> <ins> ## Background </ins> <del> ```shell kubectl get nodes --show-labels ``` </del> <ins> Kubernetes is designed so that a single Kubernetes cluster can run across multiple failure zones, typically where these zones fit within a logical grouping called a _region_. Major cloud providers define a region as a set of failure zones (also called _availability zones_) that provide a consistent set of features: within a region, each zone offers the same APIs and services. </ins> <del> The output is similar to this: </del> <ins> Typical cloud architectures aim to minimize the chance that a failure in one zone also impairs services in another zone. </ins> <del> ```shell NAME                     STATUS                     ROLES    AGE   VERSION           LABELS kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i ``` </del> <ins> ## Control plane behavior </ins> <del> ### Volume affinity </del> <ins> All [control plane components](/docs/concepts/overview/components/#control-plane-components) support running as a pool of interchangable resources, replicated per component. </ins> <del> Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity): ```bash kubectl apply -f - <<EOF { "apiVersion": "v1", "kind": "PersistentVolumeClaim", "metadata": { "name": "claim1", "annotations": { "volume.alpha.kubernetes.io/storage-class": "foo" } }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "5Gi" } } } } EOF ``` </del> <ins> When you deploy a cluster control plane, place replicas of control plane components across multple failure zones. If availability is an important concern, select at least three failure zones and replicate each individual control plane component (API server, scheduler, etcd, cluster controller manager) across at least three failure zones. If you are running a cloud controller manager then you should also replicate this across all the failure zones you selected. </ins> {{< note >}} <del> For version 1.3+ Kubernetes will distribute dynamic PV claims across the configured zones. For version 1.2, dynamic persistent volumes were always created in the zone of the cluster master (here us-central1-a / us-west-2a); that issue ([#23330](https://github.com/kubernetes/kubernetes/issues/23330)) was addressed in 1.3+. </del> <ins> Kubernetes does not provide cross-zone resilience for the API server endpoints. You can use various techniques to improve availability for the cluster API server, including DNS round-robin, SRV records, or a third-party load balancing solution with health checking. </ins> {{< /note >}} <del> Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. ```shell kubectl get pv --show-labels ``` The output is similar to this: ```shell NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` So now we will create a pod that uses the persistent volume claim. Because GCE PDs / AWS EBS volumes cannot be attached across zones, this means that this pod can only be created in the same zone as the volume: ```yaml kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: claim1 EOF ``` Note that the pod was automatically created in the same zone as the volume, as cross-zone attachments are not generally permitted by cloud providers: ```shell kubectl describe pod mypod | grep Node ``` ```shell Node:        kubernetes-minion-9vlv/10.240.0.5 ``` And check node labels: ```shell kubectl get node kubernetes-minion-9vlv --show-labels ``` ```shell NAME                     STATUS    AGE    VERSION          LABELS kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv ``` ### Pods are spread across zones Pods in a replication controller or service are automatically spread across zones.  First, let's launch more nodes in a third zone: GCE: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh ``` AWS: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` Verify that you now have nodes in 3 zones: ```shell kubectl get nodes --show-labels ``` Create the guestbook-go example, which includes an RC of size 3, running a simple web app: </del> <ins> ## Node behavior </ins> <del> ```shell find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} ``` </del> <ins> Kubernetes automatically spreads the Pods for workload resources (such as {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}) across different nodes in a cluster. This spreading helps reduce the impact of failures. </ins> <del> The pods should be spread across all 3 zones: </del> <ins> When nodes start up, the kubelet on each node automatically adds {{< glossary_tooltip text="labels" term_id="label" >}} to the Node object that represents that specific kubelet in the Kubernetes API. These labels can include [zone information](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone). </ins> <del> ```shell kubectl describe pod -l app=guestbook | grep Node ``` </del> <ins> If your cluster spans multiple zones or regions, you can use node labels in conjunction with [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) to control how Pods are spread across your cluster among fault domains: regions, zones, and even specific nodes. These hints enable the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} to place Pods for better expected availability, reducing the risk that a correlated failure affects your whole workload. </ins> <del> ```shell Node:        kubernetes-minion-9vlv/10.240.0.5 Node:        kubernetes-minion-281d/10.240.0.8 Node:        kubernetes-minion-olsh/10.240.0.11 ``` </del> <ins> For example, you can set a constraint to make sure that the 3 replicas of a StatefulSet are all running in different zones to each other, whenever that is feasible. You can define this declaratively without explicitly defining which availability zones are in use for each workload. </ins> <del> ```shell kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels ``` </del> <ins> ### Distributing nodes across zones </ins> <del> ```shell NAME                     STATUS    ROLES    AGE    VERSION          LABELS kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh ``` </del> <ins> Kubernetes' core does not create nodes for you; you need to do that yourself, or use a tool such as the [Cluster API](https://cluster-api.sigs.k8s.io/) to manage nodes on your behalf. Using tools such as the Cluster API you can define sets of machines to run as worker nodes for your cluster across multiple failure domains, and rules to automatically heal the cluster in case of whole-zone service disruption. </ins> <del> Load-balancers span all zones in a cluster; the guestbook-go example includes an example load-balanced service: </del> <ins> ## Manual zone assignment for Pods </ins> <del> ```shell kubectl describe service guestbook | grep LoadBalancer.Ingress ``` The output is similar to this: ```shell LoadBalancer Ingress:   130.211.126.21 ``` Set the above IP: ```shell export IP=130.211.126.21 ``` Explore with curl via IP: ```shell curl -s http://${IP}:3000/env | grep HOSTNAME ``` The output is similar to this: ```shell "HOSTNAME": "guestbook-44sep", ``` Again, explore multiple times: ```shell (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq ``` The output is similar to this: ```shell "HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-hum5n", "HOSTNAME": "guestbook-ppm40", ``` The load balancer correctly targets all the pods, even though they are in multiple zones. ### Shutting down the cluster When you're done, clean up: GCE: ```shell KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh ``` AWS: ```shell KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` </del> <ins> You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) to Pods that you create, as well as to Pod templates in workload resources such as Deployment, StatefulSet, or Job. ## Storage access for zones When persistent volumes are created, the `PersistentVolumeLabel` [admission controller](/docs/reference/access-authn-authz/admission-controllers/) automatically adds zone labels to any PersistentVolumes that are linked to a specific zone. The {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} then ensures, through its `NoVolumeZoneConflict` predicate, that pods which claim a given PersistentVolume are only placed into the same zone as that volume. You can specify a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} for PersistentVolumeClaims that specifies the failure domains (zones) that the storage in that class may use. To learn about configuring a StorageClass that is aware of failure domains or zones, see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies). ## Networking By itself, Kubernetes does not include zone-aware networking. You can use a [network plugin](docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) to configure cluster networking, and that network solution might have zone-specific elements. For example, if your cloud provider supports Services with `type=LoadBalancer`, the load balancer might only send traffic to Pods running in the same zone as the load balancer element processing a given connection. Check your cloud provider's documentation for details. For custom or on-premises deployments, similar considerations apply. {{< glossary_tooltip text="Service" term_id="service" >}} and {{< glossary_tooltip text="Ingress" term_id="ingress" >}} behavior, including handling of different failure zones, does vary depending on exactly how your cluster is set up. ## Fault recovery When you set up your cluster, you might also need to consider whether and how your setup can restore service if all of the failure zones in a region go off-line at the same time. For example, do you rely on there being at least one node able to run Pods in a zone? Make sure that any cluster-critical repair work does not rely on there being at least one healthy node in your cluster. For example: if all nodes are unhealthy, you might need to run a repair Job with a special {{< glossary_tooltip text="toleration" term_id="toleration" >}} so that the repair can complete enough to bring at least one node into service. Kubernetes doesn't come with an answer for this challenge; however, it's something to consider. ## {{% heading "whatsnext" %}} To learn how the scheduler places Pods in a cluster, honoring the configured constraints, visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/). </ins>

Could you please reference Azure (AKS) here too, as some customer reach your site first and think that AKS is not offering zone support: Thanks
Hi - would you be willing to provide a review (formally or informally) on

This is a Feature Request What would you like to be Revise and restructure the page about running in multiple failure zones. create a new task page about building a cluster that spans at least 2 failure zones optionally create a follow-on task page to demonstrate additional concepts, such as Volume affinity to zones. revise to explain what approach cluster operators should take and why they should follow it. failure zones should be geographically& separate consider using a managed control plane where appropriate if deploying your own control plane, run that (including etcd) across multiple zones also make sure nodes are available in multiple zones CNI considerations for running in multiple zones as good practice, cluster autoscaling should also be zone aware (run enough nodes to spread ReplicaSets etc across zones as required) Why is this needed is out of date: it talks about Kubernetes v1.2, minions, and the v1 Federation design. The page recommends using  to bring up a cluster. As I understand it, and the whole folder it lives in are deprecated. Comments Relevant to as SIG Cluster Lifecycle has expressed an intent to maintain this section of the documentation. /language en
This covers some of the same ground as
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/priority backlog
/sig cluster-lifecycle /remove-lifecycle stale
I noticed that doesn't really cover the benefits of a multi-master control plane. That'd be worth explaining too.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
i'm not familiar with the authorship of this page, but it seems to fall under SIG Cloud Provider. potentially Node / Storage too. /remove-sig cluster-lifecycle /sig cluster-lifecycle
/sig cloud-provider
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
I'm planning to remove the cloud-provider stuff as it's both outdated and not really in line with the . /remove-lifecycle stale


Question: Administrators can specify a default StorageClass just for PVCs that don't request any particular class to bind to: see the <del> [PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1) </del> <ins> [PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) </ins> for details. ```yaml

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The following documents contain the broken link which points to the wrong section name: concepts/storage/storage-[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1) tasks/administer-cluster/change-default-storage-[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1) Proposed Solution: Fix the wrong section name as the below: concepts/storage/storage-[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) tasks/administer-cluster/change-default-storage-[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
/kind bug


Question: ## {{% heading "whatsnext" %}} <del> * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) </del> <ins> * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) </ins>  No newline at end of file

This is a Bug Report Problem: The versions of the cri-tools and cni-plugins dependencies was updated in packages, but not in the documentation: Proposed Solution: Update the versions, to match what is in the deb/rpm packages. Currently they are not pinned, but installs the latest: Compared with the deb installation: Page to Update: Kubernetes Version: 27.0 <!--Additional Information:--Related:
/sig cluster-lifecycle /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cluster-lifecycle /help 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 accepted /priority backlog
/assign
/unassign


Question: OpenStack Heat       | Saltstack    | CentOS | Neutron + flannel hostgw | [docs](/docs/getting-started-guides/openstack-heat)            |  Community ([@FujitsuEnablingSoftwareTechnologyGmbH](https://github.com/FujitsuEnablingSoftwareTechnologyGmbH)) Rackspace            | CoreOS       | CoreOS | flannel     | [docs](/docs/getting-started-guides/rackspace)                              |  Community ([@doublerr](https://github.com/doublerr)) any                  | any          | any    | any         | [docs](/docs/getting-started-guides/scratch)                                |  Community ([@erictune](https://github.com/erictune)) <ins> any                  | any          | any    | any         | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/)                                |  Commercial and Community </ins> **Note**: The above table is ordered by version test/used in nodes, followed by support level.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The Table of Solutions should mention Calico with a pointer into the Calico docs. Probably with one pretty general row. Proposed Solution: Add one row with IaaS-Provider=any, Config-Mgmt=any, OS=any, Networking=any, , Support=Commercial and Community Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
CC
should we close this ?
Yeah, it looks resolved.


Question: ## API removals, deprecations, and other changes for Kubernetes 1.24 * [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information. <del> * [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=). * In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://git.k8s.io/design-proposals-archive/storage/csi-migration.md#background-and-motivations) for more information. </del> <ins> * [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=). </ins> * [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. * [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint).

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In the blog , there is a paragraph about Portworx CSI driver migration. This was because Portworx was originally targeting Beta in 1.24 so the in-tree plugin will be deprecated as a result of that. However, Portworx CSI migration didn't make it, so it stayed in Alpha in 1.24. They will try to target Beta again in 1.25. So the following paragraph should be removed from the 1.24 blog. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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
/area blog /sig release We should not remove that paragraph; however, we can follow it with a clarifying statement, and we can strike through text that is no longer correct.
I dont know its worth to mention, along with , was also in the same state, that said, both entered in 1.23 and then tried beta in , but both didnt make it.. I am not sure how only one landed in first place though.
/assign
/retitle Section regarding Portworx in-tree plugin deprecation should be removed from blog
what according to you should be more?
Hi! , according to you what changes should be done to the file so that I can have a basic idea regarding the same if we both are inclining at same thought?


Question: object to make actual Pods. The `PodTemplate` is part of the desired state of whatever workload resource you used to run your app. <ins> When you create a Pod, you can include [environment variables](/docs/tasks/inject-data-application/define-environment-variable-container/) in the Pod template for the containers that run in the Pod. </ins> The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses.

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 In , briefly mention that you can set environment variables for containers in Pods, and link to our pages about that. No need to add an explanation; this is about helping people discover the feature. Why is this needed This is about helping people discover the feature. Comments /sig node /language en
Relevant to
Potential improvement, worth doing. /priority backlog /triage accepted
I would like to assist in resolving this issue. Thanks! /assign
PRs are welcome!


Question: A node is eligible for exclusion if labelled with "`node.kubernetes.io/exclude-from-external-load-balancers`". - `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. <del> See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details. </del> - `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as the hostname of a pod. See

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Topology-aware traffic routing with topology keys is deprecated since 1.21 Confirm if it's removed and remove the related documentation if feature is removed Proposed Solution: Remove Service Topology page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Deprecated since 1.21 <!--Additional Information:--
/kind cleanup /language en
I can look into this. /assign
/sign network /triage accepted /priority important-longterm
Thanks


Question: PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数( <del> [makeLinkVariables関数](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 </del> <ins> [makeLinkVariables関数](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 </ins> 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。

Problem: Based on , I have created this issue/task to help update the [ja] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ja" /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/containers/container- 46: IPDNS /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- 146: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- 283: )Service /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- 220: {{< param "fullversion" }}: 223: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- 34: Linux{{< param "fullversion" }}: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: macOS{{< param "fullversion" }}: 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 181: {{< 181: "fullversion" }}){{< param "fullversion" }} 186: curl -LO {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- 107: Kubernetes{{< param "fullversion" }} 111: releases/latest/download/kube- kubectl apply -f - 150: .PrepareNode.

ps1 -KubernetesVersion {{% param "fullversion" %}} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- 35: # {{% param "fullversion" %}} 36: -Lo C:k {{% param "fullversion" %}} 70: -Lo C:k {{% param "fullversion" %}} 86: {{< param "fullversion" }}: 89: releases/latest/download/kube- kubectl apply -f - /sig docs /sig localization /language ja cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- /sig localization /language ja cc: 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
cc:
/triage accepted /area localization /priority backlog


Question: <del> --- title: 知名标签（Label）、注解（Annotation）和 污点（Taint） content_type: concept weight: 60 --- <!-- overview --> <!-- Kubernetes reserves all labels and annotations in the kubernetes.io namespace. This document serves both as a reference to the values and as a coordination point for assigning values. --> Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。 本文档提供这些标签、注解和污点的参考，也可用来协调对这类标签、注解和污点的设置。 <!-- body --> ## kubernetes.io/arch <!-- Example: `kubernetes.io/arch=amd64` Used on: Node The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be handy if you are mixing arm and x86 nodes. --> 示例：`kubernetes.io/arch=amd64` 用于：Node Kubelet 用 Go 中定义的 `runtime.GOARCH` 值来填充该标签。这在诸如混用 arm 和 x86 节点的情况下很有用。 ## kubernetes.io/os <!-- Example: `kubernetes.io/os=linux` Used on: Node The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems in your cluster (for example: mixing Linux and Windows nodes). --> 示例：`kubernetes.io/os=linux` 用于：Node Kubelet 用该 Go 中定义的 `runtime.GOOS` 值来填充该标签。这在集群中存在不同操作系统的节点时很有用（例如：混合 Linux 和 Windows 操作系统的节点）。 <!-- ## beta.kubernetes.io/arch (deprecated) --> ## beta.kubernetes.io/arch (已弃用) <!-- This label has been deprecated. Please use `kubernetes.io/arch` instead. --> 该标签已被弃用。请使用  `kubernetes.io/arch`。 <!-- ## beta.kubernetes.io/os (deprecated) --> ## beta.kubernetes.io/os (已弃用) <!-- This label has been deprecated. Please use `kubernetes.io/os` instead. --> 该标签已被弃用。请使用 `kubernetes.io/os`。 ## kubernetes.io/hostname <!-- Example: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` Used on: Node The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`. --> 示例：`kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` 用于：Node Kubelet 用 hostname 值来填充该标签。注意：可以通过向 `kubelet` 传入 `--hostname-override` 参数对 “真正的” hostname 进行修改。 <!-- This label is also used as part of the topology hierarchy.  See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information. --> 此标签还用作拓扑层次结构的一部分。有关更多信息，请参见 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 <!-- ## beta.kubernetes.io/instance-type (deprecated) --> ## beta.kubernetes.io/instance-type (已弃用) {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). --> 从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type)。 {{< /note >}} ## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} <!-- Example: `node.kubernetes.io/instance-type=m3.medium` Used on: Node The Kubelet populates this with the instance type as defined by the `cloudprovider`. This will be set only if you are using a `cloudprovider`. This setting is handy if you want to target certain workloads to certain instance types, but typically you want to rely on the Kubernetes scheduler to perform resource-based scheduling. You should aim to schedule based on properties rather than on instance types (for example: require a GPU, instead of requiring a `g2.2xlarge`). --> 示例：`node.kubernetes.io/instance-type=m3.medium` 用于：Node Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。未使用 `cloudprovider` 时不会设置该标签。 该标签在想要将某些负载定向到特定实例类型的节点上时会很有用，但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度， 所以用户应该致力于基于属性而不是实例类型来进行调度（例如：需要一个 GPU，而不是 `g2.2xlarge`）。 ## failure-domain.beta.kubernetes.io/region (已弃用) {#failure-domainbetakubernetesioregion} <!-- See [topology.kubernetes.io/region](#topologykubernetesioregion). --> 参考 [topology.kubernetes.io/region](#topologykubernetesioregion)。 {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion). --> 从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [topology.kubernetes.io/region](#topologykubernetesioregion)。 {{< /note >}} ## failure-domain.beta.kubernetes.io/zone (已弃用) {#failure-domainbetakubernetesiozone} <!-- See [topology.kubernetes.io/zone](#topologykubernetesiozone). --> 参考 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 {{< note >}} <!-- Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). --> 从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 {{< /note >}} ## topology.kubernetes.io/region {#topologykubernetesioregion} <!-- Example: `topology.kubernetes.io/region=us-east-1` --> 示例： `topology.kubernetes.io/region=us-east-1` <!-- See [topology.kubernetes.io/zone](#topologykubernetesiozone). --> 参考 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 ## topology.kubernetes.io/zone {#topologykubernetesiozone} <!-- Example: `topology.kubernetes.io/zone=us-east-1c` On Node: The `kubelet` or the external `cloud-controller-manager` populates this with the information as provided by the `cloudprovider`.  This will be set only if you are using a `cloudprovider`. However, you should consider setting this on nodes if it makes sense in your topology. --> 示例： `topology.kubernetes.io/zone=us-east-1c` 用于：Node、PersistentVolume 对于 Node： `Kubelet` 或外部 `cloud-controller-manager` 用 `cloudprovider` 中定义的区域信息来填充该标签。 未使用 `cloudprovider` 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。 <!-- On PersistentVolume: topology-aware volume provisioners will automatically set node affinity constraints on `PersistentVolumes`. --> 对于 PersistentVolume：可感知拓扑的卷制备程序将自动在 `PersistentVolumes` 上设置节点亲和性约束。 <!-- A zone represents a logical failure domain.  It is common for Kubernetes clusters to span multiple zones for increased availability.  While the exact definition of a zone is left to infrastructure implementations, common properties of a zone include very low network latency within a zone, no-cost network traffic within a zone, and failure independence from other zones.  For example, nodes within a zone might share a network switch, but nodes in different zones should not. --> 区域代表逻辑故障域。Kubernetes 集群通常跨越多个区域以提高可用性。 虽然区域的确切定义留给基础架构实现，但是区域的常见属性包括区域内的网络延迟非常低，区域内的免费网络流量以及与其他区域的故障独立性。 例如，一个区域内的节点可能共享一个网络交换机，但不同区域内的节点则不应共享。 <!-- A region represents a larger domain, made up of one or more zones.  It is uncommon for Kubernetes clusters to span multiple regions,  While the exact definition of a zone or region is left to infrastructure implementations, common properties of a region include higher network latency between them than within them, non-zero cost for network traffic between them, and failure independence from other zones or regions.  For example, nodes within a region might share power infrastructure (e.g. a UPS or generator), but nodes in different regions typically would not. --> 地区代表一个更大的域，由一个或多个区域组成。 Kubernetes 集群跨越多个地域是不常见的，而地域或区域的确切定义则留给基础设施实现， 地域的共同属性包括它们之间的网络延迟比它们内部更高，它们之间的网络流量成本不为零，故障独立于其他区域或域。 例如，一个地域内的节点可能共享电力基础设施（例如 UPS 或发电机），但不同地域的节点通常不会共享。 <!-- Kubernetes makes a few assumptions about the structure of zones and regions: 1) regions and zones are hierarchical: zones are strict subsets of regions and no zone can be in 2 regions 2) zone names are unique across regions; for example region "africa-east-1" might be comprised of zones "africa-east-1a" and "africa-east-1b" --> Kubernetes 对区域和区域的结构做了一些假设: 1) 地域和区域是分层的:区域是地域的严格子集，任何区域都不能位于两个地域中。 2) 区域名称在地域之间是唯一的；例如，地域 “africa-east-1” 可能包含区域 “africa-east-1a” 和 “africa-east-1b”。 <!-- It should be safe to assume that topology labels do not change. Even though labels are strictly mutable, consumers of them can assume that a given node is not going to be moved between zones without being destroyed and recreated. --> 标签的使用者可以安全地假设拓扑标签不变。 即使标签是严格可变的，标签的使用者也可以认为节点只能通过被销毁并重建才能从一个区域迁移到另一个区域。 <!-- Kubernetes can use this information in various ways. For example, the scheduler automatically tries to spread the Pods in a ReplicaSet across nodes in a single-zone cluster (to reduce the impact of node failures, see [kubernetes.io/hostname](#kubernetesiohostname)). With multiple-zone clusters, this spreading behavior also applies to zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_. --> Kubernetes 可以以各种方式使用这些信息。 例如，调度器自动尝试将 ReplicaSet 中的多个 Pods 分布到单区域集群中的多个节点上（为了减少节点故障的影响， 请参阅 [kubernetesiohostname](#kubernetesiohostname)）。 对于多区域集群，这种分布行为也被应用到区域上（以减少区域故障的影响）。 这是通过 _SelectorSpreadPriority_ 实现的。 <!-- _SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading. --> _SelectorSpreadPriority_ 是一种尽力而为（best-effort）的处理方式，如果集群中的区域是异构的 (例如：不同区域之间的节点数量、节点类型或 Pod 资源需求不同），可能使得 Pod 在各区域间无法均匀分布。 如有需要，用户可以使用同质的区域(节点数量和类型相同) 来减小 Pod 分布不均的可能性。 <!-- The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones. --> 由于卷不能跨区域挂载（Attach），调度器（通过 _VolumeZonePredicate_ 预选）也会保证需要特定卷的 Pod 被调度到卷所在的区域中。 <!-- If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. --> 如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod 跨区域进行卷的挂载， 应考虑手动打标签 (或增加对 `PersistentVolumeLabel` 的支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。 </del>

This is a Feature Request translate content/en/docs/tasks/tools/install-kubectl- into Chinese What would you like to be content/zh/docs/reference/labels-annotations- /assign /language zh
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: nohup.out # Hugo output <del> public/ resources/ </del> <ins> /public/ /resources/ </ins> .hugo_build.lock # Netlify Functions build output package-lock.json <del> functions/ node_modules/ </del> <ins> /functions/ /node_modules/ </ins> # Generated files when building with make container-build .config/

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 Update the to only ignore the directories and at the top level of the repository. Why is this needed If somebody wants to create a content directory named , that ignore will conflict. We should tidy it so it wouldn't. Comments /kind cleanup Docs for : https://git-
Can you assign it to me..??
/assign
/triage accepted
/priority backlog


Question: is running the Redis server. With this connection in place you can use your local workstation to debug the database that is running in the pod. <ins> **Warning**: Due to known limitations, port forward today only works for TCP protocol. The support to UDP protocol is being tracked in [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862). {: .warning} </ins> {% endcapture %}

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This works only for TCP ports, documentation should mention it. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign