Merge pull request #19541 from VineethReddy02/merged-master-to-dev-1.18

Merged master to dev 1.18

content/en/docs/concepts/services-networking/ingress.md

@@ -136,10 +136,10 @@ kubectl get ingress test-ingress
 
 ```
 NAME           HOSTS     ADDRESS           PORTS     AGE
-test-ingress   *         107.178.254.228   80        59s
+test-ingress   *         203.0.113.123   80        59s
 ```
 
-Where `107.178.254.228` is the IP allocated by the Ingress controller to satisfy
+Where `203.0.113.123` is the IP allocated by the Ingress controller to satisfy
 this Ingress.
 
 {{< note >}}

content/en/docs/tutorials/_index.md

@@ -22,8 +22,6 @@ Before walking through each tutorial, you may want to bookmark the
 
 * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
 
-* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
-
 * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
 
 * [Hello Minikube](/docs/tutorials/hello-minikube/)

content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html

@@ -17,6 +17,14 @@
 
     <main class="content katacoda-content">
 
+        <div class="row">
+            <div class="col-md-12">
+                <p>
+                    A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Learn more about Pods</a>.
+                </p>
+            </div>
+        </div>
+
         <br>
         <div class="katacoda">
             <div class="katacoda__alert">

content/es/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -0,0 +1,153 @@
+---
+title: Organizar el acceso a los clústeres utilizando archivos kubeconfig
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+Utilice los archivos kubeconfig para organizar la información acerca de los clústeres, los
+usuarios, los Namespaces y los mecanismos de autenticación. La herramienta de
+línea de comandos `kubectl` utiliza los archivos kubeconfig para hallar la información que
+necesita para escoger un clúster y comunicarse con el servidor API de un clúster.
+
+{{< note >}}
+Un archivo utilizado para configurar el acceso a los clústeres se denomina
+*archivo kubeconfig*. Esta es una forma genérica de referirse a los archivos de
+configuración. Esto no significa que exista un archivo llamado `kubeconfig`.
+{{< /note >}}
+
+Por defecto, `kubectl` busca un archivo llamado `config` en el directorio `$HOME/.kube`.
+Puedes especificar otros archivos kubeconfig mediante la configuración de la variable
+de entorno `KUBECONFIG` o mediante la configuracion del flag
+[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
+
+Para obtener instrucciones paso a paso acerca de cómo crear y especificar los archivos kubeconfig,
+consulte el recurso
+[Configurar El Acceso A Múltiples Clústeres](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Compatibilidad con múltiples clústeres, usuarios y mecanismos de autenticación
+
+Suponga que tiene diversos clústeres y que sus usuarios y componentes se autentican
+de diversas maneras. Por ejemplo:
+
+- Un kubelet en ejecución se podría autenticar usando certificados.
+- Un usuario se podría autenticar utilizando tokens.
+- Los administradores podrían tener un conjunto de certificados que sean suministrados a los usuarios individualmente.
+
+Con los archivos kubeconfig puedes organizar tus clústeres, usuarios y Namespaces.
+También puedes definir diferentes contextos para realizar de forma rápida y
+fácil cambios entre clústeres y Namespaces.
+
+## Contexto
+
+Un elemento *context* en un archivo kubeconfig se utiliza para agrupar los parámetros de
+acceso bajo un nombre apropiado. Cada contexto tiene tres parámetros: clúster, Namespace
+y usuario.
+Por defecto, la herramienta de línea de comandos `kubectl` utiliza los parámetros del
+*contexto actual* para comunicarse con el clúster.
+
+Para seleccionar el contexto actual:
+
+```shell
+kubectl config use-context
+```
+
+## Variable de entorno KUBECONFIG
+
+La variable de entorno `KUBECONFIG` contiene una lista de archivos kubeconfig.
+En el caso de Linux y Mac, la lista está delimitada por dos puntos.  Si se trata
+de Windows, la lista está delimitada por punto y coma. La variable de entorno
+`KUBECONFIG` no es indispensable. Si la variable de entorno `KUBECONFIG` no existe,
+`kubectl` utiliza el archivo kubeconfig por defecto `$HOME/.kube/config`.
+
+Si la variable de entorno `KUBECONFIG` existe, `kubectl` utiliza una
+configuración eficiente que es el resultado de la fusión de los archivos
+listados en la variable de entorno `KUBECONFIG`.
+
+## Fusionando archivos kubeconfig
+
+Para poder ver su configuración, escriba el siguiente comando:
+
+```shell
+kubectl config view
+```
+
+Como se ha descrito anteriormente, la respuesta de este comando podría resultar a partir de un solo
+archivo kubeconfig, o podría ser el resultado de la fusión de varios archivos kubeconfig.
+
+A continuación se muestran las reglas que usa `kubectl` cuando fusiona archivos kubeconfig:
+
+1. Si el flag `--kubeconfig` está activado, usa solamente el archivo especificado. Sin fusionar.
+   Sólo se permite una instancia con este flag.
+
+   En caso contrario, si la variable de entorno `KUBECONFIG` está activada, sera usada
+   como un listado de los archivos a ser fusionados.
+   Fusionar los archivos listados en la variable de entorno `KUBECONFIG` de acuerdo
+   con estas reglas:
+
+   * Ignorar nombres de archivo vacíos.
+   * Producir errores para archivos con contenido que no pueden ser deserializados.
+   * El primer archivo que establezca un valor particular o una clave se impone.
+   * Nunca cambie el valor o la clave.
+     Ejemplo: Conserva el contexto del primer archivo para configurar el `contexto actual`.
+     Ejemplo: Si dos archivos especifican un `red-user`, utilice sólo los valores del primer archivo.
+     Incluso desechar el segundo archivo aunque tenga registros que no tengan conflictos.
+
+   Para obtener un ejemplo de configuración de la variable de entorno `KUBECONFIG`, consulte la sección
+   [Configuración de la variable de entorno KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+
+   En caso contrario, utilice el archivo kubeconfig predeterminado `$HOME/.kube/config`, sin fusionar.
+
+2. Determinar el contexto a utilizar con base en el primer acierto en esta secuencia:
+
+   1. Si es que existe, utilice el flag `---contexto` de la línea de comandos.
+   2. Utilice el `contexto actual` procedente de los archivos kubeconfig fusionados.
+
+   En este punto se permite un contexto vacío.
+
+3. Determinar el clúster y el usuario. En este caso, puede o no haber un contexto.
+   Determine el clúster y el usuario con base en el primer acierto que se ejecute dos veces en
+   esta secuencia: una para el usuario y otra para el clúster:
+
+   1. Si es que existen, utilice el flag `--user` o `--cluster` de la línea de comandos.
+   2. Si el contexto no está vacío, tome el usuario o clúster del contexto.
+
+   En este caso el usuario y el clúster pueden estar vacíos.
+
+4. Determinar la información del clúster a utilizar. En este caso, puede o no haber información del clúster.
+   Se construye cada pieza de la información del clúster con base en esta secuencia, el primer acierto se impone:
+
+   1. Si es que existen, use el flag `--server`, `--certificate-authority`, `--insecure-skip-tls-verify` en la línea de comandos.
+   2. Si existen atributos de información de clúster procedentes de los archivos kubeconfig fusionados, utilícelos.
+   3. Falla si no existe la ubicación del servidor.
+
+5. Determinar la información del usuario a utilizar. Cree información de usuario utilizando las mismas reglas que
+   la información de clúster, con la excepción de permitir sólo un mecanismo de autenticación por usuario:
+
+   1. Si es que existen, utilice el flag `--client-certificate`, `--client-key`, `--username`, `--password`, `--token` de la línea de comandos.
+   2. Utilice los campos `user` de los archivos kubeconfig fusionados.
+   3. Falla si hay dos mecanismos de autenticación contradictorios.
+
+6. Si todavía falta información, utilice los valores predeterminados y solicite
+   información de autenticación.
+
+## Referencias de archivos
+
+Las referencias, así también como, las rutas de un archivo kubeconfig son relativas a la ubicación del archivo kubeconfig.
+Las referencias de un archivo en la línea de comandos son relativas al directorio actual de trabajo.
+Dentro de `$HOME/.kube/config`, las rutas relativas se almacenan de manera relativa a la ubicación del archivo kubeconfig , al igual que las rutas absolutas
+se almacenan absolutamente.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Configurar el acceso a multiples Clústeres](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
+
+{{% /capture %}}

content/ko/docs/concepts/architecture/nodes.md

@@ -184,7 +184,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 #### 안정성
 
 쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 
-문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 
+문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제들이 발생했기 때문에) 
 더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로, 
 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 
 내 모든 노드를 살핀다.
@@ -210,7 +210,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 
 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 
 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 
-정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이 
+`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 
 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 
 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 
 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.

content/ko/docs/concepts/configuration/overview.md

@@ -28,7 +28,7 @@ weight: 10
 - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
 
 
-## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
+## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs}
 
 - 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
 
@@ -85,7 +85,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 - `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
 
 {{< note >}}
-컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
+컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
 {{< /note >}}
 
 {{< note >}}