Consideraciones de administración de operaciones para Azure Kubernetes Service

  • Artículo

Kubernetes es una tecnología relativamente nueva que evoluciona rápidamente y con un ecosistema impresionante. Como tal, su administración y protección puede resultar todo un desafío.

Línea de base de operaciones para AKS

Puede trabajar hacia la excelencia operativa y el éxito de los clientes mediante un correcto diseño de la solución de Azure Kubernetes Service (AKS) que tenga en cuenta la administración y la supervisión.

Consideraciones de diseño

Tenga en cuenta los siguientes factores:

  • Tenga en cuenta los límites de AKS. Utilice varias instancias de AKS para escalar más allá de esos límites.
  • Tenga en cuenta las formas de aislar lógicamente las cargas de trabajo dentro de un clúster y físicamente en clústeres independientes.
  • Tenga en cuenta las maneras de controlar el consumo de recursos por parte de las cargas de trabajo.
  • Tenga en cuenta las maneras de ayudar a que Kubernetes conozca el estado de las cargas de trabajo.
  • Tenga en cuenta los distintos tamaños de máquinas virtuales y el impacto de usar uno u otro. Las máquinas virtuales más grandes pueden controlar más carga. Las máquinas virtuales más pequeñas se pueden reemplazar por otras con más facilidad cuando no estén disponibles por un mantenimiento planeado o no planeado. Además, tenga en cuenta los grupos de nodos y las máquinas virtuales en un conjunto de escalado, lo que permite que máquinas virtuales de distintos tamaños estén en el mismo clúster. Las máquinas virtuales más grandes son mejores porque AKS reserva un porcentaje menor de sus recursos, lo que hace que haya más recursos disponibles para las cargas de trabajo.
  • Tenga en cuenta las formas de supervisar y registrar AKS. Kubernetes consta de varios componentes y la supervisión y el registro deben proporcionar una visión general de su estado, tendencias y posibles problemas.
  • En el trabajo con la supervisión y el registro, puede haber muchos eventos generados por Kubernetes o por las aplicaciones que se ejecutan sobre Kubernetes. Las alertas pueden ayudar a diferenciar entre las entradas del registro con fines históricos y aquellas que requieren una acción inmediata.
  • Tenga en cuenta las actualizaciones que deba realizar. En el nivel de Kubernetes, hay versiones principales, secundarias y de revisión. El cliente debe aplicar estas actualizaciones para seguir recibiendo soporte técnico de acuerdo con la directiva de Kubernetes ascendente. En el nivel de host de trabajo, las revisiones del kernel del sistema operativo podrían requerir un reinicio, que debe llevar a cabo el cliente, y actualizaciones a las nuevas versiones del sistema operativo. Además de actualizar manualmente un clúster, puede establecer un canal de actualización automática en el clúster.
  • Tenga en cuenta las limitaciones de recursos y las cargas de trabajo individuales del clúster.
  • Tenga en cuenta las diferencias entre un escalador automático de pods horizontal y un escalador automático de clústeres
  • Considere la posibilidad de proteger el tráfico entre pods mediante directivas de red y el complemento de directivas de Azure.
  • Para ayudar a solucionar los problemas de sus aplicaciones y servicios que se ejecutan en AKS, quizás deba ver los registros generados por los componentes del plano de control. Es posible que desee habilitar los registros de recursos para AKS, ya que el registro no está habilitado de manera predeterminada.

Recomendaciones

  • Descripción de los límites de AKS:

  • Use el aislamiento lógico en el nivel de espacio de nombres para separar las aplicaciones, los equipos, los entornos y las unidades de negocio. Procedimientos recomendados para el aislamiento de clústeres en Azure Kubernetes Service (AKS). Además, los grupos de nodos pueden ayudar en los nodos con diferentes especificaciones de nodo y en el mantenimiento, como las actualizaciones de Kubernetes de grupos de varios nodos

  • Planee y aplique cuotas de recursos en el nivel del espacio de nombres. Si los pods no definen solicitudes y límites de recursos, rechace la implementación mediante directivas, etc. Esto no se aplica a los pods de kube-system, ya que no todos los pods de kube-system tienen solicitudes y límites. Supervise el uso de recursos y ajuste las cuotas según sea necesario. Características básicas del programador

  • Incorpore sondeos de estado a los pods. Asegúrese de que los pods contengan lossondeos de estado de AKSlivenessProbe, readinessProbe y startupProbe.

  • Use tamaños de máquina virtual lo suficientemente grandes como para contener varias instancias de contenedor con el fin de obtener las ventajas de aumentar la densidad, pero no tan grande como para que el clúster no pueda controlar la carga de trabajo de un nodo con errores.

  • Use una solución de supervisión. Container Insights de Azure Monitor está configurado de forma predeterminada y proporciona un acceso fácil a mucha información. Puede usar la integración con Prometheus si desea profundizar o tener experiencia en el uso de Prometheus. Si quiere ejecutar además una aplicación de supervisión en AKS, también debe usar Azure Monitor para supervisar dicha aplicación.

  • Use alertas de métricas de Container Insights de Azure Monitor para proporcionar notificaciones cuando se necesite una acción directa.

  • Use la característica de escalado automático de grupos de nodos junto con Horizontal Pod Autoscaler para satisfacer las demandas de la aplicación y reducir las cargas en las horas punta.

  • Use Azure Advisor para obtener recomendaciones de procedimientos sobre costos, seguridad, confiabilidad, excelencia operativa y rendimiento. Utilice también Microsoft Defender for Cloud para evitar y detectar amenazas, como las vulnerabilidades de las imágenes.

  • Use Kubernetes habilitado para Azure Arc para administrar clústeres de Kubernetes que no son de AKS en Azure mediante Azure Policy, Defender for Cloud, GitOps, etc.

  • Use las solicitudes y los límites de pod para administrar los recursos de proceso dentro de un clúster de AKS. Las solicitudes y los límites de pod informan al programador de Kubernetes sobre los recursos de proceso que se asignarán a un pod.

