Siéntete en la libertad de divulgar nuestra web y códigos con otro, ayúdanos a hacer crecer esta comunidad.
Solución:
Kubernetes se desarrolla casi desde cero para extender el kernel del contenedor Docker para convertirlo en una plataforma. El desarrollo de Kubernetes ha adoptado un enfoque de abajo hacia arriba. Tiene una buena optimización para especificar los requisitos de recursos por contenedor/vaina, pero carece de un programador global eficaz que pueda dividir los recursos en una agrupación lógica. El diseño de Kubernetes permite que varios programadores se ejecuten en el clúster. Cada programador administra los recursos dentro de sus propios pods. Sin embargo, el clúster de Kubernetes puede sufrir inestabilidad cuando la aplicación exige más recursos de los que pueden manejar los sistemas físicos. Funciona mejor en la capacidad de la infraestructura que supera las demandas de la aplicación. El programador de Kubernetes intentará llenar los nodos inactivos con solicitudes de aplicaciones entrantes y terminará los contenedores de baja prioridad y de inanición para mejorar la utilización de recursos. Los contenedores de Kubernetes pueden integrarse con un sistema de almacenamiento externo como S3 para brindar resiliencia a los datos. El marco de Kubernetes usa etcd para almacenar datos de clúster. Los nodos de clúster de Etcd y Hadoop Namenode son puntos únicos de fallas en Kubernetes o la plataforma Hadoop. Etcd puede tener más réplicas que Namenode, por lo tanto, desde el punto de vista de la confiabilidad, parece favorecer a Kubernetes en teoría. Sin embargo, la seguridad de Kubernetes está abierta de forma predeterminada, a menos que los RBAC se definan con un enlace de roles detallado. El contexto de seguridad está configurado correctamente para los pods. Si se omite, el grupo principal del pod se establecerá de forma predeterminada en root, lo que puede ser problemático para los administradores del sistema que intentan proteger la infraestructura.
Apache Hadoop YARN se desarrolló para ejecutar procesos java aislados para procesar grandes cargas de trabajo de datos y luego se mejoró para admitir contenedores Docker. YARN proporciona administración de recursos a nivel global, como colas de capacidad para particionar recursos físicos en unidades lógicas. A cada unidad de negocio se le puede asignar un porcentaje de los recursos del clúster. El sistema de intercambio de recursos de capacidad está diseñado para garantizar la disponibilidad de recursos para la prioridad empresarial en lugar de exprimir todos los recursos físicos disponibles. YARN obtiene más puntos en seguridad. Hay más funciones de seguridad en Kerberos, control de acceso para contenedores privilegiados/no privilegiados, imágenes acoplables confiables y restricciones de políticas de ubicación. La mayoría de los dispositivos de seguridad relacionados con la ventana acoplable están cerrados de forma predeterminada, y el administrador del sistema debe activar manualmente los indicadores para otorgar más poder a los contenedores. Las grandes empresas tienden a ejecutar Hadoop más que Kubernetes porque asegurar el sistema cuesta menos. Hay más motores SQL distribuidos creados sobre YARN, incluidos Hive, Impala, SparkSQL e IBM BigSQL. Las opciones de la base de datos hacen de YARN una opción atractiva debido a la capacidad de ejecutar el procesamiento de transacciones en línea en contenedores y el procesamiento analítico en línea utilizando la carga de trabajo por lotes. Las cadenas de herramientas de Hadoop Developer pueden ser abrumadoras. Mapreduce, Hive, Pig, Spark, etc., cada uno tiene su propio estilo de desarrollo. La experiencia del usuario es inconsistente y lleva un tiempo aprenderlas todas. Kubernetes se siente menos obstructivo en comparación porque solo implementa contenedores docker. Con la introducción de los servicios YARN para ejecutar la carga de trabajo del contenedor Docker, YARN puede parecer menos prolijo que Kubernetes.
Si su plan es externalizar las operaciones de TI a la nube pública, elija Kubernetes. Si su plan es construir nubes privadas/híbridas/múltiples, elija Apache YARN.
Si bien esta pregunta y respuesta no es exactamente lo que está preguntando, toca varios de los mismos puntos.
Lo último que vi, Yarn era solo un mecanismo para compartir recursos, mientras que Kubernetes es todo un plataformaque abarca ConfigMaps, administración de entornos declarativos, administración de secretos, montajes de volumen, una API muy bien diseñada para interactuar con todas esas cosas, control de acceso basado en roles y Kubernetes se usa ampliamente, lo que significa que uno puede encontrar muy fácilmente ambos candidatos para alquiler y herramientas para comprar.
Una publicación de blog que encontré citaba una tesis de maestría que describe algunas de las compensaciones fascinantes entre la visión del mundo de los diferentes programadores. Son muchas palabras, por lo que si está buscando una respuesta tl; dr, ese enlace puede no serlo, pero si está buscando una investigación real sobre el tema, parece sólido.
Sección de Reseñas y Valoraciones
Si estás contento con lo expuesto, tienes la opción de dejar una noticia acerca de qué te ha impresionado de este enunciado.