Compartir a través de

Consideraciones generales sobre la arquitectura para elegir un servicio de Azure Container Service

  • Artículo

Este artículo le guía por el proceso de elección de un servicio de Azure Container Service. Proporciona información general sobre las consideraciones de nivel de característica que son comunes y críticas para algunas cargas de trabajo. Puede ayudarle a tomar decisiones para asegurarse de que la carga de trabajo cumple los requisitos de confiabilidad, seguridad, optimización de costos, excelencia operativa y eficiencia del rendimiento.

Nota:

Este artículo es la segunda parte de una serie que comienza por Elección de un servicio de Azure Container Service. Se recomienda encarecidamente leer primero ese artículo de información general para obtener un contexto para estas consideraciones arquitectónicas.

Información general

Las consideraciones de este artículo se dividen en cuatro categorías:

Consideraciones sobre arquitectura y red

  • Compatibilidad con sistema operativo
  • Espacios de direcciones de la red
  • Descripción del flujo de tráfico
  • Planear subredes
  • Número de direcciones IP de entrada disponibles
  • Rutas definidas por el usuario y soporte para NAT Gateway
  • Integración de redes privadas
  • Cobertura de protocolo
  • Equilibrio de carga
  • Detección de servicios
  • Dominios personalizados y TLS administrado
  • TLS mutuo
  • Conceptos de redes para servicios específicos de Azure

Consideraciones de seguridad

  • Proporcionar seguridad para el tráfico dentro del clúster mediante directivas de red
  • Grupos de seguridad de red
  • Integración de Azure Key Vault
  • Compatibilidad con identidad administrada
  • Evaluaciones de vulnerabilidades y protección contra amenazas con Defender para contenedores
  • Líneas base de seguridad
  • Marco de buena arquitectura de Azure para seguridad

Consideraciones acerca de las operaciones

  • Actualizaciones y revisiones
  • Actualizaciones de imagen de contenedor
  • Escalabilidad vertical de la infraestructura
  • Escalabilidad horizontal de la infraestructura
  • Escalabilidad de aplicaciones
  • Observabilidad
  • Excelencia operativa del Marco de buena arquitectura de Microsoft

Consideraciones sobre la confiabilidad

  • Contratos de nivel de servicio
  • Redundancia mediante zonas de disponibilidad
  • Comprobaciones de estado y recuperación automática
  • Implementaciones de aplicaciones sin tiempo de inactividad
  • Límites de recursos
  • Marco de buena arquitectura para la confiabilidad

Tenga en cuenta que este artículo se centra en un subconjunto de servicios de contenedor de Azure que ofrecen un conjunto de características maduro para aplicaciones web y API, redes, observabilidad, herramientas de desarrollo y operaciones: Azure Kubernetes Service (AKS), Azure Container Apps y Web App for Containers. Para obtener una lista completa de todos los servicios de contenedor de Azure, consulte la página de categoría de productos de servicios de contenedor.

Nota:

En esta guía, el término carga de trabajo hace referencia a una colección de recursos de aplicación que buscan cumplir un objetivo empresarial o la ejecución de un proceso de negocio. Una carga de trabajo usa varios componentes, como las API y los almacenes de datos, que funcionan conjuntamente para ofrecer funcionalidades específicas de un extremo a otro.

Consideraciones arquitectónicas

En esta sección se describen las decisiones arquitectónicas difíciles de revertir o corregir sin un tiempo de inactividad o una nueva implementación significativos. Es especialmente necesario tener en cuenta esta consideración para los componentes fundamentales, como las redes y la seguridad.

Estas consideraciones no son específicas de los pilares del Marco de buena arquitectura. Sin embargo, merecen un examen y una evaluación adicionales frente a los requisitos de las empresas cuando se elige un servicio de Azure Container Service.

Compatibilidad con sistema operativo

La mayoría de las aplicaciones en contenedor se ejecutan en contenedores de Linux, que son compatibles con todos los servicios de contenedor de Azure. Las opciones son más limitadas para los componentes de carga de trabajo que requieren contenedores de Windows.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con Linux ✅ ✅ ✅
Compatibilidad con ventanas ❌ ✅ ✅
Compatibilidad con sistema operativo mixto ❌ ✅ ❌*

*La compatibilidad con un sistema operativo mixto para Web App for Containers requiere planes de servicio de Azure App Service independientes para Windows y Linux.

Consideraciones sobre redes

Es importante comprender el diseño de redes al principio de los procesos de planeamiento debido a restricciones de seguridad y cumplimiento e instrucciones impuestas. En general, las principales diferencias entre los servicios de Azure que se tratan en esta guía dependen de las preferencias:

  • Container Apps es una oferta de PaaS que proporciona muchas características de red administradas por Azure, como la detección de servicios, los dominios administrados internos y los controles de red virtual.
  • AKS es el más configurable de los tres servicios y proporciona el mayor control sobre el flujo de red. Por ejemplo, proporciona controladores de entrada personalizados y el control del tráfico dentro del clúster a través de directivas de red de Kubernetes. Los equipos de las cargas de trabajo pueden aprovechar varios complementos de las redes administradas de Azure, así como instalar y operar cualquier complemento del ecosistema de Kubernetes más amplio.
  • Web App for Containers es una característica de App Service. Por lo tanto, los conceptos de la red, especialmente la integración de las redes privadas, son muy específicos de App Service. Este servicio será familiar para los equipos de carga de trabajo que ya usan App Service. Se recomienda que los equipos que no tengan experiencia con App Service y que quieran una integración de red virtual de Azure más conocida tengan en cuenta Container Apps.

Tenga en cuenta que las redes son un nivel de infraestructura fundamental. A menudo es difícil realizar cambios en el diseño sin volver a implementar la carga de trabajo, lo que puede provocar tiempo de inactividad. Por lo tanto, si la carga de trabajo tiene requisitos de red específicos, revise esta sección detenidamente antes de restringir la selección del servicio de Azure Container Service.

Espacios de direcciones de la red

Al integrar aplicaciones en redes virtuales, debe realizar algún planeamiento de direcciones IP para asegurarse de que hay suficientes direcciones IP disponibles para las instancias de contenedor. Durante este proceso, planee direcciones adicionales para actualizaciones, implementaciones azules o verdes y situaciones similares en las que se implementan instancias adicionales, que consumen direcciones IP adicionales.

