Los chicos de Datawire y yo recientemente regresamos de las increíbles conferencias KubeCon y CloudNativeCon en Barcelona. Participamos en 6 actuaciones en KubeCon, repartimos un montón de camisetas geniales (sin falsa modestia) en nuestro stand, hablamos con docenas de personas y asistimos a actuaciones geniales. Había tantas cosas interesantes en KubeCon EU que decidí escribir una publicación con resultados clave.
Y aquí están las conclusiones que hice (no en orden de importancia):
- La plataforma multiplataforma y la nube híbrida (todavía) son populares.
- La integración tecnológica está ganando impulso.
- Anuncio de interfaz de malla de servicio (SMI): estad atentos.
- (¿Brumoso?) El futuro de Istio.
- La política como código sube la pila.
- Cloud DevEx todavía no está exento de problemas.
- Empresas (aún) en las primeras etapas de adopción de tecnología.
- Kubernetes local es real (pero pegadizo).
- Considere los grupos de una manada.
- El éxito de Kubernetes todavía depende de la comunidad.
En la conferencia, hubo varias presentaciones sobre nubes múltiples (y temas relacionados: red y seguridad ), pero noté que muchas diapositivas introductorias en los informes de los usuarios finales mostraban infraestructura o arquitectura con al menos dos proveedores de nube. En el stand de Datawire, hablamos sobre las tendencias de transición de múltiples nubes con más frecuencia que en conferencias anteriores.
El éxito de Kubernetes ha simplificado enormemente su estrategia de múltiples nubes, proporcionando una excelente abstracción para las entregas y la orquestación. En los últimos dos años, la funcionalidad y las API de Kubernetes se han vuelto mucho más estables, y muchos proveedores usan esta plataforma. Las capacidades de administración de almacenamiento y la conectividad de red han mejorado, y hay suficientes productos y soluciones comerciales de código abierto en esta área. En su charla, "Desacreditando el mito: es difícil construir almacenamiento en Kubernetes", Saad Ali, un desarrollador senior de Google, habló sobre las instalaciones de almacenamiento de una manera interesante, y Eran Yanay de Twistlock presentó una buena visión general de las conexiones en "Conexiones en Kubernetes: cómo escribir un complemento CNI desde cero " .
Me gustaron especialmente las diversas conversaciones sobre la combinación de Azure con las infraestructuras locales existentes. Recientemente escribí un artículo en InfoQ sobre cómo la arquitectura multiplataforma se relaciona con el trabajo en las actualizaciones de aplicaciones . Hablé sobre tres enfoques: expandir la nube a un centro de datos, como en Azure Stack , AWS Outposts y GCP Anthos ; asegurar la uniformidad de la estructura de suministro (orquestación) entre varios proveedores o nubes utilizando una plataforma como Kubernetes; Garantizar la uniformidad de la estructura de los servicios (red) utilizando una puerta de enlace API y una malla de servicios, como el Embajador y el Cónsul .
En Datawire estamos trabajando duro en las puertas de enlace API y, obviamente, nos estamos inclinando hacia un tercer enfoque flexible. Esto le permite migrar de forma gradual y segura desde una pila tradicional más cerca de la nube. HashiCorp y Nick Jackson y yo hablamos en KubeCon con una conferencia sobre "Garantizar la conectividad en la nube desde el usuario final hasta el servicio" .
La tecnología combina ganar impulso
Muchos proveedores ofrecen paquetes con herramientas Kubernetes y tecnologías adicionales. Llamé la atención al anuncio de Rio MicroPaaS de Rancher Labs: recientemente han estado produciendo cosas interesantes. Escribí una reseña en InfoQ sobre Submariner , que conecta varios clústeres, y la distribución ligera Kubernetes k3s . Y estoy ansioso por aprender el juego de herramientas Kubernetes de Supergiant . Este es un "conjunto de utilidades para automatizar el suministro y la administración de clústeres de Kubernetes en la nube".
En un entorno corporativo, los paquetes se dirigen al almacenamiento. Un buen ejemplo es VMware Velero 1.0 (basado en desarrollos adquiridos de Heptio ), con el cual los desarrolladores pueden reservar y migrar recursos de Kubernetes y volúmenes persistentes.
Muchos otros operadores para almacenar y administrar datos en Kubernetes, como CockroachDB , ElasticCloud y StorageOS , estuvieron representados en la conferencia . Red Hat Rob Szumski de Red Hat habló sobre la evolución del Operator SDK y la comunidad e introdujo el Operator Hub . Aparentemente, el soporte del operador es uno de los principales beneficios del paquete empresarial OpenShift de Red Hat .
Anuncio de interfaz de malla de servicio (SMI): estad atentos
El anuncio de Service Mesh Interface (SMI) en un informe de Gabe Monroy de Microsoft definitivamente hizo mucho ruido . Nadie negará que la malla de servicios ha sido muy popular últimamente, y SMI combinará las características principales en una interfaz estándar y proporcionará "un conjunto de API portátiles comunes que garantizarán la interoperabilidad entre diferentes tecnologías de malla de servicios, incluidos Istio, Linkerd y Consul Connect".
En la demostración, Gabe muestra las características principales: política de tráfico para aplicar políticas tales como credenciales y cifrado de tránsito entre servicios (usando Cónsul e Intención como ejemplo); monitoreo de tráfico: recopilación de las métricas principales, por ejemplo, la cantidad de errores y demoras en el intercambio de datos entre servicios (usando Linkerd y el servidor de métricas SMI como ejemplo); y gestión del tráfico: medición y transferencia de tráfico entre diferentes servicios (por ejemplo, Istio con Weaveworks Flagger ).
Sería interesante definir una interfaz en este entorno altamente competitivo, pero fui al sitio web de SMI , leí las especificaciones y sospeché que esta abstracción se puede reducir a un conjunto mínimo de funciones comunes (esto siempre es difícil de evitar en soluciones como sé a mi manera) Experiencia en procesos comunitarios de Java). El peligro potencial es que, aunque todos aplicarán esta especificación, los proveedores proporcionarán las características más interesantes a través de extensiones personalizadas.
Hablé sobre esto con los muchachos de Datawire y creo que la malla de servicios existe en un mercado que funciona según el principio de "el ganador se queda con todo", por lo que al final, SMI desviará un poco de atención y otra tecnología simplemente aparecerá y reunirá todos los beneficios ( algo como Kubernetes hizo con Mesos, Docker Swarm, etc.). Sigue las noticias, mira lo que pasa.
(¿Brumoso?) El futuro de Istio
Aunque se ha dicho mucho sobre la malla de servicio, el tema de Istio, quizás la malla de servicio más famosa, ha sido mixto. Alguien cree que Istio y la malla de servicios son sinónimos (como Docker y contenedores) y solo ven una solución, no problemas; A alguien le gustan las características de Istio; y alguien no está particularmente contento con esta tecnología.
Recientemente se ha debatido mucho sobre el benchmarking de Istio , y en la versión 1.1, algunos problemas con el componente Mixer se resuelven deliberadamente . Curiosamente, hablé con diferentes personas que evaluaron Istio durante varios meses (un equipo pasó casi un año en esto), y afirman que Istio sigue siendo muy complejo y requiere muchos recursos. Alguien dice que la emisión de Istio alojado a través de GKE resolvió muchos problemas, pero no todos pueden usar GCP.
Se le preguntó a un representante de Google qué pasaría con Istio, si se convertiría en un proyecto de CNCF. La respuesta fue muy fluida, pero vaga: Istio ahora tiene código fuente abierto, la gente puede trabajar en él y sobre CNCF, esperar y ver. Hasta ahora, solo Linkerd es el proyecto de malla de servicio oficial en CNCF, aunque Envoy Proxy también es un proyecto de CNCF (e Istio, la puerta de enlace API de Ambassador y muchas otras tecnologías se basan en él). En nuestro stand, muchos preguntaron sobre la integración de Linkerd 2 y Ambassador (gracias a Oliver Gould, director técnico de Buoyant, quien mencionó a Ambassador en su revisión detallada de Linkerd ), y a los participantes les gustó la facilidad de uso de Linkerd.
Por cierto, me encantó cuando los chicos de Knative en su discurso "Extendiendo Knative por diversión y ganancias" mostraron que reemplazaron a Istio con Ambassador en Knative, porque Ambassador es más fácil de usar (preste atención a sus camisetas en la foto y lea la tarea correspondiente en GitHub: "Eliminar Istio como una dependencia" ):
La política a medida que el código sube
En nuestra industria, todo el mundo ya está acostumbrado a presentar la política como código en relación con un sistema de gestión de identidad y acceso (IAM), configuración de iptable, ACL y grupos de seguridad, pero hasta ahora esto se ha hecho en un nivel bajo, cerca de la infraestructura. Cuando escuché a los chicos de Netflix hablar sobre el uso del Open Policy Agent (OPA) en KubeCon en Austin en 2017 , me preguntaba cómo usar este proyecto para definir una política como código.
En este KubeCon, vi esa política a medida que aumenta el código, y cada vez más personas discuten el uso de OPA, por ejemplo, durante una charla de Rita Zhang y Max Smythe , y más sobre el informe "Configuraciones de prueba de la unidad de Kubernetes" usando el agente de política abierta » Gareth Rushgrove (tiene talento para proyectos con gran potencial).
He estado siguiendo las políticas de definición de HashiCorp Sentinel a nivel de infraestructura, y ahora usando Intention en la malla del servicio de Cónsul lleva esta tecnología aún más arriba. Con Intention, se puede definir una política a nivel de servicio. Por ejemplo, el servicio A puede comunicarse con el servicio B, pero no con el servicio C. Cuando el equipo de Datawire comenzó a trabajar con HashiCorp para integrar Ambassador y Consul, rápidamente nos dimos cuenta de los beneficios de combinar Intention con mTLS (para identificar servicios) y ACL (para evitar la suplantación de identidad y para la protección multinivel).
Cloud DevEx todavía no puede hacerlo
Durante el comentario final, "Don't Stop Believing", Bryan Liles, desarrollador senior de VMware, habló sobre la importancia del flujo de trabajo del desarrollador (experiencia del desarrollador, DevEx), y este tema se ha planteado en varias conversaciones. Kubernetes y su ecosistema se están desarrollando bien, pero el ciclo de desarrollo interno y la integración de las tuberías de suministro con Kubernetes definitivamente necesitan mejoras.
Christian Roggia habló sobre esto en su informe "Desarrollo y entrega reproducibles con Bazel y telepresencia" . Habló sobre cómo Engel y Volkers usan la herramienta de telepresencia CNCF en su ciclo de desarrollo interno para que no tengan que recoger y enviar el contenedor después de cada cambio.
Hubo una interesante discusión grupal con los muchachos de Weaveworks y Cloudbees, “GitOps and Best Practices for CI / CD in the Cloud”, que analizó la entrega continua en detalle. GitOps se está desarrollando con bastante éxito, por lo que cuando trabajo en Datawire y en conferencias a menudo me encuentro con equipos que utilizan este enfoque para la configuración y la entrega. Por ejemplo, Jonathan y Rodrigo mencionaron esto en su fascinante informe, "Operaciones de escala progresiva en Onefootball con el embajador: 0 a 6,000 solicitudes por segundo" :
Empresas (aún) en las primeras etapas de adopción de tecnología
Esta es la primera KubeCon, donde en el stand de Datawire hablé mucho con desarrolladores de grandes empresas que recién comienzan a aprender tecnología en la nube. Casi todos han escuchado o experimentado con Kubernetes, pero muchos todavía están pensando en cómo integrar su vieja tecnología en el nuevo mundo.
Cheryl Hung, directora de ecosistemas en CNCF, sostuvo varias discusiones, incluyendo "Transformando la empresa con la nube", y fue interesante escuchar a pioneros como Intuit. Laura Rehorst, en su charla "De COBOL a Kubernetes: un viaje en la nube para un banco de 250 años" , describió cómo ABN AMRO aplicó los recursos estratégicos y de planificación.
Colocamos la puerta de enlace Ambassador API en el centro de la cabina, por lo que a menudo nos hicieron preguntas sobre cómo la puerta de enlace moderna para Kubernetes difiere de las soluciones existentes para administrar el ciclo de vida completo de la API. Ahora estamos trabajando en el próximo producto comercial en esta área: el Código de Embajador , y fue interesante discutir con los desarrolladores los requisitos y expectativas en relación con los nuevos paradigmas de la nube.
Kubernetes local es real (pero pegadizo)
Hubo varios anuncios sobre la instalación local de Kubernetes, en particular en un entorno corporativo, por ejemplo, Integración de Kublr VMware y VMware y kubeadm . Red Hat participó en todas las discusiones sobre OpenShift, y he escuchado más de una vez cómo a la gente le gustan las abstracciones de OpenShift, y la dependencia potencial se ve compensada por el flujo de trabajo mejorado y las convenciones de SLA que lo acompañan.
Pero todos repitieron lo mismo: no es necesario instalar y mantener Kubernetes usted mismo, si esto no es absolutamente necesario. E incluso si cree que su empresa es especial, tómese su tiempo: casi cualquier empresa que pueda usar una nube pública puede usar Kubernetes como servicio.
Considere grupos de rebaños
En su interesante informe, "Cómo Spotify eliminó accidentalmente todos los clústeres de Kube y los usuarios no notaron nada", el desarrollador de Spotify David Xia contó lo que aprendieron cuando eliminaron varios (!) Clústeres de trabajo. No describiré toda la situación (vea el video), pero el mensaje principal de David fue tratar a los grupos de Kubernetes como una manada. Creo que muchos de nosotros hemos escuchado esta frase: "Trate a los servidores como una manada, no como sus mascotas favoritas". Pero David cree que con el desarrollo de la abstracción computacional (cuando percibimos el "Centro de datos como una computadora" ), debemos aplicar el mismo principio y no apegarnos demasiado a nuestra infraestructura.
En su charla, The Co-Development of Kubernetes and GCP Networks, Purvi Desai y Tim Hockin, invitan a las organizaciones a destruir, recrear y migrar permanentemente los grupos de Kubernetes para no relacionarse con ellos. El argumento principal: si no verifica constantemente la capacidad de restaurar clústeres y transferir datos, es posible que no tenga éxito cuando surja un problema. Imagina que esto es ingeniería de caos para clusters.
El éxito de Kubernetes todavía depende de la comunidad.
En los informes, durante el almuerzo y durante todo el tiempo, uno de los temas clave fue la importancia de la comunidad y la diversidad. El jueves por la mañana, Lucas Käldström y Nikhita Raghunath en su informe "Primeros pasos en la comunidad de Kubernetes" no solo contaron dos historias increíbles, sino que también rompieron todas las excusas de aquellos que no están involucrados en proyectos de código abierto y proyectos de CNCF .
Cheryl Hung, en su informe de 2.66 millones, le agradeció su enorme contribución al proyecto y abogó por la diversidad y el liderazgo. Me sorprendió cuando supe que más de 300 becas de apoyo a la diversidad fueron financiadas por donaciones de varias organizaciones dentro del CNCF.
KubeCon Conclusión de la UE
Gracias de nuevo a todos los que hablamos en Barcelona. Si no pudo asistir a nuestras presentaciones, le doy una lista completa:
En Datawire, estamos siguiendo estas tendencias para garantizar que Ambassador continúe evolucionando y satisfaciendo las necesidades cambiantes de los desarrolladores de la nube. Si no ha usado Ambassador recientemente, pruebe nuestra última versión: Ambassador 0.70 con soporte integrado de malla de servicio Consul, soporte de definición de recursos personalizados y muchas otras características.
Si tiene problemas para actualizar, cree una tarea o encuéntrenos en Slack . Si necesita una instalación de Ambassador lista para usar con autenticación integrada, limitación de velocidad y soporte, pruebe nuestro producto comercial Ambassador Pro .
Y si te gusta trabajar con el Embajador, cuéntanoslo. Deja un comentario debajo del artículo o publica @getambassadorio en Twitter.