Esta información es útil para los siguientes tipos de usuarios:
- Usuarios que comienzan a usar Cloud Run for Anthos.
- Operadores con experiencia en la ejecución de clústeres de GKE
- Desarrolladores de aplicaciones que necesitan saber más sobre cómo Cloud Run for Anthos se integra en los clústeres de Kubernetes para diseñar mejores aplicaciones o configurar sus aplicaciones de Cloud Run for Anthos
Componentes en la instalación predeterminada
Cuando instalas Cloud Run for Anthos como un complemento para tu clúster de Google Kubernetes Engine, se crean de forma automática los espacios de nombres knative-serving y gke-system. Los siguientes componentes se implementan en uno de esos espacios de nombres:
Componentes que se ejecutan en el espacio de nombres
knative-serving:- Activador: Cuando la escala de los Pods se reduce a cero o estos se sobrecargan con solicitudes enviadas a la revisión, el activador pone en cola las solicitudes de forma temporal y envía métricas al escalador automático para iniciar más Pods. Una vez que el escalador automático ajusta la escala de la revisión según las métricas informadas y los Pods disponibles, el activador reenvía las solicitudes en cola a la revisión. El activador es un componente del plano de datos. Los componentes del plano de datos administran todas las funciones y los procesos que reenvían el tráfico de los usuarios.
- Escalador automático: Agrega y procesa métricas del activador y del contenedor de sidecar del proxy de cola, un componente en el plano de datos que aplica los límites de simultaneidad de solicitudes. Luego, el escalador automático calcula la simultaneidad observada de la revisión y ajusta el tamaño de la implementación según el recuento de Pods deseado. Cuando los Pods están disponibles en la revisión, el escalador automático es un componente del plano de control. De lo contrario, cuando se reduce la escala de los Pods a cero, el escalador automático es un componente del plano de datos.
- Controlador: Crea y actualiza los recursos secundarios del escalador automático y los objetos Service. El controlador es un componente del plano de control. Los componentes del plano de control administran todas las funciones y los procesos que establecen la ruta de acceso a solicitudes del tráfico de los usuarios.
- Webhook: Configura valores predeterminados y rechaza objetos incoherentes y no válidos, además de validar y mutar las llamadas a la API de Kubernetes en los recursos de Cloud Run for Anthos. Webhook es un componente del plano de control.
Componentes que se ejecutan en el espacio de nombres
gke-system:- Puerta de enlace local del clúster: Balanceador de cargas en el plano de datos responsable de manejar el tráfico interno que llega de un Cloud Run for Anthos a otro. Solo se puede acceder a la puerta de enlace local del clúster desde el clúster de GKE, y esta no registra un dominio externo para evitar la exposición accidental de información privada o de procesos internos.
- Puerta de enlace de entrada de Istio: Es el balanceador de cargas en el plano de datos responsable de recibir y controlar el tráfico entrante desde fuera del clúster, incluido el tráfico de redes externas o internas.
- Pilot de Istio: Configura la puerta de enlace local del clúster y la puerta de enlace de entrada de Istio para controlar las solicitudes HTTP en los extremos correctos. Pilot de Istio es un componente del plano de control. Para obtener más información, consulta Pilot de Istio.
Los componentes de Cloud Run for Anthos se actualizan de forma automática con cualquier actualización de clúster del plano de control de GKE. Para obtener más información, consulta Versiones de GKE disponibles.
Uso de recursos del clúster
La instalación inicial de Cloud Run for Anthos requiere aproximadamente 1.5 CPU virtuales y 1 GB de memoria para el clúster. La cantidad de nodos en tu clúster no afecta los requisitos de espacio y memoria de una instalación de Cloud Run for Anthos.
Un activador puede consumir solicitudes a un máximo de 1,000 millicores de CPU y 600 MiB de RAM. Cuando un activador existente no puede admitir la cantidad de solicitudes entrantes, se inicia un activador adicional, que requiere una reserva de 300 millicores de CPU y 60 MiB de RAM.
Cada Pod creado por el servicio de Cloud Run for Anthos crea un sidecar del proxy de cola que aplica los límites de simultaneidad de solicitudes. El proxy de cola reserva 25 millicores de CPU y no tiene reserva de memoria. El consumo del proxy de cola depende de la cantidad de solicitudes en cola y del tamaño de estas. No hay límites en cuanto a la CPU y los recursos de memoria que puede consumir.
Crea un Service
Cloud Run for Anthos extiende Kubernetes mediante la especificación de un conjunto de definiciones de recursos personalizados (CRD): objetos Service, revisión, configuración y ruta. Estas CRD definen y controlan el comportamiento de tus aplicaciones en el clúster:
- El objeto Service de Cloud Run for Anthos es el recurso personalizado de nivel superior que define Cloud Run for Anthos. Es una sola aplicación que administra todo el ciclo de vida de tu carga de trabajo. El servicio garantiza que tu app tenga una ruta, una configuración y una revisión nueva para cada actualización del servicio.
- La revisión es una instantánea inmutable del código y la configuración en un momento determinado.
- La configuración permite que las opciones establecidas actualmente de la última revisión se mantengan y que se registre un historial de todas las revisiones anteriores. Si modificas una configuración, se crea una revisión nueva.
- La ruta define un extremo HTTP y asocia el extremo con una o más revisiones a las que se reenvían las solicitudes.
Cuando un usuario crea un objeto Service de Cloud Run for Anthos, sucede lo siguiente:
El objeto Service de Cloud Run for Anthos define lo siguiente:
- Una configuración para entregar las revisiones
- Una revisión inmutable para esta versión del servicio
- Una ruta para administrar la asignación de tráfico especificada a la revisión
El objeto de ruta crea un VirtualService. El objeto VirtualService configura la puerta de enlace de entrada y la puerta de enlace local del clúster para enrutar el tráfico de puerta de enlace a la revisión correcta.
El objeto de revisión crea los siguientes componentes del plano de control: un objeto Deployment y un objeto Service de Kubernetes.
La configuración de red conecta el activador, el escalador automático y los balanceadores de cargas para tu app.
Cómo administrar solicitudes
En el siguiente diagrama, se muestra una descripción general de alto nivel de una posible ruta de acceso a solicitudes del tráfico de los usuarios a través de los componentes del plano de datos de Cloud Run for Anthos en un clúster de muestra de Google Kubernetes Engine:
El siguiente diagrama, se expande desde el diagrama anterior para brindar una vista detallada de la ruta de acceso a solicitudes del tráfico de los usuarios, que también se describe en detalle a continuación:
En una ruta de acceso a solicitudes de Cloud Run for Anthos, haz lo siguiente:
El tráfico llega a través de estas puertas de enlace:
- La puerta de enlace de entrada para el tráfico proveniente de fuera de los clústeres
- La puerta de enlace local del clúster para el tráfico dentro de los clústeres
El componente VirtualService, que especifica las reglas de enrutamiento de tráfico, configura las puertas de enlace para que el tráfico de los usuarios se enrute a la revisión correcta.
El objeto Service de Kubernetes, un componente del plano de control, determina el siguiente paso en la ruta de acceso a solicitudes según la disponibilidad de los Pods para manejar el tráfico:
Si no hay Pods en la revisión, sucede lo siguiente:
- El activador pone en cola de manera temporal la solicitud recibida y envía una métrica al escalador automático para aumentar la escala de Pods.
- El escalador automático ajusta la escala al estado deseado de Pods en el objeto Deployment.
- Este último objeto crea más Pods para recibir solicitudes adicionales.
- El activador vuelva intentar realizar solicitudes al sidecar del proxy de cola.
Si el servicio se escala horizontalmente (los Pods están disponibles), el objeto Service de Kubernetes envía la solicitud al sidecar del proxy de cola.
El sidecar del proxy de cola aplica parámetros de cola de solicitudes, y solicitudes de uno o varios subprocesos, que el contenedor puede controlar a la vez.
Si el sidecar del proxy de cola tiene más solicitudes de las que puede controlar, el escalador automático crea más Pods para manejar solicitudes adicionales.
El sidecar del proxy de cola envía tráfico al contenedor del usuario.