Compartir a través de

Gobernanza de soluciones modernas de plataforma de aplicaciones

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

Base de gobernanza inicial

La gobernanza comienza con una base de gobernanza inicial a menudo denominada MVP de gobernanza. Esta base implementa los productos básicos de Azure necesarios para ofrecer gobernanza en el entorno de nube.

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

  • Conectividad y red híbrida básica.
  • Control de acceso basado en rol (RBAC) de Azure para el control de identidades y acceso.
  • Estándares de nomenclatura y etiquetado para la identificación coherente 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 de gobernanza inicial se pueden usar para controlar las instancias modernas de la solución de plataforma de aplicaciones. Pero en primer lugar, deberá agregar algunos componentes a la base inicial para aplicar Azure Policy a los contenedores. Una vez configurado, puede usar Azure Policy y la base de gobernanza inicial para controlar los siguientes tipos de contenedores:

Ampliar las disciplinas de gobernanza

La base de gobernanza inicial se puede usar para expandir varias materias de gobernanza para garantizar enfoques de implementación coherentes y estables en todas las instancias de Kubernetes.

La gobernanza de clústeres de Kubernetes se puede examinar con cinco perspectivas distintas.

Gobernanza de recursos de Azure

La primera es la perspectiva del recurso de Azure. Asegurarse de que todos los clústeres cumplen los requisitos de la organización. Esto incluye conceptos como la topología de red, el clúster privado, los roles RBAC de Azure para equipos de SRE, la configuración de diagnóstico, la disponibilidad de regiones, las consideraciones del grupo de nodos, la gobernanza de Azure Container Registry, las opciones de Azure Load Balancer, los complementos de AKS, la configuración de diagnóstico, etc. Esta gobernanza garantiza la coherencia en "apariencia" y "topología" de los clústeres de las organizaciones. Esto también debe extenderse para el arranque posterior a la implementación del clúster, como qué agentes de seguridad deben instalarse y cómo deben configurarse.

Los clústeres de Snowflake son difíciles de gobernar de manera centralizada. Minimice las discrepancias entre clústeres para que las directivas se puedan aplicar de manera uniforme y los clústeres anómalos se desalienten y sean detectables. Esto también puede incluir tecnologías que se usan para implementar los clústeres, como ARM, Bicep o Terraform.

Azure Policy aplicado en el nivel de grupo de administración o suscripción puede ayudar a ofrecer muchas de estas consideraciones, pero no todas.

Gobernanza de cargas de trabajo de Kubernetes

Dado que Kubernetes es en sí misma una plataforma, la segunda es la gobernanza de lo que sucede dentro de un clúster. Esto incluiría elementos como la guía del espacio de nombres, las directivas de red, RBAC de Kubernetes, los límites y las cuotas. Esto implicaría aplicar la gobernanza más a las cargas de trabajo que al clúster. Cada carga de trabajo va a ser única, ya que todas resuelven diferentes problemas empresariales y se implementarán de varias 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.

Considere la posibilidad de estandarizar también las herramientas comunes y los patrones, si es posible hacerlo. Incluya recomendaciones sobre tecnologías como Helm, malla de servicio, controladores de entrada, operadores de GitOps, 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.

Impulsar las expectativas sólidas sobre el acceso a la telemetría, para asegurarse de que los propietarios de cargas de trabajo tienen acceso adecuado a las métricas y los datos que necesitan para mejorar su producto, al tiempo que garantizan que los operadores de clúster tengan acceso a la telemétrica del sistema para mejorar su oferta de servicio. Los datos a menudo deben estar correlacionados entre los dos, asegurarse de que las directivas de gobernanza están en vigor para garantizar el acceso adecuado cuando sea necesario.

Azure Policy para AKS aplicado en el nivel de clúster puede ayudar a ofrecer algunos de estos, pero no todos.

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

La tercera es la gobernanza en torno a los roles de operador de clúster. ¿Cómo interactúan los equipos de SRE con clústeres? ¿Cuál es la relación entre ese equipo y el equipo de carga de trabajo? ¿Son los mismos? Los operadores de clúster deben tener un cuaderno de estrategias claramente definido para las actividades de evaluación de prioridades de clúster, como cómo acceden a los clústeres, desde dónde acceden a los clústeres y qué permisos tienen en los clústeres y cuándo se asignan esos permisos. Asegúrese de que las distinciones se realicen en la documentación de gobernanza, la directiva y los materiales de entrenamiento en torno al operador de carga de trabajo frente al operador de clúster en este contexto. Dependiendo de su organización, pueden ser iguales.

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

La cuarta perspectiva corresponde a la gobernanza en multiinquilinato. Es decir, los clústeres deben contener una "agrupación similar" de aplicaciones propiedad, por definición, todo ello por el mismo equipo de carga de trabajo y representar 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 especialmente diferente para cada uno y, como tal, debe controlar que se aplique la estrategia elegida. Si tiene que admitir ambos modelos, asegúrese de que el plan de gobernanza está claramente definido para qué directivas se aplican a qué tipos de clústeres.

Esta elección debería haberse realizado durante la fase de estrategia , ya que tiene un impacto significativo en el personal, el presupuesto y la innovación.

Mantener los esfuerzos actuales

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. Tener una gobernanza sólida en torno a los esfuerzos de "mantenerse al día" es fundamental en AKS, más que en la mayoría de las demás plataformas de Azure. Esto requerirá una relación de trabajo muy estrecha con los equipos de aplicaciones y el tiempo dedicado por ellos, al menos mensualmente, para la validación de cargas de trabajo para garantizar que los clústeres permanezcan actualizados. Asegúrese de que todos los equipos que toman una dependencia de Kubernetes comprenden los requisitos y el costo de este esfuerzo continuo, lo que durará siempre que estén en la plataforma.

Línea base de seguridad

Los siguientes procedimientos recomendados se pueden agregar a la línea de base de seguridad para tener en cuenta la seguridad de los clústeres de AKS:

identidad

Hay muchos procedimientos recomendados que puede aplicar a la línea de base de identidad para garantizar una administración coherente de identidades y acceso en los clústeres de Kubernetes:

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

Los artículos siguientes le llevarán a instrucciones en puntos específicos del recorrido de adopción de la nube para ayudarle a tener éxito en el escenario de adopción de la nube.