Control Plane Machine Sets e Infra node management | Analisis Ask and a Expert

Discusión sobre la administración de nodos de infraestructura

• Existe interés en comprender cómo configurar y utilizar los nodos de infraestructura en OpenShift.
• Las consultas suelen dividirse entre configuración, uso y permisos de ejecución en estos nodos.
• Se plantea la idea de abordar conceptos básicos para los usuarios.
• Es importante recordar los fundamentos antes de avanzar en aspectos más complejos del sistema.

«A veces olvidamos los conceptos básicos, pero es fundamental tener una sólida base de fundamentos antes de avanzar.»

Validación de la preparación del clúster para producción

• La preparación del clúster para producción varía según los requisitos de cada usuario.
• Algunos consideran crítico el registro de logs por cumplimiento normativo, mientras que para otros es menos relevante.
• Se destaca la importancia de verificar la preparación del clúster para asegurar su idoneidad.

«¿Cómo validar que un clúster está listo para la producción? Depende de tus necesidades y requisitos.»

Comunicación con la audiencia y fomento de preguntas

• Se enfatiza la disposición a responder preguntas de la audiencia en tiempo real.
• Se anima a los espectadores a plantear cualquier tema que les interese.
• Se invita a contactar al presentador a través de múltiples plataformas, mostrando disponibilidad para el diálogo.

«Estamos aquí para responder tus preguntas, ¡no dudes en ponerte en contacto con nosotros!»

Acercamiento a la simplicidad en la gestión de nodos de máquina

• Se menciona un interés en simplificar la gestión de «machine sets» en Kubernetes.
• Se espera que futuras actualizaciones en GitOps faciliten la gestión de este aspecto.
• Se destaca la importancia de estar al tanto de las mejoras tecnológicas en el ámbito de la gestión de nodos.

«Creo que van a simplificar el proceso, así que será interesante ver cómo se desarrolla todo.»

Control Planes y Actualizaciones en Canales Estables

• Las actualizaciones en el canal estable de la versión 4.11 a 4.12 aún no están disponibles.
• Puede haber varias razones para esto, como bloqueos en las actualizaciones identificados en el repositorio Cincinnati Graph Data.
• En los entornos modernos de OpenShift, se utiliza promql dentro del clúster para determinar si está afectado por bloqueos de actualizaciones.
• Si su clúster se desplegó inicialmente en 4.1 y se ha actualizado a lo largo de los años hasta alcanzar la versión 4.11 o 4.12, es posible que falte un indicador específico.
• Este escenario requiere que los administradores verifiquen y decidan si una actualización particular es relevante para su clúster.

«Si su clúster fue desplegado en 4.1 y ha sido actualizado en los años hasta alcanzar la versión 4.11 o 4.12, existe la posibilidad de que falte este indicador particular.»

Problema de etiquetas cambiadas

• Uno de los problemas centrales fue que cuando cambiaron las etiquetas de «master» a «control plane», no lo detectaron a tiempo. Esto condujo a intentar implementar máquinas en lugares incorrectos, causando problemas con la configuración de Calico.

«Así que, las máquinas que están tratando de desplegar, están tratando de desplegar en ciertas cosas pensaron que era Calico al principio, pero se dieron cuenta de que Calico estaba funcionando y luego cuando vieron los registros, como ‘oh no, está tratando de alcanzar una etiqueta que no existe'».

Impacto de actualizaciones y retrocesos

• Las actualizaciones y retrocesos en cualquier plataforma pueden ser complicados, como se evidenció en este caso. La falta de un procedimiento formal de retroceso en Kubernetes añade complejidad a la gestión de cambios y actualizaciones, lo que subraya la importancia de una planificación cuidadosa.

«Se sabe que las actualizaciones son difíciles en cualquier plataforma y tratar de volver atrás y degradar no siempre es tan sencillo como ‘hagámoslo'».

Equipos de Operaciones y Configuraciones Incorrectas

• El equipo original de Operaciones ya no está presente debido a la rotación natural del personal.
• El equipo actual de Operaciones carecía de conocimiento sobre la configuración incorrecta.
• La falta de conocimiento llevó a una discrepancia entre los entornos de producción y prueba.

«La falta de conocimiento llevó a una discrepancia entre los entornos de producción y prueba.»

Importancia de la Transparencia y el Entendimiento de la Configuración

