Kubernetes se hará cargo del mundo. Cuando y como

En vísperas de DevOpsConf, Vitaliy Khabarov entrevistó a Dmitry Stolyarov ( distol ), director técnico y cofundador de Flant. Vitaly le preguntó a Dmitry qué está haciendo Flant, sobre Kubernetes, el desarrollo del ecosistema, el apoyo. Discutimos por qué se necesita Kubernetes y si es necesario. Y también sobre microservicios, Amazon AWS, el enfoque "I'm Lucky" en DevOps, el futuro de Kubernetes, por qué, cuándo y cómo se hará cargo del mundo, las perspectivas de DevOps y para qué deben prepararse los ingenieros en un futuro brillante y cercano con redes simplificadas y neuronales.

Escuche la entrevista original como un podcast en DevOps Deflop, un podcast en ruso sobre DevOps, y debajo hay una versión de texto.



En adelante, un ingeniero de Express42 hace preguntas a Vitaliy Khabarov .

Sobre Flant

- Dima, hola. Usted es el director técnico de Flant y también su fundador. Dime, por favor, ¿qué está haciendo la empresa y estás en ella?

Dmitry : Desde afuera, parece que somos los tipos que vamos, ponemos a Kubernetes sobre todos y hacemos algo con él. Pero esto no es así. Comenzamos como una empresa que se ocupa de Linux, pero durante mucho tiempo nuestra actividad principal fue prestar servicios de producción y proyectos llave en mano de alta carga. Por lo general, construimos toda la infraestructura desde cero y luego somos responsables de ello durante mucho tiempo. Por lo tanto, el trabajo principal que realiza Flant, por el cual recibe dinero, es asumir la responsabilidad y la implementación llave en mano de la producción .


Como director técnico y uno de los fundadores de la compañía, trabajo las 24 horas para pensar en formas de aumentar la disponibilidad de producción, simplificar su funcionamiento, facilitar la vida de los administradores y hacer que la vida sea más agradable para los desarrolladores.

Sobre Kubernetes

- La última vez de "Flanta" veo muchos informes y artículos sobre Kubernetes. ¿Cómo llegaste a él?

Dmitry : Ya he hablado de esto muchas veces, pero no lamento repetirlo. Creo que es correcto repetir este tema, porque hay confusión entre causa y efecto.

Realmente necesitábamos una herramienta. Enfrentamos muchos problemas, luchamos, los superamos con diferentes muletas y sentimos la necesidad de un instrumento. Analizaron muchas opciones diferentes, construyeron sus bicicletas y ganaron experiencia. Poco a poco llegamos al punto en que comenzamos a usar Docker casi tan pronto como apareció, alrededor de 2013. En el momento de su aparición, ya teníamos mucha experiencia con contenedores, ya escribimos un análogo de "Docker", algunas de nuestras muletas en Python. Con el advenimiento de Docker, las muletas pueden ser desechadas y utilizadas por una solución confiable y respaldada por la comunidad.

Con Kubernetes, la historia es similar. Para cuando comenzó a ganar impulso, para nosotros esta es la versión 1.2, ya teníamos un montón de muletas tanto en Shell como en Chef, que de alguna manera tratamos de orquestar Docker. Miramos seriamente hacia Rancher y otras soluciones, pero luego apareció Kubernetes, en el que todo se implementa exactamente como lo haríamos o incluso mejor. No hay nada de qué quejarse.

Sí, hay algún tipo de imperfección, hay algún tipo de imperfección: hay muchas imperfecciones, y 1.2 es generalmente horrible, pero ... Kubernetes es como un edificio en construcción: miras el proyecto y entiendes que será genial. Si el edificio ahora tiene una base y dos pisos, entonces comprende que es mejor no poblar todavía, pero no existen tales problemas con el software, ya puede usarlo.

No tuvimos el momento en que pensamos usar Kubernetes o no. Lo esperábamos mucho antes de que apareciera, y tratamos de hacer análogos nosotros mismos.

Cerca de Kubernetes

- ¿Participas directamente en el desarrollo de Kubernetes?

Dmitry : mediocre. Es más probable que participemos en el desarrollo del ecosistema. Enviamos una cierta cantidad de solicitudes de extracción: a Prometheus, a todo tipo de operadores, a Helm al ecosistema. Desafortunadamente, no puedo seguir todo lo que hacemos y puedo estar equivocado, pero no hay un solo grupo de nuestro núcleo.

