Question:
It is very difficult to find any links to the . This is a huge roadblock to new users trying to do anything custom with kubeadm. As a new user, I don't expect to have to read about to find information about configuring the tool. To someone who is unfamiliar with the project, that seems like more advanced documentation than I should need, and therefore not somewhere I would expect to find basic config file documentation. I also was able to find the long before I found the more user-friendly documentation, which made it seem like that was the only documentation that exists. I would expect a link to those docs to be available on the kubeadm-config page, as well as where config files are mentioned in the kubeadm-init and kubeadm-join pages.
/language en
it seems you have missed these two sections: and for these commands the kubeadm API is actually the most important for. linking the command line reference page to the API makes sense. but instead of linking to a particular version of the API we should link to: and let users navigate to a particular API version. this is done with the idea that can also migrate v1beta1 -v1beta2. PRs welcome. thanks /sig cluster-lifecycle /priority backlog /help wanted
. I will keep most of the discussion over there for now.
/remove-help /assign /lifecycle-active sending a PR with:

It's possible to configure `kubeadm init` with a configuration file instead of command line flags, and some more advanced features may only be available as <del> configuration file options. This file is passed with the `--config` option. </del> <ins> configuration file options. This file is passed using the `--config` flag and it must contain a `ClusterConfiguration` structure and optionally more structures separated by `---n` Mixing `--config` with others flags may not be allowed in some cases. </ins> The default configuration can be printed out using the [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. <del> It is **recommended** that you migrate your old `v1beta1` configuration to `v1beta2` using </del> <ins> If your configuration is not using the latest version it is **recommended** that you migrate using </ins> the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. <del> For more details on each field in the `v1beta2` configuration you can navigate to our [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). </del> <ins> For more information on the fields and usage of the configuration you can navigate to our API reference page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories). </ins> ### Adding kube-proxy parameters {#kube-proxy}


Question:
It is very difficult to find any links to the . This is a huge roadblock to new users trying to do anything custom with kubeadm. As a new user, I don't expect to have to read about to find information about configuring the tool. To someone who is unfamiliar with the project, that seems like more advanced documentation than I should need, and therefore not somewhere I would expect to find basic config file documentation. I also was able to find the long before I found the more user-friendly documentation, which made it seem like that was the only documentation that exists. I would expect a link to those docs to be available on the kubeadm-config page, as well as where config files are mentioned in the kubeadm-init and kubeadm-join pages.
/language en
it seems you have missed these two sections: and for these commands the kubeadm API is actually the most important for. linking the command line reference page to the API makes sense. but instead of linking to a particular version of the API we should link to: and let users navigate to a particular API version. this is done with the idea that can also migrate v1beta1 -v1beta2. PRs welcome. thanks /sig cluster-lifecycle /priority backlog /help wanted
. I will keep most of the discussion over there for now.
/remove-help /assign /lifecycle-active sending a PR with:

It's possible to configure `kubeadm join` with a configuration file instead of command line flags, and some more advanced features may only be available as configuration file options. This file is passed using the `--config` flag and it must <del> contain a `JoinConfiguration` structure. </del> <ins> contain a `JoinConfiguration` structure. Mixing `--config` with others flags may not be allowed in some cases. </ins> <del> To print the default values of `JoinConfiguration` run the following command: </del> <ins> The default configuration can be printed out using the [kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. </ins> <del> ```shell kubeadm config print join-defaults ``` </del> <ins> If your configuration is not using the latest version it is **recommended** that you migrate using the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. </ins> <del> For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration). </del> <ins> For more information on the fields and usage of the configuration you can navigate to our API reference page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories). </ins> ## {{% heading "whatsnext" %}}


Question:
It is very difficult to find any links to the . This is a huge roadblock to new users trying to do anything custom with kubeadm. As a new user, I don't expect to have to read about to find information about configuring the tool. To someone who is unfamiliar with the project, that seems like more advanced documentation than I should need, and therefore not somewhere I would expect to find basic config file documentation. I also was able to find the long before I found the more user-friendly documentation, which made it seem like that was the only documentation that exists. I would expect a link to those docs to be available on the kubeadm-config page, as well as where config files are mentioned in the kubeadm-init and kubeadm-join pages.
/language en
it seems you have missed these two sections: and for these commands the kubeadm API is actually the most important for. linking the command line reference page to the API makes sense. but instead of linking to a particular version of the API we should link to: and let users navigate to a particular API version. this is done with the idea that can also migrate v1beta1 -v1beta2. PRs welcome. thanks /sig cluster-lifecycle /priority backlog /help wanted
. I will keep most of the discussion over there for now.
/remove-help /assign /lifecycle-active sending a PR with:

For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/). <del> For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </del> <ins> To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </ins> To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).