• Es fundamental comprender completamente la configuración de los clústeres.
• La transparencia permite aprender de los errores y mejorar los procesos de recuperación ante desastres.
• Los clústeres deben ser recreables para garantizar una rápida restauración en situaciones críticas.

«Clusters should be disposable, and we should be able to recreate them one for one not just for disaster recovery but for things like this.»

Gestión del Plano de Control en Openshift

• La rigurosa disciplina en las operaciones de cambio en los clústeres garantiza la uniformidad y minimiza los errores.
• Los cambios en la gestión de clústeres con la implementación de control planes alojados afectan las prácticas actuales.
• La separación de los servicios del plano de control en diferentes clústeres modifica las estrategias de recuperación ante desastres.

«La rigurosa disciplina en las operaciones de cambio en los clústeres garantiza la uniformidad y minimiza los errores.»

Creación de Playbooks con Ansible mediante Machine Learning

• Se menciona que Ansible es una herramienta que permite crear playbooks rápidamente a través de un modelo de aprendizaje automático.
• El procedimiento implica crear un nuevo playbook, darle un nombre, y crear una máquina virtual en Azure para obtener el playbook en formato YAML necesario.
• Después de que el modelo de machine learning genere el playbook, el usuario lo revisa y realiza pasos como crear una nueva red en Azure y conectar la máquina virtual.

La herramienta de Ansible facilita la creación de playbooks de forma ágil a través de la incorporación de un modelo de aprendizaje automático.

Limitaciones de Comunicación entre Pods al usar VXLAN en OpenShift SDN

• Cuando se utiliza VXLAN en OpenShift SDN, la comunicación entre pods puede verse limitada a aproximadamente un gigabit por segundo debido a la encapsulación del tráfico y otros factores internos.
• A pesar de esta limitación, se menciona que hay pruebas de rendimiento que muestran velocidades superiores a un gigabit, lo que sugiere que la información proporcionada puede estar desactualizada.
• Se sugieren posibles soluciones, como cambiar a OVAN Kubernetes, utilizar una red secundaria o explorar opciones de SDN de terceros.

La documentación indica que al usar VXLAN en OpenShift SDN, la velocidad de comunicación entre pods puede verse restringida, pero podrían existir opciones para superar esta limitación.

Administración de conjunto de máquinas del plano de control

• En un conjunto de máquinas tradicional, una modificación solo afecta a las nuevas máquinas desplegadas, no retroactivamente a las existentes.
• Al modificar un conjunto de máquinas existente, la configuración solo cambia cuando se despliega una nueva máquina con la nueva configuración.
• Si se modifica el tipo de instancia de una máquina, la modificación no surte efecto hasta que se despliega una nueva máquina con el nuevo tipo de instancia.

Lo que creo que sucede es que, en un conjunto tradicional, una modificación solo afecta a las nuevas máquinas, no a las existentes hasta que se despliega una nueva.

Estrategia de implementación de actualización

• Con la estrategia de actualización progresiva, las máquinas del plano de control se ajustan automáticamente a la configuración nueva.
• Al utilizar la estrategia de actualización progresiva, se garantiza que las máquinas del plano de control se alineen con la configuración establecida.

Creo que con la estrategia de actualización progresiva, las máquinas del plano de control se ajustan para coincidir con la configuración existente.

Configuración de la máquina del plano de control

• Se encuentra una instancia de conjunto de máquinas de control con tres réplicas para tres nodos de control.
• Se identifica una estrategia de actualización de tipo «rolling update» que probablemente desencadene automáticamente un red despliegue ante cambios.
• Se definen los dominios de falla en AWS, donde actualmente solo se utilizaba la zona US East 2C.

«So one three replicas of course you know we want to have three control plane.»

Gestión de nodos infra

• La falta de identificadores de subred puede causar fallos en la configuración de la red.
• Al no encontrar los identificadores de subred, la configuración de red no funcionará correctamente.

No se encontraron identificadores de subred, lo que explica el problema.

Protección del plano de control

• Aunque ocurran cambios o fallos en un nodo de control, es fundamental mantener los tres nodos de control para mantener la estabilidad del sistema.
• Incluso tras fallas en la configuración, los nodos de control actuales no se ven afectados, garantizando la continuidad del plano de control.

La protección del plano de control es esencial para mantener la estabilidad del sistema incluso frente a cambios o fallos.

Cambios automáticos del plano de control

