🕕 🐃 👩🏻‍⚖️ "Docker ya está muerto" o lo que sea que quisieras saber sobre Devops pero temías preguntar 🥙 👩🏻‍🤝‍👨🏼 ⤴️

Recientemente, Alexander Chistyakov, DevOps con 7 años de experiencia y cofundador de la Comunidad de Ingenieros DevOps de St. Petersburg, habló en nuestras redes sociales.

Sasha es uno de los mejores oradores en esta área, actuó en los escenarios principales de Highload ++, RIT ++, PiterPy, Strike, haciendo al menos 100 informes en total. El lunes pasado respondió a las preguntas de los espectadores y habló sobre su experiencia.

Compartimos la grabación y la transcripción de la transmisión.

Mi nombre es Alexander Chistyakov, he trabajado como ingeniero de DevOps durante muchos años. He estado asesorando a varias empresas durante mucho tiempo en la implementación de prácticas de DevOps, utilizando herramientas modernas de DevOps y organizando infraestructuras para que todos podamos dormir tranquilos por la noche y las personas continúen recibiendo dinero por sus bienes y servicios.

Básicamente consulté a empresas extranjeras.

Hablaremos sobre cómo la gente usa Kubernetes en la práctica diaria, por qué es necesario, por qué no debe tenerle miedo, a qué debe prestar atención y qué sucederá a continuación.

Creo que los administradores de sistemas, los ingenieros de DevOps, los CIO y otros administradores de infraestructura (y partidarios) lo encontrarán útil.

¿Cómo se desarrolló este paisaje? Recuerdo computadoras en las que se instaló ROM Basic y era posible escribir programas sin un sistema operativo instalado. Mucha agua ha corrido debajo del puente desde entonces. Al principio, no existía ningún sistema operativo como tal (más precisamente, estaban escritos en ensamblador). Luego apareció el lenguaje C y la situación mejoró dramáticamente. Por supuesto, ahora todos estamos familiarizados con el concepto de SO: es una plataforma que nos permite ejecutar aplicaciones personalizadas y administrar los recursos que tenemos en este equipo. U otros, si se distribuye. Incluso entonces, fue posible ensamblar un clúster de computación de alto rendimiento desde su computadora portátil y computadora de escritorio; esto es lo que hicieron los estudiantes en el albergue de la Universidad Politécnica de San Petersburgo en 1997.

Luego resultó, probablemente leí este artículo hace 10 años, que Google, que inventó el correo web, está construyendo un sistema operativo en torno a este mismo correo web para que los usuarios puedan usarlo desde tabletas y teléfonos. Esto fue inesperado, generalmente el sistema operativo es algo que ejecuta los binarios, y cuando miras la aplicación a través del navegador, ni siquiera sabes si el binario está allí. Puede leer el correo, chatear en un mensajero en línea, dibujar diapositivas, editar documentos juntos. Resultó que esto se adapta a muchos.

Es cierto que Google no fue muy consistente y fabricó muchos productos de este tipo que no eran necesarios y no iban más allá del prototipo, por ejemplo, Google Wave. Bueno, esta es la política de cualquier gran empresa: moverse rápidamente, colapsar con frecuencia, hasta que la empresa deje de existir.

Sin embargo, en la conciencia de las masas, ha habido un cambio hacia la idea del sistema operativo como una plataforma que no proporciona los servicios que alguna vez fueron aprobados por algún comité de establecimiento de estándares y le fueron asignados, sino que simplemente satisface las necesidades de los usuarios. ¿Cuáles son estas necesidades?

Solía ser una costumbre preguntarle al desarrollador sobre qué escribe. Había especialistas en C ++ (probablemente, y ahora hay en alguna parte), ahora hay muchos especialistas en PHP (se ríen de sí mismos, sucede) y muchos desarrolladores de JavaScript. Typecript, el lenguaje GoLang al que han cambiado las personas con conocimientos de PHP, está ganando popularidad. Estaba el lenguaje Perl (probablemente aún permanece, pero ha perdido mucha popularidad), el lenguaje Ruby. En general, una aplicación se puede escribir en cualquier cosa. Si vives en el mundo real, probablemente te hayas encontrado con el hecho de que están escritos en cualquier cosa: Javascript, Rust, C; inventa un nombre, algo estaba escrito en él.

Y todo esto hay que aprovecharlo. Resultó que en un sistema tan heterogéneo, en primer lugar, se necesitan especialistas para desarrollar en diferentes idiomas, y, en segundo lugar, se necesita una plataforma que le permita lanzar un servicio en un entorno agradable y monitorear su ciclo de vida. Hay un contrato con esta plataforma, que en el mundo moderno se ve así: tienes una imagen de contenedor (el sistema de administración de contenedores ahora está en todas partes, Docker, aunque no puedo decir nada bueno al respecto; hablaremos de problemas más adelante).

A pesar de que la humanidad avanza por un cierto proceso evolutivo, este proceso tiene convergencia. En nuestra industria, resulta que alguien todavía está escribiendo código en Perl (bajo mod_perl Apache), y alguien ya está escribiendo una arquitectura de microservicio en GoLang. Resultó que el contrato con la plataforma es muy importante, el contenido de la plataforma es muy importante y es muy importante que la plataforma ayude a una persona. Se vuelve muy costoso realizar operaciones manuales para finalizar e iniciar el servicio. Me he encontrado con proyectos en los que había 20 servicios, y no era un proyecto muy grande; He oído hablar de tipos que tienen miles de servicios diferentes. 20 es una cantidad normal; y cada conjunto de servicios es desarrollado por su propio equipo en su propio idioma, están conectados solo por el protocolo de intercambio.

