Cómo preparar un entorno de Google Kubernetes Engine para la producción

En esta solución, se proporciona un modelo y una metodología para la integración de las cargas de trabajo de manera más segura, confiable y rentable a Google Kubernetes Engine. Se proporciona orientación para configurar el acceso administrativo y de red a los clústeres. En este artículo, se analiza una comprensión práctica de los recursos de Kubernetes y la administración de clústeres, así como la familiaridad con las funciones de red de Google Cloud Platform (GCP).

Cómo estructurar proyectos, redes de nube privada virtual (VPC) y clústeres

En el diagrama a continuación, se muestra la estructura recomendada para proyectos, redes de VPC, regiones, subredes, zonas y clústeres.

Estructura de proyecto, red y clúster

Proyectos

GCP crea todos sus recursos dentro de una entidad de proyecto. Los proyectos son la unidad de facturación y permiten a los administradores asociar las funciones de administración de identidades y accesos de Cloud (Cloud IAM) con los usuarios. Cuando las funciones se aplican a nivel de proyecto, también se aplican a todos los recursos encapsulados en el proyecto.

Debes usar proyectos para encapsular todos los entornos operativos. Por ejemplo, es posible que tengas los proyectos production y staging para los equipos de operaciones, así como un proyecto test-dev para los desarrolladores. A fin de experimentar, puedes aplicar políticas más estrictas y detalladas a los proyectos que conservan los datos sensibles y más esenciales, además de las cargas de trabajo mientras aplicas políticas permisivas y flexibles para los desarrolladores en el entorno test-dev.

Clústeres

Un proyecto puede contener varios clústeres. Si tienes varias cargas de trabajo que implementar, puedes optar por usar un clúster compartido o clústeres independientes para estas cargas de trabajo. A fin de ayudarte a decidir, considera nuestras recomendaciones en Elige el tamaño y el alcance de un clúster de GKE.

Redes y subredes

En cada proyecto, puedes tener una o más Redes de VPC, que son versiones virtuales de redes físicas. Cada red de VPC es un recurso global que contiene otros recursos relacionados con la red, como subredes, direcciones IP externas, reglas de firewall, rutas, tu VPN y Cloud Router. En una red de VPC, puedes usar Subredes, las cuales son recursos regionales para aislar y controlar el tráfico que entra o sale de cada región entre los clústeres de GKE.

Cada proyecto viene con una sola red predeterminada. Puedes crear y configurar una red adicional para asignarla a la convención de administración de direcciones IP (IPAM) existente. A continuación, puedes aplicar Reglas de firewall a esta red para filtrar el tráfico desde y hacia los nodos de GKE. Según la configuración predeterminada, se niega todo el tráfico de Internet a los nodos de GKE.

Para controlar la comunicación entre redes, debes Crear reglas de firewall que permitan el paso del tráfico entre las subredes. Usa el marcador --tags durante la creación de un clúster o grupo de nodos para etiquetar correctamente los nodos de GKE a fin de que se apliquen las reglas de firewall. También puedes usar etiquetas para crear rutas entre las subredes si es necesario.

Clústeres multizona y regionales

Según la configuración predeterminada, un clúster crea su instancia principal de clúster y sus nodos en una zona única que especificas en el momento de la creación. Puedes mejorar la disponibilidad y resiliencia de los clústeres mediante la creación de clústeres multizona o regionales. Los clústeres multizona y regionales distribuyen los recursos de Kubernetes en varias zonas dentro de una región.

Clústeres multizona:

  • Crean una instancia principal de clúster única en una zona.
  • Crean nodos en varias zonas.

Clústeres regionales:

  • Crean tres instancias principales de clúster en tres zonas.
  • Según la configuración predeterminada, crean nodos en tres zonas o en tantas zonas como desees.

La diferencia principal entre los clústeres regionales y multizona es que los primeros crean tres instancias principales y los segundos crean solo una. Ten en cuenta que en ambos casos se te cobra por el tráfico de nodo a nodo en las zonas.

Puedes optar por crear clústeres multizona o regionales en el momento de la creación del clúster. Puedes agregar zonas nuevas a un clúster existente para que sea multizona. Sin embargo, no puedes modificar un clúster existente para que sea regional. Tampoco puedes hacer que un clúster regional ya no lo sea.

Para obtener información sobre clústeres multizona y regionales, consulta la Documentación de GKE.

Cómo administrar la identidad y el acceso

Acceso a nivel de proyecto

