add es pages

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

@@ -1,10 +1,10 @@
 ---
 title: Conceptos subyacentes del Cloud Controller Manager
-content_template: templates/concept
+content_type: concept
 weight: 30
 ---
 
-{{% capture overview %}}
+<!-- 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.
 
@@ -16,10 +16,10 @@ En la siguiente imagen, se puede ver la arquitectura de un cluster de Kubernetes
 
 ![Arquitectura previa a CCM](/images/docs/pre-ccm-arch.png)
 
-{{% /capture %}}
 
 
-{{% capture body %}}
+
+<!-- body -->
 
 ## Diseño
 
@@ -235,4 +235,4 @@ Los siguientes proveedores de servicios en la nube han implementado CCMs:
 
 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

@@ -2,17 +2,17 @@
 reviewers:
 - glo-pena
 title: Comunicación Nodo-Maestro
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---
 
-{{% capture overview %}}
+<!-- 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 %}}
+
+<!-- body -->
 
 ### Clúster a Máster
 
@@ -56,4 +56,3 @@ Kubernetes ofrece soporte para túneles SSH que protegen la comunicación  Mást
 
 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 %}}

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

@@ -2,18 +2,18 @@
 reviewers:
 - glo-pena
 title: Nodos
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---
 
-{{% capture overview %}}
+<!-- overview -->
 
 Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](/docs/concepts/workloads/pods/pod). Los servicios en un nodo incluyen el [container runtime](/docs/concepts/overview/components/#node-components), kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle.
 
-{{% /capture %}}
 
 
-{{% capture body %}}
+
+<!-- body -->
 
 ## Estado del Nodo
 
@@ -180,4 +180,4 @@ Para reservar explícitamente recursos en la máquina huésped para procesos no
 Un nodo es un recurso principal dentro de la REST API de Kubernetes. Más detalles sobre el objeto en la  API se puede encontrar en: [Object Node API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
 
 
-{{% /capture %}}
+