En cuanto a cómo funciona el contrato de la aplicación. Hay un "manifiesto de aplicación de 12 factores": 12 reglas sobre cómo se debe organizar una aplicación para que sea conveniente de usar. No me gusta él. En particular, dice que necesita entregar configuraciones a través de variables de entorno; y me he encontrado repetidamente con el hecho de que en Amazon, por ejemplo, la cantidad de variables de entorno que se pueden pasar a Elastic Beanstalk es una página del kernel de Linux: 4 kilobytes. Y se desbordan muy rápidamente; cuando tiene 80 variables diferentes, es difícil ceñirse a 81. Además, es un espacio de configuración plano: cuando hay variables, deben nombrarse en mayúsculas con subrayado y no hay jerarquía entre ellas; es difícil entender qué está pasando. Todavía no he descubierto cómo lidiar con esto, y no tengo a nadie con quien discutirlo; no hay un grupo de entusiastas,quién estaría en contra de tal enfoque. Si esto de repente tampoco le conviene a alguien, escríbame (demeliorator en Telegram), sabré que no estoy solo. Absolutamente no me gusta. Es difícil de administrar, difícil de transferir datos jerárquicos; resulta que el trabajo de un ingeniero moderno es saber dónde están las variables, qué significan, si están configuradas correctamente, qué tan fácil es cambiarlas. Creo que las buenas reglas de configuración antiguas eran mejores.si están configurados correctamente, qué fácil es cambiarlos. Me parece que las buenas reglas de configuración antiguas eran mejores.si están configurados correctamente, qué fácil es cambiarlos. Creo que las buenas reglas de configuración antiguas eran mejores.

Volviendo al contrato. Resulta que necesitas una imagen de Docker: necesitarás el propio Docker (a pesar de que en sí es pobre, espero que Microsoft las compre y lo entierre o lo desarrolle normalmente). Si no está satisfecho con Docker, puede probar Stack de Red Hat; No puedo decir nada al respecto, aunque me parece que debería ser mejor que solo Kubernetes vainilla. Los chicos de Red Hat prestan mucha más atención a los problemas de seguridad, incluso saben cómo hacer instalaciones multivuelta, multiusuario, multicliente, con separación normal de derechos; en general, se aseguran de que la gestión de derechos esté en su lugar.

Detengámonos en cuestiones de seguridad. Está mal con ella en todas partes, no solo en Kubernetes. Si hablamos de seguridad y problemas de orquestación de contenedores, tengo grandes esperanzas para el ensamblaje web, que se realiza por el lado del servidor, y para las aplicaciones de ensamblaje web será posible limitar el consumo de recursos, las llamadas al sistema se pueden vincular en contenedores especiales, en Rust. Esta sería una buena respuesta a la pregunta de seguridad. Y Kubernetes no tiene seguridad.

Digamos que tenemos una aplicación. Es una imagen de Docker, es de 12 factores, es decir, puede tomar su configuración de variables de entorno, de un archivo que monte dentro del contenedor. Se puede iniciar: en su interior es autosuficiente, puede intentar vincularlo con otras aplicaciones a través de configuraciones, automáticamente. Y debería escribir registros en la salida estándar, que probablemente sea la menos mala; cuando el contenedor escribe registros en archivos, no es muy fácil recopilarlos desde allí. Incluso Nginx fue parcheado para que fuera posible recopilar registros de la salida estándar del contenedor, esto es aceptable (en lugar de pasar la configuración a través de un parámetro). De hecho, solíamos tener varios orquestadores: Rancher, Marathon Mesos, Nomad; pero, como dice el principio de Anna Karenina en relación con los sistemas técnicos,Los sistemas técnicos complejos se organizan de la misma manera.

Con Kubernetes, tenemos la misma situación que para las aerolíneas con el Boeing 737 MAX: no vuela porque hay un error en él, pero no hay nada más, porque el diseño es muy complejo. No puedo decir que me guste, como el lenguaje GoLang, y el control a través del formato YAML, cuando tienes algo de sintaxis y no hay nada encima, sin verificaciones de lo que escribes, sin tipos de datos. Todas las comprobaciones que realiza antes de aplicar configuraciones en Kubernetes son rudimentos. Puede intentar aplicar la configuración incorrecta y se aplicará sin dudas y no sabe qué. Es muy fácil escribir el archivo de configuración incorrecto. Este es un gran problema, y la gente ya ha comenzado a resolverlo lentamente usando DSL y Kubernetes en los lenguajes Kotlin, incluso Typecript. Hay un proyecto Pulumi,hay un proyecto de Amazon EKS, aunque está más centrado en Amazon; Pulumi es un Terraform, solo en Typecript. Ojalá hubiera probado Pulumi todavía porque creo que es el futuro. La configuración debe describirse en un lenguaje de programación con tipado estático fuerte, de modo que antes de aplicarse, lo que potencialmente puede destruir el clúster, al menos se le dirá en el momento de la compilación que esto no es posible.