Question:
/language zh
/sig auth
/remove-sig auth /assign
Is this not SIG Auth?
By mentioning 'SIG Auth', we mean we want members from that SIG to help review the localization. For one thing, I'm not convinced that will happen. For the other, such mentions are distracting that SIG's attention on PRs which needs their feedback.


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Document Volume and Claim Pre-binding feature. Why is this needed PVC & PV pre-binding is useful sometimes, but this feature is not documented in our official website. It's better to add a topic or subtopic for it. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/sig storage cc /assign working on it

However, the particular path specified in the custom recycler Pod template in the `volumes` part is replaced with the particular path of the volume that is being recycled. <ins> ### Reserving a PersistentVolume The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) in the cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them. By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding between that specific PV and PVC. If the PersistentVolume exists and has not reserved PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and PersistentVolumeClaim will be bound. The binding happens regardless of some volume matching criteria, including node affinity. The control plane still checks that [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid. ``` apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: volumeName: foo-pv ... ``` This method does not guarantee any binding privileges to the PersistentVolume. If other PersistentVolumeClaims could use the PV that you specify, you first need to reserve that storage volume. Specify the relevant PersistentVolumeClaim in the `claimRef` field of the PV so that other PVCs can not bind to it. ``` apiVersion: v1 kind: PersistentVolume metadata: name: foo-pv spec: claimRef: name: foo-pvc namespace: foo ... ``` This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set to `Retain`, including cases where you are reusing an existing PV. </ins> ### Expanding Persistent Volumes Claims {{< feature-state for_k8s_version="v1.11" state="beta" >}}


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

<ins> --- title: ネットワークポリシー content_type: concept weight: 50 --- <!-- overview --> ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。 NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。 <!-- body --> ## 前提条件 ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。 ## 分離されたPodと分離されていないPod デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。 Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。) ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。 ## NetworkPolicyリソース {#networkpolicy-resource} リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。 以下は、NetworkPolicyの一例です。 ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 ``` {{< note >}} 選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。 {{< /note >}} __必須フィールド__: 他のKubernetesの設定と同様に、NetworkPolicyにも`apiVersion`、`kind`、`metadata`フィールドが必須です。設定ファイルの扱い方に関する一般的な情報については、[ConfigMapを使用してコンテナを構成する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)と[オブジェクト管理](/ja/docs/concepts/overview/working-with-objects/object-management)を参照してください。 __spec__: NetworkPolicyの[spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。 __podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。 __policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に `Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。 __ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。 __egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。 したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。 1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(まだ分離されていない場合) 2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する * "default"名前空間内のラベル"role=frontend"が付いたすべてのPod * ラベル"project=myproject"が付いた名前空間内のすべてのPod * 172.17.0.0–172.17.0.255および172.17.2.0–172.17.255.255(言い換えれば、172.17.1.0/24の範囲を除く172.17.0.0/16)の範囲内のすべてのIPアドレス 3. (Egressルール) "role=db"というラベルが付いた"default"名前空間内のすべてのPodからの、TCPの5978番ポート上でのCIDR 10.0.0.0/24への接続を許可する 追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。 ## `to`と`from`のセレクターの振る舞い `ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。 __podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。 __namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。 __namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。 ```yaml ... ingress: - from: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: client ... ``` このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。 ```yaml ... ingress: - from: - namespaceSelector: matchLabels: user: alice - podSelector: matchLabels: role: client ... ``` このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。 正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。 __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。 クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。 内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。 外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。 ## デフォルトのポリシー デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。 ### デフォルトですべての内向きのトラフィックを拒否する すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。 ### デフォルトで内向きのすべてのトラフィックを許可する (たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} ### デフォルトで外向きのすべてのトラフィックを拒否する すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。 ### デフォルトで外向きのすべてのトラフィックを許可する (たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} ### デフォルトで内向きと外向きのすべてのトラフィックを拒否する 名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。 ## SCTPのサポート {{< feature-state for_k8s_version="v1.12" state="alpha" >}} この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。 {{< note >}} SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。 {{< /note >}} ## {{% heading "whatsnext" %}} - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。 - NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。 </ins>


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

<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress spec: podSelector: {} egress: - {} policyTypes: - Egress </ins>


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

<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-ingress spec: podSelector: {} ingress: - {} policyTypes: - Ingress </ins>


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

<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress </ins>


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

<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-egress spec: podSelector: {} policyTypes: - Egress </ins>


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

<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes: - Ingress </ins>


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

- kow3ns title: DaemonSet content_type: concept <del> weight: 50 </del> <ins> weight: 40 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions. content_type: concept <del> weight: 30 </del> <ins> weight: 10 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

