Compartir a través de

Control de soluciones de plataformas de aplicaciones modernas

  • Artículo

Cloud Adoption Framework proporciona una metodología para mejorar de forma sistemática e incremental la gobernanza de la cartera en la nube. En este artículo se muestra cómo puede ampliar su enfoque de gobernanza a los clústeres de Kubernetes implementados en Azure o en otras nubes públicas o privadas.

Base de gobernanza inicial

La gobernanza comienza con una base inicial a la que se suele hacer referencia como MVP de gobernanza. Esta base implementa los productos básicos de Azure necesarios para ofrecer la gobernanza en todo el entorno de la nube.

La base inicial de gobernanza se centra en los siguientes aspectos:

  • Red y conectividad híbrida básica.
  • Control de acceso basado en roles (RBAC) de Azure para el control de identidades y accesos.
  • Estándares de nomenclatura y etiquetado para una identificación uniforme de los recursos.
  • Organización de recursos mediante grupos de recursos, suscripciones y grupos de administración.
  • Emplee Azure Policy para aplicar directivas de gobernanza.

Estas características de la base inicial de gobernanza se puede usar para controlar las soluciones para instancias de soluciones de plataformas de aplicaciones modernas. En primer lugar, sin embargo, deberá agregar algunos componentes a la base inicial para aplicar Azure Policy a los contenedores. Una vez configurados estos componentes, podrá usar Azure Policy y la base inicial de gobernanza para controlar los siguientes tipos de contenedores:

Expansión a disciplinas de gobernanza

La base inicial de gobernanza se puede expandirse a diversas disciplinas de gobernanza para garantizar enfoques de implementación coherentes y estables en todas las instancias de Kubernetes.

La gobernanza de los clústeres de Kubernetes se puede considerar desde cinco perspectivas distintas.

Gobernanza de recursos de Azure

La primera es la perspectiva en función de los recursos de Azure. Esto supone asegurarse de que todos los clústeres cumplan los requisitos de la organización. Incluye conceptos como la topología de red, el clúster privado, los roles RBAC de Azure para los equipos de SRE, la configuración del diagnóstico, la disponibilidad de regiones, las consideraciones sobre grupos de nodos, la gobernanza de Azure Container Registry, las opciones de Azure Load Balancer, los complementos de AKS, etc. Esta gobernanza garantiza la coherencia en la "apariencia" y la "topología" de los clústeres de las organizaciones. También debe aplicarse al arranque tras la implementación del clúster, en aspectos como qué agentes de seguridad se deben instalar y cómo deben configurarse.

Los clústeres de Snowflake son difíciles de controlar en cualquier capacidad central. Debe reducir al mínimo las discrepancias entre los clústeres para que las directivas puedan aplicarse de manera uniforme, y se eviten y se puedan detectar los clústeres anómalos. Esto también puede incluir tecnologías que se usan para implementar clústeres, como ARM, Bicep o Terraform.

Si se aplica Azure Policy en el nivel de grupo de administración o de suscripción, se pueden aplicar muchas de estas consideraciones, pero no todas.

Gobernanza de la carga de trabajo de Kubernetes

Dado que Kubernetes es en sí mismo una plataforma, la segunda perspectiva se refiere a la gobernanza de lo que ocurre dentro de un clúster. Esto incluye aspectos como la guía de espacios de nombres, directivas de red, RBAC de Kubernetes, límites y cuotas. Se trataría de la gobernanza aplicada más a las cargas de trabajo que al clúster. Todas las cargas de trabajo van a ser únicas, ya que todas ellas resuelven distintos problemas empresariales y se implementarán de diferentes maneras con diversas tecnologías. Puede que no haya muchos procedimientos de gobernanza que sirvan para todo, pero debería considerar la gobernanza en torno a la creación y el consumo de artefactos de OCI, los requisitos de la cadena de suministro, el uso del registro de contenedor público, el proceso de cuarentena de imágenes y la gobernanza de la canalización de implementación.

Si es factible, considere también la posibilidad de normalizar herramientas y patrones comunes. Incluya recomendaciones sobre tecnologías como Helm, la malla de servicio, los controladores de entrada, los operadores de GitOps, los volúmenes persistentes, etc. También se incluiría aquí la gobernanza del uso de la identidad administrada de pod y el aprovisionamiento de secretos desde Key Vault.