- ¿Desarrollas muchas de tus herramientas en torno a Kubernetes?

Dmitry : La estrategia es esta: vamos y tiramos de todo lo que ya está allí. Si no se aceptan solicitudes de extracción allí, simplemente las bifurcamos para nosotros y vivimos hasta que sean aceptadas con nuestras compilaciones. Luego, cuando llega al nivel anterior, volvemos a la versión anterior.

Por ejemplo, tenemos un operador Prometheus con el que cambiamos de un lado a otro de nuestro ensamblaje 5 veces, probablemente. Necesitamos alguna función, enviamos una solicitud de extracción, necesitamos implementarla mañana, y no queremos esperar hasta que se publique en sentido ascendente. En consecuencia, recopilamos para nosotros mismos, enrollamos nuestro ensamblaje con nuestra función, que por alguna razón necesitamos, para todos nuestros clústeres. Luego, por ejemplo, nos envuelven aguas arriba con las palabras: "Chicos, hagámoslo por un caso más general", nosotros, o alguien más, terminaremos esto, y finalmente nos fusionaremos nuevamente.

Todo lo que existe, estamos tratando de desarrollarlo . Muchos elementos que aún no están allí todavía no se han inventado o se han inventado, pero aún no se han implementado, lo estamos haciendo. Y no porque nos guste el proceso en sí mismo o la construcción de bicicletas como industria, sino simplemente porque necesitamos esta herramienta. A menudo hacen la pregunta, ¿por qué hicimos esto o aquello? La respuesta es simple: porque tuvimos que ir más allá, resolver algunos problemas prácticos y lo resolvimos con esta herramienta.

El camino es siempre esto: miramos con mucho cuidado y, si no encontramos una solución, cómo hacer un trolebús con una barra de pan, entonces hacemos nuestra propia hogaza y nuestro propio trolebús.

Herramientas flant

“Sé que Flant ahora tiene operadores de complementos, operadores de shell, herramientas dapp / werf. Según tengo entendido, esta es la misma herramienta en diferentes encarnaciones. También entiendo que hay muchas más herramientas diferentes dentro de Flant. Es asi?

Dmitry : Todavía tenemos muchas cosas en GitHub. Por lo que recordaré ahora, tenemos un mapa de estado: un panel para Grafana que se ha enviado a todos. Se menciona en casi cada segundo artículo sobre el monitoreo de Kubernetes en el medio. Es imposible describir brevemente qué es el mapa de estado: necesita un artículo separado, pero esto es muy útil para monitorear el estado a lo largo del tiempo, ya que en Kubernetes a menudo necesitamos mostrar el estado a lo largo del tiempo. También tenemos LogHouse: esta es una pieza ClickHouse y basada en magia negra para recolectar registros en Kubernetes.

Muchas utilidades! Y habrá aún más, porque se lanzarán varias soluciones internas este año. De los grandes operadores basados ​​en complementos, hay un montón de complementos para Kubernetes, pero cómo instalar el administrador de sert, una herramienta de gestión de certificados, cómo instalar Prometheus con un montón de esquivas, estos son veinte binarios diferentes que exportan datos y recopilan algo, para esto Prometheus es impresionantes gráficos y alertas. Todo esto es solo un montón de complementos para Kubernetes que se colocan en un clúster, y pasa de simple a genial, sofisticado, automático, en el que muchos problemas ya se han resuelto. Sí, hacemos mucho

Desarrollo de ecosistemas

- Me parece que esta es una gran contribución al desarrollo de esta herramienta y sus métodos de uso. ¿Puedes descifrar quién más haría la misma contribución al desarrollo del ecosistema?

Dmitry : en Rusia, ninguna de esas compañías que operan en nuestro mercado está cerca . Por supuesto, esta es una declaración de alto perfil, porque hay grandes jugadores como Mail with Yandex: también hacen algo con Kubernetes, pero ni siquiera han igualado la contribución de las empresas en el mundo, que están haciendo mucho más que nosotros. Es difícil comparar Flant con un equipo de 80 personas y Red Hat, en el que solo hay 300 ingenieros de Kubernetes, si no me equivoco. Es difícil de comparar. Tenemos 6 personas en el departamento de RnD, incluyéndome a mí, que están cortando todas nuestras herramientas. 6 personas contra 300 ingenieros de Red Hat: de alguna manera es difícil de comparar.

