Merge branch 'main' into 31536_seccomp_tutorial_add_prereqs

Author: mrgiles

README-vi.md

@@ -1,7 +1,6 @@
 # Tài liệu Kubernetes
 
-[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
-[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
 Chào mừng! Kho lưu trữ này chứa tất cả các tài nguyên cần thiết để xây dựng [trang web của Kubernetes và các tài liệu](https://kubernetes.io/). Chúng tôi rất vui vì bạn muốn đóng góp.
 

README.md

@@ -56,7 +56,7 @@ Open up your browser to <http://localhost:1313> to view the website. As you make
 
 ## Running the website locally using Hugo
 
-Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file.
+Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file.
 
 To build and test the site locally, run:
 

content/de/docs/tasks/tools/install-kubectl-linux.md

@@ -68,7 +68,7 @@ Um kubectl auf Linux zu installieren, gibt es die folgenden Möglichkeiten:
 
    Falls die Validierung fehlschlägt, beendet sich `sha256` mit einem "nonzero"-Status und gibt einen Fehler aus, welcher so aussehen könnte:
 
-   ```bash
+   ```console
    kubectl: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    ```
@@ -253,7 +253,7 @@ Untenstehend ist beschrieben, wie die Autovervollständigungen für Fish und Zsh
 
    Falls die Validierung fehlschlägt, beendet sich `sha256` mit einem "nonzero"-Status und gibt einen Fehler aus, welcher so aussehen könnte:
 
-   ```bash
+   ```console
    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    ```

content/de/docs/tutorials/hello-minikube.md

@@ -38,9 +38,9 @@ Sie können dieses Tutorial auch verwenden, wenn Sie [Minikube lokal](/docs/task
 
 Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container-Image:
 
-{{< codenew language="js" file="minikube/server.js" >}}
+{{% codenew language="js" file="minikube/server.js" %}}
 
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
+{{% codenew language="conf" file="minikube/Dockerfile" %}}
 
 Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumentation](https://docs.docker.com/engine/reference/commandline/build/).
 

content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md

@@ -26,7 +26,7 @@ In this release, [IPVS-based in-cluster service load balancing](https://github.c
 
 ## Dynamic Kubelet Configuration Moves to Beta
 
-This feature makes it possible for new Kubelet configurations to be rolled out in a live cluster.  Currently, Kubelets are configured via command-line flags, which makes it difficult to update Kubelet configurations in a running cluster. With this beta feature, [users can configure Kubelets in a live cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/) via the API server.
+This feature makes it possible for new Kubelet configurations to be rolled out in a live cluster. Currently, Kubelets are configured via command-line flags, which makes it difficult to update Kubelet configurations in a running cluster. With this beta feature, users can configure Kubelets in a live cluster via the API server.
 
 ## Custom Resource Definitions Can Now Define Multiple Versions
 

content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md

@@ -9,7 +9,7 @@ slug: scaling-kubernetes-networking-with-endpointslices
 
 EndpointSlices are an exciting new API that provides a scalable and extensible alternative to the Endpoints API. EndpointSlices track IP addresses, ports, readiness, and topology information for Pods backing a Service.
 
-In Kubernetes 1.19 this feature is enabled by default with kube-proxy reading from [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It also enables significant new features in future Kubernetes releases like [Topology Aware Routing](/docs/concepts/services-networking/service-topology/).
+In Kubernetes 1.19 this feature is enabled by default with kube-proxy reading from [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It also enables significant new features in future Kubernetes releases like Topology Aware Routing.
 
 ## Scalability Limitations of the Endpoints API 
 With the Endpoints API, there was only one Endpoints resource for a Service. That meant that it needed to be able to store IP addresses and ports (network endpoints) for every Pod that was backing the corresponding Service. This resulted in huge API resources. To compound this problem, kube-proxy was running on every node and watching for any updates to Endpoints resources. If even a single network endpoint changed in an Endpoints resource, the whole object would have to be sent to each of those instances of kube-proxy.

content/en/blog/_posts/2021-04-08-kubernetes-release-1.21.md

@@ -55,7 +55,7 @@ What's next? We're developing a new built-in mechanism to help limit Pod privile
 
 ### TopologyKeys Deprecation
 The Service field `topologyKeys` is now deprecated; all the component features that used this field were previously alpha, and are now also deprecated.
-We've replaced `topologyKeys` with a way to implement topology-aware routing, called topology-aware hints.  Topology-aware hints are an alpha feature in Kubernetes 1.21. You can read more details about the replacement feature in [Topology Aware Hints](/docs/concepts/services-networking/service-topology/); the related [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2433-topology-aware-hints/README.md) explains the context for why we switched.
+We've replaced `topologyKeys` with a way to implement topology-aware routing, called topology-aware hints.  Topology-aware hints are an alpha feature in Kubernetes 1.21. You can read more details about the replacement feature in [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/); the related [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2433-topology-aware-hints/README.md) explains the context for why we switched.
 
 ## Other Updates
 

content/en/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md

@@ -67,7 +67,7 @@ been deprecated. These removals have been superseded by newer, stable/generally
 
 ## API removals, deprecations, and other changes for Kubernetes 1.24
 
-* [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information. 
+* [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information.
 * [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=). 
 * [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). 
 * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. 

content/en/blog/_posts/2023-07-20-sig-cli-spotlight.md

@@ -0,0 +1,161 @@
+---
+layout: blog
+title: "Spotlight on SIG CLI"
+date: 2023-07-20
+slug: sig-cli-spotlight-2023
+canonicalUrl: https://www.kubernetes.dev/blog/2023/07/13/sig-cli-spotlight-2023/
+---
+
+**Author**: Arpit Agrawal
+
+In the world of Kubernetes, managing containerized applications at
+scale requires powerful and efficient tools. The command-line
+interface (CLI) is an integral part of any developer or operator’s
+toolkit, offering a convenient and flexible way to interact with a
+Kubernetes cluster.
+
+SIG CLI plays a crucial role in improving the [Kubernetes
+CLI](https://github.com/kubernetes/community/tree/master/sig-cli)
+experience by focusing on the development and enhancement of
+`kubectl`, the primary command-line tool for Kubernetes.
+
+In this SIG CLI Spotlight, Arpit Agrawal, SIG ContribEx-Comms team
+member, talked with [Katrina Verey](https://github.com/KnVerey), Tech
+Lead & Chair of SIG CLI,and [Maciej
+Szulik](https://github.com/soltysh), SIG CLI Batch Lead, about SIG
+CLI, current projects, challenges and how anyone can get involved.
+
+So, whether you are a seasoned Kubernetes enthusiast or just getting
+started, understanding the significance of SIG CLI will undoubtedly
+enhance your Kubernetes journey.
+
+## Introductions
+
+**Arpit**: Could you tell us a bit about yourself, your role, and how
+you got involved in SIG CLI?
+
+**Maciej**: I’m one of the technical leads for SIG-CLI. I was working
+on Kubernetes in multiple areas since 2014, and in 2018 I got
+appointed a lead.
+
+**Katrina**: I’ve been working with Kubernetes as an end-user since
+2016, but it was only in late 2019 that I discovered how well SIG CLI
+aligned with my experience from internal projects. I started regularly
+attending meetings and made a few small PRs, and by 2021 I was working
+more deeply with the
+[Kustomize](https://github.com/kubernetes-sigs/kustomize) team
+specifically. Later that year, I was appointed to my current roles as
+subproject owner for Kustomize and KRM Functions, and as SIG CLI Tech
+Lead and Chair.
+
+## About SIG CLI
+
+**Arpit**: Thank you! Could you share with us the purpose and goals of SIG CLI?
+
+**Maciej**: Our
+[charter](https://github.com/kubernetes/community/tree/master/sig-cli/)
+has the most detailed description, but in few words, we handle all CLI
+tooling that helps you manage your Kubernetes manifests and interact
+with your Kubernetes clusters.
+
+**Arpit**: I see. And how does SIG CLI work to promote best-practices
+for CLI development and usage in the cloud native ecosystem?
+
+**Maciej**: Within `kubectl`, we have several on-going efforts that
+try to encourage new contributors to align existing commands to new
+standards. We publish several libraries which hopefully make it easier
+to write CLIs that interact with Kubernetes APIs, such as cli-runtime
+and
+[kyaml](https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml).
+
+**Katrina**: We also maintain some interoperability specifications for
+CLI tooling, such as the [KRM Functions
+Specification](https://github.com/kubernetes-sigs/kustomize/blob/master/cmd/config/docs/api-conventions/functions-spec.md)
+(GA) and the new ApplySet
+Specification
+(alpha).
+
+## Current projects and challenges
+
+**Arpit**: Going through the README file, it’s clear SIG CLI has a
+number of subprojects, could you highlight some important ones?
+
+**Maciej**: The four most active subprojects that are, in my opinion,
+worthy of your time investment would be:
+
+* [`kubectl`](https://github.com/kubernetes/kubectl):  the canonical Kubernetes CLI.
+* [Kustomize](https://github.com/kubernetes-sigs/kustomize): a
+  template-free customization tool for Kubernetes yaml manifest files.
+* [KUI](https://kui.tools) - a GUI interface to Kubernetes, think
+   `kubectl` on steroids.
+* [`krew`](https://github.com/kubernetes-sigs/krew): a plugin manager for `kubectl`.
+
+**Arpit**: Are there any upcoming initiatives or developments that SIG
+CLI is working on?
+
+**Maciej**: There are always several initiatives we’re working on at
+any given point in time. It’s best to join [one of our
+calls](https://github.com/kubernetes/community/tree/master/sig-cli/#meetings)
+to learn about the current ones.
+
+**Katrina**: For major features, you can check out [our open
+KEPs](https://www.kubernetes.dev/resources/keps/). For instance, in
+1.27 we introduced alphas for [a new pruning mode in kubectl
+apply](https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning/),
+and for kubectl create plugins. Exciting ideas that are currently
+under discussion include an interactive mode for `kubectl` delete
+([KEP
+3895](https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning))
+and the `kuberc` user preferences file ([KEP
+3104](https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning)).
+
+**Arpit**: Could you discuss any challenges that SIG CLI faces in its
+efforts to improve CLIs for cloud-native technologies? What are the
+future efforts to solve them?
+
+**Katrina**: The biggest challenge we’re facing with every decision is
+backwards compatibility and ensuring we don’t break existing users. It
+frequently happens that fixing what's on the surface may seem
+straightforward, but even fixing a bug could constitute a breaking
+change for some users, which means we need to go through an extended
+deprecation process to change it, or in some cases we can’t change it
+at all. Another challenge is the need to balance customization with
+usability in the flag sets we expose on our tools. For example, we get
+many proposals for new flags that would certainly be useful to some
+users, but not a large enough subset to justify the increased
+complexity having them in the tool entails for everyone. The `kuberc`
+proposal may help with some of these problems by giving individual
+users the ability to set or override default values we can’t change,
+and even create custom subcommands via aliases
+
+**Arpit**: With every new version release of Kubernetes, maintaining
+consistency and integrity is surely challenging: how does the SIG CLI
+team tackle it?
+
+**Maciej**: This is mostly similar to the topic mentioned in the
+previous question: every new change, especially to existing commands
+goes through a lot of scrutiny to ensure we don’t break existing
+users. At any point in time we have to keep a reasonable balance
+between features and not breaking users.
+
+## Future plans and contribution
+
+**Arpit**: How do you see the role of CLI tools in the cloud-native
+ecosystem evolving in the future?
+
+**Maciej**: I think that CLI tools were and will always be an
+important piece of the ecosystem. Whether used by administrators on
+remote machines that don’t have GUI or in every CI/CD pipeline, they
+are irreplaceable.
+
+**Arpit**: Kubernetes is a community-driven project. Any
+recommendation for anyone looking into getting involved in SIG CLI
+work? Where should they start? Are there any prerequisites?
+
+**Maciej**: There are no prerequisites other than a little bit of free
+time on your hands and willingness to learn something new :-)
+
+**Katrina**: A working knowledge of [Go](https://go.dev/) often helps,
+but we also have areas in need of non-code contributions, such as the
+[Kustomize docs consolidation
+project](https://github.com/kubernetes-sigs/kustomize/issues/4338).

content/en/docs/concepts/architecture/garbage-collection.md

@@ -174,8 +174,6 @@ configure garbage collection:
 * [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
 * [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
 
-<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
-
 ## {{% heading "whatsnext" %}}
 
 * Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).