Merge pull request #45399 from celestehorgan/240229-merged-main-dev-1.30

Merge main branch into dev-1.30

Author: k8s-ci-robot

content/en/blog/_posts/2020-08-03-kubernetes-1-18-release-interview.md

@@ -62,7 +62,7 @@ It was actually just making— again, startup, small company, small team, so rea
 
 **ADAM GLICK: What time frame was this?**
 
-JORGE ALARCÓN: Three, four years ago, so definitely not 1.13. That's the best guesstimate that I can give at this point. But I wasn't able to find any good examples, any tutorials. The only book that I was able to get my hands on was the one written by Joe Beda, Kelsey Hightower, and I forget the other author. But what is it? "[Kubernetes— Up and Running](](http://shop.oreilly.com/product/0636920223788.do))"?
+JORGE ALARCÓN: Three, four years ago, so definitely not 1.13. That's the best guesstimate that I can give at this point. But I wasn't able to find any good examples, any tutorials. The only book that I was able to get my hands on was the one written by Joe Beda, Kelsey Hightower, and I forget the other author. But what is it? "[Kubernetes— Up and Running](http://shop.oreilly.com/product/0636920223788.do)"?
 
 And in general, right now I use it as reference— it's really good. But as a beginner, I still was lost. They give all these amazing examples, they provide the applications, but I had no idea why someone might need a Pod, why someone might need a Deployment. So my last resort was to try and find someone who actually knew Kubernetes.
 

content/en/blog/_posts/2024-03-01-sig-cloud-provider-spotlight.md

