Kubernetes frente a CloudFoundry [cerrado]

La próxima versión de CloudFoundry / Diego ofrecerá soporte nativo para contenedores Docker que serán orquestados en múltiples hosts [ enlace ]. Esto suena muy similar a Kubernetes.

Por supuesto, el problema que Kubernetes está tratando de resolver es más genérico, donde CloudFoundry se centra más en el desarrollo de aplicaciones. Sin embargo, para mí parece que ambos se dirigen en una dirección similar y CloudFoundry está agregando muchas más funciones además de la orquestación simple.

Entonces, me pregunto acerca de los casos de uso en los que Kubernetes agregaría más valor que CloudFoundry.

Como confirmador de CloudFoundry (pasado) y Kubernetes (presente), probablemente esté calificado de manera única para responder a este.

Similar a PaaS

Me gusta llamar a CloudFoundry una "Aplicación PaaS" ya Kubernetes un "Container PaaS", pero la distinción es bastante sutil y fluida, dado que ambos proyectos cambian con el tiempo para competir en los mismos mercados.

La distinción entre los dos es que CF tiene una capa de ensayo que toma una aplicación de usuario (de 12 factores) (por ejemplo, jar o gem) y un paquete de construcción estilo Heroku (por ejemplo, Java + Tomcat o Ruby) y produce una gota (análoga a una Imagen de Docker). CF no expone la interfaz de contenedorización al usuario, pero Kubernetes sí.

Audiencia

La audiencia principal de CloudFoundry son los desarrolladores de aplicaciones empresariales que desean implementar aplicaciones sin estado de 12 factores utilizando paquetes de compilación estilo Heroku.

La audiencia de Kubernetes es un poco más amplia, e incluye tanto a los desarrolladores de aplicaciones sin estado como a los de servicios con estado que proporcionan sus propios contenedores.

Esta distinción podría cambiar en el futuro:

• CloudFoundry podría comenzar a aceptar imágenes de Docker ( Lattice acepta imágenes de Docker ).
• Kubernetes podría agregar una capa de generación de imágenes ( OpenShift hace algo como esto ).

Comparación de funciones

A medida que ambos proyectos maduran y compiten, sus similitudes y diferencias cambiarán. Así que tome la siguiente comparación de características con un grano de sal.

Tanto CF como K8 comparten muchas características similares, como contenedorización, espacio de nombres, autenticación,

Ventajas competitivas de Kubernetes:

• Agrupe y escale pods de contenedores que comparten una pila de red, en lugar de escalar de forma independiente
• Trae tu propio contenedor
• Capa de persistencia con estado
• Comunidad OSS más grande y activa
• Arquitectura más extensible con componentes reemplazables y complementos de terceros
• GUI web gratuito

Ventajas competitivas de CloudFoundry:

• Autenticación madura, agrupación de usuarios y compatibilidad con múltiples inquilinos [x]
• Trae tu propia aplicación
• Balanceador de carga incluido
• Implementado, escalado y mantenido vivo por BOSH [x]
• Agregación robusta de registros y métricas [x]
• GUI web empresarial [x]

[x] Estas funciones no son parte de Diego ni están incluidas en Lattice.

Despliegue

Una de las ventajas competitivas de CloudFoundry es que tiene un motor de implementación maduro, BOSH, que permite funciones como el escalado, la resurrección y el monitoreo de los componentes centrales de CF. BOSH también admite muchas capas de IaaS con una abstracción de proveedor de nube conectable. Desafortunadamente, la curva de aprendizaje de BOSH y la gestión de la configuración de implementación son una pesadilla. (Como confirmador de BOSH, creo que puedo decir esto con precisión).

La abstracción de implementación de Kubernetes aún está en su infancia. Hay varios entornos de destino disponibles en el repositorio principal, pero no todos funcionan, están bien probados o son compatibles con los desarrolladores principales. Esto es principalmente una cuestión de madurez. Se podría esperar que esto mejore con el tiempo y aumente la abstracción. Por ejemplo, Kubernetes en DCOS permite desplegar Kubernetes a un existente DCOS clúster con un único comando.