Aplicaciones de contenedor AKS Web App for Containers
Subredes dedicadas Plan de consumo: opcional
Plan dedicado: obligatorio		 Obligatorio Opcionales
Requisitos de las direcciones IP Plan de consumo: consulte Entorno de solo consumo.
Plan dedicado: consulte Entorno de perfiles de carga de trabajo.		 Consulte Redes virtuales de Azure para AKS. Consulte Requisitos de subred de App Service.

Tenga en cuenta que los requisitos de AKS dependen del complemento de red elegido. Algunos complementos de red para AKS requieren reservas de IP más amplias. Esos detalles se encuentran fuera del ámbito de este artículo. Para más información, consulte Conceptos de redes para AKS.

Descripción del flujo de tráfico

Los tipos de flujo de tráfico necesarios para una solución pueden afectar al diseño de red.

En las secciones siguientes se proporciona información detallada sobre varias restricciones de redes. Estas restricciones afectan a la necesidad de implementar subredes adicionales, en función de si necesita:

  • Varias cargas de trabajo coubicadas.
  • Entrada privada o pública.
  • Flujo controlado por acceso del tráfico horizontal de derecha a izquierda en un clúster (para Container Apps y AKS) o dentro de una red virtual (para todos los servicios de Azure Container Service).

Plan para subredes

Asegurarse de que tiene una subred lo suficientemente grande como para incluir instancias de la aplicación para la carga de trabajo no es el único factor que determina la superficie de red en la que se implementan estas aplicaciones.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con cargas de trabajo colocadas dentro de una subred* ❌* ✅ N/A*

*Se describe un procedimiento recomendado, no una limitación técnica.

En el caso de Container Apps, la integración de subred solo se aplica a un único entorno de Container Apps. Cada entorno de Container Apps está restringido a una única dirección IP de entrada, pública o privada.

Cada entorno de Container Apps solo está pensado para una sola carga de trabajo en la que se colocan las aplicaciones dependientes. Por lo tanto, debe introducir dispositivos de red de Azure adicionales para el equilibrio de carga de entrada si necesita entrada pública y privada. Los ejemplos incluyen Azure Application Gateway y Azure Front Door. Además, si tiene varias cargas de trabajo que deben segregarse, se requieren entornos adicionales de Container Apps, por lo que se debe asignar una subred adicional para cada entorno.

AKS proporciona un control granular de flujo de red horizontal de derecha a izquierda dentro del clúster en forma de directiva de red de Kubernetes. Este control de flujo permite segmentar varias cargas de trabajo con diferentes límites de seguridad de red dentro del mismo clúster.

En el caso de Web App for Containers, no hay restricciones en el número de aplicaciones que se pueden integrar con una sola subred, siempre y cuando la subred sea lo suficientemente grande. No hay procedimientos recomendados para el control de acceso entre aplicaciones web en la misma red virtual. Cada aplicación web administra de forma independiente el control de acceso para el tráfico horizontal de derecha a izquierda o vertical de arriba abajo desde la red virtual o Internet, respectivamente.

Nota:

No puede cambiar el tamaño de las subredes que tienen recursos implementados en ellas. Tenga cuidado adicional al planear la red para evitar tener que volver a implementar componentes de carga de trabajo completos, lo que puede provocar tiempo de inactividad.

Número de direcciones IP de entrada disponibles

En la tabla siguiente se tiene en cuenta la sección de planeamiento de subred anterior para definir cuántas direcciones IP se pueden exponer para un número arbitrario de aplicaciones hospedadas en una sola implementación de un servicio de Azure Container Service.

Aplicaciones de contenedor AKS Web App for Containers
Número de direcciones IP de entrada Uno Muchos App Service Environment: una
Sin App Service Environment: muchas

Container Apps permite una dirección IP por entorno, pública o privada. AKS permite cualquier número de direcciones IP, públicas o privadas. Web App for Containers, fuera de una instancia de App Service Environment, permite una dirección IP pública para todas las aplicaciones dentro de un plan de App Service y varias direcciones IP privadas diferentes que usan puntos de conexión privados de Azure.

Es importante tener en cuenta que las aplicaciones web integradas en una instancia de App Service Environment solo reciben tráfico a través de la dirección IP de entrada única asociada a App Service Environment, ya sea pública o privada.

Rutas definidas por el usuario y soporte para NAT Gateway

Si una carga de trabajo necesita rutas definidas por el usuario (UDR) y funcionalidades de puerta de enlace NAT para el control granular de la red, Container Apps requiere el uso de perfiles de carga de trabajo. La compatibilidad con UDR y la puerta de enlace NAT no están disponibles en el plan de solo consumo de ACA.

AKS y Web App for Containers implementan estas dos características de red a través de la funcionalidad de red virtual estándar o la integración de red virtual, respectivamente. Es decir, los grupos de nodos de AKS y Web App for Containers en una instancia de App Service Environment ya son recursos de red virtual directos. Web App for Containers que no están en una instancia de App Service Environment admite UDR y puerta de enlace NAT a través de la integración de red virtual. Con la integración de red virtual, el recurso técnicamente no reside directamente en la red virtual, pero todo su acceso saliente fluye a través de la red virtual y las reglas asociadas de la red afectan al tráfico según lo previsto.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con UDR Plan de solo consumo: ❌
Plan de perfil de carga de trabajo: ✅		 ✅ ✅
Compatibilidad con NAT Gateway Plan de solo consumo: ❌
Plan de perfil de carga de trabajo: ✅		 ✅ ✅

Integración de redes privadas

En el caso de las cargas de trabajo que requieren redes privadas estrictas de nivel 4 para la entrada y salida, considere Container Apps, AKS y la SKU de App Service Environment de un solo inquilino, donde las cargas de trabajo se implementan en una red virtual autoadministrada, lo que proporciona los controles de red privados pormenorizados habituales.

Aplicaciones de contenedor AKS Web App for Containers
Entrada privada en una red virtual ✅ ✅ Mediante un punto de conexión privado
Salida privada desde una red virtual ✅ ✅ Mediante una integración de la red virtual
Punto de conexión público totalmente suprimido ✅ ✅ Solo App Service Environment
Redes privadas con Web App for Containers