En la sección anterior, se indicó que puedes vincular Funciones de IAM a usuarios en el nivel de proyecto. Además de otorgar funciones a usuarios individuales, puedes usar Grupos para simplificar la aplicación de funciones.

A continuación, se muestra una ilustración del diseño de la política de IAM que proporciona el principio de privilegio mínimo para un proyecto de desarrollo que esté configurado a fin de que los desarrolladores generen y prueben sus funciones y correcciones de errores futuras, así como un proyecto de producto para el tráfico de producción:

Administración de identidades y accesos

Como se muestra en la siguiente tabla, hay 4 grupos de usuarios dentro de la organización con niveles diferentes de permisos, otorgados mediante las Funciones de IAM en los 2 proyectos:

Equipo Función de IAM Proyecto Permisos
Desarrolladores container.developer dev Puedes crear recursos de Kubernetes para los clústeres existentes en el proyecto, no está permitido crear o borrar clústeres.
Operaciones container.admin prod Acceso de administrador total a los clústeres y recursos de Kubernetes que se ejecutan en el proyecto.
Seguridad container.viewer
security.admin
prod Crea, modifica y borra reglas de firewall y certificados SSL. También visualiza los recursos que se crearon dentro de cada clúster, incluidos los registros de los pods en ejecución.
Red network.admin prod Crea, modifica y borra recursos de red, excepto reglas de firewall y certificados SSL.

Además de los 3 equipos con acceso al proyecto prod, se asigna una Cuenta de servicio a la función container.developer para prod, lo que le permite crear, enumerar y borrar recursos dentro del clúster. Las cuentas de servicio se pueden usar con el fin de que las secuencias de comandos de automatización o los marcos de trabajo de implementación puedan actuar en tu nombre. Las implementaciones en tu proyecto de producción y en los clústeres deben pasar por una canalización automatizada.

En el proyecto dev, hay varios desarrolladores que trabajan en la misma aplicación dentro del mismo clúster. Los espacios de nombre que el usuario del clúster puede crear facilitan esto. Cada desarrollador puede crear recursos dentro de su propio espacio de nombres, lo que evita conflictos de nombre. También pueden usar de nuevo los mismos archivos de configuración YAML para sus implementaciones, de modo que sus configuraciones se mantengan lo más similares posible durante las iteraciones de desarrollo. Los espacios de nombres también se pueden usar para crear Cuotas en el uso de CPU, memoria y almacenamiento dentro del clúster, lo que garantiza que un desarrollador no use demasiados recursos en el clúster. En la siguiente sección, se analiza la restricción de usuarios para operar dentro de ciertos espacios de nombres.

Autorización RBAC

Los clústeres de GKE que ejecutan Kubernetes 1.6 y superiores pueden aprovechar las restricciones adicionales a lo que los usuarios están autorizados a hacer en clústeres individuales. Cloud IAM puede brindar a los usuarios acceso a clústeres completos y a sus recursos, pero el Control de acceso basado en funciones de Kubernetes (RBAC) te permite usar la API de Kubernetes para restringir aún más las acciones que los usuarios puedan realizar dentro de los clústeres.

Con RBAC, los administradores de clústeres aplican políticas detalladas a espacios de nombres individuales dentro de sus clústeres o al clúster en su totalidad. La interfaz de línea de comandos kubectl de Kubernetes usa las credenciales activas de la herramienta gcloud, lo que permite a los administradores del clúster asignar funciones a las identidades de GCP (usuarios y cuentas de servicio) como sujetos en RoleBindings.

Por ejemplo, en la figura a continuación hay dos usuarios, user-a y user-b, a quienes se les otorgaron las funciones config-reader y pod-reader en el espacio de nombres app-a.

Autorización RBAC

Como otro ejemplo, hay funciones de IAM a nivel de proyecto de GCP que les brindan a ciertos usuarios acceso a todos los clústeres en un proyecto. Además, a través de RBAC, se agregan vinculaciones de funciones individuales a nivel de espacio de nombres y de clúster para brindar acceso detallado a los recursos en los clústeres o espacios de nombres particulares.

Vinculaciones de funciones de IAM

Kubernetes incluye algunas funciones predeterminadas, pero como administrador de clústeres, puedes crear las tuyas para que se ajusten mejor a tus necesidades organizativas. A continuación, se muestra un ejemplo de una función que solo permite a los usuarios ver, editar y actualizar ConfigMaps, pero no borrarlo, ya que el verbo delete no está incluido:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Una vez que hayas definido las funciones, puedes aplicarlas al clúster o al espacio de nombres mediante las vinculaciones. Estas asocian funciones a sus usuarios, grupos o cuentas de servicio. A continuación, se muestra un ejemplo de la vinculación de nuestra función creada anteriormente (config-editor) al usuario bob@example.org y al espacio de nombres development.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Para obtener más información sobre RBAC, consulta la Documentación de GKE.