@@ -0,0 +1,148 @@
+---
+layout: blog
+title: "Spotlight on SIG Cloud Provider"
+slug: sig-cloud-provider-spotlight-2024
+date: 2024-03-01
+canonicalUrl: https://www.k8s.dev/blog/2024/03/01/sig-cloud-provider-spotlight-2024/
+---
+
+**Author**: Arujjwal Negi
+
+One of the most popular ways developers use Kubernetes-related services is via cloud providers, but
+have you ever wondered how cloud providers can do that? How does this whole process of integration
+of Kubernetes to various cloud providers happen? To answer that, let's put the spotlight on [SIG
+Cloud Provider](https://github.com/kubernetes/community/blob/master/sig-cloud-provider/README.md).
+
+SIG Cloud Provider works to create seamless integrations between Kubernetes and various cloud
+providers. Their mission? Keeping the Kubernetes ecosystem fair and open for all. By setting clear
+standards and requirements, they ensure every cloud provider plays nicely with Kubernetes. It is
+their responsibility to configure cluster components to enable cloud provider integrations.
+
+In this blog of the SIG Spotlight series, [Arujjwal Negi](https://twitter.com/arujjval) interviews
+[Michael McCune](https://github.com/elmiko) (Red Hat), also known as _elmiko_, co-chair of SIG Cloud
+Provider, to give us an insight into the workings of this group.
+
+## Introduction
+
+**Arujjwal**: Let's start by getting to know you. Can you give us a small intro about yourself and
+how you got into Kubernetes?
+
+**Michael**: Hi, I’m Michael McCune, most people around the community call me by my handle,
+_elmiko_. I’ve been a software developer for a long time now (Windows 3.1 was popular when I
+started!), and I’ve been involved with open-source software for most of my career. I first got
+involved with Kubernetes as a developer of machine learning and data science applications; the team
+I was on at the time was creating tutorials and examples to demonstrate the use of technologies like
+Apache Spark on Kubernetes. That said, I’ve been interested in distributed systems for many years
+and when an opportunity arose to join a team working directly on Kubernetes, I jumped at it!
+
+## Functioning and working
+
+**Arujjwal**: Can you give us an insight into what SIG Cloud Provider does and how it functions?
+
+**Michael**: SIG Cloud Provider was formed to help ensure that Kubernetes provides a neutral
+integration point for all infrastructure providers. Our largest task to date has been the extraction
+and migration of in-tree cloud controllers to out-of-tree components. The SIG meets regularly to
+discuss progress and upcoming tasks and also to answer questions and bugs that
+arise. Additionally, we act as a coordination point for cloud provider subprojects such as the cloud
+provider framework, specific cloud controller implementations, and the [Konnectivity proxy
+project](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/).
+
+
+**Arujjwal:** After going through the project
+[README](https://github.com/kubernetes/community/blob/master/sig-cloud-provider/README.md), I
+learned that SIG Cloud Provider works with the integration of Kubernetes with cloud providers. How
+does this whole process go?
+
+**Michael:** One of the most common ways to run Kubernetes is by deploying it to a cloud environment
+(AWS, Azure, GCP, etc). Frequently, the cloud infrastructures have features that enhance the
+performance of Kubernetes, for example, by providing elastic load balancing for Service objects. To
+ensure that cloud-specific services can be consistently consumed by Kubernetes, the Kubernetes
+community has created cloud controllers to address these integration points. Cloud providers can
+create their own controllers either by using the framework maintained by the SIG or by following
+the API guides defined in the Kubernetes code and documentation. One thing I would like to point out
+is that SIG Cloud Provider does not deal with the lifecycle of nodes in a Kubernetes cluster;
+for those types of topics, SIG Cluster Lifecycle and the Cluster API project are more appropriate
+venues.
+
+## Important subprojects
+
+**Arujjwal:** There are a lot of subprojects within this SIG. Can you highlight some of the most
+important ones and what job they do?
+
+**Michael:** I think the two most important subprojects today are the [cloud provider
+framework](https://github.com/kubernetes/community/blob/master/sig-cloud-provider/README.md#kubernetes-cloud-provider)
+and the [extraction/migration
+project](https://github.com/kubernetes/community/blob/master/sig-cloud-provider/README.md#cloud-provider-extraction-migration). The
+cloud provider framework is a common library to help infrastructure integrators build a cloud
+controller for their infrastructure. This project is most frequently the starting point for new
+people coming to the SIG. The extraction and migration project is the other big subproject and a
+large part of why the framework exists. A little history might help explain further: for a long
+time, Kubernetes needed some integration with the underlying infrastructure, not
+necessarily to add features but to be aware of cloud events like instance termination. The cloud
+provider integrations were built into the Kubernetes code tree, and thus the term "in-tree" was
+created (check out this [article on the topic](https://kaslin.rocks/out-of-tree/) for more
+info). The activity of maintaining provider-specific code in the main Kubernetes source tree was
+considered undesirable by the community. The community’s decision inspired the creation of the
+extraction and migration project to remove the "in-tree" cloud controllers in favor of
+"out-of-tree" components.
+
+
+**Arujjwal:** What makes [the cloud provider framework] a good place to start? Does it have consistent good beginner work? What
+kind?
+
+**Michael:** I feel that the cloud provider framework is a good place to start as it encodes the
+community’s preferred practices for cloud controller managers and, as such, will give a newcomer a
+strong understanding of how and what the managers do. Unfortunately, there is not a consistent
+stream of beginner work on this component; this is due in part to the mature nature of the framework
+and that of the individual providers as well. For folks who are interested in getting more involved,
+having some [Go language](https://go.dev/) knowledge is good and also having an understanding of
+how at least one cloud API (e.g., AWS, Azure, GCP) works is also beneficial. In my personal opinion,
+being a newcomer to SIG Cloud Provider can be challenging as most of the code around this project
+deals directly with specific cloud provider interactions. My best advice to people wanting to do
+more work on cloud providers is to grow your familiarity with one or two cloud APIs, then look
+for open issues on the controller managers for those clouds, and always communicate with the other
+contributors as much as possible.
+
+## Accomplishments
+
+**Arujjwal:** Can you share about an accomplishment(s) of the SIG that you are proud of?
+
+**Michael:** Since I joined the SIG, more than a year ago, we have made great progress in advancing
+the extraction and migration subproject. We have moved from an alpha status on the defining
+[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/README.md) to a beta status and
+are inching ever closer to removing the old provider code from the Kubernetes source tree. I've been
+really proud to see the active engagement from our community members and to see the progress we have
+made towards extraction. I have a feeling that, within the next few releases, we will see the final
+removal of the in-tree cloud controllers and the completion of the subproject.
+
+## Advice for new contributors
+
+**Arujjwal:** Is there any suggestion or advice for new contributors on how they can start at SIG
+Cloud Provider?
+
+**Michael:** This is a tricky question in my opinion. SIG Cloud Provider is focused on the code
+pieces that integrate between Kubernetes and an underlying infrastructure. It is very common, but
+not necessary, for members of the SIG to be representing a cloud provider in an official capacity. I
+recommend that anyone interested in this part of Kubernetes should come to an SIG meeting to see how
+we operate and also to study the cloud provider framework project. We have some interesting ideas
+for future work, such as a common testing framework, that will cut across all cloud providers and
+will be a great opportunity for anyone looking to expand their Kubernetes involvement.
+
+**Arujjwal:** Are there any specific skills you're looking for that we should highlight? To give you
+an example from our own [SIG ContribEx]
+(https://github.com/kubernetes/community/blob/master/sig-contributor-experience/README.md):
+if you're an expert in [Hugo](https://gohugo.io/), we can always use some help with k8s.dev!
+
+**Michael:** The SIG is currently working through the final phases of our extraction and migration
+process, but we are looking toward the future and starting to plan what will come next. One of the
+big topics that the SIG has discussed is testing. Currently, we do not have a generic common set of
+tests that can be exercised by each cloud provider to confirm the behaviour of their controller
+manager. If you are an expert in Ginkgo and the Kubetest framework, we could probably use your help
+in designing and implementing the new tests.
+
+---
+
+This is where the conversation ends. I hope this gave you some insights about SIG Cloud Provider's
+aim and working. This is just the tip of the iceberg. To know more and get involved with SIG Cloud
+Provider, try attending their meetings
+[here](https://github.com/kubernetes/community/blob/master/sig-cloud-provider/README.md#meetings).

content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md

@@ -87,7 +87,7 @@ Here is the configuration file for the application Deployment:
    Events:                 <none>
    ```
 
-   Make a note of the NodePort value for the service. For example,
+   Make a note of the NodePort value for the Service. For example,
    in the preceding output, the NodePort value is 31496.
 
 1. List the pods that are running the Hello World application:

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -294,7 +294,6 @@ For example:
 ports:
 - name: liveness-port
   containerPort: 8080
-  hostPort: 8080
 
 livenessProbe:
   httpGet:
@@ -318,7 +317,6 @@ So, the previous example would become:
 ports:
 - name: liveness-port
   containerPort: 8080
-  hostPort: 8080
 
 livenessProbe:
   httpGet:
@@ -542,7 +540,6 @@ spec:
     ports:
     - name: liveness-port
       containerPort: 8080
-      hostPort: 8080
 
     livenessProbe:
       httpGet:

content/es/docs/tasks/run-application/force-delete-stateful-set-pod.md

@@ -0,0 +1,109 @@
+---
+reviewers:
+- ramrodo
+title: Eliminación Forzosa de Pods de StatefulSet
+content_type: task
+weight: 70
+---
+
+<!-- overview -->
+Esta página muestra cómo eliminar Pods que son parte de un
+{{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}},
+y explica las consideraciones a tener en cuenta al hacerlo.
+
+## {{% heading "prerequisites" %}}
+
+- Esta es una tarea bastante avanzada y tiene el potencial de violar algunas de las propiedades
+  inherentes de StatefulSet.
+- Antes de proceder, familiarízate con las consideraciones enumeradas a continuación.
+
+<!-- steps -->
+
+## Consideraciones de StatefulSet
+
+En la operación normal de un StatefulSet, **nunca** hay necesidad de eliminar forzosamente un Pod de StatefulSet.
+El [controlador de StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/) es responsable de
+crear, escalar y eliminar miembros del StatefulSet. Intenta asegurar que el número especificado
+de Pods, desde el ordinal 0 hasta N-1, estén vivos y listos. StatefulSet asegura que, en cualquier momento,
+exista como máximo un Pod con una identidad dada, corriendo en un clúster. Esto se refiere a la semántica de
+*como máximo uno* proporcionada por un StatefulSet.
+
+La eliminación manual forzada debe realizarse con precaución, ya que tiene el potencial de violar la
+semántica de como máximo uno, inherente a StatefulSet. Los StatefulSets pueden usarse para ejecutar aplicaciones distribuidas y
+agrupadas que necesitan una identidad de red estable y almacenamiento estable.
+Estas aplicaciones a menudo tienen configuraciones que dependen de un conjunto de un número fijo de
+miembros con identidades fijas. Tener múltiples miembros con la misma identidad puede ser desastroso
+y puede llevar a pérdida de datos (por ejemplo, escenario de cerebro dividido en sistemas basados en quórum).
+
+## Eliminar Pods
+
+Puedes realizar una eliminación de Pod paulatina con el siguiente comando:
+
+```shell
+kubectl delete pods <pod>
+```
+
+Para que lo anterior conduzca a una terminación paulatina, el Pod no debe especificar un
+`pod.Spec.TerminationGracePeriodSeconds` de 0. La práctica de establecer un
+`pod.Spec.TerminationGracePeriodSeconds` de 0 segundos es insegura y se desaconseja rotundamente
+para los Pods de StatefulSet. La eliminación paulatina es segura y garantizará que el Pod
+se apague de [manera paulatina](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), antes de que kubelet elimine el nombre en el apiserver.
+
+Un Pod no se elimina automáticamente cuando un nodo no es accesible.
+Los Pods que se ejecutan en un Nodo inaccesible entran en el estado 'Terminating' o 'Unknown' después de un
+[tiempo de espera](es/docs/concepts/architecture/nodes/#Estados).
+Los Pods también pueden entrar en estos estados cuando el usuario intenta la eliminación paulatina de un Pod
+en un nodo inaccesible.
+Las únicas formas en que un Pod en tal estado puede ser eliminado del apiserver son las siguientes:
+
+- El objeto Node es eliminado (ya sea por ti, o por el [Controlador de Nodo](/es/docs/concepts/architecture/nodes/#controlador-de-nodos)).).
+- Kubelet, en el nodo no responsivo, comienza a responder, mata el Pod y elimina la entrada del apiserver.
+- Eliminación forzada del Pod por el usuario.
+- 
+La mejor práctica recomendada es usar el primer o segundo enfoque. Si un nodo está confirmado
+como muerto (por ejemplo, desconectado permanentemente de la red, apagado, etc.), entonces elimina
+el objeto Node. Si el nodo es afectado de una partición de red, entonces trata de resolver esto
+o espera a que se resuelva. Cuando la partición se solucione, kubelet completará la eliminación
+del Pod y liberará su nombre en el apiserver.
+
+Normalmente, el sistema completa la eliminación una vez que el Pod ya no se está ejecutando en un nodo, o
+el nodo es eliminado por un administrador. Puedes anular esto forzando la eliminación del Pod.
+
+### Eliminación Forzosa
+
+Las eliminaciones forzosas **no** esperan confirmación de kubelet de que el Pod ha sido terminado.
+Independientemente de si una eliminación forzosa tiene éxito en matar un Pod, inmediatamente
+liberará el nombre del apiserver. Esto permitiría que el controlador de StatefulSet cree un Pod de reemplazo
+con esa misma identidad; esto puede llevar a la duplicación de un Pod que aún está en ejecución,
+y si dicho Pod todavía puede comunicarse con los otros miembros del StatefulSet,
+violará la semántica de como máximo uno que StatefulSet está diseñado para garantizar.
+
+Cuando eliminas forzosamente un Pod de StatefulSet, estás afirmando que el Pod en cuestión nunca
+volverá a hacer contacto con otros Pods en el StatefulSet y su nombre puede ser liberado de forma segura para que
+se cree un reemplazo.
+
+
+Si quieres eliminar un Pod de forma forzosa usando la versión de kubectl >= 1.5, haz lo siguiente:
+
+```shell
+kubectl delete pods <pod> --grace-period=0 --force
+```
+
+Si estás usando cualquier versión de kubectl <= 1.4, deberías omitir la opción `--force` y usar:
+
+```shell
+kubectl delete pods <pod> --grace-period=0
+```
+
+Si incluso después de estos comandos el pod está atascado en el estado `Unknown`, usa el siguiente comando para
+eliminar el Pod del clúster:
+
+```shell
+kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
+```
+
+Siempre realiza la eliminación forzosa de Pods de StatefulSet con cuidado y con pleno conocimiento de los riesgos involucrados.
+
+## {{% heading "whatsnext" %}}
+
+Aprende más sobre [depurar un StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/).

content/ja/releases/notes.md

@@ -0,0 +1,15 @@
+---
+linktitle: リリースノート
+title: ノート
+type: docs
+description: >
+  Kubernetesのリリースノート
+sitemap:
+  priority: 0.5
+---
+
+リリースノートは、使用しているKubernetesのバージョンに合った[Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)を読むことで確認できます。
+{{< skew currentVersionAddMinor 0 >}}のchangelogを見るには[GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)を参照してください。
+
+またリリースノートは、[relnotes.k8s.io](https://relnotes.k8s.io)上で検索してフィルタリングすることもできます。
+{{< skew currentVersionAddMinor 0 >}}のフィルタリングされたリリースノートを見るには[relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)を参照してください。

content/ru/docs/tutorials/kubernetes-basics/scale/scale-intro.html

@@ -41,7 +41,7 @@ <h3>Краткое содержание:</h3>
                     </ul>
                 </div>
                 <div class="content__box content__box_fill">
-                    <p><i>Количество экземпляров можно указать прямо при создании деплоймента, используя параметр <code>--replicas<code> команды <code>kubectl create deployment</code></i></p>
+                    <p><i>Количество экземпляров можно указать прямо при создании деплоймента, используя параметр <code>--replicas</code> команды <code>kubectl create deployment</code></i></p>
                 </div>
             </div>
         </div>