Así, por el momento solo hay un orquestador. Sé que quedan algunos usuarios de MATA, les doy la mano; Espero que nadie más use Docker Swarm; mi experiencia con él fue bastante negativa. Creo que podría ser de otra manera, pero no sé por qué; No preveo ningún desarrollo adicional de Docker Swarm, y no creo que las personas que lo publiquen vayan a hacer nada con él ahora. Capitalismo; si no gana dinero, entonces no hay nada para gastar en desarrollo, y su empresa ha estado en el "valle de la muerte" para las nuevas empresas durante los últimos dos años: nadie quiere darles dinero. Puede realizar ofertas sobre quién los comprará. Microsoft no estaba interesado. Tal vez algún Microfocus lo haga si Docker sobrevive.

Como solo queda un Kubernetes, hablemos de ello. Hay una hermosa imagen con un pentagrama de cinco de sus binarios; Está escrito que Kubernetes es muy simple, solo cinco binarios. Pero estoy lejos de medir la complejidad de un sistema en la cantidad de binarios en los que se compila y en la cantidad de servicios que conforman el núcleo del sistema. No importa cuántos binarios haya, lo que importa es lo que puede hacer Kubernetes y cómo funciona internamente.

¿Qué puede hacer él? Imagínese que necesita explicarle a un niño de cinco años lo que hizo en el trabajo. Y entonces papá, que intentó escribir libros de jugadas y roles en Ansible que le permitieran hacer una implementación azul-verde basada en Nginx en un host y un conjunto de contenedores que no están registrados con nada más que tv-ansible, dice: “Sabes, hijo, lo intenté todo es hora de crear tu propio Kubernetes. No funciona bien, está mal probado, no lo entiendo bien, no conozco todas las condiciones límite, funciona dentro de la misma máquina, ¡pero es mío! " Lo he visto injustificadamente muchas veces; solo lo vi 2 o 3 veces, y 2 veces participé escribiendo algo como esto. Tarde o temprano, una persona que participa en esto, se da cuenta de que no debería haber una cuarta vez. Es como mis amigos del cochequien una vez restauró el VAZ-2101: instaló ventanas eléctricas, reparó el interior con rebaño, lo pintó en metálico. Crear tu propio orquestador es algo como esto. Puede probarlo una vez para asegurarse de que pueda, pero no estoy listo para recomendarlo a todos, no solo a los entusiastas. Por lo tanto, la gestión del ciclo de vida y la gestión del estado del contenedor es tarea de Kubernetes.

Puede asegurarse de que el contenedor se esté ejecutando en el nodo donde hay recursos, puede reiniciar un contenedor inactivo, puede asegurarse de que si el contenedor no se inicia, el tráfico no irá hacia él si hay una nueva implementación. También comenzamos diciendo que Kubernetes es el sistema operativo; donde está el sistema operativo, debería haber un administrador de paquetes. Cuando comenzó Kubernetes, las descripciones de objetos eran imperativas; El conjunto con estado y la descripción del código son descripciones que funcionan directamente, y debe agregar algo en la parte superior para establecer el estado de su [??? 18:52 - error de grabación]. En realidad, la diferencia radical con Ansible y otros sistemas de gestión de configuración similares es que en Kubernetes se describe lo que debería resultar, no cómo debería resultar. Naturalmente, describequé objetos tienes y qué propiedades tienen. Los objetos son servicio, implementación, daemonset, statefulset. Es interesante que, además de aquellos objetos que se pueden crear de forma estándar, también hay objetos personalizados que se pueden describir y crear en Kubernetes. Es muy útil; también reducirá considerablemente las filas de administradores de sistemas e ingenieros de devops.

¿Cuándo morirá Kubernetes?

Buena pregunta. Depende de lo que se signifique con la palabra "morir". Aquí está Docker: hace un año nos reunimos en una conferencia en San Petersburgo, hubo una mesa redonda y decidimos juntos (bueno, dado que somos una industria, creo que había una mayoría calificada allí, y bien podríamos permitirnos hablar en nombre de todos) que Docker ya murió. ¿Por qué? Porque en la conferencia no se habló de Docker, aunque no tiene tantos años. Nadie dijo nada de él. Hablamos sobre Kubernetes, sobre los próximos pasos: Kube Flow, por ejemplo, sobre el uso de operadores, sobre cómo colocar bases de Kubernetes. Cualquier cosa menos Docker. Esto es la muerte, cuando estás tan mal que pareces estar vivo, pero nadie viene a ti.

Docker ya está muerto. Cuando Kubernetes muera, esperemos 5 años. No morirá, todos lo tendrán, estará dentro de Tesla, dentro de su teléfono, en todas partes, y nadie estará interesado en hablar de ello. Creo que esto es la muerte. Tal vez ni siquiera en 5 años, pero en 3. Otra pregunta es qué la reemplazará: alguna tecnología nueva y ruidosa de la que todos hablarán, tal vez no del mundo DevOps en absoluto. Ahora hablan de Kubernetes incluso solo para mantener la conversación, y está bien, está de moda.

¿Qué pasa con Docker?