Acceso y uso compartido de imágenes

Las imágenes de Container Registry se almacenan en Cloud Storage. En esta sección, se analizan dos formas de compartir imágenes. Una es hacerlas públicas; la otra es compartir imágenes entre proyectos.

Haz públicas las imágenes

Puedes hacer públicas las imágenes si haces públicos los objetos y depósitos que les crean copias de seguridad. Para ver instrucciones más detalladas, consulta la Documentación de control de acceso de Container Registry.

Accede a imágenes en proyectos

Puedes compartir imágenes de contenedor entre proyectos si te aseguras de que los nodos de Kubernetes usan una cuenta de servicio. La Cuenta de servicio predeterminada asociada con el proyecto se encuentra en el formulario [PROJECT_ID]-compute@developer.gserviceaccount.com. Una vez que tengas el identificador, puedes otorgarle acceso como un storage.viewer en proyectos en los que desees usar Container Registry. Sin embargo, usa una cuenta de servicio personalizada que cuente con permisos restringidos, ya que la predeterminada tiene Acceso de editor a todo el proyecto.

A fin de usar una cuenta de servicio diferente para los clústeres, proporciona la cuenta en la creación del clúster o grupo de nodos con el marcador --service-account. Por ejemplo, para usar la cuenta de servicio gke-sa en el proyecto my-project:

gcloud container clusters create west --service-account \
  gke-sa@my-project.google.com.iam.gserviceaccount.com

Cómo configurar herramientas de redes

Kubernetes proporciona la abstracción del servicio que proporciona balanceo de cargas y detección del servicio en conjuntos de pods dentro de un clúster, así como a sistemas heredados que se ejecutan fuera del clúster. En las secciones a continuación, se describen las recomendaciones para la comunicación entre los pods de Kubernetes y la que tienen con otros sistemas, incluidos otros clústeres de Kubernetes.

Cómo comunicar dentro del mismo clúster

Service Discovery

Kubernetes te permite definir los servicios que agrupan los pods que están en ejecución en el clúster con base en un conjunto de etiquetas. Este grupo de pods se puede detectar en el clúster mediante DNS. Para obtener más información sobre la detección de servicios en Kubernetes, ve a la documentación de Conecta aplicaciones con servicios.

DNS

Un servidor DNS local del clúster, kube-dns, se implementa en cada clúster de GKE que gestiona los nombres de los servicios de la asignación a las IP de los pods en buen estado. Según la configuración predeterminada, el servidor DNS de Kubernetes muestra la dirección IP del clúster del servicio. Esta dirección IP es estática durante toda la vida útil del servicio. Cuando se envía tráfico a esta IP, los iptables en el nodo cargarán paquetes de balanceo en los pods que estén listos y que coincidan con los selectores del servicio. El servicio kube-proxy que se ejecuta en cada nodo programa estos iptables automáticamente.

Si deseas una detección de servicios y una supervisión de estado, pero prefieres que el servicio DNS muestre las IP de los pods en lugar de una IP virtual, puedes aprovisionar el servicio con el campo ClusterIP configurado en "None", lo que hace que el servicio sea headless. En este caso, el servidor DNS muestra una lista de registros A que asignan el nombre DNS del servicio a los registros A de los pods que están listos y que coinciden con los selectores de etiquetas que el servicio define. Los registros en la respuesta se rotan para facilitar la distribución de la carga en todos los pods. Es posible que algunas resoluciones de DNS del cliente almacenen las respuestas DNS en caché, lo que procesa la rotación de los registros A de manera ineficiente. Las ventajas de usar ClusterIP se muestran en la documentación de Kubernetes.

Un caso práctico típico de los servicios headless es con StatefulSets. Los StatefulSets son adecuados para ejecutar aplicaciones con estado que requieren almacenamiento y redes estables entre sus réplicas. Este tipo de implementación aprovisiona pods que tienen una identidad de red estable, lo que significa que sus nombres de host se pueden resolver en el clúster. Aunque es posible que la dirección IP del pod cambie, la entrada DNS de su nombre de host se mantendrá actualizada y se podrá resolver.

Flujo de paquetes: ClusterIP