Web App for Containers proporciona características de red adicionales que no se exponen de la misma manera por los otros servicios de Azure que se describen en este artículo. Para implementar requisitos estrictos de red privada, los equipos de carga de trabajo deben familiarizarse con estos conceptos de red. Revise detenidamente estas características de red:

Si desea una solución PaaS y prefiere conceptos de red que se comparten entre varias soluciones de Azure, considere la posibilidad de usar Container Apps.

Cobertura de protocolo

Una consideración importante para la plataforma de hospedaje son los protocolos de red que se admiten para las solicitudes de aplicación entrantes (entrada). Web App for Containers es la opción más estricta, que solo admite HTTP y HTTPS. Container Apps también permite conexiones TCP entrantes. AKS es el uso más flexible y compatible con el uso sin restricciones de TCP y UDP en puertos seleccionados automáticamente.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con protocolos y puertos HTTP (puerto 80)*
HTTPS (puerto 443)*
TCP (puertos 1-65535, excepto 80 y 443)		 TCP.(cualquier puerto)
UDP (cualquier puerto)		 HTTP (puerto 80)
HTTPS (puerto 443)
Compatibilidad con WebSocket ✅ ✅ ✅
Compatibilidad con HTTP/2 ✅ ✅ ✅

*En el entorno de Container Apps, HTTP/S se puede exponer en cualquier puerto para la comunicación entre clústeres. En ese escenario, las características HTTP integradas de Container Apps, como CORS y afinidad de sesión, no se aplican.

Tanto Container Apps como Web App for Containers admiten TLS 1.2 para su entrada HTTPS integrada.

Equilibrio de carga

Con Container Apps y Web App for Containers, Azure deja totalmente aparte los equilibradores de carga de nivel 4 y 7.

Por el contrario, AKS usa un modelo de responsabilidad compartida en el que Azure administra la infraestructura subyacente de Azure que el equipo de carga de trabajo configura mediante la interfaz con la API de Kubernetes. Para el equilibrio de carga de nivel capa 7 en AKS, puede elegir opciones administradas por Azure, por ejemplo, el complemento de enrutamiento de aplicaciones administradas de AKS o la Application Gateway para contenedores, o implementar y autoadministrar el controlador de entrada que prefiera.

Aplicaciones de contenedor AKS Web App for Containers
Equilibrador de carga de capa 4 Administrado por Azure Responsabilidad compartida Administrado por Azure
Equilibrador de carga de capa 7 Administrado por Azure Compartido o autoadministrado Administrado por Azure

Detección de servicios

En las arquitecturas en la nube, los entornos de ejecución se pueden quitar y volver a crear en cualquier momento para reequilibrar los recursos, por lo que las direcciones IP de instancia cambian con regularidad. Estas arquitecturas usan nombres de dominio completos (FQDN) para una comunicación confiable y coherente.

Aplicaciones de contenedor AKS Web App for Containers
Detección de servicios FQDN administrados por Azure Configurable mediante Kubernetes FQDN administrados por Azure

Web App for Containers proporciona FQDN de entrada pública (comunicación vertical de arriba abajo) ya integrados. No se requiere ninguna configuración adicional de DNS. Sin embargo, no hay ningún mecanismo integrado para facilitar o restringir el tráfico entre otras aplicaciones (comunicación horizontal de derecha a izquierda).

Container Apps también proporciona FQDN de entrada públicos. Sin embargo, Container Apps va más allá al permitir que los FQDN de la aplicación se expongan y restrinja el tráfico solo dentro del entorno. Esta funcionalidad facilita la administración de la comunicación este-oeste y habilita componentes como Dapr.

Las implementaciones de Kubernetes no se pueden detectar inicialmente dentro o fuera del clúster. Debe crear servicios de Kubernetes según lo que determine la API de Kubernetes, que después expone las aplicaciones a la red de forma direccionable.

Importante

Solo Container Apps y AKS proporcionan detección de servicios a través de esquemas DNS internos dentro de sus respectivos entornos. Esta funcionalidad puede simplificar las configuraciones de DNS en entornos de desarrollo y pruebas y producción. Por ejemplo, puede crear estos entornos con nombres de servicio arbitrarios que solo tienen que ser únicos dentro del entorno o clúster, por lo que pueden ser los mismos entre desarrollo y pruebas y producción. Con Web App for Containers, los nombres de servicio deben ser únicos en distintos entornos para evitar conflictos con Azure DNS.

Dominios personalizados y TLS administrado

Tanto Container Apps como Web App for Containers proporcionan soluciones integradas para dominios personalizados y administración de certificados.

Aplicaciones de contenedor AKS Web App for Containers
Configuración de dominios personalizados De serie BYO De serie
TLS administrado para FQDN de Azure De serie N/D De serie
TLS administrado para dominios personalizados En versión preliminar BYO Listo para usar o BYO

Los usuarios de AKS son responsables de administrar DNS, configuraciones de clúster y certificados TLS para sus dominios personalizados. Aunque AKS no ofrece TLS administrado, los clientes pueden aprovechar el software del ecosistema de Kubernetes, por ejemplo, el popular administrador de certificados para administrar los certificados TLS.

TLS mutuo

Otra alternativa para restringir el tráfico entrante es TLS mutuo (mTLS). TLS mutuo es un protocolo de seguridad que garantiza que tanto el cliente como el servidor en comunicación estén autenticados. Para realizar la autenticación, ambas partes intercambian y comprueban certificados antes de que se transmitan los datos.

Web App for Containers tiene compatibilidad integrada con mTLS para las conexiones de cliente entrantes. Sin embargo, la aplicación debe validar el certificado accediendo al encabezado HTTP X-ARR-ClientCert que reenvía la plataforma de App Service.

Container Apps también tiene compatibilidad integrada con mTLS. Reenvía el certificado de cliente a la aplicación en el encabezado HTTP X-Forwarded-Client-Cert. También puede habilitar fácilmente mTLS automático para la comunicación interna entre aplicaciones en un solo entorno.

TLS mutuo en AKS se puede implementar a través de la malla de servicios basada en Istio como un complemento administrado, que incluye funcionalidades de mTLS para las conexiones del cliente entrantes y la comunicación dentro del clúster entre los servicios. Los equipos de carga de trabajo también pueden optar por instalar y administrar otra solución de malla de servicio a través del ecosistema de Kubernetes. Estas opciones hacen que la implementación de mTLS en Kubernetes sea la más flexible.

Conceptos de red específicos del servicio

