Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Kubernetes Service (AKS) explicado: plano de control, nodos, redes, seguridad y costes (Doblaje IA)

Transcript

Azure Kubernetes Service (AKS) explicado: plano de control, nodos, redes, seguridad y costes (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Has oído hablar de Kubernetes y AKS en conversaciones sobre
0:02
Speaker 2: la nube. Quizás haya sentido, pero sinceramente,¿ qué significan realmente
0:06
Speaker 2: para alguien que ejecuta aplicaciones en la nube? En, los
0:09
Speaker 2: contenedores cambiaron la forma en que creamos software porque son ligeros,
0:11
Speaker 2: portátiles y coherentes. El problema es que gestionarlos manualmente se
0:14
Speaker 2: complica rápidamente. Puedes gestionar unos pocos contenedores, pero cuando tienes
0:18
Speaker 2: docenas o cientos, dedicas todo tu tiempo a escalar, actualizar
0:21
Speaker 2: y solucionar errores en lugar de crear tu producto real.
0:25
Speaker 2: Al final de este episodio, comprenderás las cuatro cosas más
0:27
Speaker 2: importantes que Azure Kubernetes Service gestiona por ti. El plano
0:30
Speaker 2: de control, los nodos, la red y la seguridad. También
0:33
Speaker 2: desglosaremos lo que realmente cuesta. Sin rodeos de marketing en
0:36
Speaker 2: un lenguaje sencillo. El problema de los contenedores,¿ por qué
0:39
Speaker 2: necesitamos AKS? Los contenedores ganaron porque resuelven un problema real.
0:42
Speaker 2: Un paquete que agrupa el código de tu aplicación, las
0:44
Speaker 2: bibliotecas de ejecución y configuración. Se ejecuta igual en tu portátil,
0:48
Speaker 2: en un servidor de prueba o en producción. Ya no
0:50
Speaker 2: hay problemas de función en mi máquina. Ejecutar un puñado
0:53
Speaker 2: de contenedores funciona bien Los inicias manualmente, compruebas sus registros
0:57
Speaker 2: y los reinicias cuando fallan. Pero una vez que tienes
0:59
Speaker 2: docenas o cientos repartidos en varios servidores, te encuentras con
1:02
Speaker 2: un nuevo conjunto de problemas. Debes decidir dónde va cada contenedor,
1:06
Speaker 2: qué servidor obtiene qué contenedor, cómo se encuentran entre sí
1:08
Speaker 2: en la red, qué ocurre cuando uno falla a las
1:11
Speaker 2: 3 de la mañana y cómo gestionar un pico de
1:13
Speaker 2: tráfico que exige 50 copias más de tu aplicación en
1:15
Speaker 2: 30 segundos. Kubernetes es una plataforma de código abierto diseñada
1:18
Speaker 2: exactamente para este problema. Programa contenedores en servidores, los escala
1:22
Speaker 2: vertical y horizontalmente, comprueba su estado y enruta el tráfico
1:25
Speaker 2: entre ellos. Es el estándar del sector para la bloqueación
1:27
Speaker 2: de contenedores. Pero Kubernetes resuelve un problema y crea otro.
1:32
Speaker 2: Ejecutarlo tú mismo es completo. Debes configurar y mantener un
1:34
Speaker 2: plano de control, el cerebro del clúster, gestionar nodos de trabajo,
1:37
Speaker 2: aplicar parches de seguridad, actualizar versiones y acercar versiones y
1:40
Speaker 2: hacer copias de seguridad de los datos de configuración. Ese
1:42
Speaker 2: es un trabajo a tiempo completo para alguien que sabe
1:43
Speaker 2: lo que hace. Los servicios administrados, como Azure Kubernetes Service,
1:47
Speaker 2: te quitan esa carga operativa de encima. Microsoft gestiona el
1:50
Speaker 2: plano de control y se encarga de las actualizaciones, los
1:52
Speaker 2: parches y las copias. Tú te centras en tu aplicación. Entonces,¿
1:55
Speaker 2: qué hace AKS exactamente por ti? Empecemos por la parte
1:57
Speaker 2: más importante, el plano de control.¿ Qué es Azure Kubernetes Service?
2:02
Speaker 2: AKS es la versión administrada de Kubernetes de Microsoft. Así
2:04
Speaker 2: de simple, obtienes un clúster de Kubernetes totalmente funcional sin
2:08
Speaker 2: tener que configurar ni mantener la infraestructura subyacente. Microsoft ejecuta
2:12
Speaker 2: el plano de control por ti y tú te centras
2:13
Speaker 2: en implementar y ejecutar tus aplicaciones. Piensa en ello como
2:16
Speaker 2: si alquilaras un apartamento en lugar de construir una casa.
2:18
Speaker 2: Cuando construyes una casa, eres responsable de todo, los cimientos,
2:21
Speaker 2: las tuberías, la electricidad y el tejado. Cuando alquilas, el
2:23
Speaker 2: propietario se encarga de Tú solo te mudas y decoras.
2:26
Speaker 2: AKS es el propietario. Microsoft se encarga de los cimientos,
2:28
Speaker 2: el plano de control a la red, los parches de
2:30
Speaker 2: seguridad y las actualizaciones. Tú traes el mobiliario, tus aplicaciones
2:33
Speaker 2: en contenedores, las configuraciones y los procesos de implementación. Pero
2:36
Speaker 2: AKS no es solo un clúster de Kubernetes independiente. Funciona
2:38
Speaker 2: estrechamente con el resto de la plataforma Azure. Entra y
2:41
Speaker 2: digestiona la autenticación de usuarios y el control de acceso.
2:44
Speaker 2: Azure Monitor recopila registros y métricas del clúster y las aplicaciones.
2:48
Speaker 2: Azure Policy te permite aplicar reglas en todos los clústeres,
2:50
Speaker 2: como que ningún contenedor se ejecute como raíz o que
2:52
Speaker 2: todas las imágenes deben provenir de un registro aprobado. Esto
2:56
Speaker 2: es lo que hace que AKS sea más que Kubernetes
2:58
Speaker 2: en máquinas virtuales de Azure. Ahora bien, aún necesitas conocer
3:01
Speaker 2: los conceptos, pods, implementaciones y servicios básicos de Kubernetes. Eso
3:05
Speaker 2: es un conocimiento que aporta. AKS no lo sustituye. Pero
3:08
Speaker 2: lo que sí elimina es la sobrecarga operativa de mantener
3:10
Speaker 2: el clúster en buen estado. No tienes que preocuparte por
3:12
Speaker 2: la caída del plano de control. No actualizas manualmente las
3:14
Speaker 2: versiones de Kubernetes. Nos realizas copias de seguridad de TCD,
3:17
Speaker 2: la base de datos del clúster. Microsoft encarga de todo.
3:20
Speaker 2: Así que echemos un vistazo a ese cerebro, el plano
3:22
Speaker 2: de control. Plano de control, el cerebro que gestiona Microsoft.¿
3:25
Speaker 2: Qué hay exactamente dentro de ese plano de control? Cuatro
3:27
Speaker 2: componentes principales. El servidor API es la puerta de entrada.
3:31
Speaker 2: Cada comando, solicitud e interacción con el clúster pasa por él.
3:34
Speaker 2: El programador decide qué nodo ejecuta cada nuevo pod. El
3:37
Speaker 2: administrador del controlador observa el estado del clúster y se
3:39
Speaker 2: asegura de que la realidad coincida con lo que solicitaste.
3:41
Speaker 2: Y TCD almacena todos los datos de configuración. Piensa en
3:44
Speaker 2: ello como la memoria del clúster. Si ETCD se daña
3:46
Speaker 2: o se pierde, habrás perdido el clúster. Si configuras Kubernetes
3:50
Speaker 2: tú mismo eres responsable de todo esto. Aplicas parches al
3:52
Speaker 2: servidor API cuando aparecen vulnerabilidad. Regresas copias de seguridad de ETCD.
3:55
Speaker 2: Gestionas los fallos de hardware en las máquinas que ejecutan
3:58
Speaker 2: estos componentes. Es mucho trabajo. Con AKS, Microsoft te quita
4:01
Speaker 2: esa carga. Ejecutan el plano de control en su propia infraestructura.
4:04
Speaker 2: Lo parchean, hacen copias de seguridad y lo supervisan. Nunca
4:06
Speaker 2: ve las máquinas subyacentes. Solo interactúas con el punto de
4:09
Speaker 2: conexión del servidor. API y todo lo demás ocurre en
4:11
Speaker 2: segundo plano. Pero no todos los planos de control son iguales.
4:14
Speaker 2: AKS ofrece tres niveles, gratuito, estándar y premio. El nivel
4:18
Speaker 2: gratuito te ofrece el plan de control sin coste adicional,
4:20
Speaker 2: sin SDA en el servidor de API. Está bien para
4:23
Speaker 2: entornos de aprendizaje, desarrollo o pruebas en los que unos
4:25
Speaker 2: minutos de inactividad no vengan. Para cargas de trabajo de producción,¿
4:28
Speaker 2: qué harás más? El nivel estándar cuesta alrededor de 72
4:31
Speaker 2: dólares al mes por clúster. Eso te ofrece una SLA
4:33
Speaker 2: del 99,95% en el servidor de API cuando usas zonas
4:36
Speaker 2: de disponibilidad. Si el plan de control deja de funcionar,
4:40
Speaker 2: Microsoft te lo acredita. Es la opción predeterminada para mayores clústeres.
4:44
Speaker 2: El nivel premium cuesta alrededor de 400 dólares al mes.
4:47
Speaker 2: Obtienes todo lo del plan estándar y soporte a largo
4:48
Speaker 2: plazo para versiones de cobertura. Si ejecutas una carga de
4:51
Speaker 2: trabajo regulada, que debe permanecer en una versión específica durante
4:54
Speaker 2: meses o años, ahí es donde cobra sentido el plan premium.
4:57
Speaker 2: Este es el punto clave. En realidad no pagas por
4:59
Speaker 2: el plano de control en sí. El nivel gratuito es
5:01
Speaker 2: realmente gratuito. El estándar y el premium son tarifas por
5:04
Speaker 2: el SLA y el soporte a largo plazo, no por
5:05
Speaker 2: los recursos del plano de control. Lo que sí pagas
5:07
Speaker 2: son los nodos de trabajo, las máquinas virtuales que ejecutan
5:09
Speaker 2: tus usos. Se facturan por separado tarifas estándar de Azure VMs,
5:13
Speaker 2: Así que piénsalo de esta manera. El plano de control
5:15
Speaker 2: es el cerebro. Microsoft lo administra por ti. Eliges el
5:17
Speaker 2: nivel de servicio en función de tus necesidades de confiabilidad.
5:20
Speaker 2: Pero el trabajo real de ejecutar tus aplicaciones ocurre en
5:22
Speaker 2: los nodos de trabajo. Sus nodos de trabajo son donde
5:24
Speaker 2: realmente se ejecutan tus aplicaciones. Hablemos de ellos. Los nodos
5:27
Speaker 2: de los trabajadores por los que pagan. Los nodos son
5:30
Speaker 2: máquinas virtuales de Azure, así de simple. Máquinas virtuales de
5:33
Speaker 2: Azure estándar que alojan tus pods, que son la unidad
5:35
Speaker 2: más pequeña en Kubernetes que ejecuta uno o más contenedores.
5:37
Speaker 2: Tú eliges el tamaño y la cantidad. Por lo tanto,
5:39
Speaker 2: si quieres un DDoS MFP3 con 2 vCPU y 8
5:42
Speaker 2: GB de RAM, puedes hacerlo Si necesitas un E32 optimizado
5:45
Speaker 2: para memoria con 32 CPU y 256 GB, eso también funciona. Ahora,
5:49
Speaker 2: no solo tienes que juntar máquinas virtuales aleatorias. AKS las
5:52
Speaker 2: organiza en grupos de nodos. Un node pool es un
5:55
Speaker 2: grupo de máquinas virtuales idénticas con igual tamaño y configuración.
5:58
Speaker 2: Puede tener varios grupos de nodos en un solo cluster.
6:00
Speaker 2: Un grupo con máquinas virtuales de la serie de uso
6:02
Speaker 2: general para su interfaz web, otro con máquinas virtuales de
6:04
Speaker 2: la serie E optimizadas para memoria para su base de
6:06
Speaker 2: datos y un tercero con máquinas virtuales con GPU para
6:07
Speaker 2: carga de aprendizaje automático. Cada grupo se escala de forma independiente.
6:11
Speaker 2: Y ese escalado es automático. El escalador automático del clúster
6:13
Speaker 2: supervisa su spot. Cuando necesiten más recursos de los que
6:16
Speaker 2: pueden proporcionar los nodos actuales, agrega nuevos nodos. Y cuando
6:19
Speaker 2: el tráfico baja y las cargas quedan inactivas, las elimina.
6:22
Speaker 2: Se establece el tamaño mínimo y máximo para cada grupo
6:24
Speaker 2: y AKS se encarga de restos. Aquí es donde ahorra
6:26
Speaker 2: dinero de verdad. No paga por capacidad inactiva durante las
6:29
Speaker 2: horas de menor actividad. AKS se encarga también de las
6:32
Speaker 2: actualizaciones de nodos. Cuando sale un nuevo parche de seguridad
6:34
Speaker 2: para el SEO, AKS puede aplicarlo a sus nodos. Y
6:37
Speaker 2: cuando se lanza una nueva versión de Kubernetes, AKS puede
6:39
Speaker 2: actualizar su clúster. Te controla la promoción. Usted decide cuándo
6:42
Speaker 2: se realizan las actualizaciones en Microsoft. El trabajo real de
6:45
Speaker 2: vaciar los pods, actualizar los nodos y volver a ponerlos
6:47
Speaker 2: en línea se realiza por ti. Ahora el coste. Paga
6:51
Speaker 2: las tarifas estándar de Azure VM por tus nodos. Un
6:53
Speaker 2: D12V3 en el SDE cuesta unos 70 dólares al mes
6:56
Speaker 2: y una VM más grande cuesta más. Pero hay formas
6:59
Speaker 2: de reducirlo considerablemente. Las instancias reservadas permiten comprometerse uno o
7:03
Speaker 2: tres años por un descuento, ahorrando hasta un 72% frente
7:05
Speaker 2: a las tarifas de pago por uso. Si conoces tu
7:07
Speaker 2: capacidad de referencia, Los nodos que siempre necesitas en funcionamiento
7:10
Speaker 2: reservarlos tienen mucho sentido. Las VM Spots son más baratas,
7:13
Speaker 2: con hasta 90% de descuento en pago por uso. Pero
7:16
Speaker 2: aquí está el truco. Azure puede reclamar esa capacidad en
7:18
Speaker 2: cualquier momento, avisando a tus nodos con 30 segundos antes
7:21
Speaker 2: del desalojo. Eso está bien para trabajos por lotes, canalizaciones
7:25
Speaker 2: de CCC o cargas de trabajo sin estado que pueden
7:27
Speaker 2: gestionar interrupciones, pero no es ideal para tu API de
7:29
Speaker 2: producción en el estado de cliente. Por lo tanto, usted
7:31
Speaker 2: paga por los trabajadores, elige el tamaño o la cantidad
7:33
Speaker 2: del modelo de precios, mientras que acá se administra a
7:35
Speaker 2: los grupos el escalado de las actualizaciones. Sus nodos y
7:38
Speaker 2: pods necesitan comunicarse entre sí. Y ahí es donde entra
7:40
Speaker 2: en juego la red. Las redes. Cómo se comunican los pods.
7:44
Speaker 2: Cada pod de su clúster necesita una dirección IP, pero
7:46
Speaker 2: los pods aparecen constantemente. Se bloquean, se escalan, se reemplazan.
7:50
Speaker 2: Necesita un sistema que asigne IPs dinámicamente y garantice que
7:53
Speaker 2: los pods puedan comunicarse entre sí. Eso es lo que
7:55
Speaker 2: hace la interfaz de red de contenedores. Azure CNI es
7:58
Speaker 2: la implementación de Microsoft y administra cómo los pods obtienen
8:00
Speaker 2: direcciones y cómo fluye el tráfico entre ellos. Hay dos
8:03
Speaker 2: modelos de red principales entre los que puede elegir. Las
8:05
Speaker 2: redes superpuestas asignan a los pods IPs de un rango
8:07
Speaker 2: independiente que no forma parte de su propia red virtual.
8:11
Speaker 2: Esta es la opción más escalable. Puede tener hasta 5.000
8:13
Speaker 2: nodos y un cuarto de millón de pods en un
8:15
Speaker 2: solo clúster. Dado que las direcciones IP de los pods
8:18
Speaker 2: están aisladas de la red virtual, puede reutilizar el mismo
8:20
Speaker 2: espacio y direcciones en varios clústeres sin conflictos. La desventaja
8:23
Speaker 2: es que no se puede acceder a los pods directamente
8:25
Speaker 2: desde fuera del clúster. El tráfico que sale de un
8:27
Speaker 2: pod se traduce a la dirección IP del nodo. La
8:30
Speaker 2: otra opción es la red plana, donde los pods obtienen
8:32
Speaker 2: las IP directamente del rango de 2NX. Los sistemas externos
8:35
Speaker 2: pueden acceder a los pods directamente, si es necesario, pero
8:38
Speaker 2: la desventaja es que está consumiendo direcciones IP de la
8:40
Speaker 2: red virtual, que pueden agotarse rápidamente si tiene muchos pods.
8:43
Speaker 2: Debe planificar cuidadosamente los subredes. Ahora, hablemos del tráfico que
8:46
Speaker 2: sale del clúster. Cuando un pod necesita acceder a algo
8:49
Speaker 2: en Internet, una API externa, una base de datos o
8:51
Speaker 2: un servicio de terceros, ese tráfico debe pasar por algo.
8:54
Speaker 2: Por defecto, AKS emplea un equilibrador de carga de Azure
8:56
Speaker 2: para conexiones salientes y funciona bien para casi todas las cargas.
8:59
Speaker 2: Pero si las aplicaciones realizan muchas conexiones salientes... puede encontrarse
9:03
Speaker 2: con algo denominado agotamiento de puertos SNAP. Cada nodo obtiene
9:06
Speaker 2: un número fijo de puertos de traducción de direcciones de
9:08
Speaker 2: red de origen. Cuando se agotan, fallan las nuevas conexiones.
9:11
Speaker 2: La solución es AddYourNAP Gateway que gestiona mucho mejor los
9:14
Speaker 2: recuentos de conexiones elevados. Para exponer tus aplicaciones a Internet,
9:17
Speaker 2: existen dos enfoques principales. Para las aplicaciones que se comunican
9:21
Speaker 2: a través de TCP o UDP, como servidores de juegos,
9:23
Speaker 2: bases de datos o protocolos personalizados, usa un servicio de
9:26
Speaker 2: equilibrador de carga. Le asigna tu aplicación IP pública y
9:28
Speaker 2: reenvía el tráfico en K4. Para las aplicaciones web que
9:31
Speaker 2: usan HTTPS necesitas un controlador de entrada. Esto funciona en
9:35
Speaker 2: la capa 7. Entiende las URL, las rutas y los
9:37
Speaker 2: nombres de host. Puedes enrutar el tráfico a diferentes servicios
9:40
Speaker 2: en función del nombre de dominio o la ruta de
9:42
Speaker 2: la URL y una IP pública puede dar servicio a
9:44
Speaker 2: docenas de aplicaciones. AKS admite opciones de entradas administradas como
9:48
Speaker 2: Application Gateway para contenedores o puedes ejecutar la tuya como NGINX.
9:52
Speaker 2: Un error que la gente suele cometer es crear su
9:53
Speaker 2: clúster de AKS con una subred demasiado pequeña. Quizás una
9:56
Speaker 2: subred de 2816IP en total. Su función en un clúster
10:00
Speaker 2: de prueba pequeño, pero AKS reserva IPs por nodo. Un
10:02
Speaker 2: clúster de 3 nodos con 28 podría estar bien hoy,
10:04
Speaker 2: pero el mes que viene añades un grupo de nodos,
10:06
Speaker 2: tu tráfico crece y de repente no puedes escalar. Y
10:08
Speaker 2: no puedes cambiar el seed de la subred después de
10:10
Speaker 2: crear el clúster. Tendrías que reconstruir el clúster o crear
10:13
Speaker 2: un nuevo grupo de nodos en una subred diferente y
10:15
Speaker 2: migrar tus cargas de trabajo. Planifica el tamaño de subredes
10:19
Speaker 2: para crecer desde hoy. Una vez que tu aplicación esté
10:21
Speaker 2: en ejecución y sea accesible, debes bloquearlo. ¿Seguro?¿ Quién es? Entonces,¿
10:25
Speaker 2: cómo funciona realmente la seguridad en AKS? Piensa en ello
10:28
Speaker 2: como un edificio con varias capas de protección. La primera
10:30
Speaker 2: capa es la identidad y el acceso.¿ Quién entra por
10:32
Speaker 2: la puerta?¿ Conectas tu clúster a EntraID, que es el
10:35
Speaker 2: servicio de identidad de Microsoft? Antes se llamaba Azure Active Directory.¿
10:40
Speaker 2: Tu equipo inicia sesión con sus credenciales habituales sin necesidad
10:43
Speaker 2: de usar cuentas separadas? Luego, además de eso, añades Kubernetes RBAs,
10:46
Speaker 2: que es un control de acceso basado en RUN. decide
10:48
Speaker 2: quién puede ver qué, quién puede implementar pods y quién
10:50
Speaker 2: puede eliminar recursos. Un desarrollador podría acceder solo a su
10:53
Speaker 2: espacio de nombres, mientras el operador tiene acceso de lectura
10:56
Speaker 2: al clúster y el administrador control total. Puedes asignar grupos
11:00
Speaker 2: de entrada directamente a roles de Kubernetes, de modo que
11:02
Speaker 2: cuando alguien se une o abandone el equipo, actualices el
11:04
Speaker 2: grupo de entrada y los permisos se apliquen automáticamente. La
11:06
Speaker 2: recepción se encarga del acceso a todo el edificio. La
11:09
Speaker 2: seguridad de la red es de capa 2. Por defecto,
11:11
Speaker 2: el servidor de API de su clúster de AKS es
11:13
Speaker 2: accesible a internet pública. Aunque es posible restringir los rangos
11:16
Speaker 2: IP específicos, el punto de conexión sigue expuesto. Para las
11:19
Speaker 2: cargas de trabajo de producción, te recomendamos un clúster privado.
11:22
Speaker 2: De esa forma, el servidor de API obtiene una IP
11:24
Speaker 2: interna de tu red virtual, a la que solo se
11:25
Speaker 2: puede acceder a través de Azure Private Link, sin exposición
11:27
Speaker 2: pública alguna. Cualquiera que administre el clúster debe estar conectado
11:30
Speaker 2: a tu red, ya sea a través de una VPN,
11:32
Speaker 2: ExpressRoute o Jumpbox dentro de la red virtual. Luego pasamos
11:35
Speaker 2: a la seguridad de los pods, donde ocurren la mayoría
11:37
Speaker 2: de las vulnerabilidades en contenedor. La regla número uno es
11:39
Speaker 2: no ejecutar contenedores como raíz. Si un contenedor se ejecuta
11:42
Speaker 2: como raíz y un atacante accede, tendrá acceso raíz al host.
11:45
Speaker 2: Lo mismo ocurre con la escalada de privilegios. Deshabilítela. Use
11:48
Speaker 2: Azure Policy para Kubernetes para aplicar estas reglas automáticamente. Puede
11:51
Speaker 2: indicar que ningún contenedor de este espacio de nombre se
11:53
Speaker 2: puede ejecutar como raíz y la directiva bloquea cualquier implementación
11:56
Speaker 2: que infringe esa regla antes de que llegue a un nodo.
11:58
Speaker 2: Los secretos son el siguiente gran problema. Nunca almacene contraseñas
12:01
Speaker 2: claves de API ni cadenas de conexión en su código
12:03
Speaker 2: o imágenes de contenedor. La gente lo hace siempre. Codifican
12:06
Speaker 2: una contraseña de base de datos en un archivo de configuración.
12:09
Speaker 2: Crean la imagen, la suben a un registro y la
12:11
Speaker 2: contraseña queda ahí para siempre. Cualquiera con acceso al registro
12:15
Speaker 2: puede extraerla. En su lugar, use Azure Keyboard. Almacena allí
12:18
Speaker 2: sus secretos y deje que sus pods accedan a ellos
12:19
Speaker 2: mediante el controlador CSA Secrester. El pod monta el secreto
12:22
Speaker 2: como un volumen o una variable de entorno en tiempo
12:24
Speaker 2: de ejecución y el secreto nunca toca su imagen o
12:26
Speaker 2: código fuente. Por último, la supervisión. Microsoft Defender para contenedores
12:31
Speaker 2: analiza las imágenes de los contenedores en busca de vulnerabilidades
12:33
Speaker 2: conocidas y supervisa el clúster en busca de actividad sospechosa.
12:36
Speaker 2: Intentos de escala de privilegios, conexiones de red inusuales y
12:38
Speaker 2: cargas de trabajo de criptominería. No es una herramienta que
12:41
Speaker 2: se configura y se olvida, pero detecta cosas que podría
12:43
Speaker 2: pasar por alto por su cuenta. Incluso con todo eso,
12:45
Speaker 2: las cosas pueden salir mal. Veamos los errores más comunes.
12:48
Speaker 2: Errores comunes que salen mal.¿ Qué hace tropezar más a
12:51
Speaker 2: la gente? Echemos un vistazo a los sospechosos hoy. Primero,
12:53
Speaker 2: los límites de cuota de Azure. Su suscripción de Azure
12:56
Speaker 2: tiene límites sobre cuántas WCPU puede usar en una región.
12:59
Speaker 2: Y lo mismo se aplica a las IP públicas, equilibradores
13:01
Speaker 2: de carga y otros recursos. Cuando crea un clúster de AKS,
13:04
Speaker 2: este consume parte de esa cuota. Si alcanza el límite,
13:06
Speaker 2: la creación del clúster falla o el escalado deja de funcionar.
13:09
Speaker 2: La solución es sencilla, solicita un aumento de cuota a
13:11
Speaker 2: través del portal de Azure. Pero hazlo antes de necesitarlo,
13:14
Speaker 2: no con un despliegue bloqueado a las dos. Luego va
13:17
Speaker 2: el tamaño de la subred, que duele porque no se
13:19
Speaker 2: puede arreglar después. AKS reserva direcciones IP por nodo y
13:23
Speaker 2: cada nodo necesita una cierta cantidad de IP para los pods.
13:26
Speaker 2: Si tu subred es demasiado pequeña, te quedarás sin direcciones
13:28
Speaker 2: y no podrás ampliar una subred después de crear el clúster.
13:31
Speaker 2: Por lo tanto, planifique crecimiento. Si crees que necesitas 10
13:33
Speaker 2: nodos hoy, aprovisiona suficientes IP para 50. Una subred de
13:36
Speaker 2: 24 te proporciona 251 IP utilizables, lo que es un
13:39
Speaker 2: buen punto de partida para la mayoría de los clústeres.
13:41
Speaker 2: La retirada de imágenes es probablemente el error de pod
13:44
Speaker 2: más común que verás. Tu pod intenta extraer una imagen
13:46
Speaker 2: de contenedor y falla. Por lo general es un problema
13:49
Speaker 2: de autenticación. Tu clúster no puede acceder al registro de contenedor.
13:52
Speaker 2: Quizás estés usando un registro privado sin credenciales o las
13:54
Speaker 2: credenciales hayan caducado. Comprueba tus secretos de extracción, asegúrate de
13:58
Speaker 2: que la cuenta de servicio acceda al registro y verifica
13:59
Speaker 2: que el nombre de la imagen sea correcto. Rara vez
14:01
Speaker 2: se trata de un error de cubre. Otro error frecuente
14:03
Speaker 2: es el bucle bloqueo. Tu pod se inicia, corre unos segundos,
14:06
Speaker 2: se bloquea, se reinicia y se vuelve a bloquear. El
14:09
Speaker 2: instinto natural es culpar a Kubernetes, pero no lo hagas.
14:11
Speaker 2: 9 de cada 10 veces es tu aplicación, una variable
14:13
Speaker 2: de entorno mal configurada, una dependencia que falta o una
14:16
Speaker 2: cadena de conexión de base de datos que apunta al
14:18
Speaker 2: servidor equivocado. Revisa los logs del pod usando Kubernetes. El
14:21
Speaker 2: mensaje de error suele estar ahí mismo. Luego está el
14:23
Speaker 2: agotamiento de la conexión salida. Tus aplicaciones realizan muchas conexiones
14:27
Speaker 2: a servicios externos, API, bases de datos y herramientas de terceros.
14:30
Speaker 2: Cada conexión utiliza un puerto de ajuste, y cada nodo
14:33
Speaker 2: tiene un número limitado de sus puertos. Cuando se agotan
14:36
Speaker 2: las nuevas conexiones fallan silenciosamente. La aplicación parece estar en
14:38
Speaker 2: buen estado, pero no puede acceder a nada fuera de clúster.
14:40
Speaker 2: La solución es cambiar a Azure NAT Gateway, que gestiona
14:43
Speaker 2: los recuentos de conexiones altos, mucho mejor que el equilibrador
14:45
Speaker 2: de carga predeterminado, o usar tamaños de nodos más grandes
14:48
Speaker 2: que obtengan más puertos de ajuste por nodo. Todas estas
14:50
Speaker 2: piezas tienen un precio, así que vamos a desglosar lo
14:52
Speaker 2: que realmente pagarán. Costes y precios. Entonces,¿ cuánto cuesta realmente AKS?¿
14:55
Speaker 2: Me escuchas? Gran parte de tu factura viene de las
14:58
Speaker 2: máquinas virtuales de los nodos. El cómputo, el almacenamiento y
15:01
Speaker 2: las redes. Ahí es donde va el dinero duro. Un
15:03
Speaker 2: nodo de 2SV3 en el STD. Cuesta unos 70 dólares
15:06
Speaker 2: al mes. 5 nodos, 350 dólares. 10 nodos, 700 dólares.
15:11
Speaker 2: Los costes de VM suben rápido. El plano de control
15:13
Speaker 2: tiene 3 niveles de precio. El plan gratuito te ofrece
15:16
Speaker 2: el plano de control sin coste adicional, pero no hay SLA.
15:18
Speaker 2: El plan estándar cuesta unos 72 dólares al mes por
15:21
Speaker 2: cluster con un SLA del 99,95% en el servidor de API.
15:26
Speaker 2: El plan premium cuesta unos 432 dólares al mes y
15:28
Speaker 2: añade soporte a largo plazo para las versiones de Kubernetes.
15:31
Speaker 2: Para la mayoría de cargas de trabajo y producción, el
15:33
Speaker 2: estándar es el ideal. Pero puede reducir esos costes de web.
15:36
Speaker 2: Las instancias reservadas permiten compromisos de 1 o 3 años,
15:38
Speaker 2: ahorrando hasta un 72% frente al pago por uso. Si
15:42
Speaker 2: conoces tu capacidad de referencia y los nodos que siempre
15:44
Speaker 2: necesitas en ejecución, reservarlos es una obviedad. Los planes de
15:47
Speaker 2: ahorro de Azure funcionan parecido, pero te brindan más flexibilidad
15:49
Speaker 2: entre familias de máquinas virtuales. Te comprometes a un gasto
15:52
Speaker 2: por hora determinado y Azure aplica el descuento automáticamente. El
15:55
Speaker 2: ahorro puede llegar al 65%. Las máquinas spot son la
15:58
Speaker 2: opción más barata, hasta 90% menos, pero hay un truco.
16:00
Speaker 2: Azure puede reclamar esa capacidad en cualquier momento. Los nodos
16:03
Speaker 2: se expulsan y los spots se reprograman. Eso funciona bien
16:06
Speaker 2: para trabajos por lotes, ejecutores ICD o cargas sin estado,
16:09
Speaker 2: no tanto para la AP de producción. La optimización de
16:12
Speaker 2: costes no se trata de cuentos. Ajusta el tamaño de
16:14
Speaker 2: los nodos. No provisiones una OVM de 16 núcleos si
16:16
Speaker 2: tus spots solo usan 2. Usa el escalador automático de
16:18
Speaker 2: clústeres para no pagar por nodos inactivos cuando el tráfico
16:21
Speaker 2: es Para cargas de trabajo con baja CPU, considera las
16:24
Speaker 2: máquinas serie B. Son ampliables y mucho más económicas que
16:26
Speaker 2: la serie D. No olvides el almacenamiento y la transferencia.
16:29
Speaker 2: Los volúmenes persistentes en el... Azure Disk es rápido, pero caro.
16:33
Speaker 2: Azure Files es más barato, pero más lento. Elija según
16:35
Speaker 2: las necesidades de rendimiento de su carga. La salida de datos,
16:38
Speaker 2: tráfico que deja Azure, también cuesta dinero. Mantenga su tráfico
16:42
Speaker 2: dentro de la misma región siempre que sea posible. Entonces,¿
16:44
Speaker 2: cuándo tiene sentido realmente AKS? Hablemos de orientación del mundo real.¿
16:47
Speaker 2: Dónde debería usar AKS? AKS destaca por su arquitectura de microservicios.
16:51
Speaker 2: Tiene varios servicios independientes que necesitan escalarse por separado. El
16:54
Speaker 2: frontend podría necesitar 10 réplicas durante las horas punta, mientras
16:57
Speaker 2: que el backend solo necesita 3. AKS se encarga de
16:59
Speaker 2: eso de forma natural. Cada servicio escala de forma independiente
17:02
Speaker 2: en función de su propio tráfico. La alta disponibilidad es
17:05
Speaker 2: otro argumento de peso. AKS distribuye sus pods en varios nodos.
17:08
Speaker 2: Si un nodo falla, los pods se reprograman en nodos
17:10
Speaker 2: en buen estado. Si usa zonas de disponibilidad, su cluster
17:13
Speaker 2: puede sobrevivir a una caída completa del centro de datos.
17:15
Speaker 2: Para aplicaciones que necesitan estar activas las 24 horas del día,
17:17
Speaker 2: los CDDs lo hacen. La integración de CICD es donde
17:20
Speaker 2: AKS realmente vale la pena. Creas tu imagen de contenedor,
17:23
Speaker 2: la envías a un registro y AKS implementa la nueva
17:25
Speaker 2: versión con una actualización gradual. Pero tiene actividad. Si algo
17:28
Speaker 2: sale mal, reviertes. Sin SSH manual en servidores, sin copiar
17:31
Speaker 2: y pegar archivos. La canalización se encarga de todo. Pero
17:34
Speaker 2: AKS no siempre es la respuesta correcta. Si tienes una
17:36
Speaker 2: aplicación monolítica simple ejecutándose en una sola máquina virtual, AKS
17:39
Speaker 2: agrega complejidad sin mucho beneficio. Estarías administrando Kubernetes solo por administrarlo.
17:44
Speaker 2: A veces una máquina virtual, un App Service o incluso
17:46
Speaker 2: Azure Functions son la opción más sencilla y barata. Si
17:48
Speaker 2: recién estás comenzando, usa a nivel gratuito. Crea un clúster,
17:51
Speaker 2: implementa una aplicación de prueba, rompe cosas, corrígelas. Aprende los
17:54
Speaker 2: conceptos sin preocuparte por el costo. Cuando estés listo para producción,
17:57
Speaker 2: pasa a la versión stand. Vamos a unirlo todo. Esto
18:00
Speaker 2: es lo que debes recordar. AKS se encarga de cosas importantes.
18:03
Speaker 2: Microsoft administra el plano de control, que es el cerebro
18:05
Speaker 2: del clúster. Tú eliges el tamaño y la cantidad de
18:07
Speaker 2: nodos y máquinas virtuales, mientras AKS gestiona los grupos y
18:10
Speaker 2: el escalado. Para las redes, los pods se comunican entre
18:12
Speaker 2: sí con el mundo exterior a través de Azure CNI
18:15
Speaker 2: y AKS se integra con él para que todo funcione.
18:17
Speaker 2: Las herramientas de seguridad están integradas, identidad, aislamiento de red
18:21
Speaker 2: y pods. Solo pagas por el procesamiento, los nodos, el
18:24
Speaker 2: almacenamiento y las redes. El plan de control en sí
18:26
Speaker 2: es gratuito en el nivel grado. Solo necesitas el nivel
18:28
Speaker 2: estándar o premium si quieres el SLA o el soporte
18:30
Speaker 2: a largo plazo. Siguiente paso es crear un clúster de
18:33
Speaker 2: AKS gratuito en Azure Portal. Implementa una aplicación de prueba
18:36
Speaker 2: sencilla en IGNX o un contenedor Hello World. Mira cómo
18:39
Speaker 2: funciona Descompón la Herrera. Esta experiencia práctica supera cualquier tutorial.
18:43
Speaker 2: Si este episodio te ayudó, suscríbete para más explicaciones sencillas
18:46
Speaker 2: sobre Azure compártelo con alguien que inicie su recorrido en
18:48
Speaker 2: la nube. Te lo agradeceré más de nada.