Todos. Este es un único binar para administrar todo, este es un servicio que debe ser lanzado en el sistema, esta es una pieza que también se controla a través de un socket. Este es un producto que tiene mucho código que no ha sido revisado por nadie, como creo. Este es un producto para el que, en general, no hay dinero empresarial. Red Hat tiene gente muy inteligente, los respeto mucho, y si usted es un ingeniero promedio, debería mirar lo que están haciendo porque eso podría definir el panorama durante los próximos 5 años. Bueno, Red Hat abandonó Docker por completo. Se están moviendo hacia no tenerlo. Hasta ahora, no pueden hacer esto hasta el final, pero están cerca, y tarde o temprano terminarán Docker. Él, además de todo lo que he enumerado, tiene una zona de ataque enorme. Allí no hay seguridad. No se plantearon muchos CVE al respecto, pero si los observa, está claro que,como en cualquier otro proyecto en el que la seguridad no está a la vanguardia, se trata sobre una base de sobras. Esta es la ley. La seguridad es larga, cara, lúgubre, restringe al desarrollador, complica enormemente la vida. Hacer bien la seguridad es un trabajo duro y hay que pagar por ello. Si habla con cualquier profesional de seguridad, sin importar las calificaciones, escuchará muchas historias de terror sobre Docker e historias sobre lo mal que están las cosas. Están conectados en parte con el propio Docker, en parte con las personas que lo operan, pero el propio Docker podría ayudar a las personas y realizar algunos controles de seguridad dentro de sí mismo; por ejemplo, no inicie un proceso en un contenedor desde la raíz, a menos que se le indique explícitamente que lo haga.limita al desarrollador, hace la vida muy difícil. Hacer bien la seguridad es un trabajo duro y hay que pagar por ello. Si habla con cualquier profesional de seguridad, sin importar las calificaciones, escuchará muchas historias de terror sobre Docker e historias sobre lo mal que están las cosas. Están conectados en parte con el propio Docker, en parte con las personas que lo operan, pero el propio Docker podría ayudar a las personas y realizar algunos controles de seguridad dentro de sí mismo; por ejemplo, no inicie un proceso en un contenedor desde la raíz, a menos que se le indique explícitamente que lo haga.limita al desarrollador, hace la vida muy difícil. Hacer bien la seguridad es un trabajo duro y hay que pagar por ello. Si habla con cualquier profesional de seguridad, independientemente de sus calificaciones, escuchará muchas historias de terror sobre Docker e historias sobre lo mal que están las cosas. Están en parte relacionados con el propio Docker, en parte con las personas que lo operan, pero el propio Docker podría ayudar a las personas y realizar algunos controles de seguridad dentro de sí mismo; por ejemplo, no inicie un proceso en un contenedor desde la raíz, a menos que se le indique explícitamente que lo haga.parcialmente, con las personas que lo explotan, pero el propio Docker podría ayudar a las personas y realizar algunos controles de seguridad dentro de sí mismo; por ejemplo, no inicie un proceso en un contenedor desde la raíz, a menos que se le indique explícitamente que lo haga.parcialmente, con las personas que lo explotan, pero el propio Docker podría ayudar a las personas y realizar algunos controles de seguridad dentro de sí mismo; por ejemplo, no inicie un proceso en un contenedor desde la raíz, a menos que se le indique explícitamente que lo haga.

¿Cómo almacenar estados? ¿Puedo alojar la base de datos en Kubernetes?

Si le pregunta al DBA, oa la persona responsable de la infraestructura de esta base de datos antes de que decidiera ponerla en Kubernetes, esa persona dirá que no. Creo que en muchas mesas redondas la gente dirá que no debería haber bases de datos en Kubernetes: es difícil, poco confiable, no está claro cómo administrarlo.

Creo que las bases de datos en Kubernetes se pueden representar. ¿Qué tan confiable es? Bueno, mira: estamos ante un sistema distribuido. Cuando coloca una base de datos en un clúster, debe comprender que tiene un requisito de tolerancia a errores. Si tiene tal requisito, lo más probable es que lo que ponga dentro de su Kubernetes sea un clúster de base de datos. ¿Cuántas personas en el mundo moderno saben cómo hacer un clúster de base de datos normal? ¿Ofrecen muchas bases de datos capacidades de agrupamiento? Aquí comienza la división de las bases de datos en tradicionales: relacionales y no relacionales. Su diferencia no es que estos últimos no admitan SQL de una forma u otra. La diferencia es que las bases de datos no relacionales son mucho más adecuadas para trabajar en clústeres, porque originalmente se escribieron para que la base de datos se distribuyera. Por lo tanto,si por algún MongoDB o Cassandra quieres hacer hosting en Kubernetes, no puedo disuadirte, pero deberías tener una muy buena idea de lo que sucederá a continuación. Debe comprender muy bien dónde están sus datos, qué sucederá en caso de falla y recuperación, cómo van las copias de seguridad, dónde se encuentra el punto de recuperación y cuánto tiempo tomará recuperar. Estas preguntas no son relevantes para Kubernetes; tienen que ver con cómo se opera básicamente una solución de clúster basada en bases de datos convencionales. Es más fácil con las soluciones NoSQL, ya que están listas para la nube de inmediato.dónde está el punto de restauración y cuánto tardará en recuperarse. Estas preguntas no son relevantes para Kubernetes; tienen que ver con cómo se opera básicamente una solución de clúster basada en bases de datos convencionales. Es más fácil con las soluciones NoSQL, ya que están listas para la nube de inmediato.dónde está el punto de restauración y cuánto tardará en recuperarse. Estas preguntas no son relevantes para Kubernetes; tienen que ver con cómo se opera básicamente una solución de clúster basada en bases de datos convencionales. Es más fácil con las soluciones NoSQL, ya que están listas para la nube de inmediato.