• En caso de fallo de un nodo, el sistema automática y proactivamente lo reemplaza y reprovisiona para asegurar la continuidad.
• Los controles automatizados permiten reemplazar nodos con fallas sin intervención manual, evitando interrupciones en el plano de control.

La automatización reemplaza los nodos con fallas para mantener la continuidad del sistema sin necesidad de intervención manual.

Gestión de nodos de infraestructura

• Con la versión 4.12, se tiene soporte técnico preliminar para zonas y vSphere, pero no está ampliamente respaldado por OpenShift.
• No se generan reglas de afinidad o anti-afinidad para las máquinas virtuales OpenShift en vSphere a través del provisionador de API de máquinas.

«Con la versión 4.12, tenemos soporte técnico preliminar para zonas y vSphere, pero no está respaldado por OpenShift.»

Mejoras en la administración de infraestructura del nodo

• Los nodos de infraestructura eran obligatorios en OpenShift 3 pero se volvieron opcionales en OpenShift 4.
• Los nodos de infraestructura permiten alojar servicios como los de métricas y registro, liberando recursos en los nodos de trabajadores.

«Los nodos de infraestructura eran obligatorios en OpenShift 3 pero se volvieron opcionales en OpenShift 4.»

Gestión de nodos de infraestructura

• Se busca desplegar componentes como métricas o monitoreo en nodos de infraestructura en lugar de los nodos de cálculo.

El objetivo es crear nodos de infraestructura para la implementación de cargas de trabajo.

• Las cargas de trabajo de infraestructura no requieren suscripciones de trabajador y pueden incluir el enrutador Ingress, el registro integrado, Quay, entre otros.

Las cargas de trabajo de infraestructura no necesitan suscripciones de trabajador y pueden incluir el registro integrado y Quay.

• Algunos componentes, como los controladores CSI, se consideran cargas de trabajo de infraestructura, mientras que otros de terceros no.

Algunas cosas como el controlador CSI se consideran cargas de trabajo de infraestructura, pero por ejemplo, un producto de registro de un tercero no.

Módulos de infraestructura permitidos

• Ejemplos de software de terceros que califican como cargas de trabajo de infraestructura incluyen agentes de monitoreo y controladores CSI.

Agentes de monitoreo de terceros, como el agente de datadog, pueden desplegarse en nodos de infraestructura sin afectar las excepciones de suscripción.

• Los controladores de Kubernetes, software personalizado o de terceros, como NetApp Trident, pueden ser considerados cargas de trabajo de infraestructura.

Los controladores de Kubernetes, software personalizado o de terceros como NetApp Trident, pueden ser calificados como cargas de trabajo de infraestructura.

Gestión de nodos de infraestructura

• La suscripción parece ser mensual, pero hay dudas al respecto.
• Se menciona la importancia de la infraestructura normal para Rel y otros informes.
• La frecuencia de actualización de la utilización de suscripciones y derechos no está clara.
• Se discute sobre la posibilidad de trabajar con clústeres desconectados.
• Se sugiere contactar al equipo de cuentas para entender mejor el tema de la capacidad de escalado.

«La frecuencia de actualización de la utilización de suscripciones y derechos no está clara.»

Entitlements en Instalaciones de Infraestructura

• Al desplegar clústeres de OpenShift en hardware y usar virtualización de OpenShift, se discute cómo se manejan los entitlements.
• Si el clúster físico solo ejecuta clústeres de OpenShift alojados, no es necesario otorgarles entitlements.
• Sin embargo, se debe entitular si se ejecutan otras cargas de trabajo, como VM no relacionadas con OpenShift.

«Si el clúster físico solo ejecuta clústeres de OpenShift alojados, no es necesario otorgarles entitlements.»

Uso de Taints y Tolerations en Nodos de Infraestructura

• Al alojar cargas de trabajo de aplicaciones en un nodo de infraestructura, se detalla cómo se deben gestionar los taints y tolerations.
• Se menciona cómo aplicar una taint para excluir otras cargas de trabajo en un nodo específico.

«Al alojar cargas de trabajo de aplicaciones en un nodo de infraestructura, se detalla cómo se deben gestionar los taints y tolerations.»

Gestión de nodos de infraestructura