--- title: Garbage Collection content_type: concept <del> weight: 70 </del> <ins> weight: 60 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

title: Batch execution description: > In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired. <del> weight: 60 </del> <ins> weight: 50 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

- madhusudancs title: ReplicaSet content_type: concept <del> weight: 10 </del> <ins> weight: 20 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. content_type: concept <del> weight: 20 </del> <ins> weight: 90 </ins> --- <!-- overview -->


Question:
This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. 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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

- smarterclayton title: StatefulSets content_type: concept <del> weight: 40 </del> <ins> weight: 30 </ins> --- <!-- overview -->


Question:
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: There is a remark that mixes up two issues: is not about , rather it is about . even actually relevant to kube-controller-manager? Ayodele Abejide and I can not see any relevant for it (). 1350 looks like a show-stopper for this recipe. Proposed Solution: Fix the recipe. Fix issue 1350. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /language en
/kind bug (seems valid to me)
Note: Remove the flag --client-ca-file from the Kubernetes controller manager configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. Issue 1350 tracks an issue with Kubernetes controller manager being unable to accept a CA bundle. i think the problem that --client-ca-file and --cluster-signing-cert-file flags share is that the KCM does not allow CA bundles for both of them. this also implies complications around this guide. the kubeadm ticket is noisy and i don't think it should be linked from this page. note that the step above mentions: Update Kubernetes controller manager's --root-ca-file to include both old and new CA and restart controller manager. at that point if the same file is a bundle the KCM would just error out because of --client-ca-file, thus the recommendation about removal or making it point to a separate CA. used for client certificate authentication to allow clients to validate the signature of the serving certificate. the KCM can still be served over HTTPs. i guess not if the flag is removed from from the KCM, until the old CA is removed from the bundle at which point the flag can be re-. i think there are wider problems here and we should have an issue in k/k tagged with sig/auth that tracks progress on the KCM supporting bundles. i've seen mentions around this being worked on here: the note in this document needs clarification: it should link to the k/k issue, if one day the KCM --client-ca-file supports bundles it should explain why the flag is being removed and what are the consequences of doing that (e.g. MITM?). should the flag removal be temporary until the bundle no longer has the old CA? cc
In my opinion, the flag is still needed, when I tested the recipe there were 2 problems at the start, one from and another from , that when I found to be problematic, the point that later only got caught when I removed chain from . That's why I included this in the recipe, that we should either remove it or replace it with the new CA, whichever fits the need cluster to cluster basis. It doesn't makes it show stopper but, yes, I agree that the page needs a bit reword in the paragraph to make it less confusing for people following it.
PS: Just in case someone wants to re-validate, the error I was getting with with old+new CA certs was similar to "certificate signed by unknown authority" and stopped when I replaced it with only new CA. So it was more like the first bundle in the chain was accepted but the newer one did not.
/priority awaiting-more-evidence Please feel free to /priority some-other-value and /triage accepted if this is confirmed valid.
would you like send a PR to amend the paragraph? EDIT: NVM i've sent the PR here, PTAL:
(sent the PR) /remove-priority awaiting-more-evidence /priority backlog
/triage accepted

(ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory. <del> 1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager. </del> <ins> 1. Update {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}'s `--root-ca-file` to include both old and new CA. Then restart the component. </ins> Any service account created after this point will get secrets that include both old and new CAs. {{< note >}} <del> Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. </del> <ins> The files specified by the kube-controller-manager flags `--client-ca-file` and `--cluster-signing-cert-file` cannot be CA bundles. If these flags and `--root-ca-file` point to the same `ca.crt` file which is now a bundle (includes both old and new CA) you will face an error. To workaround this problem you can copy the new CA to a separate file and make the flags `--client-ca-file` and `--cluster-signing-cert-file` point to the copy. Once `ca.crt` is no longer a bundle you can restore the problem flags to point to `ca.crt` and delete the copy. </ins> {{< /note >}} 1. Update all service account tokens to include both old and new CA certificates.


Question: This is a Feature Request What would you like to be Translate docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign

<ins> --- reviewers: - michmike - patricklang title: Windowsノードの追加 min-kubernetes-server-version: 1.17 content_type: tutorial weight: 30 --- <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} Kubernetesを使用してLinuxノードとWindowsノードを混在させて実行できるため、Linuxで実行するPodとWindowsで実行するPodを混在させることができます。このページでは、Windowsノードをクラスターに登録する方法を示します。 ## {{% heading "prerequisites" %}} {{< version-check >}} * WindowsコンテナをホストするWindowsノードを構成するには、[Windows Server 2019ライセンス](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)(またはそれ以上)を取得します。 VXLAN/オーバーレイネットワークを使用している場合は、[KB4489899](https://support.microsoft.com/help/4489899)もインストールされている必要があります。 * コントロールプレーンにアクセスできるLinuxベースのKubernetes kubeadmクラスター([kubeadmを使用した単一のコントロールプレーンクラスターの作成](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照) ## {{% heading "objectives" %}} * Windowsノードをクラスターに登録する * LinuxとWindowsのPodとServiceが相互に通信できるようにネットワークを構成する <!-- lessoncontent --> ## はじめに: クラスタへのWindowsノードの追加 ### ネットワーク構成 LinuxベースのKubernetesコントロールプレーンノードを取得したら、ネットワーキングソリューションを選択できます。このガイドでは、簡単にするためにVXLANモードでのFlannelの使用について説明します。 #### Flannel構成 1. FlannelのためにKubernetesコントロールプレーンを準備する クラスター内のKubernetesコントロールプレーンでは、多少の準備が推奨されます。Flannelを使用する場合は、iptablesチェーンへのブリッジIPv4トラフィックを有効にすることをお勧めします。すべてのLinuxノードで次のコマンドを実行する必要があります: ```bash sudo sysctl net.bridge.bridge-nf-call-iptables=1 ``` 1. Linux用のFlannelをダウンロードして構成する 最新のFlannelマニフェストをダウンロード: ```bash wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml ``` VNIを4096、ポートを4789に設定するために、flannelマニフェストの`net-conf.json`セクションを変更します。次のようになります。: ```json net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan", "VNI" : 4096, "Port": 4789 } } ``` {{< note >}}Linux上のFlannelがWindows上のFlannelと相互運用するには、VNIを4096およびポート4789に設定する必要があります。これらのフィールドの説明については、[VXLANドキュメント](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)を参照してください。{{< /note >}} {{< note >}}L2Bridge/Host-gatewayモードを使用するには、代わりに`Type`の値を`"host-gw"`に変更し、`VNI`と`Port`を省略します。{{< /note >}} 1. Flannelマニフェストを適用して検証する Flannelの構成を適用しましょう: ```bash kubectl apply -f kube-flannel.yml ``` 数分後、Flannel Podネットワークがデプロイされていれば、すべてのPodが実行されていることがわかります。 ```bash kubectl get pods -n kube-system ``` 出力結果には、実行中のLinux flannel DaemonSetが含まれているはずです: ``` NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE ... kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m ``` 1. Windows Flannelとkube-proxy DaemonSetを追加する これで、Windows互換バージョンのFlannelおよびkube-proxyを追加できます。 順番に互換性のあるバージョンのkube-proxyを確実に入手するには、イメージのタグを代用する必要があります。 次の例は、Kubernetes{{< param "fullversion" >}}の使用方法を示していますが、 独自のdeploymentに合わせてバージョンを調整する必要があります。 ```bash curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml ``` {{< note >}} ホストゲートウェイを使用している場合は、代わりにhttps://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.ymlを使用してください。 {{< /note >}} {{< note >}} Windowsノードでイーサネット(「Ethernet0 2」など)ではなく別のインターフェースを使用している場合は、次の行を変更する必要があります。: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` `flannel-host-gw.yml`または`flannel-overlay.yml`ファイルで、それに応じてインターフェースを指定します。 ```bash # 例 curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` {{< /note >}} ### Windowsワーカーノードの参加 {{< note >}} `Containers`機能をインストールし、Dockerをインストールする必要があります。 行うための指示としては、[Dockerエンジンのインストール - Windowsサーバー上のエンタープライズ](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)を利用できます。 {{< /note >}} {{< note >}} Windowsセクションのすべてのコードスニペットは、 Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実行されます。 {{< /note >}} 1. wins、kubelet、kubeadmをインストールします。 ```PowerShell curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 .PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} ``` 1. `kubeadm`を実行してノードに参加します コントロールプレーンホストで`kubeadm init`を実行したときに提供されたコマンドを使用します。 このコマンドがなくなった場合、またはトークンの有効期限が切れている場合は、`kubeadm token create --print-join-command` (コントロールプレーンホスト上で)を実行して新しいトークンを生成します。 #### インストールの確認 次のコマンドを実行して、クラスター内のWindowsノードを表示できるようになります: ```bash kubectl get nodes -o wide ``` 新しいノードが`NotReady`状態の場合は、flannelイメージがまだダウンロードされている可能性があります。 `kube-system`名前空間のflannel Podを確認することで、以前と同様に進行状況を確認できます: ```shell kubectl -n kube-system get pods -l app=flannel ``` flannel Podが実行されると、ノードは`Ready`状態になり、ワークロードを処理できるようになります。 ## {{% heading "whatsnext" %}} - [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) </ins>


Question:
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: can be set to any value, but . If it's set to any value less than 10s the CronJob will be never scheduled. Proposed Solution: Force the value to be always greater than 10, or warn people there are non-working values Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.15.12
/kind cleanup /language en /triage accepted
Thanks
Relevant to
I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. Specifically I would add a callout, with text similar to: /good-first-issue /sig apps
This request has been marked as suitable for new contributors. 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 : I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. if is set to a value less than 10 seconds then the CronJob may not be scheduled. /sig apps 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
/assign

and if `concurrencyPolicy` is set to `Allow`, the jobs will always run at least once. <ins> {{< caution >}} If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds. {{< /caution >}} </ins> For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error ````


Question:
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: can be set to any value, but . If it's set to any value less than 10s the CronJob will be never scheduled. Proposed Solution: Force the value to be always greater than 10, or warn people there are non-working values Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.15.12
/kind cleanup /language en /triage accepted
Thanks
Relevant to
I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. Specifically I would add a callout, with text similar to: /good-first-issue /sig apps
This request has been marked as suitable for new contributors. 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 : I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. if is set to a value less than 10 seconds then the CronJob may not be scheduled. /sig apps 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
/assign

For instructions on creating and working with cron jobs, and for an example of CronJob manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).


Question:
This is a Bug Report <!--Required Information--Problem: In Dualstack doc updates for 1.18 , it only removes IPVS prerequisites in but not remove it in , you still can find "Kube-proxy running in mode IPVS" in the doc. Proposed Solution: remove "Kube-proxy running in mode IPVS" in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /priority important-soon /kind bug – Can you verify the issue described is correct? If so we can tag it as a good first issue and have someone tackle it.
Hi and Thank you very much for raising this. I can indeed validate that the issue is correct and that the proposed solution is correct and would be more than happy to review a PR if someone would be happy to contribute. Thanks again
/assign
– no further action from you needed, this was a small fix. Thank you!

* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) <del> * Kube-proxy running in mode IPVS </del> * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster {{< version-check >}}


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

<ins> --- title: コンテンツの改善を提案する slug: suggest-improvements content_type: concept weight: 10 card: name: contribute weight: 20 --- <!-- overview --> Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、[GitHubアカウント](https://github.com/join)とウェブブラウザーだけです。 Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。 <!-- body --> ## issueを作る 既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。 1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。 2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。 3. **Submit new issue**ボタンをクリックします。 送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。 ## 新しいコンテンツの提案 新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。 - コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。 - [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。 ## よいissueを作るには issueを作るときは、以下のことを心に留めてください。 - 明確なissueの説明を書く。不足している点、古くなっている点、誤っている点、改善が必要な点など、どの点がそうであるか明確に書く。 - issueがユーザーに与える具体的な影響を説明する。 - 合理的な作業単位になるように、特定のissueのスコープを制限する。スコープの大きな問題については、小さな複数のissueに分割する。たとえば、"Fix the security docs"(セキュリティのドキュメントを修正する)というのはスコープが大きすぎますが、"Add details to the 'Restricting network access' topic"(トピック「ネットワークアクセスの制限」に詳細情報を追加する)であれば十分に作業可能な大きさです。 - すでにあるissueを検索し、関連または同様のissueがないかどうか確認する。 - 新しいissueがほかのissueやpull requestと関係する場合は、完全なURLを参照するか、issueやpull requestの数字の前に`#`の文字を付けて参照する。例えば、`Introduced by #987654`のように書きます。 - [行動規範](/ja/community/code-of-conduct/)に従って、仲間のコントリビューターに敬意を払いましょう。たとえば、"The docs are terrible"(このドキュメントは最悪だ)のようなコメントは、役に立つ敬意のあるフィードバックではありません。 </ins>


Question:
A page just to provide a link another page? My be you are planning more links on this page. If not this page it self can point to target page.
Hi in this there is another link reference to kubectl commands refrence , so far i am understanding is that you want to replace reference Link for kubectl command to be in this ?
To fix this, edit  so that it redirects to /good-first-issue /language en
/triage accepted
/retitle No page content for
/assign
hi could you help to review the PR? Thanks
~reviewers~ approvers for the English localization (who are mainly volunteers) pick up that task on a . I can take a look though.
/remove-good-first-issue
/assign
I the redirect () but it doesn't seem to be working on the deploy preview or locally. Any advice would be appreciated:

/docs/reference/glossary/maintainer/    /docs/reference/glossary/approver/ 301 <ins> /docs/reference/kubectl/kubectl-cmds/     /docs/reference/generated/kubectl/kubectl-commands/ 301! </ins> /docs/reference/kubectl/kubectl/kubectl_*.md    /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301


Question:
/language zh /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 : /language zh /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

<ins> --- title: 升级 Windows 节点 min-kubernetes-server-version: 1.17 content_type: task weight: 40 --- <!-- title: Upgrading Windows nodes min-kubernetes-server-version: 1.17 content_type: task weight: 40 --> <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} <!-- This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes). --> 本页解释如何升级[用 kubeadm 创建的](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 节点。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Windows nodes. --> * 熟悉[更新 kubeadm 集群中的其余组件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)。 在升级你的 Windows 节点之前你会想要升级控制面节点。 <!-- steps --> <!-- ## Upgrading worker nodes ### Upgrade kubeadm --> ## 升级工作节点   {#upgrading-worker-nodes} ### 升级 kubeadm    {#upgrade-kubeadm} <!-- 1.  From the Windows node, upgrade kubeadm: ```powershell # replace {{< param "fullversion" >}} with your desired version curl.exe -Lo C:kkubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` --> 1. 在 Windows 节点上升级 kubeadm： ```powershell # 将 {{< param "fullversion" >}} 替换为你希望的版本 curl.exe -Lo C:kkubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` <!-- ### Drain the node 1.  From a machine with access to the Kubernetes API, prepare the node for maintenance by marking it unschedulable and evicting the workloads: ```shell # replace <node-to-drain> with the name of your node you are draining kubectl drain <node-to-drain> -ignore-daemonsets ``` You should see output similar to this: ``` node/ip-172-31-85-18 cordoned node/ip-172-31-85-18 drained ``` --> ### 腾空节点   {#drain-the-node} 1. 在一个能访问到 Kubernetes API 的机器上，将 Windows 节点标记为不可调度并 驱逐其上的所有负载，以便准备节点维护操作： ```shell # 将 <要腾空的节点> 替换为你要腾空的节点的名称 kubectl drain <要腾空的节点> -ignore-daemonsets ``` 你应该会看到类似下面的输出： ``` node/ip-172-31-85-18 cordoned node/ip-172-31-85-18 drained ``` <!-- ### Upgrade the kubelet configuration 1.  From the Windows node, call the following command to sync new kubelet configuration: ```powershell kubeadm upgrade node ``` --> ### 升级 kubelet 配置   {#upgrade-the-kubelet-configuration} 1. 在 Windows 节点上，执行下面的命令来同步新的 kubelet 配置： ```powershell kubeadm upgrade node ``` <!-- ### Upgrade kubelet 1.  From the Windows node, upgrade and restart the kubelet: ```powershell stop-service kubelet curl.exe -Lo C:kkubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` --> ### 升级 kubelet   {#upgrade-kubelet} 1. 在 Windows 节点上升级并重启 kubelet： ```powershell stop-service kubelet curl.exe -Lo C:kkubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` <!-- ### Uncordon the node 1.  From a machine with access to the Kubernetes API, bring the node back online by marking it schedulable: ```shell # replace <node-to-drain> with the name of your node kubectl uncordon <node-to-drain> ``` --> ### 对节点执行 uncordon 操作   {#uncordon-the-node} 1. 从一台能够访问到 Kubernetes API 的机器上，通过将节点标记为可调度，使之 重新上线： ```shell # 将 <要腾空的节点> 替换为你的节点名称 kubectl uncordon <要腾空的节点> ``` <!-- ### Upgrade kube-proxy 1. From a machine with access to the Kubernetes API, run the following, again replacing {{< param "fullversion" >}} with your desired version: ```shell curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - ``` --> ### 升级 kube-proxy   {#upgrade-kube-proxy} 1. 在一台可访问 Kubernetes API 的机器上和，将 {{< param "fullversion" >}} 替换成你 期望的版本后再次执行下面的命令： ```shell curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - ``` </ins>


Question:
/language zh /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 : /language zh /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
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

<ins> --- title: 为 Windows Pod 和容器配置 GMSA content_type: task weight: 20 --- <!-- title: Configure GMSA for Windows Pods and containers content_type: task weight: 20 --> <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="stable" >}} <!-- This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. --> 本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置 [组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。 组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的 密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个 服务器将管理操作委派给其他管理员等能力。 <!-- In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads. --> 在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源 （Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为 使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便 与其他 Windows 服务相交互。自 Kubernetes 1.16 版本起，Docker 运行时为 Windows 负载支持 GMSA。 ## {{% heading "prerequisites" %}} <!-- You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster: --> 你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，且工具必须已配置 为能够与你的集群通信。集群预期包含 Windows 工作节点。 本节讨论需要为每个集群执行一次的初始操作。 <!-- ### Install the GMSACredentialSpec CRD A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` --> ### 安装 GMSACredentialSpec CRD 你需要在集群上配置一个用于 GMSA 凭据规约资源的 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)， 以便定义类型为 `GMSACredentialSpec` 的自定义资源。 首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) 并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml` 安装 CRD。 <!-- ### Install webhooks to validate GMSA users Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level: 1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec. 1. A validating webhook ensures all references to GMSAs are authorized to be used by the Pod service account. --> ### 安装 Webhook 来验证 GMSA 用户 你需要为 Kubernetes 集群配置两个 Webhook，在 Pod 或容器级别填充和检查 GMSA 凭据规约引用。 1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字） 展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。 1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权 给 Pod 的服务账号使用的。 <!-- Installing the above webhooks and associated objects require the steps below: 1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster) 1. Install a secret with the certificate from above. 1. Create a deployment for the core webhook logic. 1. Create the validating and mutating webhook configurations referring to the deployment. --> 安装以上 Webhook 及其相关联的对象需要执行以下步骤： 1. 创建一个证书密钥对（用于允许 Webhook 容器与集群通信） 1. 安装一个包含如上证书的 Secret 1. 创建一个包含核心 Webhook 逻辑的 Deployment 1. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置 <!-- A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a `-dry-run=server` option to allow you to review the changes that would be made to your cluster. The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) --> 你可以使用[这个脚本](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) 来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 `--dry-run=server` 选项以便审查脚本将会对集群做出的变更。 脚本所使用的[YAML 模板](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) 也可用于手动部署 Webhook 及相关联的对象，不过需要对其中的参数作适当替换。 <!-- steps --> <!-- ## Configure GMSAs and Windows nodes in Active Directory Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) --> ## 在活动目录中配置 GMSA 和 Windows 节点 在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) 中描述的那样先在活动目录中准备好期望的 GMSA。 Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便 访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) 中。 <!-- ## Create GMSA credential spec resources With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). --> ## 创建 GMSA 凭据规约资源 当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据 规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。 其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。 GMSA 凭据规约可以使用 [PowerShell 脚本](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 以 YAML 格式生成。 <!-- Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: 1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)` 1. Use `Get-CredentialSpec` to show the path of the JSON file. 1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. --> 下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤： 1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. 使用 `New-CredentialSpec` 来创建一个 JSON 格式的凭据规约。 要创建名为 `WebApp1` 的 GMSA 凭据规约，调用 `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`。 1. 使用 `Get-CredentialSpec` 来显示 JSON 文件的路径。 1. 将凭据规约从 JSON 格式转换为 YAML 格式，并添加必要的头部字段 `apiVersion`、`kind`、`metadata` 和 `credspec`，使其成为一个可以在 Kubernetes 中配置的 GMSACredentialSpec 自定义资源。 <!-- The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`: ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  #This is an arbitrary name but it will be used as a reference credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   #Username of the GMSA account Scope: CONTOSO  #NETBIOS Domain Name - Name: WebApp1   #Username of the GMSA account Scope: contoso.com #DNS Domain Name CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  #DNS Domain Name DnsTreeName: contoso.com #DNS Domain Name Root Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID MachineAccountName: WebApp1 #Username of the GMSA account NetBiosName: CONTOSO  #NETBIOS Domain Name Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` --> 下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约： ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  # 这是随意起的一个名字，将用作引用 credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   # GMSA 账号的用户名 Scope: CONTOSO  # NETBIOS 域名 - Name: WebApp1   # GMSA 账号的用户名 Scope: contoso.com # DNS 域名 CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  # DNS 域名 DnsTreeName: contoso.com # DNS 域名根 Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID MachineAccountName: WebApp1 # GMSA 账号的用户名 NetBiosName: CONTOSO  # NETBIOS 域名 Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSA 的 SID ``` <!-- The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml` --> 上面的凭据规约资源可以保存为 `gmsa-Webapp1-credspec.yaml`，之后使用 `kubectl apply -f gmsa-Webapp1-credspec.yml` 应用到集群上。 <!-- ## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` --> ## 配置集群角色以启用对特定 GMSA 凭据规约的 RBAC 你需要为每个 GMSA 凭据规约资源定义集群角色。 该集群角色授权某主体（通常是一个服务账号）对特定的 GMSA 资源执行 `use` 动作。 下面的示例显示的是一个集群角色，对前文创建的凭据规约 `gmsa-WebApp1` 执行鉴权。 将此文件保存为 `gmsa-webapp1-role.yaml` 并执行 `kubectl apply -f gmsa-webapp1-role.yaml`。 <!-- ```yaml #Create the Role to read the credspec apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` --> ```yaml # 创建集群角色读取凭据规约 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` <!-- ## Assign role to service accounts to use specific GMSA credspecs A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above. --> ## 将角色指派给要使用特定 GMSA 凭据规约的服务账号 你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。 这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。 下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，使之 能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: allow-default-svc-account-read-on-gmsa-WebApp1 namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: ClusterRole name: webapp1-role apiGroup: rbac.authorization.k8s.io ``` <!-- ## Configure GMSA credential spec reference in Pod spec The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`: --> ## 在 Pod 规约中配置 GMSA 凭据规约引用 Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName` 可用来 设置对指定 GMSA 凭据规约自定义资源的引用。 设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。 下面是一个 Pod 规约示例，其中包含了对 `gmsa-WebApp1` 凭据规约的引用： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-webapp1 containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis nodeSelector: kubernetes.io/os: windows ``` <!-- Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example: --> Pod 中的各个容器也可以使用对应容器的 `securityContext.windowsOptions.gmsaCredentialSpecName` 字段来设置期望使用的 GMSA 凭据规约。 例如： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-Webapp1 nodeSelector: kubernetes.io/os: windows ``` <!-- As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place: 1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec. 1. The validating webhook ensures the service account associated with the Pod is authorized for the `use` verb on the specified GMSA credential spec. 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. --> 当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次 发生以下事件： 1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开， 得到 GMSA 凭据规约的实际内容。 1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约 上执行 `use` 动作。 1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以 活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。 <!-- ## Troubleshooting If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take. --> ## 故障排查 如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能 的故障。 <!-- First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  In the example below the Pod did not get the credspec correctly: --> 首先，确保凭据规约已经被传递到 Pod。要实现这点，你需要先通过 `exec` 进入到 你的 Pod 之一，检查 `nltest.exe /parentdomain` 命令的输出。 在下面的例子中，Pod 未能正确地获得凭据规约： ```shell kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:> nltest.exe /parentdomain Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE PS C:> ``` <!-- If your Pod did get the credspec correctly, then next check communication with the domain.  First, from inside of your Pod, quickly do an nslookup to find the root of your domain. This will tell us 3 things: 1. The Pod can reach the DC 1. The DC can reach the Pod 1. DNS is working correctly. --> 如果 Pod 未能正确获得凭据规约，则下一步就要检查与域之间的通信。 首先，从 Pod 内部快速执行一个 nslookup 操作，找到域根。 这一操作会告诉我们三件事情： 1. Pod 能否访问域控制器（DC） 1. DC 能否访问 Pod 1. DNS 是否正常工作 <!-- If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain.  To do this, again, `exec` into your Pod and run the `nltest.exe /query` command. --> 如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了 安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中 并执行 `nltest.exe /query` 命令。 ```shell PS C:> nltest.exe /query I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE ``` <!-- This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command. --> 这一输出告诉我们，由于某些原因，Pod 无法使用凭据规约中的账号登录到域。 你可以通过运行 `nltest.exe /sc_reset:domain.example` 命令尝试修复安全通道。 ```shell PS C:> nltest /sc_reset:domain.example Flags: 30 HAS_IP  HAS_TIMESERV Trusted DC Name dc10.domain.example Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully PS C:> ``` <!-- If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete. --> 如果上述命令修复了错误，你就可以通过向你的 Pod 规约添加生命周期回调来将此操作 自动化。如果上述命令未能奏效，你就需要再次检查凭据规约，以确保其数据时正确的 而且是完整的。 ```yaml image: registry.domain.example/iis-auth:1809v1 lifecycle: postStart: exec: command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"] imagePullPolicy: IfNotPresent ``` <!-- If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error. --> 如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所 列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query` 命令返回时没有错误信息。 <!-- ## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> ## GMSA 的局限 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。 容器会收到身份标识且 `nltest.exe /query` 调用也能正常工作。 当需要访问网络共享资源时，建议使用 [Docker EE 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee)。 Windows Server 团队正在 Windows 内核中解决这一问题，并在将来发布解决此问题的补丁。 你可以在 [Microsoft Windows Containers 问题跟踪列表](https://github.com/microsoft/Windows-Containers/issues/44) 中查找这类更新。 </ins>


Question:
This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected. So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks

from the community. Please try it out and give us feedback! {{< /caution >}} <ins> ## kubeadm alpha certs {#cmd-certs} A collection of operations for operating Kubernetes certificates. {{< tabs name="tab-certs" >}} {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs renew {#cmd-certs-renew} You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.


Question:
This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected. So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks

{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.


Question:
This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected. So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks

{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} <ins> ## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} {{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} {{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} {{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} </ins> ## kubeadm init phase addon {#cmd-phase-addon}


Question:
This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected. So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks

{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}


Question:
I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /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 : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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
/retitle Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign

Notice how the number of desired replicas is 3 according to `.spec.replicas` field. <del> 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. </del> <ins> 3. To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. </ins> The output is similar to: ```


Question:
I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /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 : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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
/retitle Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign

2. To see the rollout status, run: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this: