Referencia de configuración del clúster AKS

Para obtener el ID de suscripción, haz clic en Todos los servicios en la barra de navegación izquierda. Luego haz clic en Suscripciones. Ve al nombre de la suscripción que deseas asociar con tu clúster de Kubernetes y copia el ID de suscripción.

Para obtener el ID del cliente, ve al Portal de Azure, luego haz clic en Azure Active Directory, luego haz clic en Registros de aplicaciones, y luego haz clic en el nombre del principal de servicio. El ID del cliente se muestra en la página de detalles del registro de la aplicación como ID de aplicación (cliente).

No puedes recuperar el valor del secreto del cliente después de que se crea, así que si no tienes ya un valor de secreto del cliente, necesitarás crear un nuevo secreto del cliente.

Para obtener un nuevo secreto del cliente, ve al Portal de Azure, luego haz clic en Azure Active Directory, luego haz clic en Registros de aplicaciones, y luego haz clic en el nombre del principal de servicio.

Luego haz clic en Certificados y secretos y haz clic en Nuevo secreto del cliente. Haz clic en Añadir. Luego copia el Valor del nuevo secreto del cliente.

Microsoft proporciona múltiples nubes para cumplir con las leyes regionales, que están disponibles para tu uso:

Las versiones de Kubernetes disponibles se obtienen dinámicamente de la API de Azure.

Un grupo de recursos es un contenedor que alberga recursos relacionados para una solución de Azure. El grupo de recursos puede incluir todos los recursos de la solución, o solo aquellos recursos que deseas gestionar como un grupo. Decides cómo quieres asignar recursos a los grupos de recursos en función de lo que tenga más sentido para tu organización. Generalmente, añade recursos que compartan el mismo ciclo de vida al mismo grupo de recursos para que puedas desplegarlos, actualizarlos y eliminarlos fácilmente como un grupo.

Utiliza un grupo de recursos existente o introduce un nombre de grupo de recursos y se creará uno para ti.

Usar un grupo de recursos que contenga un clúster AKS existente creará un nuevo grupo de recursos. Azure AKS solo permite un clúster AKS por grupo de recursos.

Para información sobre la gestión de grupos de recursos, consulta la documentación de Azure.

El nombre de usuario utilizado para crear una conexión SSH a los nodos de Linux.

El nombre de usuario predeterminado para los nodos de AKS es azureuser.

La clave utilizada para crear una conexión SSH a los nodos de Linux.

Las etiquetas de clúster pueden ser útiles si tu organización utiliza etiquetas como una forma de organizar recursos a través de múltiples servicios de Azure. Estas etiquetas no se aplican a los recursos dentro del clúster.

Los balanceadores de carga de Azure admiten tanto SKU estándar como básicos (unidades de mantenimiento de stock).

Para una comparación de balanceadores de carga estándar y básicos, consulta la documentación oficial de Azure. Microsoft recomienda el balanceador de carga estándar.

El balanceador de carga estándar es necesario si has seleccionado una o más zonas de disponibilidad, o si tienes más de un grupo de nodos.

Todos los pods en un clúster de AKS pueden enviar y recibir tráfico sin limitaciones, por defecto. Para mejorar la seguridad, puedes definir reglas que controlen el flujo de tráfico. La función de política de red en Kubernetes te permite definir reglas para el tráfico de entrada y salida entre pods en un clúster.

Azure proporciona dos formas de implementar política de red. Eliges una opción de política de red cuando creas un clúster de AKS. La opción de política no se puede cambiar después de que se crea el clúster:

También puedes optar por no tener política de red.

Para más información sobre las diferencias entre las políticas de red de Azure y Calico y sus capacidades, consulta la documentación de AKS.

Introduce un prefijo DNS único para el FQDN del servidor API de Kubernetes de tu clúster.

Hay dos plugins de red: kubenet y Azure CNI.

El plugin de Kubernetes kubenet es la configuración predeterminada para la creación de clústeres AKS. Cuando se utiliza kubenet, cada nodo en el clúster recibe una dirección IP enrutada. Los pods utilizan NAT para comunicarse con otros recursos fuera del clúster AKS. Este enfoque reduce el número de direcciones IP que necesitas reservar en tu espacio de red para que los pods las utilicen.

Con el plugin de red Azure CNI (avanzado), los pods obtienen conectividad completa a la red virtual y pueden ser alcanzados directamente a través de su dirección IP privada desde redes conectadas. Este plugin requiere más espacio de direcciones IP.

Para obtener más información sobre las diferencias entre kubenet y Azure CNI, consulta la documentación de AKS.

Cuando está habilitado, el complemento de enrutamiento de aplicaciones HTTP facilita el acceso a las aplicaciones desplegadas en el clúster AKS. Despliega dos componentes: un controlador de Ingress de Kubernetes y un controlador de External-DNS.

Para obtener más información, consulta la documentación de AKS.

Puedes asegurar el acceso al servidor API de Kubernetes utilizando rangos de direcciones IP autorizadas.

El servidor API de Kubernetes expone la API de Kubernetes. Este componente proporciona la interacción para herramientas de gestión, como kubectl. AKS proporciona un plano de control de clúster de inquilino único con un servidor API dedicado. Por defecto, al servidor API se le asigna una dirección IP pública, y deberías controlar el acceso a ella utilizando RBAC basado en Kubernetes o en Azure.