El siguiente diagrama muestra la respuesta DNS y el flujo de paquetes de un servicio estándar de Kubernetes. Si bien las direcciones IP de los pod se pueden enrutar desde el exterior del clúster, solo se puede acceder a la dirección IP del clúster de un servicio dentro del clúster. Estas direcciones IP virtuales se implementan mediante la traslación de direcciones de red de destino (DNAT) en cada nodo de Kubernetes. El servicio kube-proxy que se ejecuta en cada nodo mantiene las reglas de reenvío actualizadas en cada nodo que asigna la dirección IP del clúster a las direcciones IP de los pods en buen estado en todo el clúster. Si hay un pod del servicio que se ejecuta en el nodo local, se usa ese pod, de lo contrario, se elige uno aleatorio en el clúster.

Servicio IP de clúster

Para obtener más información sobre cómo se implementan las IP de servicio, ve a la Documentación de Kubernetes. Para profundizar más en la red de GKE, mira la próxima charla de 2017 en YouTube:

Servicios headless

A continuación, se muestra un ejemplo de la respuesta DNS y el patrón de tráfico para un servicio headless. Las direcciones IP de los pod se pueden enrutar mediante las tablas de rutas de subred de GCP predeterminadas y la aplicación accede directamente a ellas.

Ejemplo de respuesta DNS y patrón de tráfico para el servicio headless

Políticas de red

Puedes usar la aplicación de la política de red de Kubernetes Engine para controlar la comunicación entre los pods y los servicios del clúster. Para definir una política de red en Kubernetes Engine, puedes usar la API de Kubernetes Network Policy a fin de crear reglas de firewall a nivel de Pod. Estas reglas de firewall determinan los pods y servicios que pueden acceder entre sí dentro del clúster.

Las políticas de red son un tipo de defensa minuciosa que mejora la seguridad de las cargas de trabajo que se ejecutan en el clúster. Por ejemplo, puedes crear una política de red para asegurarte de que un servicio de frontend vulnerable en la aplicación no pueda comunicarse directamente con un servicio de facturación o contabilidad en varios niveles inferiores.

Las políticas de red también se pueden usar para aislar cargas de trabajo que pertenezcan a instancias diferentes. Por ejemplo, puedes proporcionar instancia múltiple segura si defines un modelo de instancia por espacio de nombres. En este modelo, las reglas de la política de red pueden garantizar que los pods y los servicios en un espacio de nombres determinado no puedan acceder a otros pods o servicios en un espacio de nombres diferente.

Para obtener más información sobre las políticas de red, consulta la Documentación de GKE.

Cómo conectarse a un clúster de GKE desde Google Cloud Platform desde el interior

Para conectarte a tus servicios desde el exterior del clúster, pero dentro del espacio de la IP privada de la red de GCP, usa el Balanceo de cargas interno. Cuando se crea un servicio con type: Load Balancer y una anotación cloud.google.com/load-balancer-type: Internal en Kubernetes, se crea un Balanceador de cargas de red interno en el proyecto de GCP y se configura para distribuir el tráfico de TCP y UDP entre los pods.

Cómo conectarse desde el interior de un clúster a servicios externos

En muchos casos, es necesario conectar las aplicaciones que se ejecutan dentro de Kubernetes con un servicio, una base de datos o una aplicación que se encuentre fuera del clúster. Tienes 3 opciones que se describen a continuación.

Dominios de stub

En Kubernetes 1.6 y superiores, puedes configurar el servicio DNS interno del clúster (kube-dns) a fin de reenviar las consultas de DNS para un dominio determinado a un servidor DNS externo. Esto es útil cuando cuentas con servidores DNS autoritativos que deben consultarse para un dominio que los pods de Kubernetes deberán aprovechar.

Servicios de nombre externo

Los servicios de nombre externo te permiten asignar un registro DNS a un nombre de servicio en el clúster. En este caso, las consultas de DNS para el servicio en el clúster muestran un registro CNAME de tu elección. Debes usar esto si solo tienes unos cuantos registros que deseas asignar de nuevo a los servicios DNS existentes.

Servicios sin selectores

Puedes crear servicios sin un selector y luego agregarle extremos de forma manual a fin de propagar la detección del servicio con los valores correctos. Esto te permite usar el mismo mecanismo de detección de servicios para tus servicios en el clúster mientras te aseguras de que se pueda acceder a los sistemas sin detección de servicios a través de DNS. Si bien este enfoque es el más flexible, también requiere la mayor configuración y mantenimiento a largo plazo.