Continuidad empresarial o recuperación ante desastres para proteger y recuperar AKS

Su organización necesita diseñar funcionalidades de nivel de plataforma de Azure Kubernetes Service (AKS) adecuadas para satisfacer sus requisitos específicos. Estos servicios de aplicación tienen requisitos relacionados con el objetivo de tiempo de recuperación (RTO) y el de punto de recuperación (RPO). Hay varias consideraciones que se deben tener en cuenta para la recuperación ante desastres de AKS. El primer paso es definir un Acuerdo de Nivel de Servicio (SLA) para la infraestructura y la aplicación. Obtenga más información sobre el Acuerdo de Nivel de Servicio para Azure Kubernetes Service (AKS). Consulte la sección Detalles del Acuerdo de Nivel de Servicio para obtener información sobre los cálculos de tiempo de actividad mensual.

Consideraciones de diseño

Tenga en cuenta los siguientes factores:

  • El clúster de AKS debe usar varios nodos de un grupo de nodos para proporcionar el nivel mínimo de disponibilidad para la aplicación.

  • Establezca solicitudes y límites de pods. La configuración de estos límites permite a Kubernetes lo siguiente:

    • Ofrecer de forma eficaz recursos de CPU y memoria a los pods.
    • Tener una mayor densidad de contenedor en un nodo.

    Los límites también pueden aumentar la confiabilidad con costos reducidos debido a un mejor uso del hardware.

  • Idoneidad de AKS para zonas de disponibilidad o conjuntos de disponibilidad.

    • Elija una región que admita zonas de disponibilidad.
    • Las zonas de disponibilidad solo se pueden definir cuando se crea el grupo de nodos y no se pueden cambiar más tarde. La compatibilidad con varias zonas solo se aplica a los grupos de nodos.
    • Para obtener una ventaja de zona completa, todas las dependencias de servicio también deben admitir zonas. Si un servicio dependiente no admite zonas, un error de zona podría provocar un error en el servicio.
    • Ejecute varios clústeres de AKS en diferentes regiones emparejadas para lograr una disponibilidad mayor a la que puede lograr Availability Zones. Si un recurso de Azure admite redundancia geográfica, proporcione la ubicación en la que el servicio redundante tiene su región secundaria.

  • Debe conocer las instrucciones para la recuperación ante desastres en AKS. A continuación, considere si se aplican a los clústeres de AKS que usa para Azure Dev Spaces.

  • Cree copias de seguridad para aplicaciones y datos de forma coherente.

    • Un servicio sin estado se puede replicar de forma eficaz.
    • Si tiene que almacenar el estado en el clúster, realice una copia de seguridad de los datos con frecuencia en la región emparejada. Se debe tener en cuenta que almacenar correctamente el estado en el clúster puede ser complicado.

  • Actualización y mantenimiento del clúster.

    • Mantenga siempre actualizado el clúster.
    • Tenga en cuenta el proceso de lanzamiento y retirada.
    • Planee las actualizaciones y el mantenimiento.

  • Conectividad de red si se produce una conmutación por error.

    • Elija un enrutador de tráfico que pueda distribuir el tráfico entre zonas o regiones, en función de sus requisitos. Esta arquitectura implementa Azure Load Balancer porque puede distribuir el tráfico que no es web entre zonas.
    • Si necesita distribuir el tráfico entre regiones, considere la posibilidad de usar Azure Front Door.

  • Conmutaciones por error planeadas y no planeadas.

    • Al configurar cada servicio de Azure, elija características que admitan la recuperación ante desastres. Por ejemplo, esta arquitectura habilita Azure Container Registry para la replicación geográfica. Puede extraer imágenes de la región replicada si una región deja de funcionar.

  • Mantenga las funcionalidades de ingeniería de DevOps para alcanzar los objetivos de nivel de servicio.

  • Determine si necesita un Acuerdo de Nivel de Servicio con respaldo financiero para el punto de conexión de servidor de la API de Kubernetes.

Recomendaciones de diseño