Para asegurar el acceso al plano de control y al servidor API de AKS, que de otro modo son accesibles públicamente, puedes habilitar y utilizar rangos de IP autorizados. Estos rangos de IP autorizados solo permiten que los rangos de direcciones IP definidos se comuniquen con el servidor API.

Sin embargo, incluso si utilizas rangos de direcciones IP autorizados, aún debes usar Kubernetes RBAC o Azure RBAC para autorizar a los usuarios y las acciones que solicitan.

El monitoreo de contenedores te proporciona visibilidad del rendimiento al recopilar métricas de memoria y procesador de controladores, nodos y contenedores que están disponibles en Kubernetes a través de la API de Métricas. Los registros de contenedores también se recopilan. Después de habilitar el monitoreo, las métricas y los registros se recopilan automáticamente para ti a través de una versión en contenedores del agente de Log Analytics para Linux. Las métricas se escriben en el almacén de métricas y los datos de registro se escriben en el almacén de registros asociado con tu espacio de trabajo de Log Analytics.

El grupo de recursos que contiene el Espacio de Trabajo de Log Analytics. Debes crear al menos un espacio de trabajo para usar Azure Monitor Logs.

Los datos recopilados por Azure Monitor Logs se almacenan en uno o más espacios de trabajo de Log Analytics. El espacio de trabajo define la ubicación geográfica de los datos, los derechos de acceso que definen qué usuarios pueden acceder a los datos y la configuración, como el nivel de precios y la retención de datos.

Debes crear al menos un espacio de trabajo para usar Azure Monitor Logs. Un solo espacio de trabajo puede ser suficiente para todos tus datos de monitoreo, o puedes optar por crear múltiples espacios de trabajo según tus requisitos. Por ejemplo, podrías tener un espacio de trabajo para tus datos de producción y otro para pruebas.

Para más información sobre Azure Monitor Logs, consulta la documentación de Azure.

Normalmente, los nodos de trabajo de AKS no obtienen IPs públicas, independientemente de si el clúster es privado. En un clúster privado, el plano de control no tiene un punto de acceso público.

Rancher puede conectarse a un clúster privado de AKS de dos maneras.

La primera forma de asegurar que Rancher esté ejecutándose en el mismo NAT que los nodos de AKS.

La segunda forma es ejecutar un comando para registrar el clúster con Rancher. Una vez que el clúster esté aprovisionado, puedes ejecutar el comando mostrado en cualquier lugar donde puedas conectarte a la API de Kubernetes del clúster. Este comando se muestra en una ventana emergente cuando aprovisionas un clúster de AKS con un punto de acceso API privado habilitado.

Para más información sobre cómo conectarse a un clúster privado de AKS, consulta la documentación de AKS.

La interfaz de Azure permite a los usuarios especificar si un Grupo de Nodos Primario se basa en system (normalmente utilizado para planos de control) o user (lo que se necesita típicamente para Rancher).

Para Grupos de Nodos Primarios, puedes especificar Modo, SO, Cantidad y Tamaño.

Los grupos de nodos del sistema siempre requieren nodos en ejecución, por lo que no se pueden escalar por debajo de un nodo. Se requiere al menos un grupo de nodos del sistema.

Para los grupos de nodos subsiguientes, la interfaz de usuario de Rancher impone el valor predeterminado de Usuario. Los grupos de nodos de usuario permiten escalar a cero nodos. Los grupos de nodos de usuario no ejecutan ninguna parte del plano de control de Kubernetes.

AKS no expone los nodos que ejecutan los componentes del plano de control de Kubernetes.

Las zonas de disponibilidad son ubicaciones físicas únicas dentro de una región. Cada zona está compuesta por uno o más centros de datos equipados con energía, refrigeración y redes independientes.

No todas las regiones tienen soporte para zonas de disponibilidad. Para obtener una lista de las regiones de Azure con zonas de disponibilidad, consulta la documentación de Azure.

Elige un tamaño para cada VM en el grupo de nodos. Para obtener detalles sobre cada tamaño de VM, consulta esta página.

Los nodos en el grupo de nodos pueden tener discos administrados o efímeros.

Los discos efímeros del SO se crean en el almacenamiento local de la máquina virtual y no se guardan en el almacenamiento remoto de Azure. Los discos efímeros del SO funcionan bien para cargas de trabajo sin estado, donde las aplicaciones son tolerantes a fallos individuales de VM, pero se ven más afectadas por el tiempo de despliegue de VM o la reimagen de las instancias individuales de VM. Con el disco efímero del SO, obtienes una menor latencia de lectura-escritura al disco del SO y una reimagen más rápida de la VM.

Los discos administrados de Azure son volúmenes de almacenamiento a nivel de bloque que son gestionados por Azure y utilizados con Máquinas Virtuales de Azure. Los discos administrados están diseñados para una disponibilidad del 99.999%. Los discos administrados logran esto al proporcionarte tres réplicas de tus datos, lo que permite una alta durabilidad.

El tamaño en GB del disco para cada nodo.

El número de nodos en el grupo de nodos. El número máximo de nodos puede estar limitado por tu suscripción de Azure.

El número máximo de pods por nodo se establece por defecto en 110, con un máximo de 250.

Cuando el escalado automático está habilitado, deberás introducir un número mínimo y máximo de nodos.

Cuando el escalado automático está habilitado, no puedes escalar manualmente el grupo de nodos. La escala es controlada por el autoscaler de AKS.