Impulse un control estricto en torno al acceso a los datos de telemetría, para asegurarse de que los propietarios de las cargas de trabajo tienen el acceso adecuado a las métricas y los datos que necesitan para mejorar su producto, a la vez que garantiza que los operadores del clúster tienen acceso a la telemetría del sistema para mejorar su oferta de servicio. A menudo es necesario que los datos estén en correlación entre los dos, por lo que debe asegurarse de que existen las directivas de gobernanza precisas para garantizar el acceso adecuado cuando sea necesario.

Si se aplica Azure Policy para AKS en el nivel de clúster, se pueden conseguir algunos de estos objetivos, pero no todos.

Roles de operador de clúster (DevOps, SRE)

La tercera perspectiva corresponde a la gobernanza de los roles de operador de clúster. ¿Cómo interactúan los equipos de SRE con los clústeres? ¿Cuál es la relación entre ese equipo y el equipo de carga de trabajo? ¿Son el mismo equipo? Los operadores de clúster deben tener un cuaderno de estrategias claramente definido para las actividades de evaluación de prioridades del clúster, como el modo en que acceden a los clústeres, desde dónde lo hacen, qué permisos tienen en los clústeres y cuándo se asignan esos permisos. Asegúrese de que en la documentación, la directiva y los materiales de aprendizaje sobre la gobernanza quedan claras las diferencias entre el operador de la carga de trabajo y el operador de clúster en este contexto. En función de su organización, puede que sean el mismo.

Clúster por carga de trabajo o varias cargas de trabajo por clúster

La cuarta perspectiva corresponde a la gobernanza de varios inquilinos. Es decir, ¿es necesario que los clústeres contengan algo parecido a una agrupación de aplicaciones que pertenezcan, por definición, al mismo equipo de carga de trabajo y representen un único conjunto de componentes de carga de trabajo relacionados? ¿O los clústeres deben ser multiinquilinos por naturaleza, con varias cargas de trabajo dispares y varios propietarios de cargas de trabajo, que se ejecutan y se controlan como una oferta de servicio administrada dentro de la organización? La estrategia de gobernanza es muy diferente en cada caso y, por lo tanto, debe asegurarse de que se aplique la estrategia elegida. Si tiene que trabajar con ambos modelos, asegúrese de que en el plan de gobernanza se define claramente qué directivas se aplican a qué tipos de clústeres.

Esta decisión debería adoptarse durante la fase de estrategia, porque tiene un impacto significativo en lo que respecta al personal, el presupuesto y la innovación.

Labores para mantenerse al día

La quinta perspectiva se centra en las operaciones, como la actualización de las imágenes de nodo (aplicación de revisiones) y el control de versiones de Kubernetes. ¿Quién es el responsable de las actualizaciones de las imágenes de nodo, el seguimiento de las revisiones aplicadas, el seguimiento y la combinación de los planes de corrección de las vulnerabilidades y exposiciones más habituales de Kubernetes y AKS? Los equipos de cargas de trabajo deben estar implicados a la hora de validar si la solución funciona en las actualizaciones del clúster; si los clústeres no están actualizados, dejarán de contar con el soporte técnico de Azure. Contar con una sólida gobernanza en torno a las labores para mantenerse al día es fundamental en AKS, mucho más que en la mayoría de las demás plataformas de Azure. Esto exigirá una relación de trabajo muy estrecha con los equipos de aplicación y tiempo dedicado por su parte, al menos cada mes, a validar la carga de trabajo para asegurarse de que los clústeres se mantienen actualizados. Asegúrese de que todos los equipos que dependen de algún modo de Kubernetes comprenden los requisitos y el costo que supone este esfuerzo continuado, que durará mientras estén en la plataforma.

Línea de base de seguridad

Para tener en cuenta la seguridad de los clústeres de AKS, se pueden incorporar los siguientes procedimientos recomendados a la base de referencia de la seguridad:

Identidad

Existen muchos procedimientos recomendados que puede aplicar a la base de referencia de la identidad para garantizar una administración coherente de la identidad y el acceso en los clústeres de Kubernetes:

Paso siguiente: Administración de soluciones de plataformas de aplicaciones modernas

Los siguientes artículos le proporcionarán orientación sobre puntos específicos del recorrido de adopción de la nube que le ayudarán a completar el escenario de adopción de la nube correctamente.