- Sin embargo, cuando incluso estas 6 personas pueden hacer algo realmente útil y alienado, cuando se enfrentan a una tarea práctica y dan una decisión a la comunidad, un caso interesante. Entiendo que en las grandes empresas de tecnología, donde tienen su propio desarrollo y el equipo de soporte de Kubernetes, en principio, se pueden desarrollar las mismas herramientas. Este es un ejemplo para ellos que se puede desarrollar y dar a la comunidad, para dar un impulso a toda la comunidad que usa Kubernetes.

Dmitry : este es probablemente un chip integrador, su característica. Tenemos muchos proyectos y vemos muchas situaciones diferentes. Para nosotros, la forma principal de crear valor agregado es analizar estos casos, encontrar los más comunes y hacerlos lo más baratos posible para nosotros. Estamos haciendo esto activamente. Para mí es difícil hablar sobre Rusia y el mundo, pero tenemos unos 40 ingenieros de DevOps en Kubernetes. No creo que en Rusia haya muchas compañías con un número comparable de especialistas que entiendan Kubernetes, si es que hay alguno.

Entiendo todo sobre el título de ingeniero de DevOps, todos entienden todo y están acostumbrados a llamar a los ingenieros de DevOps, no discutiremos esto. Todos estos 40 maravillosos ingenieros de DevOps enfrentan problemas todos los días y los resuelven, solo analizamos esta experiencia e intentamos resumir. Entendemos que si permanece con nosotros, en un año o dos la herramienta será inútil, porque en algún lugar de la comunidad aparecerá una herramienta lista para usar. No tiene sentido acumular esta experiencia en el interior: es solo una pérdida de tiempo y energía en dev / null. Y por eso no lo sentimos en absoluto. Es un gran placer que publiquemos todo y comprendamos que necesitamos publicarlo, desarrollarlo, promoverlo, promocionarlo, para que las personas puedan usar y agregar su propia experiencia, luego todo crece y vive. Luego, después de dos años, la herramienta no se va a la basura. No es una pena continuar vertiendo energía, porque está claro que alguien está usando su herramienta, y después de dos años todos la están usando.

Esto es parte de nuestra gran estrategia con dapp / werf . No recuerdo cuándo empezamos a hacerlo, al parecer, hace unos 3 años. Inicialmente, generalmente estaba en el caparazón. Fue una súper prueba de concepto, resolvimos algunas de nuestras tareas privadas, ¡resultó! Pero hay problemas con el shell, es imposible construirlo más, la programación en el shell es otra cosa. Teníamos la costumbre de escribir en Ruby, respectivamente, en Ruby rehicimos algo, desarrollamos, desarrollamos, desarrollamos y nos basamos en el hecho de que la comunidad, una multitud que no dice "queremos o no queremos", levanta la nariz de Ruby, no es gracioso Nos dimos cuenta de que deberíamos escribir todo esto en Go, solo para corresponder con el primer párrafo de la lista de verificación: DevOps-tool debería ser un binario estático . En Go o no Go no es tan importante, pero un binario estático escrito en Go es mejor.

Esfuerzo gastado, reescribió Dapp en Go y lo nombró werf. Dapp ya no es compatible, no se desarrolla, funciona en alguna versión más reciente, pero hay una ruta de actualización absoluta a la parte superior, y puede seguirla.

¿Por qué se creó Dapp?

- ¿Puede decirnos brevemente por qué se creó Dapp, qué problemas resuelve?

Dmitry : La primera razón en la asamblea. Inicialmente, tuvimos fuertes problemas de compilación cuando Docker no sabía cómo realizar varias etapas, y lo hicimos solos. Luego tuvimos un montón de preguntas con la imagen de limpieza. Todos los que fabrican CI / CD, más temprano que tarde, se enfrentan al problema de que hay un montón de imágenes recopiladas, de alguna manera debe limpiar lo que no se necesita y dejar lo que se necesita.

La segunda razón está en el despliegue. Sí, existe Helm, pero solo resuelve parte de los problemas. Irónicamente, está escrito que "Helm - el Administrador de paquetes para Kubernetes". A saber que "el". También están las palabras "Administrador de paquetes": ¿cuál es la expectativa habitual del Administrador de paquetes? Decimos: "Administrador de paquetes: ¡entregue el paquete!" y esperamos que nos diga: "El paquete ha sido entregado".