En las secciones anteriores se describen algunas de las consideraciones más comunes que se deben tener en cuenta. Para más información y obtener más información sobre las características de red específicas de los servicios de contenedor de Azure individuales, consulte estos artículos:

Las secciones anteriores se centran en el diseño de red. Continúe con la sección siguiente para obtener más información sobre la seguridad de red y la protección del tráfico de red.

Consideraciones sobre la seguridad

Si no se solucionan los riesgos de seguridad, se puede producir un acceso no autorizado, vulneraciones de datos o pérdidas de información confidencial. Los contenedores ofrecen un entorno encapsulado para la aplicación. Sin embargo, los sistemas de hospedaje y las superposiciones de red subyacentes requieren límites de protección adicionales. La elección del servicio de Azure Container Service debe admitir sus requisitos específicos para proteger cada aplicación individualmente y proporcionar medidas de seguridad adecuadas para evitar el acceso no autorizado y mitigar el riesgo de ataques.

Introducción a la comparación de seguridad

La mayoría de los servicios de Azure, como Container Apps, AKS y Web App for Containers, se integran con ofertas de seguridad clave, incluidas Key Vault e identidades administradas.

De los servicios de esta guía, AKS ofrece la mayor capacidad de configuración y extensibilidad, en parte mediante la exposición de los componentes subyacentes, que a menudo se pueden proteger a través de las opciones de configuración. Por ejemplo, los clientes pueden deshabilitar las cuentas locales en el servidor de la API de Kubernetes o activar las actualizaciones automáticas de los nodos subyacentes a través de las opciones de configuración.

Para obtener una comparación detallada, revise detenidamente las siguientes consideraciones para asegurarse de que se pueden cumplir los requisitos de seguridad de la carga de trabajo.

Seguridad del plano de control de Kubernetes

AKS ofrece la mayor flexibilidad de las tres opciones que se consideran en este artículo, lo que proporciona acceso completo a la API de Kubernetes para que pueda personalizar la orquestación de contenedores. Este acceso a la API de Kubernetes, sin embargo, también representa una superficie de ataque significativa y necesita protegerla.

Importante

Tenga en cuenta que esta sección no es relevante para Web App for Containers, que usa la API de Azure Resource Manager como plano de control.

Seguridad basada en la identidad

Los clientes son responsables de proteger el acceso basado en identidades a la API. De por sí, Kubernetes proporciona su propio sistema de administración de autenticación y autorización, que también debe protegerse con controles de acceso.

Para aprovechar una única vista unificada para la administración de identidades y acceso en Azure, es recomendable deshabilitar cuentas locales específicas de Kubernetes y, en su lugar, implementar la integración de Microsoft Entra administrada por AKS junto con Azure RBAC para Kubernetes. Si implementa este procedimiento recomendado, los administradores no necesitan realizar la administración de identidades y acceso en varias plataformas.

Aplicaciones de contenedor AKS
Controles de acceso de la API de Kubernetes Sin acceso Acceso total

Los clientes que usan Container Apps no tienen acceso a la API de Kubernetes. Microsoft proporciona seguridad para esta API.

Seguridad basada en la red

Si desea restringir el acceso de red al plano de control de Kubernetes, debe usar AKS, que proporciona dos opciones. La primera opción es usar clústeres de AKS privados, que usan Azure Private Link entre la red privada del servidor de API y la red privada del clúster de AKS. La segunda opción es la integración con red virtual del servidor de API (versión preliminar), donde el servidor de API se integra en una subred delegada. Para obtener más información, consulte la documentación.

Hay consecuencias al implementar el acceso restringido a la red a la API de Kubernetes. En particular, la administración solo se puede realizar desde dentro de la red privada. Normalmente, esto significa que se deben implementar agentes autohospedados para Azure DevOps o Acciones de GitHub. Para obtener información sobre otras limitaciones, consulte la documentación específica sobre cada producto.

Aplicaciones de contenedor AKS
Seguridad de red de la API de Kubernetes No configurable en PaaS Configurable: dirección IP pública o IP privada

Estas consideraciones no se aplican a Container Apps. Dado que es PaaS, Microsoft abstrae la infraestructura subyacente.

Seguridad de red del plano de datos

Las siguientes características de red se pueden usar para controlar el acceso a, desde y dentro de una carga de trabajo.

Uso de directivas de red para proporcionar seguridad para el tráfico dentro del clúster

Algunas posturas de seguridad requieren la segregación del tráfico de red dentro de un entorno, por ejemplo, cuando se usan entornos multiinquilino para hospedar varias aplicaciones o de varios niveles. En estos escenarios, debe elegir AKS e implementar directivas de red, una tecnología nativa de la nube que permite una configuración granular de redes de nivel 4 en clústeres de Kubernetes.

Aplicaciones de contenedor AKS Web App for Containers
Directivas de red Plan de consumo: ❌
Plan dedicado: ❌		 ✅ ❌

De los tres servicios de Azure descritos en este artículo, AKS es el único que admite el aislamiento adicional de la carga de trabajo dentro del clúster. Las directivas de red no se admiten en Container Apps o Web App for Containers.

Grupos de seguridad de red

En todos los escenarios, puede regular la comunicación de red dentro de la red virtual más amplia mediante grupos de seguridad de red, lo que le permite usar reglas de tráfico de nivel 4 que regulan la entrada y salida en el nivel de red virtual.

Aplicaciones de contenedor AKS Web App for Containers
Grupos de seguridad de red Plan de consumo: ✅
Plan dedicado: ✅		 ✅ ✅ Aplicaciones integradas en red virtual: solo salida

Restricciones de IP para la entrada

Normalmente, las restricciones de tráfico de red se aplican a través de las reglas de capa 4 descritas anteriormente. Sin embargo, en los escenarios de PaaS de aplicaciones sin integración de red virtual, puede ser útil restringir el tráfico en la capa de la aplicación.

Container Apps y Web App for Containers crean restricciones de IP de origen integradas para el tráfico de entrada en aplicaciones determinadas.

Aplicaciones de contenedor AKS Web App for Containers
Restricciones de IP de entrada en la capa de la aplicación De serie Auto gestionado o a través de un complemento gestionado De serie
Consumo de recursos - Consume recursos del clúster -