Contexto histórico

Diego es una reescritura del Droplet Execution Agent de CF. Se desarrolló originalmente antes de que se anunciara Kubernetes y ha adquirido más funciones a medida que evoluciona el panorama competitivo. Su objetivo original era generar gotas (aplicación de usuario + paquete de compilación CF) y ejecutarlas en contenedores Warden (renombrado Garden cuando se reescribe en Go). Desde su inicio, también se ha vuelto a empaquetar como Lattice , que es algo así como CloudFoundry-lite (aunque ese nombre fue tomado por un proyecto existente). Por esa razón, Lattice es algo parecido a un juguete, ya que ha reducido deliberadamente la audiencia y el alcance de los usuarios, faltando explícitamente características que lo harían "listo para la empresa". Características que CF ya ofrece. Esto se debe en parte a que Lattice se usa para probar los componentes principales, sin algunos de los gastos generales del CF más complejo, pero también puede usar Lattice en entornos internos de alta confianza donde la seguridad y la tenencia múltiple no son una preocupación tan grande. .

También vale la pena mencionar que CloudFoundry y Warden (su motor de contenedores) también son anteriores a Docker, por un par de años.

Kubernetes, por otro lado, es un proyecto relativamente nuevo que fue desarrollado por Google basado en años de uso de contenedores con BORG y Omega. Kubernetes podría considerarse como una orquestación de contenedores de tercera generación en Google, de la misma manera que Diego es una orquestación de contenedores de tercera generación en Pivotal / VMware (v1 escrito en VMware; v2 en VMware con la ayuda de Pivotal Labs; v3 en Pivotal después de que asumió el proyecto) .

Cloud Foundry es una gran herramienta asumiendo que está dispuesto a trabajar siempre dentro de las limitaciones de la oferta, ya que es muy obstinado / prescrito. La interfaz de usuario web es genial para mirar el primer día, pero rara vez se usa después de comenzar a trabajar con el cliente y haber configurado su canal de CI / CD. Descubrí que Cloud Foundry es excelente hasta que surgen casos de uso que no son fácilmente compatibles con Cloud Foundry. La entrega de estos casos de uso puede retrasar los proyectos mientras intenta resolver esos problemas, como resultado, pierde visibilidad de la infraestructura y los beneficios de soporte de esos componentes que luego se ejecutan principalmente fuera de Cloud Foundry (piense en múltiples bases de datos, kafka, hadoop, cassandra , etc.) Sospecho que con el tiempo, el impulso que rodea a Docker y la inflexibilidad de Cloud Foundry llevarán a los usuarios a Kubernetes, Mesos o Docker Swarm / Datacenter. Es posible que Cloud Foundry alcance estos tres, pero parece poco probable debido a la popularidad de estos proyectos de código abierto.

Es difícil responder por qué una empresa fabricaría un producto que es sustancialmente similar a otro producto. Hay muchas razones. Tal vez ya hayan comenzado a usarlo y hayan invertido en él. Tal vez ellos (CF) piensan que Kubernetes está mal hecho o está obteniendo mal la API / el modelo / los detalles. Tal vez piensen que pueden moverse más rápidamente si controlan todo el producto en lugar de contribuir.

Por supuesto, digo esto como desarrollador de Kubernetes: uno podría hacer las mismas preguntas de Kubernetes vs Mesos, Amazon ECS vs Kubernetes o Docker Swarm vs Kubernetes.

Espero que con el tiempo, todos estemos en la misma dirección y podamos colaborar más y dedicar menos tiempo a reinventar el trabajo de los demás.

En cuanto a Kubernetes, la atención se centra en los desarrolladores de aplicaciones: primitivas simples y potentes que le permiten crear e implementar aplicaciones a escala muy rápidamente. Nos apoyamos en nuestra experiencia (bueno, la de Google) con tecnologías similares para trazar nuestro rumbo. Otras personas tendrán diferentes experiencias u opiniones.

Una diferencia significativa, en mi opinión, es el enfoque que están adoptando:

CF crea el tiempo de ejecución a partir de 3 componentes automáticamente: binario de aplicación proporcionado por el usuario, paquete de compilación que contiene el middleware necesario para ejecutar la aplicación y una imagen del sistema operativo (una célula madre). El usuario de CF (un desarrollador) tiene que proporcionar sólo el binario de la aplicación (por ejemplo, un archivo jar ejecutable). El CF se encarga del resto, es decir, empaquetar y ejecutar la aplicación.

Kubernetes espera de un desarrollador imágenes de Docker que contengan middleware y SO ya integrados y listos para ejecutarse. Para eso, el "manifiesto de implementación" de Kubernetes (por ejemplo, un gráfico de Helm) describe no solo una aplicación o servicio, sino todos los [micro] servicios que componen su solución en tiempo de ejecución. Envía una descripción declarativa única de su tiempo de ejecución y Kubernetes se encarga de que el estado del tiempo de ejecución real coincida con la descripción proporcionada.

Por lo tanto, el enfoque de CF le permite abordar casos de uso como "reemplazar un sistema operativo con una falla de seguridad parcheada en toda su nube sin tiempo de inactividad para sus servicios". Pero también se centra en la implementación de servicio por servicio en lugar de una descripción declarativa de un tiempo de ejecución "ideal" de destino de su sistema.

Cloud Foundry es un sistema de computación en la nube de plataforma como servicio de código abierto. Cloud Foundry permite implementar proyectos en diferentes espacios y también vincula cualquier servicio en la nube a su aplicación.

Kubernete es más una herramienta de ornamentación para contenedores (pods) que automatiza la implementación, el escalado y la gestión de aplicaciones en contenedores. Utiliza el término vainas para definir contenedor o grupo de contenedores.

Cualquier implementación de Kubernetes necesita al menos dos recursos:

1) deployment.yaml: este recurso define qué versión de imagen necesita recoger de su registro de contenedores, conjuntos de réplicas (réplicas de pod), estrategia de despliegue, escalado y sondeos, etc.

2) service.yaml: Es una interfaz entre sus pods internos y el mundo exterior, todo el tráfico externo escuchará el puerto definido en este recurso desde donde distribuye la carga a los pods internos.

Otro recurso más es el ingreso que proporcionan los kubernetes que administra el acceso externo a los servicios en un clúster, generalmente http. A través de Ingress, puede proporcionar equilibrio de carga, terminación SSL y alojamiento virtual basado en nombres.

Más sobre kubernetes puede encontrar a continuación: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Diferencia entre pcf y kubernetes

                                PCF

(abstracción de plataforma a nivel de aplicación) • Pivotal Cloud Foundry es una abstracción de alto nivel del desarrollo de aplicaciones nativas de la nube.

• Tenemos la abstracción de la plataforma a nivel de la aplicación, construyendo e implementando una aplicación completamente configurada

• PCF es un ejemplo de una “aplicación” PaaS (también llamada el tiempo de ejecución de aplicaciones de Cloud Foundry)

• El desarrollador mantiene la aplicación en el futuro

• Ideal para nuevas aplicaciones, aplicaciones nativas de la nube. Para equipos que trabajan con ciclos de vida cortos y lanzamientos frecuentes, PCF ofrece un producto excelente.

                       Kubernetes 

(abstracción de la plataforma a nivel de contenedor) • Kubernetes es un programador u orquestador de contenedores.

• Tenemos la abstracción de la plataforma a nivel de contenedor, creando y desplegando contenedores como parte de una aplicación completa.

• Kubernetes es un PaaS "contenedor" (a veces llamado CaaS).

• Con las herramientas de orquestación de contenedores, el desarrollador crea y luego mantiene el contenedor en el futuro.

• Para una nueva aplicación, más trabajo para sus equipos de ingeniería y menor productividad

Después de 4 años, las tendencias se ven así:

Los clústeres de Kubernetes se están volviendo realmente baratos en estos días y el entorno de herramientas para kubernetes es mejor.

Además, la mayoría de las características competitivas enumeradas por otros carteles son claramente fáciles de replicar dentro de Kubernetes en estos días.