Es interesante que digamos: "Helm, pon el paquete", y cuando responde que lo ha instalado, resulta que acaba de comenzar la instalación. Kubernetes señaló: "¡Ejecute esta cosa!", Pero comenzó o no, funciona o no. Helm no resuelve este problema en absoluto.

Resulta que Helm es solo un preprocesador de texto que carga datos en Kubernetes.

Pero queremos saber en el marco de cualquier implementación: ¿la aplicación se ha implementado para producir o no? La implementación del producto significa que la aplicación fue allí, que se implementó una nueva versión y que al menos no se bloqueó y responde correctamente. Helm no resuelve este problema. Para resolverlo, debes gastar mucha energía, porque debes darle a Kubernetes la orden de desplegarse y monitorear lo que sucede allí, ya sea que haya cambiado o no. Y también hay un montón de tareas relacionadas con la implementación, la limpieza y el ensamblaje.

Planes

Este año iremos al desarrollo local. Queremos llegar a lo que solía ser en Vagrant: escribimos "vagabundo" e implementamos máquinas virtuales. Queremos llegar a un estado en el que haya un proyecto en Git, escribimos "werf up" allí, y genera una copia local de este proyecto, implementado en un mini-Kub local, con todos los directorios convenientes para el desarrollo conectados. Dependiendo del lenguaje de desarrollo, esto se hace de diferentes maneras, pero, sin embargo, es conveniente realizar el desarrollo local bajo los archivos montados.

El siguiente paso para nosotros es invertir fuertemente en la comodidad para los desarrolladores . Para implementar rápidamente un proyecto localmente, con una herramienta, para completar, ingrese a Git, y también se implementará en la etapa o las pruebas, dependiendo de las tuberías, y luego irá al producto con la misma herramienta. Esta unidad, unificación, reproducibilidad de la infraestructura desde el entorno local hasta la venta es un momento muy importante para nosotros. Pero esto aún no está en werf, solo planea hacerlo.

Pero el camino hacia dapp / werf siempre ha sido el mismo que con Kubernetes al principio. Nos topamos con problemas, los solucionamos con soluciones alternativas: se nos ocurrió algún tipo de soluciones para nosotros mismos en el shell, en cualquier cosa. Luego, estas soluciones intentaron de alguna manera enderezar, generalizar y consolidar en binarios en este caso, que simplemente compartimos.

Hay otra visión de toda esta historia, con analogías.

Kubernetes es un cuadro de automóvil con motor. No hay puertas, ventanas, una radio, árboles de Navidad, nada en absoluto. Solo el cuadro y el motor. Y ahí está Helm, este es el volante. Genial: hay un volante, pero aún necesita un pasador de dirección, cremallera de dirección, caja de cambios y ruedas, pero sin ellos nada.

En el caso de werf, este es otro componente de Kubernetes. Solo ahora en nuestra versión alfa de werf, por ejemplo, Helm se compila en werf por completo, porque estamos cansados ​​de hacerlo nosotros mismos. Hay muchas razones para hacer esto, en detalle sobre por qué compilamos Helm en su conjunto junto con la caña dentro de werf, lo diré solo en el informe sobre RIT ++ .

Ahora werf es un componente más integrado. Obtenemos un volante ya preparado, un pasador de dirección: no soy muy bueno con los automóviles, pero este es un bloque grande que ya resuelve una gama bastante amplia de tareas. No necesitamos escalar el catálogo nosotros mismos, recoger una parte a otra, pensar en cómo sujetarlos entre sí. Obtenemos una cosechadora lista para usar que resuelve de inmediato un gran conjunto de tareas. Pero en su interior se compone de los mismos componentes de código abierto, también utiliza Docker para el ensamblaje, Helm para parte de la funcionalidad y hay varias otras bibliotecas. Esta es una herramienta integrada para obtener CI / CD rápido y convenientemente listo para usar.

¿Kubernetes es difícil de mantener?

- Hablas de la experiencia que comenzaste a usar Kubernetes, este es un cuadro, un motor para ti, y que puedes colgar muchas cosas diferentes en él: cuerpo, volante, sujetar pedales, asientos. La pregunta es: ¿qué tan difícil es el apoyo de Kubernetes para usted? Tienes una gran experiencia, ¿cuánto tiempo y recursos te lleva apoyar Kubernetes por separado de todo lo demás?

Dmitry : Esta es una pregunta muy difícil y para responder, debe comprender qué es el apoyo y qué queremos de Kubernetes. Tal vez lo va a revelar?