En el caso de las cargas de trabajo de AKS, la implementación depende del controlador de entrada elegido. Tanto el complemento de enrutamiento de las aplicaciones auto administradas como el complemento de enrutamiento de Azure consumen recursos del clúster.

Seguridad en el nivel de aplicación

Debe proteger las cargas de trabajo no solo en el nivel de red e infraestructura, sino también en el nivel de carga de trabajo y aplicación. Las soluciones de contenedor de Azure se integran con ofertas de seguridad de Azure para ayudar a estandarizar la implementación y los controles de seguridad de las aplicaciones.

Integración de Key Vault

Se recomienda almacenar y administrar secretos, claves y certificados en una solución de administración de claves, como Key Vault, que proporciona seguridad mejorada para estos componentes. En lugar de almacenar y configurar secretos en el código o en un servicio de proceso de Azure, todas las aplicaciones deben integrarse con Key Vault.

La integración de Key Vault permite a los desarrolladores de aplicaciones centrarse en su código de aplicación. Los tres servicios de Azure Container Service descritos en este artículo pueden sincronizar automáticamente los secretos del servicio Key Vault y proporcionarlos a la aplicación, normalmente como variables de entorno o archivos montados.

Aplicaciones de contenedor AKS Web App for Containers
Integración de Key Vault ✅ ✅ ✅

Para más información, vea:

Compatibilidad con identidad administrada

Las aplicaciones con identidades administradas asignadas pueden acceder a los recursos de Azure sin contraseñas. Todos los servicios de contenedores mencionados en esta guía admiten identidades administradas.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con identidad administrada ✅ ✅ ✅

Para más información, vea:

Evaluaciones de vulnerabilidades y protección contra amenazas con Defender para contenedores

La protección contra amenazas para vulnerabilidades también es importante. Se recomienda usar Defender para contenedores. Las evaluaciones de vulnerabilidades se admiten en los registros de contenedor de Azure, por lo que se pueden usar en cualquier servicio de Azure Container Service, no solo las descritas en este artículo. Sin embargo, la protección en entornos de ejecución de Defender para contenedores solo está disponible con AKS.

A medida que AKS expone la API nativa de Kubernetes, la seguridad del clúster también se puede evaluar con herramientas de seguridad específicas de Kubernetes del ecosistema de Kubernetes.

Aplicaciones de contenedor AKS Web App for Containers
Protección contra amenazas en tiempo de ejecución ❌ ✅ ❌

Para obtener más información, consulte Matriz de compatibilidad de contenedores en Defender for Cloud.

Tenga en cuenta que las evaluaciones de vulnerabilidades de imágenes de contenedor no son exámenes en tiempo real. Azure Container Registry se examina a intervalos regulares.

Líneas base de seguridad

En general, la mayoría de los servicios de contenedor de Azure integran las ofertas de seguridad de Azure. En general, tenga en cuenta que un conjunto de características de seguridad es solo una pequeña parte de la implementación de la seguridad en la nube. Para obtener más información sobre cómo implementar la seguridad para los servicios de contenedor, consulte las siguientes líneas base de seguridad específicas del servicio:

Las líneas base de seguridad cubren otras integraciones de Azure, incluido el cifrado de hardware y el registro, que están fuera del ámbito de este artículo.

Marco de buena arquitectura para la seguridad

Este artículo se centra en las principales diferencias entre las características de servicios de contenedor que se describen aquí.

Para obtener instrucciones de seguridad más completas sobre AKS, consulte Revisión del marco de buena arquitectura: AKS.

Consideraciones acerca de las operaciones

Para ejecutar correctamente una carga de trabajo en producción, los equipos deben implementar prácticas de excelencia operativa, como el registro centralizado, la supervisión, la escalabilidad, las actualizaciones periódicas y la aplicación de revisiones y la administración de imágenes.

Actualizaciones y revisiones

Es importante que el sistema operativo subyacente de una aplicación se actualice y se revise periódicamente. Tenga en cuenta, sin embargo, que con cada actualización hay un riesgo de error. En esta sección y en la siguiente se describen las consideraciones principales para los tres servicios de contenedor con respecto a la responsabilidad compartida entre el cliente y la plataforma.

Como servicio de Kubernetes administrado, AKS facilita las imágenes actualizadas de los componentes del sistema operativo del nodo y del plano de control. Sin embargo, los equipos de carga de trabajo son responsables de aplicarles actualizaciones a sus clústeres. Puede activar manualmente las actualizaciones o aprovechar la función de los canales de actualización automática de los clústeres para asegurarse de que los clústeres estén actualizados. Consulte la guía de operaciones del día 2 de AKS para obtener información sobre la aplicación de revisiones y la actualización de clústeres de AKS.

Container Apps y Web App for Containers son soluciones PaaS. Azure es responsable de administrar actualizaciones y revisiones, por lo que los clientes pueden evitar la complejidad de la administración de actualizaciones de AKS.

Aplicaciones de contenedor AKS Web App for Containers
Actualizaciones del plano de control Plataforma Cliente Plataforma
Hospedar actualizaciones y revisiones Plataforma Cliente Plataforma
Actualizaciones y revisiones de imágenes de contenedor Cliente Cliente Cliente

Actualizaciones de imagen de contenedor

Independientemente de la solución de contenedor de Azure, los clientes siempre son responsables de sus propias imágenes de contenedor. Si hay revisiones de seguridad para imágenes base de contenedor, es su responsabilidad recompilar las imágenes. Para obtener alertas sobre estas vulnerabilidades, use Defender para contenedores para contenedores hospedados en Container Registry.

Escalabilidad

El escalado se usa para ajustar la capacidad de los recursos para satisfacer las demandas, agregando más capacidad para garantizar el rendimiento y la eliminación de la capacidad sin usar para ahorrar dinero. Al elegir una solución de contenedor, debe tener en cuenta las restricciones de infraestructura y las estrategias de escalado.

Escalabilidad vertical de la infraestructura

El escalado vertical hace referencia a la capacidad de aumentar o disminuir la infraestructura existente, es decir, la CPU de proceso y la memoria. Las diferentes cargas de trabajo requieren diferentes cantidades de recursos de proceso. Al elegir una solución de contenedor de Azure, debe tener en cuenta las ofertas de SKU de hardware que están disponibles para un servicio de Azure determinado. Varían y pueden imponer restricciones adicionales.