Pero aún así, surge la pregunta: ¿por qué poner la base de datos en Kubernetes? Puede tomar un servicio proporcionado por su proveedor, una solución administrada; puede tomar RDS de Amazon y también la base de datos administrada de Google. E incluso un clúster distribuido geográficamente de esta base de datos, en el caso de Amazon, esto es Aurora, puede instalarlo y usarlo. Pero, si va a instalar un clúster de la base distribuido geográficamente, lea la documentación detenidamente; Me he encontrado con clústeres de Aurora con un solo nodo; ni siquiera se dividieron en dos regiones. Además, la segunda región no era necesaria en absoluto. En general, la gente tiene cosas muy extrañas en la cabeza: creen que lo principal es elegir un producto, y luego se proporcionará y funcionará como debe. No. Las bases de datos relacionales no estaban del todo listas para funcionar ni siquiera en un clúster normal,sin mencionar la distribución geográfica. Por lo tanto, si está haciendo algo complejo basado en ellos, consulte la documentación.

Básicamente, tengo experiencia en operar una base de datos dentro de Kubernetes. No hubo nada terrible. Ha habido varios accidentes relacionados con la caída del nodo; el movimiento funcionó normalmente a otro nodo. Todo esta bajo control. Lo único que no puedo complacerlos es decir que hubo una gran cantidad de miles de solicitudes por segundo.

Si tiene una solución mediana o pequeña, una solución promedio para Rusia corresponde aproximadamente a una agencia de noticias grande como Lenta, entonces no debería haber una gran cantidad de consultas complejas en la base de datos. Si la base falla, probablemente esté haciendo algo mal y debe pensar en ello. No escales sin pensar. Mover una solución no agrupada a un clúster tiene sus ventajas, pero también una gran cantidad de desventajas, especialmente si toma un clúster postgres basado en Patroni o Stallone. Hay muchas condiciones de contorno; No los he encontrado, pero los colegas de Data Egret estarán encantados de contarles cómo sucede. Hay un informe maravilloso de Alexei Lesovsky sobre lo que sucederá si intentas transferir tu base a un grupo sin pensar.

Aproximadamente miles de solicitudes por segundo. Si tiene una sola instancia de base de datos, ajustarla a miles de solicitudes por segundo sigue aumentando. Tarde o temprano tendrás problemas. Me parece que es mejor, si se planea una carga pesada, considerar opciones de escala horizontal. Busque la tabla más grande en su base de datos, vea qué hay allí y piense si se puede mover a un almacenamiento no relacional. Piense en cómo no almacenar en una base de datos relacional lo que normalmente almacena en ella, por ejemplo, los registros de acceso al sistema, de los cuales muchos caen, y normalmente accede a ellos de acuerdo con el mismo patrón mediante el cual accede al almacenamiento de clave-valor. ... Entonces, ¿por qué no escribir registros en Cassandra? Esta es una pregunta para un arquitecto. Mantener una instancia base pequeña y no muy ocupada en Kubernetes es lo queporque la magia del operador empieza a responsabilizarse de ello.

Básicamente, si observa lo que es Kubernetes como sistema operativo y plataforma, entonces este es un constructor de bricolaje. Hay todo para que usted cree una arquitectura de microservicio, incluida la capacidad de almacenar estados en discos, organizar la telemetría, el monitoreo y las alertas. Esto lo hace Helm, el administrador de paquetes de Kubernetes. Hay una gran cantidad de Helm Charts de código abierto disponibles públicamente en Internet. La forma más sencilla de elevar la infraestructura de un proyecto es tomar el Helm Chart que pone su aplicación, su servicio, si este servicio es una base de datos Redis, PostgreSQL, Patroni - lo que sea; comience a configurarlo y aplique esta configuración. Es completamente declarativo; todo lo que se pueda prever, suelen proporcionar los autores de Helm Charts. Su aplicación también se publica mejor con Helm.El tercer Helm no contiene servicios del lado del clúster; el segundo contenía, tenía un servicio trabajando constantemente desde el administrador del clúster, que era necesario para distribuir lanzamientos por espacio de nombres, pero el tercer Helm cerró este agujero de seguridad.

Helm es un motor de plantillas de este tipo basado en la sintaxis de plantillas de GoLang. Toma una lista de variables, que son una estructura no plana (gracias a Dios, es jerárquica, escrita en YAML); Usando Helm, estas variables se colocan en los lugares correctos en las Plantillas de Helm, luego lo aplica todo en algún espacio de nombres, sus códigos, servicios se lanzan allí, se crean sus roles. Hay un generador de andamios que permite a Helm Chart escribir sin recuperar la conciencia. Lo único que no me gusta es la necesidad de conocer la sintaxis de las plantillas GoLang y las ramas condicionales en el propio Helm; se hacen según el principio lisp, con notación de prefijo. Es bueno que a alguien más le guste, pero hace que la cabeza cambie cada vez. Bueno, lo superaremos.