- Hasta donde yo sé y por lo que veo, ahora muchos equipos quieren probar Kubernetes. Todos se pusieron a su lado, se pusieron de rodillas. Tengo la sensación de que las personas no siempre entienden la complejidad de este sistema.

Dmitry : Eso es.

- ¿Qué tan difícil es tomar y entregar Kubernetes sin nada que lo haga listo para la producción?

Dmitry : ¿Crees lo difícil que es trasplantar un corazón? Entiendo, la pregunta es comprometedora. Llevar con un bisturí y no cometer un error no es tan difícil. Si le dicen dónde cortar y dónde coser, entonces el procedimiento en sí es simple. Es difícil garantizar de vez en cuando que todo saldrá bien.

Pon Kubernetes y haz que funcione simple: ¡chica! - Entregado, hay un montón de métodos de instalación. Pero, ¿qué sucede cuando surgen problemas?

Siempre surgen preguntas: ¿qué aún no hemos tenido en cuenta? ¿Qué no hemos hecho todavía? ¿Qué parámetros del kernel de Linux indicaron incorrectamente? Señor, ¿los señalamos? ¿Qué componentes de Kubernetes hemos entregado y cuáles no? Surgen miles de preguntas y, para responderlas, debe cocinar durante 15-20 años en esta industria.

Tengo un nuevo ejemplo sobre este tema que puede revelar el significado del problema “¿Es difícil mantener Kubernetes?”. Hace algún tiempo, consideramos seriamente si deberíamos intentar implementar Cilium como una red en Kubernetes.

Déjame explicarte qué es Cilium. Kubernetes tiene muchas implementaciones diferentes del subsistema de red, y una de ellas es genial: es Cilium. Cual es su significado En el kernel hace algún tiempo se hizo posible escribir ganchos para el kernel que de alguna manera invaden el subsistema de red y varios otros subsistemas y le permiten evitar grandes fragmentos en el kernel.

El núcleo de Linux históricamente tiene una ruta IP, un superfiltro, puentes y muchos componentes antiguos diferentes que tienen 15, 20, 30 años. En general, funcionan, todo está bien, pero ahora han hecho un contenedor de contenedores, y parece una torre de 15 ladrillos uno encima del otro, y uno se para sobre una pierna, una sensación extraña. Este sistema se ha desarrollado históricamente con muchos matices, como un apéndice en el cuerpo. En algunas situaciones, hay problemas con el rendimiento, por ejemplo.

Hay un maravilloso BPF y la capacidad de escribir ganchos para el núcleo: los chicos escribieron sus ganchos para el núcleo. El paquete llega al kernel de Linux, lo sacan directamente en la entrada, lo procesan ellos mismos sin puentes, sin TCP, sin la pila de IP; en resumen, omiten todo lo que está escrito en el kernel de Linux e inmediatamente lo escupen en el contenedor.

Que paso Rendimiento muy bueno, características geniales, ¡simplemente genial! Pero miramos esto y vemos que en cada máquina hay un programa que se conecta a la API de Kubernetes y, según los datos recibidos de esta API, genera código C y compila los binarios que carga en el núcleo para que estos ganchos funcionen en el espacio del núcleo .

¿Qué pasa si algo sale mal? No lo sabemos Para comprender esto, debe leer todo este código, comprender toda la lógica, y esto es sorprendente, qué difícil. Pero, por otro lado, existen estos puentes, filtros de red, enrutamiento ip: no leí sus fuentes y 40 ingenieros que trabajan en nuestra empresa también. Quizás algunas piezas entiendan unidades.

¿Y cuál es la diferencia? Resulta que hay una ruta IP, el kernel de Linux, y hay una nueva herramienta: cuál es la diferencia, no entendemos ni uno ni el otro. Pero tenemos miedo de usar el nuevo, ¿por qué? Porque si la herramienta tiene 30 años, se han encontrado todos los errores durante 30 años, todos los rastrillos han llegado y no necesita saberlo todo: funciona como una caja negra y siempre funciona. Todos saben qué destornillador de diagnóstico colocar en qué lugar, qué tcpdump en qué punto comenzar. Todos conocen bien las utilidades de diagnóstico y entienden cómo funciona este conjunto de componentes en el kernel de Linux, no cómo funciona, sino cómo usarlo.