• Cambiar cualquier instancia de la palabra «trabajador» a «infra».
• Los nodos de infraestructura requieren configuraciones específicas y etiquetas adecuadas.
• Es vital mantener la seguridad de los datos y la configuración de seguridad de los grupos.
• Es recomendable tener un pool de configuración de máquinas específico para nodos de infraestructura.

Cambia básicamente cualquier instancia de la palabra trabajador a infra.

Configuración del proveedor de máquinas AWS

• La configuración de las etiquetas es esencial para identificar y gestionar adecuadamente las máquinas.
• Se debe revisar detenidamente la configuración de seguridad y las etiquetas.
• Es importante mantener la consistencia en las etiquetas de las instancias.

Todas las etiquetas están bien.

Ventajas de tener un pool de configuración de máquinas separado para nodos de infraestructura

• Los updates se aplican fácilmente al nivel del pool de configuración de máquinas.
• Permite administrar de manera eficiente las actualizaciones de los nodos de infraestructura.
• La personalización de configuraciones específicas para estos nodos es más sencilla con pools separados.

Los updates se aplican en el nivel del pool de configuración de máquinas.

Escalando nodos de infraestructura de forma independiente

• Escalar nodos de infraestructura independientemente permite una gestión más ágil y eficiente.
• La capacidad de escalar los nodos según las necesidades específicas brinda flexibilidad en el despliegue de infraestructuras.
• Escalar los nodos de infraestructura de manera independiente optimiza el rendimiento del sistema.

Sin duda, la capacidad de escalar los nodos es impresionante.

Consideraciones al asignar tipos de nodos de infraestructura

• La posibilidad de asignar tipos de nodos de infraestructura específicos según requisitos del sistema es ventajosa.
• Personalizar nodos de infraestructura para aplicaciones con necesidades específicas mejora el rendimiento general del sistema.
• No es obligatorio tener un solo tipo de nodo de infraestructura, permitiendo adaptabilidad a diferentes cargas de trabajo.

Es perfectamente válido tener más de un tipo de nodo de infraestructura.

Gestión de nodos de infraestructura

• Puedes modificar los controladores de ingreso para asegurarte de que solo aterricen en un nodo específico usando un selector de nodo y añadiendo potenciales taints adicionales para restringir su despliegue.
• Los taints como «infra=reserved» y «applicationX.Ingress.don’tuse» pueden ser utilizados para diferenciar entre tipos de nodos, como los dedicados a ingreso o a registro (logging).
• Al configurar tolerations y selectores de nodos para diferentes servicios, se pueden asignar específicamente cargas de trabajo a nodos especializados.

«Puedes incluso agregar un taint adicional, si así lo deseas, para mantener otras cosas lejos de ahí».

Nodo de Infraestructura y Taints

• Se puede etiquetar un nodo de infraestructura con «infra=» y luego un valor específico como «logging» o «Ingress» para categorizarlo.
• Los taints como «infra=reserved» o «infra=» junto con tolerations y selectores de nodo permiten una gestión detallada y adaptada a las necesidades de una infraestructura compleja.
• Combinar diferentes taints y tolerations es útil para controlar qué cargas de trabajo van a cuales nodos.

«Both of them work equally well, it’s entirely based on how you choose to manage your tags and everything.»

Gestión de nodos de infraestructura

• Si un Pod sin tolerancia sigue presente después de 6,000 segundos, se eliminará forzosamente del nodo.
• Es crucial verificar y corregir las tolerancias y selectores de nodos para garantizar que los Pods se programen correctamente.

Después de 6,000 segundos si el Pod que no tiene tolerancia persiste, será eliminado forzosamente del nodo.

Control de Operadores de Cluster

• La gestión de cosas como Ingress en OpenShift es diferente, ya que se administran a través de los operadores de cluster.
• Los operadores de cluster permiten controlar y gestionar distintos elementos en OpenShift.

«La gestión de coas como Ingress en OpenShift es diferente, ya que se administran a través de los operadores de cluster.»

Repositorios de GitHub como Recursos de Información

• Los repositorios de GitHub son una fuente interesante de información, ya que los ingenieros suelen incluir una gran cantidad de detalles y guías de desarrollo.
• Es importante tener cuidado, ya que a veces pueden contener elementos no compatibles o no soportados.
• Revisar los repositorios de GitHub de los operadores puede proporcionar una gran cantidad de información sobre cada uno de ellos.

Estos repositorios de GitHub son una fuente interesante de información, pero es crucial estar atento a las posibles características no compatibles que puedan contener.