Para AKS, revise los tamaños de las máquinas virtuales en la documentación de Azure y las restricciones de AKS por región.

En estos artículos se proporcionan detalles sobre las ofertas de SKU para los otros dos servicios:

Escalabilidad horizontal de la infraestructura

El escalado horizontal hace referencia a la capacidad de aumentar o disminuir la capacidad a través de una nueva infraestructura, como los nodos de máquina virtual. Durante los aumentos o disminuciones de escalado, el nivel de consumo de Container Apps abstrae las máquinas virtuales subyacentes. Para el resto de los servicios de contenedor de Azure, puede administrar la estrategia de escalado horizontal mediante la API estándar de Azure Resource Manager.

Tenga en cuenta que el escalado horizontal y vertical incluye el reequilibrio de instancias, por lo que también crea un riesgo de tiempo de inactividad. El riesgo es menor que el riesgo correspondiente con el escalado vertical. Sin embargo, los equipos de cargas de trabajo siempre son responsables de garantizar que sus aplicaciones puedan controlar los errores y la implementación de inicios y apagados correctos de sus aplicaciones para evitar el tiempo de inactividad.

Aplicaciones de contenedor AKS Web App for Containers
Escalado horizontal y reducción horizontal de la infraestructura Plan de consumo: N/D
Plan dedicado: configurable		 Configurable Configurable
Aprovisionamiento de hardware flexible Plan de consumo: N/D
Plan dedicado: abstraído con perfiles de carga de trabajo		 Cualquier SKU de máquina virtual Abstraída. Consulte Plan de App Service.

Importante

Las opciones de aprovisionamiento de hardware disponibles a través del plan dedicado de Container Apps (perfiles de carga de trabajo) y Web App for Containers (planes de App Service) no son tan flexibles como AKS. Debe familiarizarse con las SKU disponibles en cada servicio para asegurarse de que se cumplen sus necesidades.

Escalabilidad de aplicaciones

La medida típica en la que se desencadena el escalado de la infraestructura y las aplicaciones es el consumo de recursos: CPU y memoria. Algunas soluciones de contenedor pueden escalar el recuento de instancias de contenedor en métricas con contexto específico de la aplicación, como las solicitudes HTTP. Por ejemplo, AKS y Container Apps pueden escalar instancias de contenedor en función de las colas de mensajes a través de KEDA y muchas otras métricas a través de sus escaladores. Estas funcionalidades proporcionan flexibilidad al elegir la estrategia de escalabilidad de la aplicación. Web App for Containers se basa en las opciones de escalabilidad proporcionadas por Azure. (Consulte la tabla siguiente). Web App for Containers no admite configuraciones de escalador personalizadas como KEDA.

Aplicaciones de contenedor AKS Web App for Containers
Escalado horizontal de contenedores HTTP, TCP o basado en métricas (CPU, memoria, controlada por eventos). Basado en métricas (CPU, memoria o personalizado). Manual, basado en métricas o automático (versión preliminar).
Escalabilidad controlada por eventos Sí. Nativo de nube. Sí. Nativo de nube. Se requiere configuración adicional. Sí. Específico del recurso de Azure.

Observabilidad

Instrumentación de cargas de trabajo

La recopilación de métricas para aplicaciones complejas o de varios niveles puede ser difícil. Para obtener métricas, puede integrar cargas de trabajo en contenedor con Azure Monitor de dos maneras:

  • Instrumentación automática. No se requiere ningún cambio de código.
  • Instrumentación manual. Cambios mínimos de código necesarios para integrar y configurar el SDK o el cliente.
Aplicaciones de contenedor AKS Web App for Containers
Instrumentación automática a través de la plataforma ❌ ❌ La compatibilidad es parcial*
Instrumentación automática mediante el agente ❌ La compatibilidad es parcial* N/D
Instrumentación manual Mediante SDK u OpenTelemetry Mediante SDK u OpenTelemetry Mediante SDK u OpenTelemetry

*AKS y Web App for Containers admiten la instrumentación automática para determinadas configuraciones de cargas de trabajo de Linux y Windows, en función del lenguaje de la aplicación. Para obtener más información, consulta estos artículos:

La instrumentación dentro del código de aplicación es responsabilidad de los desarrolladores de aplicaciones, por lo que es independiente de cualquier solución de contenedor de Azure. La carga de trabajo puede usar soluciones como:

Registros

Todos los servicios de Azure Container Service proporcionan funcionalidad de registro de aplicaciones y plataformas. Los registros de aplicación son registros de consola generados por la carga de trabajo. Los registros de plataforma capturan eventos que se producen en el nivel de plataforma, fuera del ámbito de la aplicación, como el escalado e implementaciones.

Las principales diferencias entre la funcionalidad de registro para los servicios de contenedor pertenecen al registro de plataforma: qué se registra y cómo se organizan los registros internamente. Azure Monitor es el servicio de registro principal de Azure que se integra con estos servicios. El monitor usa registros de recursos para separar los registros procedentes de orígenes diferentes en categorías. Una manera de determinar qué registros están disponibles en cada servicio de Azure es examinar las categorías de registro de recursos que están disponibles para cada uno de los servicios.

Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad con el streaming de registros (streaming en directo) ✅ ✅ ✅
Compatibilidad con Azure Monitor ✅ ✅ ✅
Registros de recursos de Azure Monitor Consola y sistema Servidor de API de Kubernetes, Auditoría, Planificador, Escalador automático de clústeres, etc. ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs y más

Para obtener una descripción detallada de cada uno de los registros de recursos de la tabla, seleccione los vínculos de la tabla.

Este es un breve resumen de las funcionalidades de registro de los servicios de contenedor:

  • Container Apps extrae todos los registros internos de Kubernetes en dos categorías simples. Una, denominada registros de Consola, contiene los registros de contenedor de cargas de trabajo. Una segunda categoría Sistema contiene todos los registros relacionados con la plataforma.
  • AKS proporciona todos los registros relacionados con Kubernetes y un control granular sobre lo que se puede registrar. También conserva la compatibilidad completa con las herramientas de cliente de Kubernetes para el streaming de registros, como kubectl.
  • Web App for Containers proporciona muchas categorías de registros de recursos porque su plataforma (App Service) no es exclusivamente para cargas de trabajo de contenedor. Para las operaciones específicas del contenedor que administran su plataforma de Docker interna, proporciona la categoría de registro AppServicePlatformLogs. Otra categoría importante es AppServiceEnvironmentPlatformLogs, que registra eventos como el escalado y los cambios de configuración.