Y Cilium, increíblemente genial, no tiene 30 años, todavía no está maduro. Con Kubernetes el mismo problema, copie. Que Cilium está configurado perfectamente, que Kubernetes está configurado perfectamente, pero cuando algo sale mal en la producción, ¿puedes entender rápidamente qué salió mal en una situación crítica?

Cuando decimos que es difícil mantener Kubernetes, no, es muy simple y sí, es increíblemente difícil. Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . Esto no es asi.

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . Que es esto Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

serverless

- Si mira un poco más hacia el futuro, entonces, tratando de resolver el problema de la falta de dolor de cabeza con la infraestructura, con la velocidad de implementación y la velocidad de cambio de aplicaciones, aparecen nuevas soluciones, por ejemplo, sin servidor. ¿Siente algún potencial en esta dirección y, digamos así, un peligro para Kubernetes y soluciones similares?

Dmitry : Aquí tenemos que hacer un comentario nuevamente, que no soy un visionario que mira hacia adelante y dice: ¡será así! Aunque acabo de hacer lo mismo. Miro mis pies y veo un montón de problemas allí, por ejemplo, cómo funcionan los transistores en una computadora. Gracioso, ¿eh? Nos encontramos con algunos errores en la CPU.

Hacer que el servidor sea lo suficientemente confiable, económico, eficiente y conveniente, resolviendo todos los problemas del ecosistema. Entonces estoy de acuerdo con Elon Mask en que necesitamos un segundo planeta para tolerar las fallas de la humanidad. Aunque no sé lo que está diciendo, entiendo que yo no estoy preparado para volar a Marte y que no será mañana.

Con sin servidor, está claro que esto es lo ideológicamente correcto, como tolerancia a fallas para la humanidad: dos planetas son mejores que uno. ¿Pero cómo hacerlo ahora? Enviar una expedición no es un problema si nos concentramos en este esfuerzo. Enviar varias expediciones y poblar a miles de personas allí, creo, también es realista. Pero es completamente tolerante a fallas que la mitad de la humanidad viva allí, me parece ahora imposible, no considerado.

Con uno a uno sin servidor: la cosa es genial, pero está lejos de los problemas de 2019. Más cerca de 2030: vivamos para verlo. No tengo dudas de que sobreviviremos, ciertamente sobreviviremos (repetir antes de acostarse), pero ahora tenemos que resolver otros problemas. Es como creer en un fabuloso pony Rainbow. Sí, un par de por ciento de los casos se resuelven, y se resuelven perfectamente, pero subjetivamente sin servidor es un arcoíris ... Para mí, este tema está demasiado lejos y es demasiado incomprensible. No estoy listo para hablar En 2019, con serverless, no escribirás una sola aplicación.

Cómo se desarrollará Kubernetes

"A medida que avanzamos hacia este futuro potencialmente hermoso y distante, ¿qué creen que desarrollará Kubernetes y el ecosistema que lo rodea?"

Dmitry : Pensé mucho en esto y tengo una respuesta clara. El primero es con estado: aún sin estado es más fácil de hacer. Kubernetes inicialmente invirtió más en él, todo comenzó con eso. La apatridia funciona casi perfectamente en Kubernetes, no hay nada de qué quejarse. Según Statefull todavía hay muchos problemas, o más bien, matices. Todo ya funciona bien para nosotros allí, pero lo estamos. Para que esto funcione para todos, necesita al menos un par de años más. Este no es un indicador calculado, sino mi sensación desde la cabeza.

En resumen, Statefull necesita, y se desarrollará mucho, porque todas nuestras aplicaciones tienen estado, no hay aplicaciones sin estado. Esto es una ilusión, siempre necesitas algún tipo de base de datos y algo más. Statefull es la rectificación de todo lo que es posible, la corrección de todos los errores, la mejora de todos los problemas que enfrenta actualmente, llamémoslo adopción.

El nivel de lo desconocido, el nivel de problemas no resueltos, el nivel de probabilidad de encontrar algo, caerá bruscamente. Esta es una historia importante. Y los operadores, todo lo relacionado con la codificación de la lógica de administración, la lógica de control, para obtener un servicio fácil: servicio fácil de MySQL, servicio fácil de RabbitMQ, servicio fácil de Memcache, en general, todos estos componentes que debemos garantizar que funcionen de inmediato. Esto solo resuelve el dolor de que queremos una base de datos, pero no queremos administrarla, o queremos Kubernetes, pero no queremos administrarla.