Ahora un poco sobre lo que sucederá a continuación. Ya me parecía a los operadores; Estos son los servicios que viven dentro del clúster de Kubernetes y administran el ciclo de vida de otra aplicación más grande. Suficientemente difícil. Puede pensar en un operador como el ingeniero de confiabilidad de su sitio de origen de silicio; seguro que en el futuro la gente escribirá más y más operadores, porque nadie quiere mantener un cambio de personas de primer nivel de soporte que seguirían el cronograma de Nagios, notarían interrupciones y tomarían acciones manuales. El operador comprende qué estados del sistema son posibles; es una máquina de estado. Ahora la concentración de conocimiento humano, escrito en el lenguaje GoLang o similar, se compila, se coloca en un clúster y hace mucho trabajo por usted: agregar o eliminar nodos, reconfigurar, asegurarse de que el caído se eleve,para que los datos se acoplen a los códigos deseados desde donde se encuentran. En general, gestiona el ciclo de vida de lo que se instala debajo. Los operadores ahora están literalmente para todo. Me he divertido usando el operador Rook para poner sev directamente en el clúster de Kubernetes. Observé cómo está sucediendo esto, y estoy muy contento, y creo que se necesitan más operadores y todos deberíamos participar en probarlos. El tiempo que dedicas a corregir al operador de otra persona es un regalo para la humanidad. Ya no necesita hacer el mismo trabajo una y otra vez. Puede poner este trabajo en forma alienada en el repositorio, y luego un programa inteligente lo hará por usted, ¿no es la felicidad?Los operadores ahora están literalmente para todo. Me he divertido al usar el operador Rook para poner sev directamente en el clúster de Kubernetes. Observé cómo está sucediendo esto, y estoy muy satisfecho, y creo que se necesitan más operadores y todos deberíamos participar en las pruebas. El tiempo que dedicas a corregir al operador de otra persona es un regalo para la humanidad. Ya no necesita hacer el mismo trabajo una y otra vez. Puede poner este trabajo en forma alienada en el repositorio, y luego un programa inteligente lo hará por usted, ¿no es la felicidad?Los operadores ahora están literalmente para todo. Me he divertido usando el operador Rook para poner sev directamente en el clúster de Kubernetes. Observé cómo está sucediendo esto, y estoy muy satisfecho, y creo que se necesitan más operadores y todos deberíamos participar en las pruebas. El tiempo que dedicas a corregir al operador de otra persona es un regalo para la humanidad. Ya no necesita hacer el mismo trabajo una y otra vez. Puede poner este trabajo en forma alienada en el repositorio, y luego un programa inteligente lo hará por usted, ¿no es la felicidad?que gasta en corregir al operador de otra persona es un regalo para la humanidad. Ya no necesita hacer el mismo trabajo una y otra vez. Puede poner este trabajo en forma alienada en el repositorio, y luego un programa inteligente lo hará por usted, ¿no es la felicidad?que gasta en corregir al operador de otra persona es un regalo para la humanidad. Ya no necesita hacer el mismo trabajo una y otra vez. Puede poner este trabajo en forma alienada en el repositorio, y luego un programa inteligente lo hará por usted, ¿no es la felicidad?

Descargué el libro de Red Hat, lo dan gratis, sobre cómo funcionan los operadores de Kubernetes y cómo escribir el suyo, le recomiendo que vaya a su sitio web y lo descargue también, el libro es muy interesante. Cuando lo lea en su totalidad, tal vez podamos analizar a algún operador juntos.

¿Quién apoya Swarm? ¿Además de Docker Inc?

Nadie. Y Docker Inc. ya roto en dos mitades, y la mitad vendida en alguna parte. No sigo lo que está pasando con ellos; en un momento llamaron al producto Mobi, pero era una versión de código abierto, es decir, no era una versión abierta. Y algo se vendió con derechos, pero algo no se vendió. Para mí, parece que "un paciente sudaba antes de su muerte": la gente está tratando de extraer de alguna manera el dinero invertido. En general, nadie lo apoya.

Maestro-esclavo

Funciona. Si maestro / esclavo deja de funcionar en una base de datos relacional, entonces el mundo terminará allí. Kubernetes no interfiere con el funcionamiento de la base de datos de ninguna manera; lo único que aporta son diferentes chequeos de salud, que se pueden deshabilitar si se desea, y, en principio, gestión estatal. Es aconsejable no deshabilitarlo: su operador, que administra la base de datos, debería ver su estado.

¿Cómo se llama el libro de Red Hat?

Operadores de Kubernetes se llama así. El pato se dibuja allí. El libro de O'Reilly, ahora rediseñado las cubiertas; Se han publicado bastantes libros en colaboración con Red Hat. Red Hat tiene 3 o 4 libros más de Kubernetes que puede descargar de forma gratuita: por ejemplo, Kubernetes Patterns, gRPC. El protocolo gRPC, aunque no está directamente relacionado con Kubernetes, es utilizado por muchos para intercambiar datos entre microservicios. Además, se utiliza en equilibradores de carga de próxima generación, por ejemplo, en Envoy.

¿Qué es una SRA?

Este es el tipo de persona que comprende el marco de tiempo de los cambios que ocurren en un sistema distribuido. Hablando en términos generales, entiende cuánto ya has estado acostado este mes, cuánto más puedes, si puedes dar permiso para la liberación. Está a cargo de las claves de respaldo, planes de recuperación, problemas de recuperación ante desastres, problemas de mantenimiento de infraestructura para una aplicación industrial que debería funcionar 24/7. Tiene métricas para el estado y el estado comercial de la aplicación en las métricas de la aplicación: cuánta latencia, dónde y cuántas solicitudes; esas mismas 4 señales doradas. Además, la SRA, basándose en estas métricas, puede tomar medidas para que el sistema vuelva a estar listo para el combate, tiene un plan sobre cómo hacerlo. Por alguna razón, esto no es un requisito de DevOps clásico, solo ayuda al desarrollador a lanzar la aplicación, en general a implementarla en algún lugar.Y SRA también resiste el flujo de solicitudes de diferentes lados.

Prometí hablar de seguridad. Ya sabes, este es un tema bastante joven en Kubernetes. Solo conozco los conceptos básicos: por ejemplo, que no debe ejecutar una aplicación en un servicio desde la raíz, porque tan pronto como esto sucede, tiene acceso a todo en el espacio de nombres, derechos de superusuario, y puede intentar romper el kernel del sistema host, que, probablemente funcionará (y realizará cualquier otra operación desde la raíz). No le dé a los piratas una pista como esa; si es posible, otorgue a los usuarios la menor cantidad de derechos posible y maneje bien las entradas del usuario. Me parece que si hablamos de seguridad de Kubernetes, hay que sacarla en algún lugar de los circuitos cerrados que tenemos actualmente. O, si realmente quiere meterse en problemas de seguridad, debería consultar el proyecto Cilium. Sabe cómo utilizar protectores contra sobretensiones,Diferenciación de tráfico de red basada en BPF: esto funciona mejor que iptables. Este es el futuro. Me parece que fuera de California nadie lo usa realmente, pero ya puedes empezar. Tal vez haya algún otro proyecto, pero lo dudo. En general, la humanidad tiene pocas manos trabajadoras.

Por tanto, no tengo nada especial que decir sobre la seguridad. Hay varias opciones para la tenencia montada en Kubernetes, pero ahí tienes que sentarte con un lápiz y averiguar qué hicieron las personas, qué vulnerabilidad cerraron, si tenía sentido, si se aplica a tu modelo de amenazas. Por cierto, recomiendo comenzar por buscar una descripción de cómo se construye el modelo de amenazas y hacerlo usted mismo. Hay métodos más o menos formales. Dibuje, mírelo, y tal vez suceda una idea, y comprenderá lo que necesita y lo que no se necesita en la situación actual. Tal vez sea suficiente para llevar a todos los Kubernetes a un circuito cerrado. Por cierto, esta es la decisión correcta; Me he encontrado con esto y es impenetrable. Si puede acceder al sistema solo presentando un pase en el reloj, y no hay Internet adentro, y el intercambio pasa por alguna puerta de enlace especial,ubicado en la DMZ y es difícil de romper porque está escrito de manera inusual, entonces es un sistema bien protegido. Cómo hacerlo por medios técnicos: bueno, necesita monitorear el mercado actual de soluciones. Está cambiando mucho, la seguridad es un tema candente. Hay muchos jugadores que intentan serlo, pero cuál de ellos miente y cuál no, no pretendo decirlo. Si bien Red Hat probablemente no miente, no está por delante de todos. Solo necesitas investigar (y yo también), porque aún no está claro.Solo necesitas investigar (y yo también), porque aún no está claro.Solo necesitas investigar (y yo también), porque aún no está claro.

Hablemos de qué más debería tener el clúster de Kubernetes. Ya que tenemos la oportunidad de instalar aplicaciones allí de forma gratuita, y no tenemos miedo de almacenar la base de datos allí. Por cierto, si tiene Managed Kubernetes, entonces no hay dudas sobre dónde almacenar la base de datos: tiene almacenamiento tolerante a fallas, de una forma u otra (a menudo en forma de dispositivos de bloque) suministrado desde la nube en la que se encuentra Managed Kubernetes. Puede colocar de forma segura los discos de este almacenamiento en su clúster y usar instantáneas para realizar copias de seguridad consistentes. No olvide que la instantánea no es una copia de seguridad, también debe copiar la instantánea en algún lugar. Esto es obvio, pero es bueno repetir las cosas obvias para que no se olviden.

