Merge pull request #41702 from ramrodo/gh-41699-localize-configuratio…

…n-overview

[es] Localize content/en/docs/concepts/configuration/overview.md to Spanish

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

@@ -0,0 +1,135 @@
+---
+title: Prácticas Recomendadas de Configuración
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+Este documento destaca y consolida las prácticas recomendadas de configuración que se presentan
+a lo largo de la guía del usuario, la documentación de Introducción y los ejemplos.
+
+Este es un documento vivo. Si se te ocurre algo que no está en esta lista pero que puede ser útil
+a otros, no dudes en crear un _issue_ o enviar un PR.
+
+<!-- body -->
+## Consejos Generales de Configuración
+
+- Al definir configuraciones, especifica la última versión estable de la API.
+
+- Los archivos de configuración deben almacenarse en el control de versiones antes de enviarse al clúster. Este
+  le permite revertir rápidamente un cambio de configuración si es necesario. También ayuda a
+  la recreación y restauración del clúster.
+
+- Escribe tus archivos de configuración usando YAML en lugar de JSON. Aunque estos formatos se pueden utilizarse
+   indistintamente en casi todos los escenarios, YAML tiende a ser más amigable con el usuario.
+
+- Agrupa los objetos relacionados en un solo archivo siempre que tenga sentido. Un archivo suele ser más fácil de
+  administrar que varios. Ver el archivo
+  [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)
+  como un ejemplo de esta sintaxis.
+
+- Ten en cuenta también que se pueden llamar muchos comandos `kubectl` en un directorio. Por ejemplo, puedes llamar
+   `kubectl apply` en un directorio de archivos de configuración.
+
+- No especifiques valores predeterminados innecesariamente: una configuración simple y mínima hará que los errores sean menos probables.
+
+- Coloca descripciones de objetos en anotaciones, para permitir una mejor introspección.
+
+## "Naked" Pods vs ReplicaSets, Deployments y Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
+
+- No usar "Naked" Pods (es decir, Pods no vinculados a un [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) o a un
+  [Deployment](/docs/concepts/workloads/controllers/deployment/)) si puedes evitarlo. Los Naked Pods
+  no se reprogramará en caso de falla de un nodo.
+
+  Un Deployment, que crea un ReplicaSet para garantizar que se alcance la cantidad deseada de Pods está
+  siempre disponible y especifica una estrategia para reemplazar los Pods (como
+  [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), es
+  casi siempre preferible a crear Pods directamente, excepto por algunos explícitos
+  [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) escenarios.
+  Un [Job](/docs/concepts/workloads/controllers/job/) también puede ser apropiado.
+
+## Servicios
+
+- Crea un [Service](/docs/concepts/services-networking/service/) antes de tus cargas de trabajo de backend correspondientes
+  (Deployments o ReplicaSets) y antes de cualquier carga de trabajo que necesite acceder a él.
+  Cuando Kubernetes inicia un contenedor, proporciona variables de entorno que apuntan a todos los _Services_
+  que se estaban ejecutando cuando se inició el contenedor. Por ejemplo, si existe un _Service_ llamado `foo`,
+  todos los contenedores obtendrán las siguientes variables en su entorno inicial:
+
+  ```shell
+  FOO_SERVICE_HOST=<el host en el que se ejecuta el Service>
+  FOO_SERVICE_PORT=<el puerto en el que se ejecuta el Service>
+  ```
+
+  \* Esto implica un requisito de ordenamiento - cualquier `Service` al que un `Pod` quiera acceder debe ser
+  creado antes del `Pod` en sí mismo, de lo contrario, las variables de entorno no se completarán.
+  El DNS no tiene esta restricción.
+
+- Un [cluster add-on](/docs/concepts/cluster-administration/addons/) opcional (aunque muy recomendable)
+  es un servidor DNS. El servidor DNS observa la API de Kubernetes en busca de nuevos `Servicios` y crea un conjunto
+  de registros DNS para cada uno. Si el DNS se ha habilitado en todo el clúster, todos los `Pods` deben ser
+  capaces de hacer la resolución de nombres de `Services` automáticamente.
+
+- No especifiques un `hostPort` para un Pod a menos que sea absolutamente necesario. Cuando vinculas un Pod a un
+   `hostPort`, limita la cantidad de lugares en los que se puede agendar el Pod, porque cada combinación <`hostIP`,
+   `hostPort`, `protocol`> debe ser única. Si no especificas el `hostIP` y
+   `protocol` explícitamente, Kubernetes usará `0.0.0.0` como el `hostIP` predeterminado y `TCP` como el
+   `protocol` por defecto.
+
+  Si solo necesitas acceder al puerto con fines de depuración, puedes utilizar el
+  [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)
+  o [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+
+  Si necesitas exponer explícitamente el puerto de un Pod en el nodo, considera usar un
+  [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service antes de recurrir a
+  `hostPort`.
+
+- Evita usar `hostNetwork`, por las mismas razones que `hostPort`.
+
+- Usa [headless Services](/docs/concepts/services-networking/service/#headless-services)
+  (que tiene un `ClusterIP` de `None`) para el descubrimiento de servicios cuando no necesites
+  balanceo de carga `kube-proxy`.
+
+## Usando Labels
+
+- Define y usa [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquen
+  __atributos semánticos__ de tu aplicación o Deployment, como `{ app.kubernetes.io/name:
+  MyApp, tier: frontend, phase: test, deployment: v3 }`. Puedes utilizar estas labels para seleccionar los
+  Pods apropiados para otros recursos; por ejemplo, un Service que selecciona todo los
+  Pods `tier: frontend`, o todos los componentes `phase: test` de `app.kubernetes.io/name: MyApp`.
+  Revisa el [libro de visitas](https://github.com/kubernetes/examples/tree/master/guestbook/)
+  para ver ejemplos de este enfoque.
+
+  Un Service puede hacer que abarque múltiples Deployments omitiendo las labels específicas de la versión de su
+  selector. Cuando necesites actualizar un servicio en ejecución sin downtime, usa un
+  [Deployment](/docs/concepts/workloads/controllers/deployment/).
+
+  Un estado deseado de un objeto se describe mediante una implementación, y si los cambios a esa especificación son
+  _aplicados_, el controlador de implementación cambia el estado actual al estado deseado en un
+  ritmo controlado.
+
+- Use las [labels comunes de Kubernetes](/docs/concepts/overview/working-with-objects/common-labels/)
+  para casos de uso común. Estas labels estandarizadas enriquecen los metadatos de una manera que permite que las herramientas,
+  incluyendo `kubectl` y el [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard),
+  trabajen de forma interoperable.
+
+- Puedes manipular las labels para la depuración. Debido a que los controladores de Kubernetes (como ReplicaSet) y
+  los Services coinciden con los Pods usando labels de selector, se detendrá la eliminación de las labels relevantes de un Pod
+  que sea considerado por un controlador o que un Service sirva tráfico. si quitas
+  las labels de un Pod existente, su controlador creará un nuevo Pod para ocupar su lugar. Esto es un
+  forma útil de depurar un Pod previamente "vivo" en un entorno de "cuarentena". Para eliminar interactivamente
+  o agregar labels, usa [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
+
+## Usando kubectl
+
+- Usa `kubectl apply -f <directorio>`. Esto busca la configuración de Kubernetes en todos los `.yaml`,
+   `.yml`, y `.json` en `<directorio>` y lo pasa a `apply`.
+
+- Usa selectores de labels para las operaciones `get` y `delete` en lugar de nombres de objetos específicos. Ve las
+  secciones en [selectores de labels](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+  y [usar labels de forma eficaz](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+
+- Usa `kubectl create deployment` y `kubectl expose` para crear rápidamente un contenedor único
+   Deployments y Services.
+   Consulta [Usar un Service para Acceder a una Aplicación en un Clúster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
+   para un ejemplo.