Esta historia con el desarrollo de operadores de una forma u otra será importante en los próximos años.

Creo que la facilidad de uso debería aumentar considerablemente: la caja se volverá cada vez más negra, más y más confiable, con giros cada vez más simples.

Una vez escuché la antigua entrevista de Isaac Asimov de los 80 en YouTube en Saturday Night Live, un programa similar a Urgant que es simplemente interesante. Allí se le preguntó sobre el futuro de las computadoras. Dijo que el futuro es simple, como fue el caso con la radio. La radio fue originalmente una cosa complicada. Para atrapar la ola, tardó 15 minutos en girar los giros, girar los pinchos y, en general, saber cómo funciona todo, comprender la física de la transmisión de ondas de radio. Como resultado, un giro permaneció en la radio.

Ahora en 2019, ¿qué radio? En el auto, la radio encuentra todas las ondas, el nombre de las estaciones. La física del proceso no ha cambiado en 100 años, la facilidad de uso ha cambiado. Ahora, y no solo ahora, ya en 1980, cuando hubo una entrevista con Azimov, todos usaron la radio y nadie pensó en cómo se organizó. Siempre funcionó, es un hecho.

Azimov luego dijo que sería similar con las computadoras: la facilidad de uso aumentaría . Si en 1980 necesita una educación especial para presionar botones en una computadora, en el futuro esto no será así.

Tengo la sensación de que con Kubernetes y con la infraestructura, la facilidad de uso también aumentará dramáticamente. Esto, en mi opinión, es obvio: se encuentra en la superficie.

¿Qué hacer con los ingenieros?

- ¿Y qué pasará con los ingenieros, administradores de sistemas que apoyan a Kubernetes?

Dmitry : ¿Y qué pasó con el contador después de la aparición de 1C? Sobre lo mismo. Antes de eso, pensaron en una hoja de papel, ahora en el programa. La productividad laboral ha aumentado en órdenes de magnitud, y el trabajo en sí no ha desaparecido de esto. Anteriormente, 10 ingenieros necesitaban atornillar la bombilla, pero ahora uno será suficiente.

La cantidad de software y la cantidad de tareas, me parece, ahora está creciendo a una velocidad mayor que los nuevos DevOps y la eficiencia está aumentando. Hay una escasez específica en el mercado y durará mucho tiempo. Más tarde, todo entrará en una determinada norma, en la que aumentará la eficiencia del trabajo, se volverá más sin servidor, conectarán una neurona a Kubernetes, que seleccionará todos los recursos como debería, y en general hará todo como debería: la persona se escapa y no se molesta.

Pero de todos modos, alguien tendrá que tomar decisiones. Está claro que el nivel de calificación y especialización de esta persona es mayor. Ahora en el departamento de contabilidad no necesita 10 empleados que guarden libros para que su mano no se canse. Simplemente no es necesario. El sistema de gestión electrónica de documentos escanea y reconoce automáticamente muchos documentos. Un jefe de contabilidad inteligente es suficiente, ya con habilidades mucho más grandes, con una buena comprensión.

En general, tal camino en todos los sectores. Es lo mismo con los automóviles: anteriormente, un mecánico de automóviles y tres conductores estaban unidos al automóvil. Ahora conducir un automóvil es el proceso más simple en el que todos participamos todos los días. Nadie piensa que un automóvil es algo complicado.

DevOps o la ingeniería de sistemas no irán a ninguna parte: aumentará la eficiencia operativa y de alto nivel.

- También escuché una idea interesante de que, de hecho, el trabajo aumentará.

Dmitry : ¡Por supuesto, cien por ciento! Porque la cantidad de software que escribimos está en constante crecimiento. El número de problemas que resolvemos con el software está en constante crecimiento. La cantidad de trabajo está creciendo. Ahora el mercado de DevOps está terriblemente sobrecalentado. Esto es evidente por las expectativas salariales. En el buen sentido, sin entrar en detalles, debería haber juniors que quieran X, middles que quieran 1.5X y seniors que quieran 2X. Y ahora, si observa el mercado salarial de DevOps de Moscú, el junior quiere de X a 3X y el senior quiere de X a 3X.

Nadie sabe cuánto cuesta. Su nivel de salario se mide por su confianza: un manicomio completo, para ser honesto, un mercado terriblemente sobrecalentado.