Para obtener más información sobre DNS, ve a la página de documentación Pods y servicios DNS de Kubernetes.

Cómo recibir tráfico de Internet en el clúster

El tráfico de Internet se puede dirigir a los servicios que se ejecutan en Kubernetes mediante dos métodos diferentes, el balanceo de cargas de red o de HTTP(s).

Los servicios de Kubernetes deben crearse como LoadBalancer para el balanceo de cargas de TCP/UDP externo. Kubernetes crea un Balanceador de cargas de red en el proyecto de GCP y lo asigna a los nodos del clúster de tu Kubernetes Engine. Esta es una manera fácil de obtener un balanceo de cargas para las cargas de trabajo de TCP y UDP con una configuración mínima. El balanceador de cargas de red tiene un alcance regional, por lo que solo puede balancear el tráfico con los pods que se ejecutan en la misma región.

Balanceador de cargas de red en la región us-west1

Para el balanceo de cargas HTTP(S), debes aprovechar el Balanceador de cargas HTTP(S) global de Google, que puede realizar balanceos de cargas de tráfico en varias regiones con una dirección IP Anycast. En Kubernetes, puedes crear recursos de Ingress que te permitan asignar nombres de host y rutas a servicios dentro del clúster. Para que Ingress funcione correctamente, los servicios deben crearse con type: NodePort.

balanceo de cargas en varias regiones

Firewall

Los nodos de GKE se aprovisionan como instancias en Compute Engine. Como tales, se adhieren al mismo mecanismo de firewall con estado como otras instancias. Estas reglas de firewall se aplican a las instancias dentro la red mediante el Uso de etiquetas. Cada grupo de nodos recibe su propio conjunto de etiquetas que puedes usar en las reglas. Según la configuración predeterminada, cada instancia que pertenece a un grupo de nodos recibe una etiqueta que identifica un clúster específico de Kubernetes Engine del que forma parte este grupo de nodos. Esta etiqueta se usa en las reglas de firewall que Kubernetes Engine crea automáticamente para ti. Puedes agregar tus propias etiquetas personalizadas en el momento de la creación del clúster o del grupo de nodos con el marcador --tags en la línea de comandos de gcloud.

Por ejemplo, para permitir el acceso de un Balanceador de cargas interno al puerto 8080 en todos los nodos, tendrías que usar los siguientes comandos:

gcloud compute firewall-rules create \
  allow-8080-fwr --target-tags allow-8080 --allow tcp:8080 \
  --network gke --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

El ejemplo que se presenta a continuación muestra cómo etiquetar un clúster para que el tráfico de Internet pueda acceder a los nodos en el puerto 30000, mientras que el otro clúster está etiquetado para permitir el tráfico desde la VPN al puerto 40000. Esto es útil cuando se expone un servicio a través de un NodePort al que solo se debe acceder mediante redes privilegiadas, como una VPN a un centro de datos corporativo o desde otro clúster dentro del proyecto.

etiqueta dos clústeres de manera diferente

Cómo conectarse a un centro de datos local

Hay varias opciones de Cloud Interconnect para conectarse a centros de datos locales. Estas opciones no se excluyen mutuamente, por lo que puedes tener una combinación con base en la carga de trabajo y los requisitos:

  1. Internet para las cargas de trabajo que no requieren una gran cantidad de datos ni son sensibles a la latencia. Google tiene más de 100 puntos de presencia (PoPs) que se comunican con proveedores de servicios en todo el mundo.
  2. Intercambio de tráfico directo para las cargas de trabajo que requieren ancho de banda dedicado, son sensibles a la latencia y necesitan acceso a todos los servicios de Google, incluido el kit completo de productos de GCP. El intercambio de tráfico directo es una conexión de capa 3 que se realiza mediante el intercambio de rutas BGP y, por lo tanto, requiere un ASN registrado.
  3. El Intercambio de tráfico por proveedores es igual que el intercambio de tráfico directo, pero se realiza a través de un proveedor de servicios. Esta es una excelente opción si no cuentas con un ASN registrado o si tienes relaciones con un proveedor de servicios de tu preferencia.
  4. Cloud VPN se configura a través de las opciones de interconexión y de Internet de capa 3 (1, 2 y 3), si se requiere encriptación IPsec o si deseas extender tu red privada a tu red privada de Compute Engine.

¿Qué sigue?

  • Prueba otras características de Google Cloud Platform tú mismo. Revisa nuestros instructivos.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...