Excelencia operativa del Marco de buena arquitectura de Microsoft

Este artículo se centra en las principales diferencias entre las características de servicios de contenedor que se describen aquí. Consulte estos artículos para revisar la guía completa de excelencia operativa para los siguientes servicios:

Fiabilidad

Confiabilidad es la capacidad de un sistema de reaccionar ante los errores y seguir funcionando. En el nivel de software de la aplicación, las cargas de trabajo deben implementar procedimientos recomendados como el almacenamiento en caché, el reintento, los patrones de disyuntor y las comprobaciones de estado. En el nivel de infraestructura, Azure es responsable de controlar errores físicos, como errores de hardware e interrupciones de energía, en centros de datos. Los errores todavía pueden producirse. Los equipos de carga de trabajo deben seleccionar el nivel de servicio de Azure adecuado y aplicar las configuraciones de instancia mínima necesarias para implementar conmutaciones automáticas por error entre zonas de disponibilidad.

Para elegir el nivel de servicio adecuado, debe comprender cómo funcionan los acuerdos de nivel de servicio (SLA) y las zonas de disponibilidad.

Contratos de nivel de servicio

La confiabilidad se mide normalmente mediante métricas controladas por la empresa, como acuerdos de nivel de servicio o métricas de recuperación, como objetivos de tiempo de recuperación (RTO).

Azure tiene muchos Acuerdos de Nivel de Servicio para servicios específicos. No existe un nivel de servicio del 100 %, ya que los errores siempre pueden producirse en software y hardware, y por desastres naturales, por ejemplo, tormentas y terremotos. Un Acuerdo de Nivel de Servicio no es una garantía, sino un acuerdo de disponibilidad del servicio respaldado financieramente.

Para obtener los acuerdos de nivel de servicio y los detalles más recientes, descargue el documento de SLA más reciente para Microsoft Online Services desde el sitio web de licencias de Microsoft.

Niveles gratis frente a de pago

Por lo general, los niveles gratuitos de servicios de Azure no ofrecen un Acuerdo de Nivel de Servicio, lo que los convierte en opciones rentables para entornos que no son de producción. Sin embargo, para entornos de producción, se recomienda elegir un nivel de pago que tenga un Acuerdo de Nivel de Servicio.

Factores adicionales para AKS

AKS tiene diferentes acuerdos de nivel de servicio para diferentes componentes y configuraciones:

  • Plano de control. El servidor de API de Kubernetes tiene un Acuerdo de Nivel de Servicio independiente.
  • Plano de datos. Los grupos de nodos usan los Acuerdos de Nivel de Servicio de SKU de máquina virtual subyacentes.
  • Zonas de disponibilidad. Hay diferentes acuerdos de nivel de servicio para los dos planos, en función de si el clúster de AKS tiene habilitadas las zonas de disponibilidad y la ejecución de varias instancias en zonas de disponibilidad.

Tenga en cuenta que cuando se usan varios servicios de Azure, los SLO compuestos pueden diferir y ser inferiores a los SLA de servicio individuales.

Redundancia con zonas de disponibilidad

Las zonas de disponibilidad son centros de datos distintos que tienen energía eléctrica independiente, refrigeración, etc., dentro de una sola región. La redundancia resultante aumenta la tolerancia de errores sin necesidad de implementar arquitecturas de varias regiones.

Azure tiene zonas de disponibilidad en todos los países o regiones en los que Azure opera una región de centro de datos. Para permitir que varias instancias de contenedores crucen zonas de disponibilidad, asegúrese de seleccionar SKU, niveles de servicio y regiones que proporcionan compatibilidad con zonas de disponibilidad.

Característica Aplicaciones de contenedor AKS Web App for Containers
Compatibilidad de zonas de disponibilidad Completo Completo Completo

Por ejemplo, una aplicación o infraestructura configurada para ejecutar una sola instancia deja de estar disponible si se produce un problema en la zona de disponibilidad donde se hospeda el hardware. Para usar completamente la compatibilidad con zonas de disponibilidad, debe implementar cargas de trabajo con una configuración mínima de tres instancias del contenedor, distribuidas entre zonas.

Comprobaciones de estado y recuperación automática

Los puntos de conexión de comprobación de estado son cruciales para una carga de trabajo confiable. Pero crear esos puntos de conexión es solo la mitad de la solución. La otra mitad controla lo que hace la plataforma de hospedaje y cómo, cuando hay errores.

Para distinguir mejor entre los tipos de sondeos de estado, eche un vistazo a los tipos de sondeos integrados de Kubernetes:

  • Inicio. Comprueba si la aplicación se inició correctamente.
  • Preparación. Comprueba si la aplicación está lista para controlar las solicitudes entrantes.
  • Ejecución. Comprueba si la aplicación sigue en ejecución y responde.

Otra consideración importante es la frecuencia con la que se solicitan esas comprobaciones de estado desde la aplicación (granularidad interna). Si tiene un intervalo largo entre estas solicitudes, puede seguir atendiendo el tráfico hasta que la instancia se considere incorrecta.

La mayoría de las aplicaciones admiten comprobaciones de estado mediante el protocolo HTTP(S). Sin embargo, es posible que algunas necesiten otros protocolos, como TCP o gRPC, para realizar esas comprobaciones. Tenga esto en cuenta al diseñar el sistema de comprobación de estado.

Aplicaciones de contenedor AKS Web App for Containers
Sondeos de inicio ✅ ✅ Compatibilidad parcial
Sondeos de preparación ✅ ✅ ❌
Sondeos de ejecución ✅ ✅ ✅
Granularidad de intervalo Segundos Segundos 1 minuto
Compatibilidad con protocolos HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Las comprobaciones de estado son más fáciles de implementar en Web App for Containers. A continuación se indican algunas consideraciones importantes:

  • Sus sondeos de inicio están integrados y no se pueden cambiar. Envía una solicitud HTTP al puerto inicial del contenedor. Cualquier respuesta de la aplicación se considera un inicio correcto.
  • No admite sondeos de preparación. Si el sondeo de inicio se realiza correctamente, la instancia de contenedor se agrega al grupo de instancias correctas.
  • Envía la comprobación de estado en intervalos de un minuto. Este intervalo no se puede cambiar.
  • El umbral mínimo que se puede establecer para que se quite una instancia incorrecta del mecanismo de equilibrio de carga interno es de dos minutos. La instancia incorrecta obtiene el tráfico durante al menos dos minutos después de que se produzca un error en una comprobación de estado. El valor predeterminado de este ajuste es de 10 minutos.

