Localisation of the architecture section (kubernetes#14145)

content/es/docs/concepts/architecture/cloud-controller.md

@@ -0,0 +1,238 @@
+---
+title: Conceptos subyacentes del Cloud Controller Manager
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionasen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes.
+
+El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en incorporar nuevos proveedores de servicios y para migrar los existentes del viejo modelo al nuevo CCM.
+
+Este documento describe los conceptos tras el Cloud Controller Manager y da detalles sobre sus funciones asociadas.
+
+En la siguiente imagen, se puede ver la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager:
+
+![Arquitectura previa a CCM](/images/docs/pre-ccm-arch.png)
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Diseño
+
+En el diagrama anterior, Kubernetes y el proveedor de servicios en la nube están integrados a través de diferentes componentes:
+
+* Kubelet
+* Kubernetes controller manager
+* Kubernetes API server
+
+El CCM consolida toda la lógica dependiente de la nube de estos tres componentes para crear un punto de integración único. La nueva arquitectura con CCM se muestra a continuación:
+
+![Arquitectura CCM](/images/docs/post-ccm-arch.png)
+
+## Componentes del CCM
+
+El CCM secciona parte de la funcionalidad del Kubernetes Controller Manager (KCM) y la ejecuta como procesos independientes. Específicamente, aquellos controladores en el KCM que son dependientes de la nube:
+
+ * Controlador de Nodos
+ * Controlador de Volúmenes
+ * Controlador de Rutas
+ * Controlador de Servicios
+
+En la versión 1.9, el CCM se encarga de la ejecución de los siguientes controladores:
+
+ * Controlador de Nodos
+ * Controlador de Rutas
+ * Controlador de Servicios
+
+{{< note >}}
+El controlador de volúmenes se dejó fuera del CCM de forma explícita. Debido a la complejidad que ello requería y a los esfuerzos existentes para abstraer lógica de volúmenes específica a proveedores de servicios, se decidió que el controlador de volúmenes no fuese movido al CCM.
+{{< /note >}}
+
+El plan original para habilitar volúmenes en CCM era utilizar volúmenes Flex con soporte para volúmenes intercambiables. Sin embargo, otro programa conocido como CSI (Container Storage Interface) se está planeando para reemplazar Flex.
+
+Considerando todo lo anterior, se ha decidido esperar hasta que CSI esté listo.
+
+## Funciones del CCM
+
+El CCM hereda sus funciones de componentes que son dependientes de un proveedor de servicios en la nube. Esta sección se ha estructurado basado en dichos componentes:
+
+### 1. Kubernetes Controller Manager
+
+La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control: 
+
+ * Controlador de Nodos
+ * Controlador de Rutas
+ * Controlador de Servicios
+
+#### Controlador de Nodos
+
+El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones: 
+
+1. Inicializa un nodo con etiquetas de región y zona específicas del proveedor.
+2. Inicializa un nodo con detalles de la instancia específicos del proveedor, como por ejemplo, el tipo o el tamaño.
+3. Obtiene las direcciones de red del nodo y su hostname.
+4. En caso de que el nodo deje de responder, comprueba la nube para ver si el nodo ha sido borrado. Si lo ha sido, borra el objeto nodo en Kubernetes.
+
+#### Controlador de Rutas
+
+El controlador de Rutas es responsable de configurar rutas en la nube para que contenedores en diferentes nodos dentro de un clúster kubernetes se puedan comunicar entre sí.
+
+#### Controlador de Servicios
+
+El controlador de servicios es responsable de monitorizar eventos de creación, actualización y borrado de servicios. Basándose en el estado actual de los servicios en el clúster Kubernetes, configura balanceadores de carga del proveedor (como Amazon ELB, Google LB, or Oracle Cloud Infrastructure Lb) de forma que estos reflejen los servicios definidos en Kubernetes. Adicionalmente, se asegura de que los sistemas de apoyo de servicios para balanceadores de carga en la nube se encuentren actualizados.
+
+### 2. Kubelet
+
+El controlador de nodos incluye la funcionalidad del kubelet que es dependiente de la nube. Previa a la introducción de CCM, el kubelet era responsable de inicializar un nodo con detalles específicos al proveedor como direcciones IP, etiquetas de región/zona y tipo de instancia. La introduccion de CCM transfiere esta inicialización del kubelet al CCM.
+
+En este nuevo modelo, el kubelet inicializa un nodo sin información especifica del proveedor de servicios. Sin embargo, añade un `taint` al nodo recién creado de forma que este no esté disponible para el planificador hasta que el CCM completa el nodo con la información específica del proveedor. Sólo entonces elimina el `taint` y el nodo se vuelve accesible.
+
+## Mecanismo de Plugins (extensiones)
+
+El Cloud Controller Manager utiliza interfaces Go(lang), lo que permite que implementaciones de cualquier proveedor de servicios sean conectadas. Específicamente, utiliza el CloudProvider Interface definido [aquí](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
+
+La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes. 
+
+Para más información sobre el desarrollo de extensiones/plugins, consultar [Desarrollo del CCM](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
+
+## Autorización
+
+Esta sección divide el nivel de acceso requerido por varios objetos API para que el CCM pueda llevar acabo sus operaciones.
+
+### Controlador de Nodos
+
+El controlador de nodos sólo opera con objetos Nodo. Necesita de acceso total para obtener, listar, crear, actualizar, arreglar, monitorizar y borrar objetos Nodo.
+
+v1/Node:
+
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+### Controlador de Rutas
+
+El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo. 
+
+v1/Node:
+
+- Get
+
+### Controlador de Servicios
+
+El controlador de servicios permanece a la escucha de eventos de creación, actualización y borrado de objetos Servicio, y se encarga de configurar los endpoints para dichos servicios.
+
+Para acceder a los objetos Servicio, necesita permisos para listar y monitorizar. Para el mantenimiento de servicios necesita permisos para parchear y actualizar.
+
+Para configurar endpoints para los servicios necesita permisos para crear, listar, obtener, monitorizar y actualizar.
+
+v1/Service:
+
+- List
+- Get
+- Watch
+- Patch
+- Update
+
+### Otros
+
+La implementación del núcleo de CCM requiere acceso para crear eventos, y para asegurar la seguridad de operaciones; necesita acceso para crear ServiceAccounts.
+
+v1/Event:
+
+- Create
+- Patch
+- Update
+
+v1/ServiceAccount:
+
+- Create
+
+El RBAC ClusterRole para CCM se muestra a continuación:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: cloud-controller-manager
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - events
+  verbs:
+  - create
+  - patch
+  - update
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - '*'
+- apiGroups:
+  - ""
+  resources:
+  - nodes/status
+  verbs:
+  - patch
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - persistentvolumes
+  verbs:
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - endpoints
+  verbs:
+  - create
+  - get
+  - list
+  - watch
+  - update
+```
+
+## Implementaciones de Proveedores
+
+Los siguientes proveedores de servicios en la nube han implementado CCMs:
+
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
+* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
+* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
+* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
+
+## Administración del Clúster
+
+Instrucciones para configurar y ejecutar el CCM pueden encontrarse [aquí](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
+
+{{% /capture %}}

content/es/docs/concepts/architecture/master-node-communication.md

@@ -0,0 +1,59 @@
+---
+reviewers: 
+- glo-pena
+title: Comunicación Nodo-Maestro
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+Este documento cataloga las diferentes vías de comunicación entre el nodo máster (en realidad el apiserver) y el clúster de Kubernetes. La intención es permitir a los usuarios personalizar sus instalaciones para proteger sus configuraciones de red de forma que el clúster pueda ejecutarse en una red insegura. (o en un proveedor de servicios en la nube con direcciones IP públicas)
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+### Clúster a Máster
+
+Todos los canales de comunicación desde el clúster hacia el máster terminan en el apiserver (ningún otro componente del máster está diseñado para exponer servicios remotos). En un despliegue típico, el apiserver está configurado para escuchar conexiones remotas en un canal seguro cómo HTTPS en el puerto (443) con una o más formas de [autenticación de clientes](/docs/reference/access-authn-authz/authentication/) habilitada. Una o más formas de [autorización](/docs/reference/access-authn-authz/authorization/) deberían ser habilitadas, especialmente si se permiten [peticiones anónimas](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+o [tokens de cuenta de servicio](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
+
+Los nodos deben ser aprovisionados con el certificado raíz público del clúster de forma que puedan conectar de forma segura con el apiserver en conjunción con credenciales de cliente válidas. Por ejemplo, en un despliegue por defecto en GKE, las credenciales de cliente proporcionadas al kubelet están en la forma de certificados de cliente. Accede [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) para ver cómo aprovisionar certificados de cliente de forma automática.
+
+Aquellos Pods que deseen conectar con el apiserver pueden hacerlo de forma segura a través de una cuenta de servicio, de esta forma Kubernetes inserta de forma automática el certificado raíz público y un bearer token válido en el pod cuando este es instanciado. El servicio `kubernetes` (en todos los namespaces) se configura con una dirección IP virtual que es redireccionada (via kube-proxy) al punto de acceso HTTPS en el apiserver.
+
+Los componentes máster también se comunican con el apiserver del clúster a través de un puerto seguro.
+
+Como resultado, el modo de operación por defecto para conexiones desde el clúster (nodos y pods ejecutándose en nodos) al máster es seguro por defecto y puede correr en redes públicas y/o inseguras.
+
+## Máster a Clúster
+
+Hay dos vías de comunicación primaria desde el máster (apiserver) al clúster. La primera es desde el apiserver al proceso kubelet que se ejecuta en cada nodo del clúster. La segunda es desde el apiserver a cualquier nodo, pod, o servicio a través de la funcionalidad proxy del apiserver.
+
+### apiserver al kubelet
+
+Las conexiones del apiserver al kubelet se utilizan para:
+
+  * Recoger entradas de registro de pods.
+  * Conectar (a través de `kubectl`) con pods en ejecución.
+  * Facilitar la funcionalidad `port-forwarding` del kubelet.
+
+Estas conexiones terminan en el endpoint HTTPS del kubelet. Por defecto, el apiserver no verifica el certificado del kubelet, por lo que la conexión es vulnerable a ataques del tipo `man-in-the-middle`, e **insegura** para conectar a través de redes públicas o de no confianza.
+
+Para verificar esta conexión, se utiliza el atributo `--kubeket-certificate-authority` que provee el apiserver con un certificado raíz con el que verificar el certificado del kubelet.
+Si esto no es posible, se utiliza un [túnel SSH](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) entre el apiserver y el kubelet para conectar a través de redes públicas o de no confianza.
+
+Finalmente, [autenticación y/o autorización al kubelet](/docs/admin/kubelet-authentication-authorization/) debe ser habilitada para proteger su API.
+
+### apiserver a nodos, pods y servicios
+
+Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. Pueden ser ejecutadas en una conexión HTTPS segura añadiendo el prefijo `https:` al nodo, pod o nombre de servicio en la API URL, pero los receptores no validan el certificado provisto por el endpoint HTTPS ni facilitan credenciales de cliente asi que, aunque la conexión esté encriptada, esta no ofrece garantía de integridad. Estas conexiones **no son seguras** para conectar a través de redes públicas o inseguras.  
+
+### Túneles SSH
+
+Kubernetes ofrece soporte para túneles SSH que protegen la comunicación  Máster -> Clúster. En este modo de configuración, el apiserver inicia un túnel SSH a cada nodo en el clúster (conectando al servidor SSH en el puerto 22) y transfiere todo el tráfico destinado a un kubelet, nodo, pod o servicio a través del túnel. El túnel garantiza que dicho tráfico no es expuesto fuera de la red en la que se ejecutan los nodos.
+
+Los túneles SSH se consideran obsoletos, y no deberían utilizarse a menos que se sepa lo que se está haciendo. Se está diseñando un reemplazo para este canal de comunicación.
+
+{{% /capture %}}