kubernetes cloudfoundry pivotal-cloud-foundry

Kubernetes vs. CloudFoundry



pivotal-cloud-foundry (8)

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

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

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

1) despliegue.yaml: este recurso define qué versión de imagen necesita recoger de su registro de contenedor, 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.

Un recurso más importante es el ingreso que proporcionan los kubernetes que administran 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.

Puede encontrar más sobre kubernetes a continuación: https://kubernetes.io/docs/

La próxima versión de CloudFoundry / Diego ofrecerá soporte nativo para contenedores Docker que se organizarán en varios hosts [ link ]. Esto suena muy similar a Kubernetes.

Por supuesto, el problema que Kubernetes está tratando de resolver es más genérico, donde CloudFoundry está más enfocado 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 sobre los casos de uso en los que Kubernetes agregaría más valor que CloudFoundry.

Cloud Foundry es una gran herramienta, suponiendo que esté dispuesto a trabajar siempre dentro de las limitaciones de la oferta, ya que es muy obstinada / prescrita. La interfaz de usuario web es genial para ver el primer día, pero rara vez se usa después de comenzar a trabajar con el cliente y configurar su canalización de CI / CD. He descubierto que Cloud Foundry es excelente hasta que aparecen casos de uso que no son totalmente compatibles con Cloud Foundry. La entrega de estos casos de uso puede retrasar los proyectos cuando intente resolver esos problemas, como resultado, pierde la visibilidad de la infraestructura y los beneficios de soporte de aquellos 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 conducirán a los usuarios a Kubernetes, Mesos o Docker Swarm / Datacenter. Es posible que Cloud Foundry pueda alcanzar estos tres, pero parece poco probable debido a la popularidad de estos proyectos de código abierto.

Como comprometido con CloudFoundry (pasado) y Kubernetes (presente), probablemente estoy especialmente calificado para responder a este.

PaaS-like

Me gusta llamar a CloudFoundry una "Aplicación PaaS" y Kubernetes una "Contenedor 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 preparación que toma una aplicación de usuario (factor 12) (por ejemplo, jar o gem) y un paquete de construcción de estilo Heroku (por ejemplo, Java + Tomcat o Ruby) y produce una gota (análoga a Imagen de Docker). CF no expone la interfaz de contenedorización al usuario, pero Kubernetes sí.

Audiencia

El público principal de CloudFoundry son los desarrolladores de aplicaciones empresariales que desean implementar aplicaciones sin estado de 12 factores utilizando paquetes de construcción de estilo Heroku.

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

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

Comparación de características

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 vainas 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 más activa
  • Arquitectura más extensible con componentes reemplazables y complementos de terceros
  • GUI web gratis

Ventajas competitivas de CloudFoundry:

  • Autenticación madura, agrupación de usuarios y soporte multicliente [x]
  • Trae tu propia aplicación
  • Balanceador de carga incluido
  • Implementado, escalado y mantenido con vida por BOSH [x]
  • Registro robusto y agregación de métricas [x]
  • GUI web empresarial [x]

[x] Estas características 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 características como escalado, resurrección y monitoreo de 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 administración de la configuración de implementación son una pesadilla. (Como BOSH committer, creo que puedo decir esto con precisión).

La abstracción del despliegue de Kubernetes todavía está en pañales. Hay múltiples entornos de destino disponibles en el repositorio principal, pero no todos funcionan, están bien probados o no son compatibles con los desarrolladores principales. Esto es principalmente una cosa de madurez. Uno podría esperar que esto mejore con el tiempo y aumente la abstracción. Por ejemplo, Kubernetes en DCOS permite implementar Kubernetes en un clúster DCOS existente con un solo comando.

Contexto histórico

Diego es una reescritura de Droplet Execution Agent de CF. Fue desarrollado originalmente antes de que se anunciara Kubernetes y ha adquirido más funciones a medida que el panorama competitivo ha evolucionado. Su objetivo original era generar gotitas (aplicación de usuario + paquete de construcción CF) y ejecutarlas en contenedores Warden (renombrado Garden cuando se reescribió en Go). Desde su inicio, también ha sido reempaquetado como Lattice , que es algo así como un 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 del usuario, faltan 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 parte de la sobrecarga 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 tan preocupantes .

También vale la pena mencionar que CloudFoundry y Warden (su motor de contenedor) 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 la orquestación de contenedores de tercera generación en Google, de la misma manera que Diego es la orquestación de contenedores de tercera generación en Pivotal / VMware (v1 escrito en VMware; v2 en VMware con ayuda de Pivotal Labs; v3 en Pivotal después de que se hizo cargo del proyecto) .

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 muy fáciles de replicar dentro de kubernetes en estos días.

Es difícil responder por qué una compañía construiría un producto que sea sustancialmente similar a otro producto. Hay muchas razones. Tal vez ya comenzaron a usarlo y están invertidos en él. Tal vez ellos (CF) piensan que Kubernetes está mal hecho o está equivocando la API / modelo / detalles. Tal vez piensan que pueden moverse más rápidamente si controlan todo el producto en lugar de contribuir.

De acuerdo, 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 tengamos una tendencia en la misma dirección y podamos colaborar más y pasar menos tiempo reinventando el trabajo del otro.

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.

MOTOR KUBERNETES

Kubernetes Engine es un entorno administrado y listo para la producción para implementar aplicaciones en contenedores. Trae nuestras últimas innovaciones en productividad para desarrolladores, eficiencia de recursos, operaciones automatizadas y flexibilidad de código abierto para acelerar su tiempo de comercialización.

Lanzado en 2015, Kubernetes Engine se basa en la experiencia de Google de ejecutar servicios como Gmail y YouTube en contenedores durante más de 12 años. Kubernetes Engine le permite comenzar a trabajar con Kubernetes en muy poco tiempo, eliminando por completo la necesidad de instalar, administrar y operar sus propios clústeres de Kubernetes.