Cuando tiene una plataforma de arquitectura de microservicio, es muy importante hacerla rastreable, observable, para que pueda comprender dónde están las solicitudes y dónde están perdiendo el tiempo, etc. Construir una plataforma así es mucho trabajo. Necesitarás Prometheus. Será necesario porque es un proyecto de Cloud Native Computing Foundation; está diseñado específicamente para monitorear Kubernetes. Contiene una gran cantidad de exportadores, recopiladores de métricas; algunas aplicaciones contienen de forma nativa todos sus paneles. Si su aplicación no los contiene, se necesitan 20 minutos para adjuntarlo a la aplicación de panel de Prometheus de larga duración. Aunque por alguna razón nadie lo adjunta. En mi experiencia, esto se debe a que las personas mantienen sus productos en las nubes. Hay Amazon CloudWatch, Google StackDriver,y puede enviar métricas allí de la misma manera, aunque costará dinero. Es decir, si la gente todavía paga por la infraestructura, entonces paga por las herramientas de monitoreo adjuntas. Sin embargo, Prometheus puede ser muy conveniente si tiene varios lugares diferentes de donde toma métricas, si la nube no está en un solo lugar, si es híbrida, si tiene máquinas en las instalaciones y necesita una infraestructura centralizada. Entonces Prometheus es tu elección.si tiene máquinas en las instalaciones y necesita una infraestructura centralizada. Entonces Prometheus es tu elección.si tiene máquinas en las instalaciones y necesita una infraestructura centralizada. Entonces Prometheus es tu elección.

Que más necesitas? Está claro que donde está Prometheus, también existe la necesidad de Alert Manager. Y también necesita algún tipo de seguimiento distribuido de sus solicitudes. Cómo hacer esto en Kubernetes: bueno, tome algún producto como jaeger o zipkin, o lo que sea que esté en la parte superior ahora mismo; también Cassandra para almacenar tus rastros, también Grafana para renderizarlos. Por lo que tengo entendido, esta función apareció en Grafana recientemente, pero esta no es una razón para no implementarla. Es decir, puede ensamblar manualmente un entorno en el que las aplicaciones [fallos 49:14] (¿tienen?) En este tiempo de ejecución, tanto contadores como otras métricas adecuadas para la construcción, visualización de sus trazas distribuidas: ¿dónde pasa la aplicación cuánto tiempo?

Es menos conveniente hablar de ello que mostrarlo, pero no hay nada que mostrarme ahora; Ahora no tengo nada de esto en mi laboratorio. Probablemente algún día me prepararé.

Creo que dije todo lo que quería contar. Repetiré las disposiciones principales una vez más.

Primero: Kubernetes lo libera de la necesidad de escribir un mecanismo para el reemplazo a prueba de fallas de un contenedor por otro en Ansible Engine X. En

segundo lugar, Kubernetes no desaparecerá en ninguna parte. Puede "morir", pero ya no es posible dejar de usarlo, ha acaparado la mayor parte del mercado. A la pregunta "cuándo morirá Kubernetes:" Quiero preguntar "¿cuándo morirá WordPress?" Y todavía tiene que vivir y vivir. Establezcamos el orden: primero WP, luego Kubernetes.

Entonces Kubernetes está con nosotros. Más bien, no es él quien es interesante, pero los servicios que están en la parte superior son interesantes: estos son los operadores y la Definición de recursos personalizados. La capacidad de tomar y escribir su propio recurso, que se llamará "Clúster de PostgreSQL", describirlo con un tapiz YAML y lanzarlo al clúster.

¿Qué más pasará? También habrá la capacidad de administrar todo esto, lenguajes de programación de tipo estático como GoLang y TypeScript. Y realmente creo en Kotlin: ya están escritos muchos DSL geniales. Y se escribirán más.

También aparecerá Helm Chart de pago, aplicaciones de pago que se pueden lanzar en las instalaciones, algunas con licencia, mediante suscripción. Habrá integración de varios servicios; de hecho, ya existe, por ejemplo, DataDog ya se está integrando con Kubernetes. Y los nuevos tipos que aparecerán en el mercado de alertas de monitoreo también se integrarán con Kubernetes, por razones obvias. Ningún producto en la nube pasará por Kubernetes, de una forma u otra. Esta es la plataforma a la que todos apuntarán.

Pero todo esto no significa que Kubernetes sea bueno y nada podría ser mejor. Lo comparo con lo que era antes, con las soluciones de Amazon: ECS, Elastic Beanstalk. Aquellos que los han encontrado saben que en mi vieja analogía esa cosa, esa otra sería no solo el 737 MAX, sino el 737 MAX, hecho de cinta aislante y plastilina. Por lo tanto, los principales actores, Amazon, Microsoft Azure, Google, ya están en Kubernetes. Probablemente, Yandex y Mail.ru también lo estén, pero yo no los sigo. Este es un futuro tan común. Un futuro común tan malo, pero "suficientemente bueno", en el que todos están de acuerdo hasta ahora. En qué se transforma todo a continuación, debe preguntarle a Red Hat: son más inteligentes que yo.

¿Qué opina Java sobre Kubernetes?

Multa.

¿Qué sistema operativo estás usando en tu PC?

Ambos están en macOS.

¿Se contratan activamente especialistas en DevOps ahora?

Sí, siempre se tomaron activamente en una ubicación remota y ahora se toman activamente de la misma manera. La situación no cambiará fundamentalmente, creo. En general, no considero trabajo no removido: no todas las buenas empresas tienen una oficina en San Petersburgo. Por supuesto, habrá una distancia, y los acontecimientos actuales le han demostrado a la gente que es posible. La cantidad de personas que se sienten más cómodas con él solo aumentará. Se nos dice que “mucha gente lo intentó y volvió a la oficina”, bueno, volver a la oficina cuesta dinero. Sin dinero, sin elección, y muchas empresas están ahorrando ahora.

"Docker ya está muerto" o lo que sea que quisieras saber sobre Devops pero temías preguntar