A continuación se muestran los procedimientos recomendados para el diseño:

  • Use tres nodos para el grupo de nodos del sistema. Para el grupo de nodos de usuario, empiece con dos nodos al menos. Si necesita una mayor disponibilidad, configure más nodos.

  • Aísle la aplicación de los servicios del sistema colocándolo en un grupo de nodos independiente. De este modo, los servicios de Kubernetes se ejecutan en nodos dedicados y no compiten con otros servicios. Use etiquetas y valores taint para identificar el grupo de nodos para programar la carga de trabajo.

  • El mantenimiento regular del clúster, como las actualizaciones puntuales, es crucial para la confiabilidad. Tenga en cuenta las Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS) y planee las actualizaciones. También se recomienda supervisar el mantenimiento de los pods a través de sondeos.

  • Siempre que sea posible, quite el estado de servicio del interior de los contenedores. En su lugar, use una plataforma de Azure como servicio (PaaS) que admita la replicación en varias regiones.

  • Protección de los recursos de pods. Se recomienda encarecidamente que las implementaciones especifiquen los requisitos de los recursos de pods. Después, el programador puede programar correctamente el pod. La confiabilidad se devalúa cuando los pods no están programados.

  • Configure varias réplicas en la implementación para controlar las interrupciones, como los errores de hardware. En el caso de los eventos planeados, como las actualizaciones, un presupuesto de interrupciones puede garantizar que exista el número necesario de réplicas de pods para controlar la carga esperada de la aplicación.

  • Las aplicaciones pueden utilizar Azure Storage para sus datos. Como las aplicaciones se extienden entre varios clústeres de AKS en distintas regiones, debe mantener sincronizado el almacenamiento. Existen dos formas habituales de replicar el almacenamiento:

    • Replicación asincrónica basada en la infraestructura
    • Replicación asincrónica basada en la aplicación

  • Calcule los límites de pods. Pruebe y establezca una base de referencia. Comience con valores iguales para solicitudes y límites. A continuación, ajuste los valores gradualmente hasta que haya establecido un umbral que pueda provocar inestabilidad en el clúster. Los límites de pods se pueden especificar en los manifiestos de implementación.

    Las características integradas proporcionan una solución a la compleja tarea de controlar errores e interrupciones en la arquitectura del servicio. Estas configuraciones ayudan a simplificar la automatización del diseño y la implementación. Cuando una organización ha definido un estándar para el Acuerdo de Nivel de Servicio, el RTO y el RPO, puede usar servicios integrados para Kubernetes y Azure a fin de lograr sus objetivos empresariales.

  • Consulte presupuestos de interrupciones de pods. Este valor comprueba cuántas réplicas de una implementación pueden desactivarse durante una actualización o evento de actualización.

  • Aplique cuotas de recursos en espacios de nombres de servicio. La cuota de recursos de un espacio de nombres garantiza que las solicitudes y los límites de pods se establezcan correctamente en una implementación.

    • El establecimiento de cuotas de recursos en el nivel de clúster puede generar problemas al implementar servicios de asociado que no tienen las solicitudes y los límites adecuados.

  • Almacene las imágenes de contenedor en Azure Container Registry y replique geográficamente el registro en cada región de AKS.

  • Use el Acuerdo de Nivel de Servicio de tiempo de actividad para habilitar un Acuerdo de Nivel de Servicio superior, con respaldo financiero, para todos los clústeres que hospedan cargas de trabajo de producción. El acuerdo de nivel de servicio de tiempo de actividad garantiza una disponibilidad del 99,95 % del punto de conexión del servidor de API de Kubernetes para los clústeres que usan zonas de disponibilidad, y una disponibilidad del 99,9 % de los clústeres que no utilizan zonas de disponibilidad. Los nodos, grupos de nodos y otros recursos se incluyen bajo su Acuerdo de Nivel de Servicio. AKS ofrece un nivel gratuito con un objetivo de nivel de servicio (SLO) del 99,5 % para sus componentes del plano de control. Los clústeres sin el Acuerdo de Nivel de Servicio de tiempo de actividad habilitado no deben usarse para cargas de trabajo de producción.

  • Use varias regiones y ubicaciones de emparejamiento para la conectividad de Azure ExpressRoute.

    En caso de que se produzca una interrupción de servicio que afecte a una región de Azure o a una ubicación del proveedor de emparejamiento, una arquitectura de red híbrida redundante puede ayudarle a garantizar una conectividad entre entornos locales ininterrumpida.

  • Interconexión de regiones con el emparejamiento de redes virtuales globales. Si los clústeres necesitan comunicarse entre sí, puede conectar ambas redes virtuales entre sí a través del emparejamiento de redes virtuales. Esta tecnología conecta las redes virtuales entre sí, lo que ofrece un alto ancho de banda en toda la red troncal de Microsoft, incluso en distintas regiones geográficas.

  • Mediante el uso del protocolo de difusión por proximidad basado en división TCP, Front Door garantiza que los usuarios finales se conecten inmediatamente al punto de presencia de Front Door más cercano. Otras características de Azure Front Door Azure son las siguientes:

    • Finalización de TLS
    • Dominio personalizado
    • Firewall de aplicaciones web
    • Reescritura de direcciones URL
    • Afinidad de sesión

    Revise los requisitos del tráfico de su aplicación para averiguar qué solución es la más conveniente.