Kubernetes Engine permite un rápido desarrollo e iteración de aplicaciones al facilitar la implementación, actualización y administración de sus aplicaciones y servicios. Kubernetes Engine tampoco es solo para aplicaciones sin estado; puede adjuntar almacenamiento persistente e incluso ejecutar una base de datos en su clúster. Simplemente describa los recursos de cómputo, memoria y almacenamiento que requieren sus contenedores de aplicaciones, y Kubernetes Engine aprovisiona y administra los recursos de la nube subyacente automáticamente. La compatibilidad con aceleradores de hardware facilita la ejecución del aprendizaje automático, la GPU de uso general, la informática de alto rendimiento y otras cargas de trabajo que se benefician de los aceleradores de hardware especializados.

Controle su entorno desde el panel de control integrado de Kubernetes Engine en la consola Google Cloud. Utilice las comprobaciones de estado rutinarias para detectar y reemplazar aplicaciones bloqueadas o bloqueadas dentro de sus implementaciones. Las estrategias de replicación de contenedores, el monitoreo y las reparaciones automáticas ayudan a garantizar que sus servicios estén altamente disponibles y ofrezcan una experiencia perfecta a sus usuarios. Los ingenieros de confiabilidad del sitio (SRE) de Google monitorean constantemente su clúster y sus recursos de cómputo, redes y almacenamiento para que no tenga que hacerlo, lo que le brinda tiempo para concentrarse en sus aplicaciones.

Pase de una sola máquina a miles: el escalado automático de Kubernetes Engine le permite manejar la mayor demanda de los usuarios por sus servicios, manteniéndolos disponibles cuando más lo necesita. Luego, retroceda en los períodos de silencio para ahorrar dinero, o programe trabajos por lotes de baja prioridad para agotar los ciclos de reserva. Kubernetes Engine lo ayuda a aprovechar al máximo su grupo de recursos.

Conéctese y aísle clústeres sin importar dónde se encuentre con políticas de red específicas utilizando Global Virtual Private Cloud (VPC) en Google Cloud. Utilice los servicios públicos detrás de una única dirección IP global de difusión ilimitada para lograr un equilibrio de carga continuo. Protéjase contra DOS y otros tipos de ataques de borde en sus contenedores.

Kubernetes Engine ejecuta Kubernetes certificados para garantizar la portabilidad entre nubes y locales. No hay bloqueo de proveedores: puede sacar sus aplicaciones de Kubernetes Engine y ejecutarlas en cualquier lugar donde Kubernetes sea compatible, incluso en sus propios servidores locales. Puede personalizar integraciones como monitoreo, registro y CI / CD utilizando Google Cloud Platform (GCP) y soluciones de terceros en el ecosistema.

FUNDICIÓN EN LA NUBE

Cloud Foundry tiene una arquitectura basada en contenedores que ejecuta aplicaciones en cualquier lenguaje de programación. Implemente aplicaciones en CF utilizando sus herramientas existentes y con cero modificaciones en el código. Instale, implemente y administre clústeres de Kubernetes de alta disponibilidad con CF BOSH en cualquier nube.

Las aplicaciones implementadas en Cloud Foundry acceden a recursos externos a través de la API de Open Service Broker. Vea los servicios e integraciones disponibles en The Foundry.

Cloud Foundry es altamente adaptable y resistirá cambios en la tecnología para que pueda adoptar nuevas herramientas, idiomas o plataformas en el futuro.

Al desacoplar las aplicaciones de la infraestructura, puede tomar decisiones individuales sobre dónde alojar las cargas de trabajo, en las instalaciones, en las nubes públicas o en las infraestructuras administradas, y mover esas cargas de trabajo según sea necesario en minutos, sin cambios en la aplicación.

Cloud Foundry no interrumpirá su flujo de trabajo actual. Es compatible con la tecnología y las herramientas que usa hoy en día, ya sea AWS o Docker o Kubernetes o Java o .NET, y casi cualquier cosa en su entorno actual.

Cloud Foundry es un proyecto de código abierto con una contribución abierta y un modelo de gobierno abierto que brinda a los usuarios la máxima flexibilidad para evitar el bloqueo de proveedores. Ayudamos a supervisar una comunidad confiable de diversas mentes que se han unido para abordar todo tipo de desafíos. Más perspectivas y pensamiento divergente significan un código más fuerte.

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

CF crea automáticamente el tiempo de ejecución de 3 componentes: binario de aplicación proporcionado por el usuario, paquete de compilación que contiene 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 solo la aplicación binaria (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 sistema operativo ya integrados y listos para ejecutarse. Para eso, el "manifiesto de implementación" de Kubernetes (por ejemplo, un diagrama de Helm) describe no solo una aplicación o servicio, sino todos los [micro] servicios que comprenden su solución en tiempo de ejecución. Envías una descripción declarativa única de tu tiempo de ejecución y Kubernetes se encarga de que el estado de tiempo de ejecución real coincida con tu descripción proporcionada.

Por lo tanto, el enfoque 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 enfoca en la implementación del servicio por servicio en lugar de la descripción declarativa de un tiempo de ejecución "ideal" objetivo de su sistema.

[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 aplicación, construyendo e implementando una aplicación totalmente configurada

• PCF es un ejemplo de una "aplicación" PaaS (también llamada Cloud Foundry Application Runtime)

• El desarrollador mantiene la aplicación en el futuro.

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

Kubernetes

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

• Tenemos la abstracción de la plataforma a nivel de contenedor, construyendo e implementando contenedores como parte de una aplicación completa.

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

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

• Para nuevas aplicaciones, más trabajo para sus equipos de ingeniería y menor productividad.