Por supuesto, esta situación cambiará muy pronto, debería producirse cierta saturación. Con el desarrollo de software, este no es el caso; a pesar de que todos necesitan desarrolladores y todos necesitan buenos desarrolladores, el mercado comprende cuánto cuesta, la industria se ha calmado. Este no es el caso con DevOps.

- Por lo que escuché, llegué a la conclusión de que el administrador del sistema actual no debería estar muy preocupado, pero es hora de descargar habilidades y prepararse para el hecho de que mañana habrá más trabajo, pero estará más calificado.

Dmitry : absolutamente. En general, vivimos en 2019 y la regla de vida es esta: aprendizaje de por vida : aprendemos toda nuestra vida . Me parece que ahora todo el mundo lo sabe y lo siente, pero saber un poco es necesario. Todos los días tenemos que cambiar. Si no lo hacemos, tarde o temprano nos dejarán al margen de la profesión.

Prepárese para giros bruscos de 180 grados. No excluyo una situación en la que algo cambia dramáticamente, se les ocurre algo nuevo, sucede. Hop! - Y ahora actuamos de manera diferente. Es importante estar preparado para esto y no vaporizar. Puede suceder que mañana todo lo que haga sea innecesario; nada, lo he estudiado toda mi vida y estoy listo para aprender algo más. Esto no es un problema No debe tener miedo a la seguridad laboral, pero debe estar preparado para aprender constantemente algo nuevo.

Deseos y un minuto de publicidad

- ¿Tendrás algún deseo?

Dmitry : Sí, tengo algunos deseos.

El primero y mercantil - suscríbete a YouTube . Estimados lectores, vayan a YouTube y suscríbase a nuestro canal. En aproximadamente un mes, comenzaremos una expansión activa en el servicio de video y tendremos mucho contenido educativo sobre Kubernetes, abierto y diferente: desde cosas prácticas, hasta laboratorios, hasta cosas teóricas fundamentales y profundas y cómo aplicar Kubernetes a nivel de principios y patrones.

El segundo deseo mercantil: ir a GitHub y poner estrellas, porque las comemos. Si no nos das estrellas, no tendremos nada para comer. Es como el maná en un juego de computadora. Estamos haciendo algo, haciendo, intentando, alguien dice que estas son bicicletas terribles, alguien que generalmente todo está mal, y continuamos y actuamos con absoluta honestidad. Vemos el problema, lo resolvemos y compartimos nuestra experiencia. Por lo tanto, denos un asterisco, no disminuirá de usted, pero vendrá a nosotros, porque los comemos.

El tercer deseo importante y ya no mercantil: dejar de creer en los cuentos de hadas . Ustedes son profesionales DevOps es una profesión muy seria y responsable. Deja de jugar en el lugar de trabajo. Deja que hagas clic y lo entenderás. Imagine que vendrá al hospital y allí el médico experimentará con usted. Entiendo que esto puede ser ofensivo para alguien, pero lo más probable es que no se trate de ti, sino de otra persona. Dile a otros que se detengan también. Realmente arruina la vida para todos nosotros, muchos comienzan a relacionarse con la explotación, con los administradores y DevOps, como con los tipos que nuevamente rompieron algo. Esto fue "roto" con mayor frecuencia debido al hecho de que fuimos a jugar, y no vimos con una fría conciencia de que era así, sino de esa manera.

Esto no significa que no necesite experimentar. Necesitamos experimentar, lo hacemos nosotros mismos. Para ser sincero, nosotros mismos también jugamos a veces; esto, por supuesto, es muy malo, pero nada humano es ajeno a nosotros. Declaremos 2019 el año de experimentos serios y reflexivos, no de juegos en prod. Probablemente sí.

- Muchas gracias!

Dmitry : Gracias, Vitaly, tanto por el tiempo como por la entrevista. Estimados lectores, muchas gracias si de repente llegaron a este punto. Espero que al menos un par de pensamientos te hayamos traído.

En una entrevista, Dmitry tocó werf. Ahora es un cuchillo suizo universal que resuelve casi todas las tareas. Pero ese no fue siempre el caso. En DevOpsConf en el festival RIT ++ , Dmitry Stolyarov hablará sobre esta herramienta en detalle. El informe "werf es nuestra herramienta para CI / CD en Kubernetes" tendrá todo: problemas y matices ocultos de Kubernetes, soluciones a estas dificultades y la implementación actual de werf en detalle. Únase el 27 y 28 de mayo, crearemos herramientas ideales.