Container Apps y AKS, por otro lado, son mucho más flexibles y ofrecen opciones similares. En cuanto a las diferencias específicas, AKS proporciona las siguientes opciones para realizar las comprobaciones del estado, que no están disponibles en Container Apps:

Recuperación automática

Identificar una instancia de contenedor incorrecta y dejar de enviar tráfico a ella es un inicio. El siguiente paso es implementar la recuperación automática. La recuperación automática es el proceso de reinicio de la aplicación en un intento de recuperarse de un estado incorrecto. Este es el modo en que se comparan los tres servicios de contenedor:

  • En Web App for Containers, no hay ninguna opción para reiniciar una instancia de contenedor inmediatamente después de que se produzca un error en una comprobación de estado. Si la instancia sigue fallando durante una hora, se reemplaza por una nueva instancia. Hay otra característica, denominada recuperación automática, que supervisa y reinicia instancias. No está relacionada directamente con las comprobaciones de estado. Usa varias métricas de aplicación, como los límites de memoria, la duración de la solicitud HTTP y los códigos de estado.
  • Container Apps y AKS intentan reiniciar automáticamente una instancia de contenedor si el sondeo de ejecución alcanza el umbral de error definido.

Implementaciones de aplicaciones sin tiempo de inactividad

La capacidad de implementar y reemplazar aplicaciones sin provocar tiempo de inactividad para los usuarios es fundamental para una carga de trabajo confiable. Los tres servicios de contenedor que se describen en este artículo admiten implementaciones de tiempo de inactividad cero, pero de maneras diferentes.

Aplicaciones de contenedor AKS Web App for Containers
Estrategia de tiempo de inactividad cero Actualización gradual Actualización continua, además de todas las demás estrategias de Kubernetes Ranuras de implementación

Tenga en cuenta que las arquitecturas de las aplicaciones también deben admitir la implementación sin tiempo de inactividad. Consulte el Marco de la Well-Architected de Azure para obtener instrucciones.

Límites de recursos

Otro componente importante de un entorno compartido confiable es el control sobre el uso de recursos (como la CPU o la memoria) de los contenedores. Debe evitar escenarios en los que una sola aplicación ocupa todos los recursos y deja otras aplicaciones en un estado incorrecto.

Aplicaciones de contenedor AKS Web App for Containers
Límites de recursos (CPU o memoria) Por aplicación o contenedor Por aplicación o contenedor
Por espacio de nombres		 Por plan de App Service
  • Web App for Containers: puede hospedar varias aplicaciones (contenedores) en un único plan de App Service. Por ejemplo, puede asignar un plan con dos núcleos de CPU y 4 GiB de RAM en el que puede ejecutar varias aplicaciones web en contenedores. Sin embargo, no puede restringir una de las aplicaciones a una cantidad determinada de CPU o memoria. Todos compiten por los mismos recursos del plan de App Service. Si desea aislar los recursos de la aplicación, debe crear planes adicionales de App Service.
  • Container Apps: puede establecer límites de CPU y memoria por aplicación en su entorno. Sin embargo, está restringido a un conjunto de combinaciones permitidas de CPU y memoria. Por ejemplo, no puede configurar una vCPU y 1 GiB de memoria, pero puede configurar una vCPU y 2 GiB de memoria. Un entorno de Container Apps es análogo a un espacio de nombres de Kubernetes.
  • AKS: puede elegir cualquier combinación de vCPU y memoria, siempre y cuando los nodos tengan el hardware para admitirla. También puede limitar los recursos en el nivel de espacio de nombres si desea segmentar el clúster de esa manera.

Marco de buena arquitectura para la confiabilidad

Este artículo se centra en las principales diferencias entre las características de los servicios de contenedor en Azure. Si desea revisar la guía de confiabilidad completa de un servicio específico, consulte estos artículos:

Conclusión

Las soluciones bien diseñadas establecen las bases para cargas de trabajo correctas. Aunque las arquitecturas se pueden ajustar a medida que crece una carga de trabajo y los equipos progresan en sus recorridos en la nube, algunas decisiones, especialmente en torno a las redes, son difíciles de revertir sin un tiempo de inactividad significativo o una nueva implementación.

En general, al comparar los servicios de contenedor de Azure, se da una situación: AKS expone la infraestructura más subyacente, lo que ofrece la mayor capacidad de configuración y extensibilidad. La cantidad de sobrecarga operativa y complejidad es muy variable en las cargas de trabajo de AKS. Algunos equipos pueden reducir considerablemente la sobrecarga operativa mediante complementos y extensiones administrados por Microsoft, así como las funcionalidades de actualizaciones automáticas. Otros clientes pueden preferir el control total del clúster con el fin de aprovechar la extensibilidad completa de Kubernetes y el ecosistema CNCF. Por ejemplo, aunque Microsoft ofrece Flux como una extensión de GitOps administrada, muchos equipos prefieren configurar y manejar ArgoCD por su cuenta.

Los equipos de la carga de trabajo que, por ejemplo, no requieren de aplicaciones CNCF, tienen menos experiencia en las operaciones o prefieren centrarse en las características de la aplicación pueden preferir una oferta de PaaS. Le recomendamos que tenga en cuenta como primera alternativa Container Apps.

Aunque Container Apps y Web App for Containers son ofertas de PaaS que proporcionan niveles similares de infraestructura administrada por Microsoft, una diferencia clave es que Container Apps está más cerca de Kubernetes y proporciona funcionalidades nativas de nube adicionales para la detección de servicios, el escalado automático controlado por eventos, la integración de Dapr, etc. Sin embargo, los equipos que no necesitan estas funcionalidades y están familiarizados con los modelos de implementación y redes de App Service podrían preferir Web App for Containers.

Las generalizaciones pueden ayudarle a reducir la lista de servicios de Azure Container Service que se deben tener en cuenta. Pero tenga en cuenta que también debe comprobar su elección examinando los requisitos individuales en detalle y comparándolos con conjuntos de características específicos del servicio.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes