Question:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

## Default policies <del> By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior </del> <ins> By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior </ins> in that namespace. ### Default deny all ingress traffic <del> You can create a "default" ingress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </del> <ins> You can create a "default" ingress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </ins> {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} <del> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated for ingress. This policy does not affect isolation for egress from any pod. </del> <ins> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated for ingress. This policy does not affect isolation for egress from any pod. </ins> ### Allow all ingress traffic <del> If you want to allow all incoming connections to all pods in a namespace, you can create a policy that explicitly allows that. </del> <ins> If you want to allow all incoming connections to all pods in a namespace, you can create a policy that explicitly allows that. </ins> {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} <del> With this policy in place, no additional policy or policies can cause any incoming connection to those pods to be denied.  This policy has no effect on isolation for egress from any pod. </del> <ins> With this policy in place, no additional policy or policies can cause any incoming connection to those pods to be denied.  This policy has no effect on isolation for egress from any pod. </ins> ### Default deny all egress traffic <del> You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. </del> <ins> You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. </ins> {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} <del> This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not change the ingress isolation behavior of any pod. </del> <ins> This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not change the ingress isolation behavior of any pod. </ins> ### Allow all egress traffic <del> If you want to allow all connections from all pods in a namespace, you can create a policy that explicitly allows all outgoing connections from pods in that namespace. </del> <ins> If you want to allow all connections from all pods in a namespace, you can create a policy that explicitly allows all outgoing connections from pods in that namespace. </ins> {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} <del> With this policy in place, no additional policy or policies can cause any outgoing connection from those pods to be denied.  This policy has no effect on isolation for ingress to any pod. </del> <ins> With this policy in place, no additional policy or policies can cause any outgoing connection from those pods to be denied.  This policy has no effect on isolation for ingress to any pod. </ins> ### Default deny all ingress and all egress traffic <del> You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. </del> <ins> You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. </ins> {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} <del> This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic. </del> <ins> This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic. </ins> ## SCTP support {{< feature-state for_k8s_version="v1.20" state="stable" >}} <del> As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. </del> <ins> As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. </ins> When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. {{< note >}} <del> You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. </del> <ins> You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. </ins> {{< /note >}} ## Targeting a range of ports


Question:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

This is achievable with the usage of the `endPort` field, as the following example: <del> ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: multi-port-egress namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 32000 endPort: 32768 ``` </del> <ins> {{< codenew file="service/networking/networkpolicy-multiport-egress.yaml" >}} </ins> The above rule allows any Pod with label `role=db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` over TCP, provided that the target port is between the range 32000 and 32768. The following restrictions apply when using this field: * The `endPort` field must be equal to or greater than the `port` field. * `endPort` can only be defined if `port` is also defined. * Both ports must be numeric.


Question:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

## What you can't do with network policies (at least, not yet) <del> As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. </del> <ins> As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. </ins> <del> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </del> <ins> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </ins> - Anything TLS related (use a service mesh or ingress controller for this). <del> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </del> <ins> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </ins> - Creation or management of "Policy requests" that are fulfilled by a third party. <del> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </del> <ins> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </ins> - Advanced policy querying and reachability tooling. - The ability to log network security events (for example connections that are blocked or accepted). <del> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </del> <ins> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </ins> ## {{% heading "whatsnext" %}} - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. <del> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </del> <ins> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </ins>


Question:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

"name-virtual-host-ingress-no-third-host": {&networking.Ingress{}}, "namespaced-params":                       {&networking.IngressClass{}}, "networkpolicy":                           {&networking.NetworkPolicy{}}, <ins> "networkpolicy-multiport-egress":          {&networking.NetworkPolicy{}}, </ins> "network-policy-allow-all-egress":         {&networking.NetworkPolicy{}}, "network-policy-allow-all-ingress":        {&networking.NetworkPolicy{}}, "network-policy-default-deny-egress":      {&networking.NetworkPolicy{}},


Question:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

<ins> apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: multi-port-egress namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 32000 endPort: 32768 </ins>


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. --Translate into Japanese Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<ins> --- title: オーナーと従属 content_type: concept weight: 90 --- <!-- overview --> Kubernetesでは、いくつかのオブジェクトは他のオブジェクトの*オーナー*になっています。 例えば、{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}}はPodの集合のオーナーです。 これらの所有されているオブジェクトはオーナーに*従属*しています。 オーナーシップはいくつかのリソースでも使われている[ラベルとセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)とは仕組みが異なります。 例として、`EndpointSlice`オブジェクトを作成するServiceオブジェクトを考えてみます。 Serviceはラベルを使ってどの`EndpointSlice`がどのServiceに利用されているかをコントロールプレーンに判断させています。 ラベルに加えて、Serviceの代わりに管理される各`EndpointSlice`はオーナーリファレンスを持ちます。 オーナーリファレンスは、Kubernetesの様々な箇所で管理外のオブジェクトに干渉してしまうのを避けるのに役立ちます。 ## オブジェクト仕様におけるオーナーリファレンス 従属オブジェクトはオーナーオブジェクトを参照するための`metadata.ownerReferences`フィールドを持っています。 有効なオーナーリファレンスは従属オブジェクトと同じ名前空間に存在するオブジェクトの名前とUIDで構成されます。 KubernetesはReplicaSet、DaemonSet、Deployment、Job、CronJob、ReplicationControllerのようなオブジェクトの従属オブジェクトに、自動的に値を設定します。 このフィールドの値を手動で変更することで、これらの関係性を自分で設定することもできます。 ただし、通常はその必要はなく、Kubernetesが自動で管理するようにすることができます。 従属オブジェクトは、オーナーオブジェクトが削除されたときにガベージコレクションをブロックするかどうかを管理する真偽値を取る`ownerReferences.blockOwnerDeletion`フィールドも持っています。 Kubernetesは、{{<glossary_tooltip text="コントローラー" term_id="controller">}} (例：Deploymentコントローラー)が`metadata.ownerReferences`フィールドに値を設定している場合、自動的にこのフィールドを`true`に設定します。 `blockOwnerDeletion`フィールドに手動で値を設定することで、どの従属オブジェクトがガベージコレクションをブロックするかを設定することもできます。 Kubernetesのアドミッションコントローラーはオーナーの削除権限に基づいて、ユーザーが従属リソースのこのフィールドを変更できるかを管理しています。 これにより、認証されていないユーザーがオーナーオブジェクトの削除を遅らせることを防ぎます。 {{< note >}} 名前空間をまたぐオーナーリファレンスは仕様により許可されていません。 名前空間付き従属オブジェクトには、クラスタースコープ、または名前空間付きのオーナーを指定することができます。名前空間付きオーナーは**必ず**従属オブジェクトと同じ名前空間に存在していなければなりません。 そうでない場合、オーナーリファレンスはないものとして扱われ、全てのオーナーがいなくなった時点で従属オブジェクトは削除対象となります。 クラスタースコープの従属オブジェクトはクラスタースコープのオーナーのみ指定できます。 v1.20以降では、クラスタースコープの従属オブジェクトが名前空間付きのオブジェクトをオーナーとした場合、 解決できないオーナーリファレンスを持っているものとして扱われ、ガベージコレクションの対象とすることができません。 v1.20以降で、ガベージコレクターが無効な名前空間またぎの`ownerReference`や名前空間付きのオーナーに依存するクラスタースコープのオブジェクトなどを検知した場合、`OwnerRefInvalidNamespace`を理由とした警告のEventを出し、`involvedObject`で無効な従属オブジェクトを報告します。 `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`を実行することで、この種類のEventを確認することができます。 {{< /note >}} ## オーナーシップとファイナライザー Kubernetesでリソースを削除するとき、APIサーバーはリソースを管理するコントローラーに[ファイナライザールール](/ja/docs/concepts/overview/working-with-objects/finalizers/)を処理させることができます。 {{<glossary_tooltip text="ファイナライザー" term_id="finalizer">}}はクラスターが正しく機能するために必要なリソースを誤って削除してしまうことを防ぎます。 例えば、まだPodが使用中の`PersistentVolume`を削除しようとするとき、`PersistentVolume`が持っている`kubernetes.io/pv-protection`ファイナライザーにより、削除は即座には行われません。 その代わり、Kubernetesがファイナライザーを削除するまでボリュームは`Terminating`ステータスのまま残り、`PersistentVolume`がPodにバインドされなくなった後で削除が行われます。 またKubernetesは[フォアグラウンド、孤立したオブジェクトのカスケード削除](/ja/docs/concepts/architecture/garbage-collection/#cascading-deletion)を行ったとき、オーナーリソースにファイナライザーを追加します。 フォアグラウンド削除では、`foreground`ファイナライザーを追加し、オーナーを削除する前にコントローラーが`ownerReferences.blockOwnerDeletion=true`を持っている従属リソースを削除するようにします。 孤立したオブジェクトの削除を行う場合、Kubernetesは`orphan`ファイナライザーを追加し、オーナーオブジェクトを削除した後にコントローラーが従属リソースを無視するようにします。 ## {{% heading "whatsnext" %}} * [Kubernetesのファイナライザー](/ja/docs/concepts/overview/working-with-objects/finalizers/)についてさらに学習しましょう。 * [ガベージコレクション](/ja/docs/concepts/architecture/garbage-collection)について学習しましょう。 * [オブジェクトのメタデータ](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)のAPIリファレンスをご覧ください。 </ins>  No newline at end of file


Question:
This is a Bug Report Problem: Links for API compatibility and Kubelet Device Manager API Versions under in task are Invalid. It gives a 404 Page not found error. Proposed Solution: For API compatibility the link should be: For Kubelet Device Manager API Versions the link should be: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign /sig docs
Fixed it here
/triage accepted

both version before the node is upgraded in order to guarantee that device allocations continue to complete successfully during the upgrade. <del> Refer to [API compatiblity](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility) and [Kubelet Device Manager API Versions](/docs/reference/node/device-plugin-api-versions/) for more details. </del> <ins> Refer to [API compatibility](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility) and [Kubelet Device Manager API Versions](/docs/reference/node/device-plugin-api-versions/) for more details. </ins>  No newline at end of file


Question:
The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations. For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.

First, the user defines a new configuration containing only the `replicas` field: <del> {{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}} </del> <ins> ```yaml # Save this file as 'nginx-deployment-replicas-only.yaml'. apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 ``` {{< note >}} The YAML file for SSA in this case only contains the fields you want to change. You are not supposed to provide a fully compliant Deployment manifest if you only want to modify the `spec.replicas` field using SSA. {{< /note >}} </ins> The user applies that configuration using the field manager name `handover-to-hpa`: ```shell <del> kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml  </del> <ins> kubectl apply -f nginx-deployment-replicas-only.yaml  </ins> --server-side --field-manager=handover-to-hpa  --validate=false ```


Question:
The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations. For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.

<del> apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 </del>


Question:
The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations. For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.

"nginx-svc":        {&api.Service{}}, }, "application/ssa": { <del> "nginx-deployment":               {&apps.Deployment{}}, "nginx-deployment-no-replicas":   {&apps.Deployment{}}, "nginx-deployment-replicas-only": {&apps.Deployment{}}, </del> <ins> "nginx-deployment":             {&apps.Deployment{}}, "nginx-deployment-no-replicas": {&apps.Deployment{}}, </ins> }, "application/web": { "web":          {&api.Service{}, &apps.StatefulSet{}},


Question:
This is a Feature Request What would you like to be Translate tasks/administer-cluster/use-cascading-deletion/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

この時点で、オブジェクトはKubernetesAPIに表示されなくなります。 フォアグラウンドカスケード削除中に、オーナーの削除をブロックする依存関係は、`ownerReference.blockOwnerDeletion=true`フィールドを持つ依存関係のみです。 <del> 詳細については、[フォアグラウンドカスケード削除の使用](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)を参照してください。 </del> <ins> 詳細については、[フォアグラウンドカスケード削除の使用](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)を参照してください。 </ins> ### バックグラウンドカスケード削除 {#background-deletion} バックグラウンドカスケード削除では、Kubernetes APIサーバーがオーナーオブジェクトをすぐに削除し、コントローラーがバックグラウンドで依存オブジェクトをクリーンアップします。 デフォルトでは、フォアグラウンド削除を手動で使用するか、依存オブジェクトを孤立させることを選択しない限り、Kubernetesはバックグラウンドカスケード削除を使用します。 <del> 詳細については、[バックグラウンドカスケード削除の使用](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)を参照してください。 </del> <ins> 詳細については、[バックグラウンドカスケード削除の使用](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)を参照してください。 </ins> ### 孤立した依存関係 Kubernetesがオーナーオブジェクトを削除すると、残された依存関係は*orphan*オブジェクトと呼ばれます。 <del> デフォルトでは、Kubernetesは依存関係オブジェクトを削除します。この動作をオーバーライドする方法については、[オーナーオブジェクトと孤立した依存関係の削除](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)を参照してください。 </del> <ins> デフォルトでは、Kubernetesは依存関係オブジェクトを削除します。この動作をオーバーライドする方法については、[オーナーオブジェクトの削除と従属オブジェクトの孤立](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)を参照してください。 </ins> ## 未使用のコンテナとイメージのガベージコレクション {#containers-images}


Question:
This is a Feature Request What would you like to be Translate tasks/administer-cluster/use-cascading-deletion/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

これらのリソースを管理するコントローラーに固有のオプションを設定することにより、リソースのガベージコレクションを調整できます。次のページは、ガベージコレクションを設定する方法を示しています。 <del> * [Kubernetesオブジェクトのカスケード削除の設定](/docs/tasks/administer-cluster/use-cascading-deletion/) </del> <ins> * [Kubernetesオブジェクトのカスケード削除の設定](/ja/docs/tasks/administer-cluster/use-cascading-deletion/) </ins> * [完了したジョブのクリーンアップの設定](/ja/docs/concepts/workloads/controllers/ttlafterfinished/) <!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->


Question:
This is a Feature Request What would you like to be Translate tasks/administer-cluster/use-cascading-deletion/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<ins> --- title: クラスターでカスケード削除を使用する content_type: task weight: 360 --- <!--overview--> このページでは、{{<glossary_tooltip text="ガベージコレクション" term_id="garbage-collection">}}中にクラスターで使用する[カスケード削除](/ja/docs/concepts/architecture/garbage-collection/#cascading-deletion)のタイプを指定する方法を示します。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} また、さまざまな種類のカスケード削除を試すために、[サンプルのDeploymentを作成する](/ja/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)必要があります。 タイプごとにDeploymentを再作成する必要があります。 ## Podのオーナーリファレンスを確認する {#check-owner-references-on-your-pods} Podに`ownerReferences`フィールドが存在することを確認します: ```shell kubectl get pods -l app=nginx --output=yaml ``` 出力には、次のように`ownerReferences`フィールドがあります。 ```yaml apiVersion: v1 ... ownerReferences: - apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: ReplicaSet name: nginx-deployment-6b474476c4 uid: 4fdcd81c-bd5d-41f7-97af-3a3b759af9a7 ... ``` ## フォアグラウンドカスケード削除を使用する {#use-foreground-cascading-deletion} デフォルトでは、Kubernetesは[バックグラウンドカスケード削除](/ja/docs/concepts/architecture/garbage-collection/#background-deletion)を使用して、オブジェクトの依存関係を削除します。 クラスターが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIのいずれかを使用して、フォアグラウンドカスケード削除に切り替えることができます。 {{<version-check>}} `kubectl`またはKubernetes APIを使用して、フォアグラウンドカスケード削除を使用してオブジェクトを削除することができます。 **kubectlを使用する** 以下のコマンドを実行してください: <!--TODO: verify release after which the --cascade flag is switched to a string in https://github.com/kubernetes/kubectl/commit/fd930e3995957b0093ecc4b9fd8b0525d94d3b4e--> ```shell kubectl delete deployment nginx-deployment --cascade=foreground ``` **Kubernetes APIを使用する** 1. ローカルプロキシーセッションを開始します: ```shell kubectl proxy --port=8080 ``` 1. 削除のトリガーとして`curl`を使用します: ```shell curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}'  -H "Content-Type: application/json" ``` 出力には、次のように`foregroundDeletion`{{<glossary_tooltip text="ファイナライザー" term_id="finalizer">}}が含まれています。 ``` "kind": "Deployment", "apiVersion": "apps/v1", "metadata": { "name": "nginx-deployment", "namespace": "default", "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505", "resourceVersion": "1363097", "creationTimestamp": "2021-07-08T20:24:37Z", "deletionTimestamp": "2021-07-08T20:27:39Z", "finalizers": [ "foregroundDeletion" ] ... ``` ## バッググラウンドカスケード削除を使用する {#use-background-cascading-deletion} 1. [サンプルのDeploymentを作成する](/ja/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)。 1. クラスターが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIのいずれかを使用してDeploymentを削除します。{{<version-check>}} `kubectl`またはKubernetes APIを使用して、バックグラウンドカスケード削除を使用してオブジェクトを削除できます。 Kubernetesはデフォルトでバックグラウンドカスケード削除を使用し、`--cascade`フラグまたは`propagationPolicy`引数なしで以下のコマンドを実行した場合も同様です。 **kubectlを使用する** 以下のコマンドを実行してください: ```shell kubectl delete deployment nginx-deployment --cascade=background ``` **Kubernetes APIを使用する** 1. ローカルプロキシーセッションを開始します: ```shell kubectl proxy --port=8080 ``` 1. 削除のトリガーとして`curl`を使用します: ```shell curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}'  -H "Content-Type: application/json" ``` 出力は、次のようになります。 ``` "kind": "Status", "apiVersion": "v1", ... "status": "Success", "details": { "name": "nginx-deployment", "group": "apps", "kind": "deployments", "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456" } ``` ## オーナーオブジェクトの削除と従属オブジェクトの孤立 {#set-orphan-deletion-policy} デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{<glossary_tooltip text="コントローラー" term_id="controller">}}は従属オブジェクトも削除します。クラスタが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{<version-check>}} **kubectlを使用する** 以下のコマンドを実行してください: ```shell kubectl delete deployment nginx-deployment --cascade=orphan ``` **Kubernetes APIを使用する** 1. ローカルプロキシーセッションを開始します: ```shell kubectl proxy --port=8080 ``` 1. 削除のトリガーとして`curl`を使用します: ```shell curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}'  -H "Content-Type: application/json" ``` 出力には、次のように`finalizers`フィールドに`orphan`が含まれます。 ``` "kind": "Deployment", "apiVersion": "apps/v1", "namespace": "default", "uid": "6f577034-42a0-479d-be21-78018c466f1f", "creationTimestamp": "2021-07-09T16:46:37Z", "deletionTimestamp": "2021-07-09T16:47:08Z", "deletionGracePeriodSeconds": 0, "finalizers": [ "orphan" ], ... ``` Deploymentによって管理されているPodがまだ実行中であることを確認できます。 ```shell kubectl get pods -l app=nginx ``` ## {{% heading "whatsnext" %}} * Kubernetesの[オーナーと従属](/ja/docs/concepts/overview/working-with-objects/owners-dependents/)について学ぶ。 * Kubernetes [ファイナライザー(Finalizers)](/ja/docs/concepts/overview/working-with-objects/finalizers/)について学ぶ。 * [ガベージコレクション](/ja/docs/concepts/architecture/garbage-collection/)について学ぶ。 </ins>


Question:
This is a Feature Request What would you like to be Translate tasks/administer-cluster/use-cascading-deletion/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<!-- lessoncontent --> <del> ## nginx deploymentの作成と探検 </del> <ins> ## nginx deploymentの作成と探検 {#creating-and-exploring-an-nginx-deployment} </ins> Kubernetes Deploymentオブジェクトを作成することでアプリケーションを実行できます。また、YAMLファイルでDeploymentを記述できます。例えば、このYAMLファイルはnginx:1.14.2 Dockerイメージを実行するデプロイメントを記述しています:


Question:
I was doing the step-by-step installation for v1.26.3 and found this as the final step for installing on Windows: installing the plugin, clean up the installation files: del Please correct me if I am wrong, but isn't the kube controller that I just installed? It isn't an installer, it's the product. Your instruction should not be to delete it. If I delete then I won't have kubectl installed anymore. Make sense?
/kind bug /language en /triage accepted For Windows, we don't provide our own installable package and the instructions don't explain putting the kubectl binary anywhere special. Until that changes, let's not advise readers to delete .
do we have to comment down or delete the 5th instruction there ?
/assign

kubectl version --client --output=yaml ``` <del> 1. After installing the plugin, clean up the installation files: ```powershell del kubectl.exe kubectl.exe.sha256 ``` </del> {{< note >}} [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)


Question:
In the third sentence on the second paragraph it reads: | operations, such as containerd or Docker. It is not clear if is a typo or a new term.
I believe writing "such as containerd or Docker" was not necessary because it was not very accurate , only writing till operations is fine enough . But still it is not an issue there .
is a container runtime that manages the lifecycle of a container.
/retitle "Using Minikube to Create a Cluster" unclear on meaning of containerd /language en Page to Update: For additional info, adding a hyperlink pointing to the corresponding official doc of the container runtime would be useful here.
I think the sentence is referring to the container tools and containerd manage the lifecycle of container on VMs.
Yeah, I get that. For someone new not familiar that this is a tool, might be confused. I originally thought it ws a typo and later realized it was referring to a dameon process. Not sure if there could be a link to docs of containerd so the reader won't get confused.
yes i also think adding link to docs of containerd would be useful for the reader to get clear understanding.
/assign
/kind documentation /triage accepted Improvements are welcome!
We could add a reference to our glossary entry:
/language en /priority backlog /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /language en /priority backlog 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
It is not the only problem on that page, the description of minikube is not very accurate (anymore) either... But it will soon need to change anyway, when the online tutorials disappear, so probably time for a rewrite ?
/assign

The Control Plane is responsible for managing the cluster. The Control Plane coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as {{< glossary_tooltip text="containerd" term_id="containerd" >}} or {{< glossary_tooltip term_id="cri-o" >}}. A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.


Question:
This is a Bug Report Problem: Issue clarified privileges of kubectl debug node (through PR ) including " will fail" but in newer versions of Kubernetes 1.25 on EKS, works, although there may still be permissions issues as before. Proposed Solution: Change to " may fail" Page to Update:
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
Created PR

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


Question:
This blog has not zh version yet. I will localize it. Open the issue to avoid possible dup. /assign /language zh
/triage accepted

<ins> --- layout: blog title: "dl.k8s.io 采用内容分发网络（CDN）" date: 2023-06-09 slug: dl-adopt-cdn --- <!-- layout: blog title: "dl.k8s.io to adopt a Content Delivery Network" date: 2023-06-09 slug: dl-adopt-cdn --> <!-- **Authors**: Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) --> **作者**：Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) **译者**：[Xin Li](https://github.com/my-git9) (Daocloud) <!-- We're happy to announce that dl.k8s.io, home of the official Kubernetes binaries, will soon be powered by [Fastly](https://www.fastly.com). Fastly is known for its high-performance content delivery network (CDN) designed to deliver content quickly and reliably around the world. With its powerful network, Fastly will help us deliver official Kubernetes binaries to users faster and more reliably than ever before. --> 我们很高兴地宣布，官方 Kubernetes 二进制文件的主页 dl.k8s.io 很快将由 [Fastly](https://www.fastly.com) 提供支持。 Fastly 以其高性能内容分发网络（CDN）而闻名， 该网络旨在全球范围内快速可靠地分发内容。凭借其强大的网络，Fastly 将帮助我们实现比以往更快、更可靠地向用户分发官方 Kubernetes 二进制文件。 <!-- The decision to use Fastly was made after an extensive evaluation process in which we carefully evaluated several potential content delivery network providers. Ultimately, we chose Fastly because of their commitment to the open internet and proven track record of delivering fast and secure digital experiences to some of the most known open source projects (through their [Fast Forward](https://www.fastly.com/fast-forward) program). --> 使用 Fastly 是在经过广泛的评估过程后做出的决定， 在该过程中我们仔细评估了几个潜在的内容分发网络提供商。最终，我们选择 Fastly 是因为他们对开放互联网的承诺以及在为一些著名的开源项目（通过他们的 [Fast Forward](https://www.fastly.com/fast-forward) 计划）提供快速和安全的数字体验方面的良好记录。 <!-- ## What you need to know about this change - On Monday, July 24th, the IP addresses and backend storage associated with the dl.k8s.io domain name will change. - The change will not impact the vast majority of users since the domain name will remain the same. - If you restrict access to specific IP ranges, access to the dl.k8s.io domain could stop working. --> ## 关于本次更改你需要了解的信息 - 7 月 24 日星期一，与 dl.k8s.io 域名关联的 IP 地址和后端存储将发生变化。 - 由于域名将保持不变，因此更改不会影响绝大多数用户。 - 如果你限制对特定 IP 范围的访问，则对 dl.k8s.io 域的访问可能会停止工作。 <!-- If you think you may be impacted or want to know more about this change, please keep reading. --> 如果你认为你可能会受到影响或想了解有关此次更改的更多信息，请继续阅读。 <!-- ## Why are we making this change The official Kubernetes binaries site, dl.k8s.io, is used by thousands of users all over the world, and currently serves _more than 5 petabytes of binaries each month_. This change will allow us to improve access to those resources by leveraging a world-wide CDN. --> ## 我们为什么要进行此更改 官方 Kubernetes 二进制文件网站 dl.k8s.io 被全世界成千上万的用户使用， 目前**每月提供超过 5 PB 的二进制文件服务**。本次更改将通过充分利用全球 CDN 来改善对这些资源的访问。 <!-- ## Does this affect dl.k8s.io only, or are other domains also affected? Only dl.k8s.io will be affected by this change. --> ## 这只影响 dl.k8s.io，还是其他域也受到影响？ 只有 dl.k8s.io 会受到本次变更的影响。 <!-- ## My company specifies the domain names that we are allowed to be accessed. Will this change affect the domain name? No, the domain name (`dl.k8s.io`) will remain the same: no change will be necessary, and access to the Kubernetes release binaries site should not be affected. --> ## 我公司规定了允许我们访问的域名，此更改会影响域名吗？ 不，域名（`dl.k8s.io`）将保持不变：无需更改，不会影响对 Kubernetes 发布二进制文件站点的访问。 <!-- ## My company uses some form of IP filtering. Will this change affect access to the site? If IP-based filtering is in place, it’s possible that access to the site will be affected when the new IP addresses become active. --> ## 我的公司使用某种形式的 IP 过滤，此更改会影响对站点的访问吗？ 如果已经存在基于 IP 的过滤，则当新 IP 地址变为活动状态时，对站点的访问可能会受到影响。 <!-- ## If my company doesn’t use IP addresses to restrict network traffic, do we need to do anything? No, the switch to the CDN should be transparent. --> ## 如果我的公司不使用 IP 地址来限制网络流量，我们需要做些什么吗？ 不，切换到 CDN 的过程应该是透明的。 <!-- ## Will there be a dual running period? **No, it is a cutover.** You can, however, test your networks right now to check if they can route to the new public IP addresses from Fastly.  You should add the new IPs to your network's `allowlist` before July 24th. Once the transfer is complete, ensure your networks use the new IP addresses to connect to the `dl.k8s.io` service. --> ## 会有双运行期吗？ **不，这是切换。**但是，你现在可以测试你的网络，检查它们是否可以从 Fastly 路由到新的公共 IP 地址。 你应该在 7 月 24 日之前将新 IP 添加到你网络的 `allowlist`（白名单）中。 切换完成后，确保你的网络使用新的 IP 地址连接到 `dl.k8s.io` 服务。 <!-- ## What are the new IP addresses? If you need to manage an allow list for downloads, you can get the ranges to match from the Fastly API, in JSON: [public IP address ranges](https://api.fastly.com/public-ip-list).  You don't need any credentials to download that list of ranges. --> ## 新 IP 地址是什么？ 如果你需要管理下载允许列表，你可以从 Fastly API 中获取需要匹配的范围， JSON 格式地址：[公共 IP 地址范围](https://api.fastly.com/public-ip-list)。 你不需要任何凭据即可下载该范围列表。 <!-- ## What next steps would you recommend? If you have IP-based filtering in place, we recommend the following course of action **before July, 24th**: --> ## 推荐哪些后续操作？ 如果你已经有了基于 IP 的过滤，我们建议你**在 7 月 24 日**之前采取以下行动： <!-- - Add the new IP addresses to your allowlist. - Conduct tests with your networks/firewall to ensure your networks can route to the new IP addresses. After the change is made, we recommend double-checking that HTTP calls are accessing dl.k8s.io with the new IP addresses. --> - 将新的 IP 地址添加到你的白名单。 - 对你的网络/防火墙进行测试，以确保你的网络可以路由到新的 IP 地址。 进行更改后，我们建议仔细检查 HTTP 调用是否正在使用新 IP 地址访问 dl.k8s.io。 <!-- ## What should I do if I detect some abnormality after the cutover date? If you encounter any weirdness during binaries download, please [open an issue](https://github.com/kubernetes/k8s.io/issues/new/choose). --> ## 切换后发现异常怎么办？ 如果你在二进制文件下载过程中遇到任何异常， 请[提交 Issue](https://github.com/kubernetes/k8s.io/issues/new/choose)。 </ins>


Question:
Just like the pods and the control plane have hover which makes it easier to understand. There should be a hover that should explain what does replica mean here and in what context we are using it as for a beginner it might will be confusing to understand what replica is
Would you be able to provide us with the web page's URL that requires modification? If it's possible, it would be helpful to include the URL in the issue description as well. /language en /triage needs-information
Reference:
/remove-triage needs-information
/retitle Include in glossary and add tooltip for it on "Kubernetes Components" page /language en
Can I work on it now?
/triage accepted Anyone - including you - is welcome to open a pull request. This is open source in action! /priority backlog
/assign

<!-- body --> ## Control Plane Components <del> The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied). </del> <ins> The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's `{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied). </ins> Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all control plane components on


Question:
Just like the pods and the control plane have hover which makes it easier to understand. There should be a hover that should explain what does replica mean here and in what context we are using it as for a beginner it might will be confusing to understand what replica is
Would you be able to provide us with the web page's URL that requires modification? If it's possible, it would be helpful to include the URL in the issue description as well. /language en /triage needs-information
Reference:
/remove-triage needs-information
/retitle Include in glossary and add tooltip for it on "Kubernetes Components" page /language en
Can I work on it now?
/triage accepted Anyone - including you - is welcome to open a pull request. This is open source in action! /priority backlog
/assign

### DNS <del> While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. </del> <ins> While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. </ins> <del> Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. </del> <ins> Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. </ins> Containers started by Kubernetes automatically include this DNS server in their DNS searches. ### Web UI (Dashboard) <del> [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. </del> <ins> [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. </ins> ### Container Resource Monitoring <del> [Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics </del> <ins> [Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics </ins> about containers in a central database, and provides a UI for browsing that data. ### Cluster-level Logging


Question:
Just like the pods and the control plane have hover which makes it easier to understand. There should be a hover that should explain what does replica mean here and in what context we are using it as for a beginner it might will be confusing to understand what replica is
Would you be able to provide us with the web page's URL that requires modification? If it's possible, it would be helpful to include the URL in the issue description as well. /language en /triage needs-information
Reference:
/remove-triage needs-information
/retitle Include in glossary and add tooltip for it on "Kubernetes Components" page /language en
Can I work on it now?
/triage accepted Anyone - including you - is welcome to open a pull request. This is open source in action! /priority backlog
/assign

## {{% heading "whatsnext" %}} Learn more about the following: <del> * [Nodes](/docs/concepts/architecture/nodes/) and [their communication](/docs/concepts/architecture/control-plane-node-communication/) with the control plane. </del> <ins> * [Nodes](/docs/concepts/architecture/nodes/) and [their communication](/docs/concepts/architecture/control-plane-node-communication/) with the control plane. </ins> * Kubernetes [controllers](/docs/concepts/architecture/controller/). * [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) which is the default scheduler for Kubernetes. * Etcd's official [documentation](https://etcd.io/docs/).


Question:
Just like the pods and the control plane have hover which makes it easier to understand. There should be a hover that should explain what does replica mean here and in what context we are using it as for a beginner it might will be confusing to understand what replica is
Would you be able to provide us with the web page's URL that requires modification? If it's possible, it would be helpful to include the URL in the issue description as well. /language en /triage needs-information
Reference:
/remove-triage needs-information
/retitle Include in glossary and add tooltip for it on "Kubernetes Components" page /language en
Can I work on it now?
/triage accepted Anyone - including you - is welcome to open a pull request. This is open source in action! /priority backlog
/assign

<ins> --- title: Replica id: replica date: 2023-06-11 full_link: short_description: > Replicas are copies of pods, ensuring availability, scalability, and fault tolerance by maintaining identical instances. aka: tags: - fundamental - workload --- A copy or duplicate of a {{< glossary_tooltip text="Pod" term_id="pod" >}} or a set of pods. Replicas ensure high availability, scalability, and fault tolerance by maintaining multiple identical instances of a pod. <!--more--> Replicas are commonly used in Kubernetes to achieve the desired application state and reliability. They enable workload scaling and distribution across multiple nodes in a cluster. By defining the number of replicas in a Deployment or ReplicaSet, Kubernetes ensures that the specified number of instances are running, automatically adjusting the count as needed. Replica management allows for efficient load balancing, rolling updates, and self-healing capabilities in a Kubernetes cluster. </ins>


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. --Update translation /ja/docs/home/supported-doc-versions to current English version Tue May 31 06:54:51 2022 +0600 Why is this needed fix outdated doc Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

--- title: 利用可能なドキュメントバージョン content_type: custom <del> layout: supported-versions </del> <ins> layout: supported-versions </ins> card: name: about weight: 10


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. --Update translation /ja/docs/home/supported-doc-versions to current English version Tue May 31 06:54:51 2022 +0600 Why is this needed fix outdated doc Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

--- 本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 <ins> Kubernetesバージョンのドキュメントの入手性は、そのリリースが現在サポートされているかどうかで分かれます。 どのKubernetesバージョンが公式にどのくらいの期間サポートされるかについて知るには、[サポート期間](/releases/patch-releases/#support-period)を参照してください。 </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: The Bold isn't effect in "Auditing", as shown below: ! Proposed Solution: Modify the format to make the bold effective. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
If this issue been triage/accepted, I think I can fix this. /assign
/sig docs /language zh
/triage accepted
Thanks for the catch! You can fix it if you want.
Sure, let me fix it.

Auditing allows cluster administrators to answer the following questions: --> <del> Kubernetes**审计（Auditing）**功能提供了与安全相关的、按时间顺序排列的记录集， </del> <ins> Kubernetes **审计（Auditing）** 功能提供了与安全相关的、按时间顺序排列的记录集， </ins> 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。 审计功能使得集群管理员能够回答以下问题：


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. -- page has some problems. -page link isn't working. resource metrics pipeline full metrics pipeline the Japanese page exists, some links jump to the English page. Pod Service Why is this needed it is inconvenient for the user. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted

<!-- overview --> アプリケーションを拡張し、信頼性の高いサービスを提供するために、デプロイ時にアプリケーションがどのように動作するかを理解する必要があります。 <del> コンテナ、[Pod](/docs/concepts/workloads/pods/)、[Service](/docs/concepts/services-networking/service/)、クラスター全体の特性を調べることにより、Kubernetesクラスターのアプリケーションパフォーマンスを調査することができます。 </del> <ins> コンテナ、[Pod](/ja/docs/concepts/workloads/pods/)、[Service](/ja/docs/concepts/services-networking/service/)、クラスター全体の特性を調べることにより、Kubernetesクラスターのアプリケーションパフォーマンスを調査することができます。 </ins> Kubernetesは、これらの各レベルでアプリケーションのリソース使用に関する詳細な情報を提供します。 この情報により、アプリケーションのパフォーマンスを評価し、ボトルネックを取り除くことで全体のパフォーマンスを向上させることができます。


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. -- page has some problems. -page link isn't working. resource metrics pipeline full metrics pipeline the Japanese page exists, some links jump to the English page. Pod Service Why is this needed it is inconvenient for the user. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted

Kubernetesでは、アプリケーションの監視は1つの監視ソリューションに依存することはありません。 新しいクラスターでは、[リソースメトリクス](#resource-metrics-pipeline)または[フルメトリクス](#full-metrics-pipeline)パイプラインを使用してモニタリング統計を収集することができます。 <del> ## リソースメトリクスパイプライン </del> <ins> ## リソースメトリクスパイプライン {#resource-metrics-pipeline} </ins> リソースメトリックパイプラインは、[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)コントローラーなどのクラスターコンポーネントや、`kubectl top`ユーティリティに関連する限定的なメトリックセットを提供します。


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. -- page has some problems. -page link isn't working. resource metrics pipeline full metrics pipeline the Japanese page exists, some links jump to the English page. Pod Service Why is this needed it is inconvenient for the user. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted

そして、集約されたPodリソース使用統計情報を、metrics-server Resource Metrics APIを通じて公開します。 このAPIは、kubeletの認証済みおよび読み取り専用ポート上の `/metrics/resource/v1beta1` で提供されます。 <del> ## フルメトリクスパイプライン </del> <ins> ## フルメトリクスパイプライン {#full-metrics-pipeline} </ins> フルメトリクスパイプラインは、より豊富なメトリクスにアクセスすることができます。 Kubernetesは、Horizontal Pod Autoscalerなどのメカニズムを使用して、現在の状態に基づいてクラスターを自動的にスケールまたは適応させることによって、これらのメトリクスに対応することができます。


Question:
Hello there, I would like to suggest adding a link to the CEL Playground in the Kubernetes documentation. CEL (Common Expression Language) is used in Kubernetes APIs, such as the , and the CEL Playground can help users easily test expressions. The playground also includes a set of examples and the . I believe the link would be useful on the following pages: The CEL Playground is available at and the source code can be found at I also invite you to test and contribute to the project. Thank you.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
/transfer website The repo is not quite the right place to track this.
/language en /kind feature
If we add a link, I would add it to: (and I wouldn't add it to the reference page ; instead, we can have link to the three pages I listed above)
/wg api-expression
@ Hey which particular points on these links would you want the CEL playground. I will be glad for more clarification on this?
IMHO, a mention similar to the mention of on the would help: but saying that users can quickly test CEL expressions in the playground.
Hi I've opened a PR () with some suggestions for adding the CEL Playground link. Please take a look and let me know your thoughts. Inviting to share their thoughts as well.
I'm supportive of this. It's a wonderful tool and the community will benefit from being more aware of it.
/triage accepted

to validate the request. If an expression evaluates to false, the validation check is enforced according to the `spec.failurePolicy` field. <ins> {{< note >}} You can quickly test CEL expressions in [CEL Playground](https://playcel.undistro.io). {{< /note >}} </ins> To configure a validating admission policy for use in a cluster, a binding is required. The following is an example of a ValidatingAdmissionPolicyBinding.:


Question:
Hello there, I would like to suggest adding a link to the CEL Playground in the Kubernetes documentation. CEL (Common Expression Language) is used in Kubernetes APIs, such as the , and the CEL Playground can help users easily test expressions. The playground also includes a set of examples and the . I believe the link would be useful on the following pages: The CEL Playground is available at and the source code can be found at I also invite you to test and contribute to the project. Thank you.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
/transfer website The repo is not quite the right place to track this.
/language en /kind feature
If we add a link, I would add it to: (and I wouldn't add it to the reference page ; instead, we can have link to the three pages I listed above)
/wg api-expression
@ Hey which particular points on these links would you want the CEL playground. I will be glad for more clarification on this?
IMHO, a mention similar to the mention of on the would help: but saying that users can quickly test CEL expressions in the playground.
Hi I've opened a PR () with some suggestions for adding the CEL Playground link. Please take a look and let me know your thoughts. Inviting to share their thoughts as well.
I'm supportive of this. It's a wonderful tool and the community will benefit from being more aware of it.
/triage accepted

* spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: failed rule: self.replicas <= self.maxReplicas ``` <ins> {{< note >}} You can quickly test CEL expressions in [CEL Playground](https://playcel.undistro.io). {{< /note >}} </ins> Validation rules are compiled when CRDs are created/updated. The request of CRDs create/update will fail if compilation of validation rules fail. Compilation process includes type checking as well.


Question:
It is unclear what is meant by The statement appears directly under the heading "Creating a Deployment." It is confusing, and it is unclear what relevance defining an "environment variable" has to do with a deployment. Could it be that the author intended to present an action item of defining a pod, and linked to another article that coincidentally contained markup to do so? Suggestion is to clean up the paragraph, and link it to an appropriate article on defining pods, if so.
/sig apps
/retitle Unclear text in “Creating a Deployment” section of Deployment concept
/language en /help /triage accepted
I recommend removing from the page. That's a small fix that doesn't need us to work on the rest of
/assign
page to be updated:
Looks similar (possibly duplicate) of issue we already have
True. /triage duplicate
/remove-triage accepted
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
/remove-help Oops

## Creating a Deployment <del> Before creating a Deployment define an [environment variable](/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) for a container. </del> The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods: {{< codenew file="controllers/nginx-deployment.yaml" >}}


Question:
It is quite unclear from that the feature "GenericEphemeralVolume" is a feature gate because its design does not follow the guideline. The following steps should be done: write the feature gate name as inline code, e.g. change the wording from "feature" to "feature gate" Also there is no information about the components on which this feature gate can be enabled. But! This feature gate is only in . Looks like it's not a feature gate now. Consider removing it from the page.
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
Page related to issue: /language en
/retitle "Ephemeral Volumes" page references the usage of a deprecated feature gate
/sig storage
feature gate has been removed in , the text needs to be updated.
/assign

### Security <del> Enabling the GenericEphemeralVolume feature allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </del> <ins> Using generic ephemeral volumes allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </ins> that rejects objects like Pods that have a generic ephemeral volume. The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota)


Question:
This is a Feature Request What would you like to be Add a comparison between the CRDs and API aggregation layer. should explain this - but doesn't! Why is this needed It's needed so users can understand the difference between CRDs and API aggregation layers.
/sig docs /sig api-machinery
/trick-or-treat
! <detailsIn response to : /trick-or-treat 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
We can take some reference from this to understand the difference between and .
/triage accepted /wg api-expression
This issue looks interesting. I would like to raise a PR for more explanation. /assign

title: Extending the Kubernetes API weight: 30 --- <ins> Custom resources are extensions of the Kubernetes API. Kubernetes provides two ways to add custom resources to your cluster: - The [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD) mechanism allows you to declaratively define a new custom API with an API group, kind, and schema that you specify. The Kubernetes control plane serves and handles the storage of your custom resource. CRDs allow you to create new types of resources for your cluster without writing and running a custom API server. - The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) sits behind the primary API server, which acts as a proxy. This arrangement is called API Aggregation (AA), which allows you to provide specialized implementations for your custom resources by writing and deploying your own API server. The main API server delegates requests to your API server for the custom APIs that you specify, making them available to all of its clients. </ins>


Question:
This page should probably link to resources for defining standard annotations. Especially the thinks mentioned as examples. That would unify it a bit (for example contact address). Maybe link to
Page related to issue: /language en
/retitle Signpost from "Annotations" to "Well-Known Labels, Annotations and Taints" reference page
We can enhance the section by including a link to the reference page, as well as any other relevant pages. This will be beneficial in guiding readers to explore those additional pages.
/kind feature /triage accepted /priority backlog
please i will want to work in this! /assign
i have riased pull request please review.

## {{% heading "whatsnext" %}} <del> Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). </del> <ins> - Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). - Find [Well-known labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) </ins>


Question:
In page , the first part describes that an online interative tutorial is included. But in fact, this tutorial was shutdown a few months ago. I think that may confuse some readers. !
/language en
Some replacement of words can fix this paragraph, but why katacoda/killercoda playgrounds are not used in these tutorial pages to make it interactive? /sig docs /kind feature
/assign
Seems like it's katacoda related.
Hi you don't need to translate anything. Just create a PR for english. (Optionally you can translate this if your know some other languages too. If you try to do so, raise a single PR per language.)
/assign
/kind bug /language en /remove-kind feature /triage accepted /priority important-longterm To discuss potential replacements for Katacoda (which has shut down), visit If anyone would like to support the Kubernetes project to set up or make use of a free replacement for Katacoda, you can: send financial to the Linux Foundation (very indirect support)
/assign

Kubernetes Basics

This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and includes an interactive online tutorial. These interactive tutorials let you manage a simple cluster and its containerized applications for yourself.

Using the interactive tutorials, you can learn to:

This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and a tutorial for you to follow along.

Using the tutorials, you can learn to:

Deploy a containerized application on a cluster.

Scale the deployment.