{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes conquistar\u00e1 el mundo. \u00bfCu\u00e1ndo y c\u00f3mo?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En la v\u00edspera de DevOpsConf<\/a><\/noindex> Vitaliy Khabarov<\/b> realiz\u00f3 una entrevista con\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), director t\u00e9cnico y cofundador de la empresa \u00abFlant\u00bb. Vitaliy pregunt\u00f3 a Dmitry sobre lo que hace \u00abFlant\u00bb, sobre Kubernetes, el desarrollo del ecosistema, el soporte. Discutieron por qu\u00e9 es necesario Kubernetes y si realmente es necesario. Tambi\u00e9n hablaron sobre microservicios, Amazon AWS, el enfoque de \u2018Me siento afortunado\u2019 en DevOps, el futuro de Kubernetes, por qu\u00e9, cu\u00e1ndo y c\u00f3mo dominar\u00e1 el mundo, las perspectivas de DevOps y a qu\u00e9 deben prepararse los ingenieros en un futuro brillante y cercano con la simplificaci\u00f3n y las redes neuronales.<\/p>\n

Escucha la entrevista original<\/a><\/noindex> en forma de p\u00f3dcast en DevOps Deflop, un p\u00f3dcast en ruso sobre DevOps, y abajo la versi\u00f3n escrita. <\/p>\n

\"Kubernetes
\n
\nAqu\u00ed y adelante, las preguntas las hace Vitaliy Khabarov<\/a><\/noindex> un ingeniero de Express42.
\n<\/a><\/noindex><\/p>\n

Sobre \u00abFlant\u00bb<\/h2>\n

\n\u2014 Dima, hola. T\u00fa eres el director t\u00e9cnico de \u00abFlant<\/a><\/noindex>\u00bb y tambi\u00e9n su fundador. Cu\u00e9ntame, por favor, qu\u00e9 hace la empresa y qu\u00e9 haces t\u00fa en ella.<\/b><\/p>\n

\"KubernetesDmitry<\/b>: Desde fuera parece que somos esos chicos que van por ah\u00ed, instalando Kubernetes a todos y haciendo algo con \u00e9l. Pero no es as\u00ed. Comenzamos como una empresa que se ocupa de Linux, pero desde hace mucho tiempo nuestra actividad principal es el mantenimiento de proyectos de producci\u00f3n y de alta carga llave en mano. Generalmente, construimos toda la infraestructura desde cero y luego nos hacemos responsables de ella durante mucho tiempo. Por lo tanto, el trabajo principal que realiza \u00abFlant\u00bb, por lo que recibe dinero, es asumir la responsabilidad y llevar a cabo la producci\u00f3n llave en mano<\/b>.
\n

\n

\nYo, como director t\u00e9cnico y uno de los fundadores de la empresa, estoy todo el d\u00eda pensando en c\u00f3mo aumentar la disponibilidad de la producci\u00f3n, simplificar su operaci\u00f3n, hacer la vida m\u00e1s f\u00e1cil a los administradores y mejorar la experiencia de los desarrolladores.<\/p>\n

Sobre Kubernetes<\/h2>\n

\n\u2014 \u00daltimamente he visto muchas conferencias de \u00abFlant\u00bb y\u00a0art\u00edculos<\/a><\/noindex> sobre Kubernetes. \u00bfC\u00f3mo llegaron a \u00e9l?<\/b><\/p>\n

Dmitry<\/b>: Ya he contado esto muchas veces, pero no me importa repetirlo en absoluto. Creo que es correcto volver a hablar de este tema, porque hay confusi\u00f3n entre la causa y el efecto.<\/p>\n

Realmente necesit\u00e1bamos una herramienta. Nos enfrentamos a un mont\u00f3n de problemas, luchamos, los superamos con diferentes parches y experimentamos la necesidad de una herramienta. Probamos muchas opciones diferentes, construimos nuestros propios sistemas y acumulamos experiencia. Poco a poco, llegamos al punto en que comenzamos a usar Docker casi tan pronto como apareci\u00f3, alrededor de 2013. En el momento de su aparici\u00f3n, ya ten\u00edamos mucha experiencia con contenedores, ya hab\u00edamos escrito algo similar a \"Docker\" \u2014 algunos parches propios en Python. Con la llegada de Docker, tuvimos la oportunidad de deshacernos de esos parches y usar una soluci\u00f3n confiable y respaldada por la comunidad.<\/p>\n

La historia con Kubernetes es similar. Para el momento en que comenz\u00f3 a ganar tracci\u00f3n \u2014 para nosotros fue la versi\u00f3n 1.2 \u2014 ya ten\u00edamos un mont\u00f3n de parches tanto en Shell como en Chef, que intent\u00e1bamos orquestar con Docker. Mir\u00e1bamos seriamente hacia Rancher y otras soluciones, pero ah\u00ed apareci\u00f3 Kubernetes, que est\u00e1 implementado exactamente como lo har\u00edamos nosotros o incluso mejor. No tenemos nada de qu\u00e9 quejarnos.<\/p>\n

S\u00ed, hay alg\u00fan tipo de defecto aqu\u00ed, hay algunos defectos all\u00ed \u2014 muchos defectos, y 1.2 es realmente aterrador, pero\u2026 Kubernetes es como un edificio en construcci\u00f3n \u2014 miras el proyecto y entiendes que ser\u00e1 genial. Si el edificio tiene ahora una base y dos pisos, comprendes que es mejor no mudarse todav\u00eda, pero con el software no hay tales problemas \u2014 ya se puede usar.<\/p>\n

No hubo un momento en el que pens\u00e1ramos si deb\u00edamos usar Kubernetes o no. Lo esper\u00e1bamos mucho antes de que apareciera y tratamos de construir nuestras propias alternativas.<\/p><\/blockquote>\n

<\/p>\n

Alrededor de Kubernetes<\/h2>\n

\n\u2014 \u00bfParticipan directamente en el desarrollo de Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: De manera indirecta. M\u00e1s bien participamos en el desarrollo del ecosistema. Enviamos una cierta cantidad de pull requests: en Prometheus, en varios operadores, en Helm \u2014 al ecosistema. Desafortunadamente, no puedo seguir todo lo que hacemos y puedo estar equivocado, pero desde nuestra parte no hay ning\u00fan pull request en el n\u00facleo.<\/p>\n

\u2014 A pesar de esto, \u00bfdesarrollan muchas de sus propias herramientas alrededor de Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: La estrategia es esta: vamos y hacemos pull requests en todo lo que ya existe. Si no aceptan pull requests, simplemente los forkeamos para nosotros y seguimos viviendo hasta que sean aceptados con nuestras versiones. Luego, cuando llegue a upstream, regresamos a la versi\u00f3n upstream.<\/p>\n

Por ejemplo, tenemos el operador de Prometheus, con el que hemos estado alternando en el upstream de nuestra compilaci\u00f3n unas 5 veces, probablemente. Necesitamos alguna funci\u00f3n, enviamos un pull request, necesitamos implementarla ma\u00f1ana y no queremos esperar a que la liberen en el upstream. Por lo tanto, estamos construyendo nuestra propia versi\u00f3n con la funci\u00f3n que necesitamos en todos nuestros cl\u00fasteres. Luego, esto, por ejemplo, en el upstream lo llevan con las palabras: \"Chicos, hagamos esto para un caso m\u00e1s general\", nosotros, o alguien m\u00e1s, lo completamos y eventualmente se fusiona nuevamente.<\/p>\n

Todo lo que existe, nos esforzamos por desarrollarlo.<\/b>Muchos elementos que a\u00fan no existen, o que se han pensado pero no se han implementado, los hacemos. Y no porque nos guste el proceso en s\u00ed o la construcci\u00f3n de bicicletas como industria, sino simplemente porque necesitamos esta herramienta. A menudo nos preguntan por qu\u00e9 hicimos tal o cual cosa. La respuesta es simple: porque necesit\u00e1bamos avanzar, resolver alg\u00fan problema pr\u00e1ctico, y lo hicimos con esta herramienta.<\/p>\n

El camino siempre es este: buscamos detenidamente y, si no encontramos ninguna soluci\u00f3n, como hacer un troleb\u00fas a partir de un pan, hacemos nuestro propio pan y nuestro propio troleb\u00fas.<\/p><\/blockquote>\n

<\/p>\n

Herramientas de Flant<\/h2>\n

\nS\u00e9 que en Flant ahora hay operadores addon, operadores shell, herramientas dapp\/werf. Como entiendo, es la misma herramienta en diferentes encarnaciones. Tambi\u00e9n entiendo que dentro de Flant hay muchas otras herramientas diferentes. \u00bfEs as\u00ed?<\/b><\/p>\n

Dmitry<\/b>En nuestro GitHub hay muchas m\u00e1s cosas. De lo que puedo recordar ahora, tenemos statusmap, un panel para Grafana que ha sido muy bien recibido. Se menciona en pr\u00e1cticamente cada segundo art\u00edculo sobre monitoreo de Kubernetes en Medium. Es imposible resumir qu\u00e9 es statusmap; se necesita un art\u00edculo aparte, pero es una herramienta muy \u00fatil para monitorear el estado en el tiempo, ya que a menudo necesitamos mostrar el estado en el tiempo en Kubernetes. Tambi\u00e9n tenemos LogHouse, que es una herramienta basada en ClickHouse y un poco de magia negra para recopilar logs en Kubernetes.<\/p>\n

\u00a1Muchas utilidades! Y habr\u00e1 m\u00e1s, porque una serie de soluciones internas se lanzar\u00e1n este a\u00f1o. De las grandes, hay un mont\u00f3n de addons para Kubernetes, como c\u00f3mo instalar correctamente el sert manager\u2014una herramienta para gestionar certificados, c\u00f3mo instalar Prometheus con un mont\u00f3n de complementos\u2014son alrededor de veinte binaries diferentes que exportan datos y recopilan algo, adem\u00e1s Prometheus tiene una gr\u00e1fica espectacular y alertas. Todo esto es simplemente un mont\u00f3n de addons para Kubernetes que se instalan en el cl\u00faster, y se transforma de uno simple en uno impresionante, sofisticado, autom\u00e1tico, en el que muchas cuestiones ya est\u00e1n resueltas. S\u00ed, hacemos muchas cosas.<\/p>\n

Desarrollo del ecosistema<\/h2>\n

\n\u2014 Creo que es una gran contribuci\u00f3n al desarrollo de esta herramienta y sus m\u00e9todos de uso. \u00bfPuedes estimar qui\u00e9n m\u00e1s podr\u00eda hacer una contribuci\u00f3n similar al desarrollo del ecosistema?<\/b><\/p>\n

Dmitry<\/b>: En Rusia, de las empresas que operan en nuestro mercado, no hay nadie ni cerca<\/b>. Por supuesto, es una declaraci\u00f3n audaz, porque hay grandes jugadores como Mail y Yandex\u2014they tambi\u00e9n est\u00e1n haciendo algo con Kubernetes, pero incluso ellos no se acercan a la contribuci\u00f3n de empresas en todo el mundo, que hacen mucho m\u00e1s de lo que hacemos nosotros. Es dif\u00edcil comparar a 'Flant' con un equipo de 80 personas y a Red Hat, que tiene 300 ingenieros solo para Kubernetes, si no me equivoco. Es complicado comparar. En nuestro departamento de I+D somos 6 personas, incluy\u00e9ndome, que crean todas nuestras herramientas. 6 personas contra 300 ingenieros de Red Hat\u2014es un poco raro comparar.<\/p>\n

\u2014 Sin embargo, cuando incluso estas 6 personas pueden hacer algo realmente \u00fatil y transferible, cuando se enfrentan a un problema pr\u00e1ctico y entregan la soluci\u00f3n a la comunidad\u2014es un caso interesante. Entiendo que en grandes empresas tecnol\u00f3gicas, donde hay su propio desarrollo y un equipo de soporte para Kubernetes, tambi\u00e9n pueden desarrollarse herramientas similares. Es un ejemplo para ellos de lo que se puede desarrollar y entregar a la comunidad, dando un impulso a toda la comunidad que usa Kubernetes.<\/b><\/p>\n

Dmitry<\/b>: Probablemente, esto es una caracter\u00edstica del integrador, su particularidad. Tenemos muchos proyectos y vemos muchas situaciones diferentes. Para nosotros, la principal forma de crear valor agregado es analizar estos casos, encontrar lo com\u00fan y maximizar su reducci\u00f3n de costos para nosotros. Esto es algo en lo que trabajamos activamente. Me resulta dif\u00edcil hablar sobre Rusia y el mundo, pero tenemos alrededor de 40 ingenieros DevOps en la empresa, que se dedican a Kubernetes. No creo que haya muchas empresas en Rusia con una cantidad comparable de especialistas que realmente entiendan Kubernetes, si es que existen.<\/p>\n

Entiendo todo sobre el t\u00edtulo de DevOps Engineer, todos lo comprenden y est\u00e1n acostumbrados a llamar a los ingenieros DevOps ingenieros DevOps, no lo discutiremos. Todos estos 40 maravillosos ingenieros DevOps enfrentan problemas todos los d\u00edas y los resuelven; simplemente analizamos esta experiencia y tratamos de generalizar. Entendemos que si se queda con nosotros internamente, en un a\u00f1o o dos la herramienta ser\u00e1 in\u00fatil, porque en alg\u00fan lugar de la comunidad aparecer\u00e1 un tool listo. No tiene sentido acumular esta experiencia internamente: es solo el despilfarro de recursos y tiempo en dev\/null. As\u00ed que no nos importa en absoluto. Publicamos todo con gran placer y entendemos que es necesario publicar, desarrollar, promocionar y difundir para que las personas usen y a\u00f1adan su experiencia; entonces todo crece y vive. As\u00ed, despu\u00e9s de dos a\u00f1os, la herramienta no termina en la basura. No nos importa seguir invirtiendo recursos, porque es evidente que alguien est\u00e1 utilizando tu herramienta, y despu\u00e9s de dos a\u00f1os, ya la est\u00e1n usando todos.<\/p>\n

Es parte de nuestra gran estrategia con dapp\/werf<\/b>. No recuerdo cu\u00e1ndo comenzamos a hacerlo, parece que hace 3 a\u00f1os. Originalmente estaba en shell. Fue un gran proof of concept, resolvimos algunos de nuestros problemas espec\u00edficos, \u00a1y funcion\u00f3! Pero con shell hay problemas, es imposible escalar m\u00e1s all\u00e1, programar en shell es una tarea complicada. Ten\u00edamos la costumbre de programar en Ruby, por lo que rehicimos algo en Ruby, desarrollamos, desarrollamos, desarrollamos, y llegamos al punto de que la comunidad, la multitud que no dice 'queremos o no queremos', se aleja de Ruby, por muy divertido que parezca. Nos dimos cuenta de que deb\u00edamos escribir todo esto en Go, para cumplir con el primer punto de la lista de verificaci\u00f3n: La herramienta DevOps debe ser un binario est\u00e1tico<\/b>. En Go o no en Go no es tan importante, pero es mejor un binario est\u00e1tico escrito en Go.<\/p>\n

Hemos invertido esfuerzo, reescribimos la dapp en Go y la llamamos werf. La dapp ya no se mantiene, no se desarrolla, funciona en alguna versi\u00f3n final, pero hay una ruta de actualizaci\u00f3n absoluta hacia arriba, y se puede seguir.<\/p>\n

Por qu\u00e9 se cre\u00f3 la dapp<\/h2>\n

\n\u2014 \u00bfPuedes contar brevemente por qu\u00e9 se cre\u00f3 la dapp, qu\u00e9 problemas resuelve?<\/b><\/p>\n

Dmitry<\/b>: La primera raz\u00f3n es la compilaci\u00f3n. Al principio ten\u00edamos serios problemas con la compilaci\u00f3n, cuando Docker no sab\u00eda hacer multi-stage, y lo hicimos por nuestra cuenta. Luego tuvimos un mont\u00f3n m\u00e1s de preguntas sobre la limpieza de im\u00e1genes. Todos los que realizan CI\/CD, m\u00e1s temprano que tarde, se enfrentan al problema de que hay un mont\u00f3n de im\u00e1genes compiladas, necesitas limpiar lo que no se necesita y dejar lo que s\u00ed.<\/p>\n

La segunda raz\u00f3n es el despliegue. S\u00ed, existe Helm, pero solo resuelve una parte de las tareas. Como es ir\u00f3nico, est\u00e1 escrito que \"Helm es el gestor de paquetes para Kubernetes\". Precisamente eso, \"el\". Tambi\u00e9n hay palabras \"Gestor de Paquetes\" \u2014 \u00bfqu\u00e9 expectativas hay normalmente de un Gestor de Paquetes? Decimos: \"Gestor de Paquetes, \u00a1instala el paquete!\" y esperamos que nos diga: \"El paquete ha sido instalado\". <\/p>\n

Es curioso que digamos: \"Helm, instala el paquete\", y cuando responde que lo ha instalado, resulta que solo ha comenzado la instalaci\u00f3n \u2014 le indic\u00f3 a Kubernetes: \"\u00a1Inicia esta cosa!\", pero si se inici\u00f3 o no, si funciona o no, Helm no resuelve esa cuesti\u00f3n en absoluto.<\/p>\n

As\u00ed que resulta que Helm es simplemente un preprocesador de texto que carga datos en Kubernetes.<\/p><\/blockquote>\n

\nPero dentro de cualquier despliegue queremos saber \u2014 \u00bfla aplicaci\u00f3n se ha implementado en producci\u00f3n o no? Implementarse en producci\u00f3n significa que la aplicaci\u00f3n ha sido desplegada, se ha lanzado una nueva versi\u00f3n y no se cae y responde correctamente. Helm no resuelve esta tarea. Para resolverla, hay que invertir mucho esfuerzo porque es necesario dar la orden a Kubernetes para que implemente y seguir lo que sucede \u2014 si se ha desplegado o no.<\/p>\n

Planes<\/h2>\n

\nEste a\u00f1o comenzaremos con el desarrollo local. Queremos llegar a un estado como el que ten\u00edamos anteriormente con Vagrant: ingresamos 'vagrant up' y nuestras m\u00e1quinas virtuales se desplegaban. Queremos llegar a un estado en el que tengamos un proyecto en Git, escribimos 'werf up' y se levanta una copia local de ese proyecto, desplegada en un mini-Kub local, con todos los directorios conectados y listos para el desarrollo. Dependiendo del lenguaje de programaci\u00f3n, esto se ejecuta de diferentes maneras, pero, en cualquier caso, queremos facilitar el desarrollo local con archivos montados.<\/p>\n

El siguiente paso para nosotros es invertir fuertemente en la comodidad para los desarrolladores<\/b>. Para poder desplegar r\u00e1pidamente un proyecto localmente con una sola herramienta, desarrollarlo, subirlo a Git, y que se despliegue exactamente igual en stage o en pruebas, dependiendo de los pipelines, y luego usar la misma herramienta para ir a producci\u00f3n. Esta unidad, unificaci\u00f3n y reproducibilidad de la infraestructura desde el entorno local hasta producci\u00f3n es un aspecto muy importante para nosotros. Pero esto a\u00fan no est\u00e1 presente en werf; solo planeamos hacerlo.<\/p>\n

Sin embargo, el camino hacia dapp\/werf siempre ha sido similar al de Kubernetes al principio. Enfrentamos problemas, los solucionamos de manera indirecta, creando algunas soluciones en shell o lo que fuera. Luego intentamos simplificar, generalizar y consolidar esos soluciones en binarios que, en este caso, simplemente compartimos.<\/p>\n

Hay otra perspectiva sobre toda esta historia, con analog\u00edas. <\/p>\n

Kubernetes es el chasis de un autom\u00f3vil con su motor. No hay puertas, cristales, receptor de radio, nada, solo el marco y el motor. Y Helm es el volante. Es genial tener el volante, pero tambi\u00e9n se necesitan el pasador de direcci\u00f3n, la cremallera, la transmisi\u00f3n y las ruedas; sin ellos, no sirve de nada.<\/p><\/blockquote>\n

\nEn el caso de werf, es otro componente para Kubernetes. Actualmente, en nuestra versi\u00f3n alfa de werf, por ejemplo, Helm se compila completamente dentro de werf, porque ya est\u00e1bamos cansados de hacerlo nosotros mismos. Hay muchas razones para hacerlo de esta manera; explicar\u00e9 en detalle por qu\u00e9 hemos incorporado helm junto con tiller completamente dentro de werf en una presentaci\u00f3n en RIT++<\/a><\/noindex>.<\/p>\n

Ahora, werf es un componente m\u00e1s integrado. Nos proporciona un volante listo, un v\u00e1stago de direcci\u00f3n; no tengo mucho conocimiento sobre autom\u00f3viles, pero es un gran bloque que resuelve una amplia gama de tareas. No necesitamos buscar en el cat\u00e1logo, seleccionar una pieza para otra, pensar en c\u00f3mo atornillarlas entre s\u00ed. Obtenemos una cosechadora lista que resuelve un mont\u00f3n de tareas de entrada. Pero en su interior, est\u00e1 construido con los mismos componentes de c\u00f3digo abierto, tambi\u00e9n utiliza Docker para la construcci\u00f3n, Helm para parte de la funcionalidad y hay varias otras bibliotecas. Es una herramienta integrada para obtener r\u00e1pida y c\u00f3modamente un CI\/CD impresionante desde la caja.<\/p>\n

\u00bfEs dif\u00edcil mantener Kubernetes?<\/h2>\n

\n\u2014 Est\u00e1s hablando sobre la experiencia de haber comenzado a usar Kubernetes, este es su marco, su motor, y se puede agregar mucho m\u00e1s: chasis, volante, atornillar pedales, asientos. Surge la pregunta: \u00bfcu\u00e1n dif\u00edcil es para ustedes mantener Kubernetes? Tienen una rica experiencia, \u00bfcu\u00e1nto tiempo y recursos les lleva espec\u00edficamente mantener Kubernetes independientemente de todo lo dem\u00e1s?<\/b><\/p>\n

Dmitry<\/b>: Es una pregunta muy complicada y para responderla, necesitamos entender qu\u00e9 significa mantenimiento y qu\u00e9 queremos de Kubernetes. \u00bfPodr\u00edas explicarlo?<\/p>\n

\u2014 Hasta donde s\u00e9 y como veo, actualmente muchos equipos quieren probar Kubernetes. Todos est\u00e1n involucr\u00e1ndose, instal\u00e1ndolo en sus laptops. Tengo la sensaci\u00f3n de que las personas no siempre comprenden la complejidad de este sistema.<\/b><\/p>\n

Dmitry<\/b>: As\u00ed es.<\/p>\n

\u2014 \u00bfQu\u00e9 tan dif\u00edcil es instalar Kubernetes de cero para que est\u00e9 listo para producci\u00f3n?<\/b><\/p>\n

Dmitry<\/b>: \u00bfQu\u00e9 piensas, cu\u00e1n dif\u00edcil es realizar un trasplante de coraz\u00f3n? Entiendo que es una pregunta comprometida. Manejar un escalpelo y no cometer errores no es tan complicado. Si te dicen d\u00f3nde cortar y d\u00f3nde coser, el procedimiento en s\u00ed no es dif\u00edcil. Lo complicado es garantizar que todo salga bien cada vez.<\/p>\n

Instalar Kubernetes y lograr que funcione es simple: \u00a1clic! \u2014 se instala, hay montones de formas de hacerlo. Pero, \u00bfqu\u00e9 pasar\u00e1 cuando surjan problemas?<\/p><\/blockquote>\n

\nSiempre surgen preguntas: \u00bfqu\u00e9 m\u00e1s no hemos considerado? \u00bfQu\u00e9 m\u00e1s no hemos hecho? \u00bfQu\u00e9 par\u00e1metros del n\u00facleo de Linux configuramos incorrectamente? Dios m\u00edo, \u00bfacaso los configuramos en absoluto? \u00bfQu\u00e9 componentes de Kubernetes instalamos y cu\u00e1les no? Aparecen miles de preguntas, y para responderlas, se necesita hervir en esta industria durante 15-20 a\u00f1os.<\/p>\n

Tengo un ejemplo reciente sobre este tema que puede revelar el sentido del problema \"\u00bfEs dif\u00edcil mantener Kubernetes?\". Hace un tiempo, consideramos seriamente implementar Cilium como red en Kubernetes.<\/p>\n

Voy a explicar qu\u00e9 es Cilium. En Kubernetes hay muchas implementaciones diferentes del subsistema de red, y una de ellas es muy interesante: Cilium. \u00bfCu\u00e1l es su prop\u00f3sito? Hace alg\u00fan tiempo, se introdujo la capacidad de escribir ganchos para el n\u00facleo que interaccionan de alguna manera con el subsistema de red y otros subsistemas, permitiendo eludir grandes partes del n\u00facleo.<\/p>\n

Hist\u00f3ricamente, en el n\u00facleo de Linux existen ip rout, netfilter, puentes y muchos componentes antiguos que tienen 15, 20 o 30 a\u00f1os. En general, funcionan, todo est\u00e1 bien, pero actualmente hemos llenado de contenedores, y se ve como una torre de 15 ladrillos uno sobre otro, y t\u00fa te mantienes en ella sobre una pierna: una sensaci\u00f3n extra\u00f1a. Este sistema se ha desarrollado hist\u00f3ricamente con muchos matices, como un ap\u00e9ndice en el organismo. En algunas situaciones hay problemas de rendimiento, por ejemplo.<\/p>\n

Hay un maravilloso BPF y la posibilidad de escribir ganchos para el n\u00facleo: los chicos han escrito sus ganchos para el n\u00facleo. El paquete llega al n\u00facleo de Linux, lo extraen justo en la entrada, lo procesan como necesitan sin puentes, sin TCP, sin pila IP: en resumen, eludiendo todo lo escrito en el n\u00facleo de Linux, y lo escupen directamente en el contenedor.<\/p>\n

\u00bfQu\u00e9 se obtuvo? Un rendimiento muy bueno, caracter\u00edsticas geniales: \u00a1simplemente incre\u00edble! Pero miramos esto y vemos que en cada m\u00e1quina hay un programa que se conecta a la API de Kubernetes y, bas\u00e1ndose en los datos que obtiene de esa API, genera c\u00f3digo en C y compila binarios que carga en el n\u00facleo, para que esos ganchos funcionen en el espacio del kernel.<\/p>\n

\u00bfQu\u00e9 pasar\u00e1 si algo no sale bien? No lo sabemos. Para entenderlo, es necesario leer todo este c\u00f3digo y comprender toda la l\u00f3gica, y eso es incre\u00edblemente complicado. Pero, por otro lado, existen estos puentes, filtros de red, ip rout: yo no he le\u00eddo sus fuentes, y 40 ingenieros que trabajan en nuestra empresa tampoco. Tal vez, algunas partes solo sean entendidas por unos pocos.<\/p>\n

\u00bfY cu\u00e1l es la diferencia? Resulta que hay ip rout, n\u00facleo de Linux, y hay una nueva herramienta \u2014 \u00bfcu\u00e1l es la diferencia?, ninguna de las dos las entendemos. Pero tememos usar lo nuevo \u2014 \u00bfpor qu\u00e9? Porque si la herramienta tiene 30 a\u00f1os, durante estos 30 a\u00f1os se han encontrado todos los errores, se han ca\u00eddo en todas las trampas y no es necesario saber todo \u2014 funciona como una caja negra y siempre opera. Todos saben d\u00f3nde insertar el destornillador de diagn\u00f3stico, qu\u00e9 tcpdump ejecutar en qu\u00e9 momento. Todos conocen bien las utilidades de diagn\u00f3stico y comprenden c\u00f3mo funciona este conjunto de componentes en el n\u00facleo de Linux \u2014 no c\u00f3mo est\u00e1 construido, sino c\u00f3mo usarlo.<\/p>\n

Pero el incre\u00edble Cilium no tiene 30 a\u00f1os, a\u00fan no ha madurado. Hay el mismo problema con Kubernetes, es una copia. Tanto Cilium como Kubernetes se instalan perfectamente, pero cuando algo falla en producci\u00f3n, \u00bfser\u00e1n capaces de entender r\u00e1pidamente, en una situaci\u00f3n cr\u00edtica, qu\u00e9 sali\u00f3 mal? <\/p>\n

Cuando decimos que es dif\u00edcil mantener Kubernetes \u2014 no, es muy f\u00e1cil, y s\u00ed, es incre\u00edblemente complicado. Kubernetes funciona maravillosamente por s\u00ed mismo, pero con un bill\u00f3n de matices.<\/p><\/blockquote>\n

<\/p>\n

Sobre el enfoque \"Me va a ir bien\"<\/h2>\n

\n\u2014 \u00bfY hay empresas donde estos matices aparecer\u00e1n casi garantizadamente? Supongamos que Yandex de repente traslade todos sus servicios a Kubernetes, habr\u00e1 una carga enorme.<\/b><\/p>\n

Dmitry<\/b>: No, esta conversaci\u00f3n no trata sobre la carga, sino sobre cosas sencillas. Por ejemplo, tenemos Kubernetes, hemos desplegado una aplicaci\u00f3n all\u00ed. \u00bfC\u00f3mo entender que est\u00e1 funcionando? No hay una herramienta lista para saber que la aplicaci\u00f3n no falla. No hay un sistema preparado que env\u00ede alertas \u2014 se deben configurar estas alertas y cada gr\u00e1fico. Ah, y estamos actualizando Kubernetes.<\/p>\n

Tenemos Ubuntu 16.04. Se podr\u00eda decir que es una versi\u00f3n antigua, pero seguimos utiliz\u00e1ndola porque es LTS. Ah\u00ed est\u00e1 systemd, cuyo detalle es que no limpia los grupos C. Kubernetes inicia pods, crea grupos C, luego elimina los pods, y de alguna manera, no recuerdo los detalles, disculpen, quedan residuos de systemd. Esto lleva a que, con el tiempo, cualquier m\u00e1quina comience a ralentizarse considerablemente. No se trata ni siquiera de una cuesti\u00f3n de alta carga. Si se est\u00e1n ejecutando pods de forma continua, por ejemplo, si hay un trabajo cron que genera pods constantemente, la m\u00e1quina con Ubuntu 16.04 comenzar\u00e1 a ralentizarse despu\u00e9s de una semana. Habr\u00e1 una carga promedio alta debido a que se han creado muchos grupos C. Este es un problema con el que se enfrenta cualquier persona que simplemente instale Ubuntu 16 y encima Kubernetes.<\/p>\n

Supongamos que de alguna manera actualiza systemd o algo m\u00e1s, pero en el n\u00facleo de Linux hasta la versi\u00f3n 4.16 es incluso m\u00e1s curioso: al eliminar grupos C, estos gotean en el n\u00facleo y efectivamente no se eliminan. Por eso, despu\u00e9s de un mes de uso de esta m\u00e1quina, no se podr\u00e1 ver la estad\u00edstica de memoria por pods. Sacamos un archivo, lo contamos en el programa, y un archivo tarda 15 segundos en procesarse porque el n\u00facleo tarda mucho en calcular internamente un mill\u00f3n de grupos C que supuestamente han sido eliminados, pero no, siguen goteando.<\/p>\n

Todav\u00eda hay muchos de estos detalles por todos lados. No es un asunto con el que las grandes empresas puedan tropezar de vez en cuando bajo cargas muy altas; no, se trata de cuestiones cotidianas. La gente puede vivir as\u00ed durante meses: instalar Kubernetes, desplegar una aplicaci\u00f3n, y parece que funciona. A muchos les parece bien. No se dar\u00e1n cuenta de que en alg\u00fan momento esa aplicaci\u00f3n fallar\u00e1 por alguna raz\u00f3n; no recibir\u00e1n alertas, pero para ellos eso es normal. Antes viv\u00edan en m\u00e1quinas virtuales sin monitorizaci\u00f3n, ahora se han trasladado a Kubernetes tambi\u00e9n sin monitorizaci\u00f3n, \u00bfcu\u00e1l es la diferencia?<\/p>\n

La cuesti\u00f3n es que cuando caminamos sobre el hielo, nunca sabemos su grosor si no lo hemos medido previamente. Muchos caminan sin preocupaciones porque lo han hecho antes.<\/p>\n

Desde mi punto de vista, la complejidad y el matiz del funcionamiento de cualquier sistema radica en garantizar que el grosor del hielo es suficiente para cumplir nuestras tareas. De eso se trata.<\/p><\/blockquote>\n

\nEn TI, parece que hay demasiados enfoques de \u00abtendr\u00e9 suerte\u00bb. Muchos instalan software, utilizan bibliotecas en la esperanza de que tendr\u00e1n suerte. En general, a muchos les va bien. Tal vez por eso funciona.<\/p>\n

\u2014 Desde mi evaluaci\u00f3n pesimista, esto se presenta as\u00ed: cuando los riesgos son altos y la aplicaci\u00f3n debe funcionar, se necesita apoyo de \u00abFlant\u00bb, posiblemente de Red Hat, o se requiere un equipo interno dedicado espec\u00edficamente a Kubernetes, que est\u00e9 preparado para gestionarlo.<\/b><\/p>\n

Dmitry<\/b>: Objetivamente, es as\u00ed. Involucrarse por s\u00ed mismo con Kubernetes es arriesgado para un equipo peque\u00f1o.<\/p>\n

\u00bfNecesitamos contenedores?<\/h2>\n

\n\u2014 \u00bfPuedes contarme cu\u00e1n extendido est\u00e1 Kubernetes en Rusia?<\/b><\/p>\n

Dmitry<\/b>: No tengo esos datos, y no estoy seguro de que nadie los tenga. Decimos: \u00abKubernetes, Kubernetes\u00bb, pero hay otra perspectiva sobre el tema. No s\u00e9 cu\u00e1n extendidos est\u00e1n los contenedores, pero tengo una cifra de informes en internet que dice que el 70% de los contenedores son orquestados por Kubernetes. Esta fue una fuente confiable con una muestra bastante grande a nivel mundial.<\/p>\n

A continuaci\u00f3n, otra pregunta: \u00bfnecesitamos contenedores?<\/b> Tengo la sensaci\u00f3n personal y tambi\u00e9n la posici\u00f3n de la empresa \u00abFlant\u00bb de que Kubernetes es el est\u00e1ndar de facto.<\/p>\n

No habr\u00e1 nada m\u00e1s que Kubernetes.<\/p><\/blockquote>\n

\nEs un cambio absoluto en el campo de la gesti\u00f3n de infraestructura. Simplemente absoluto: no m\u00e1s Ansible, Chef, m\u00e1quinas virtuales, Terraform. Y ni hablar de los m\u00e9todos antiguos y obsoletos. Kubernetes es un cambio absoluto<\/b>, y as\u00ed ser\u00e1 siempre.<\/p>\n

Es claro que a algunos les llevar\u00e1 un par de a\u00f1os, y a otros, un par de d\u00e9cadas, darse cuenta de esto. No tengo dudas de que no habr\u00e1 nada m\u00e1s que Kubernetes y esta nueva perspectiva: ya no da\u00f1amos la operaci\u00f3n del sistema, sino que utilizamos infrastructure as code<\/b>, solo que no con c\u00f3digo, sino con yml: infraestructura descrita de manera declarativa. Tengo la sensaci\u00f3n de que as\u00ed ser\u00e1 siempre.<\/p>\n

\u2014 Entonces, \u00bflas empresas que a\u00fan no han migrado a Kubernetes necesariamente lo har\u00e1n o quedar\u00e1n en el olvido? \u00bfTe he entendido correctamente?<\/b><\/p>\n

Dmitry<\/b>: Esto tampoco es del todo correcto. Por ejemplo, si nuestra tarea es poner en marcha un servidor DNS, se puede hacer en FreeBSD 4.10 y puede funcionar perfectamente durante 20 a\u00f1os. Simplemente funciona y ya est\u00e1. Puede que durante esos 20 a\u00f1os se necesite actualizar algo una vez. Si hablamos de software en un formato en el que lo hemos lanzado y realmente funciona durante muchos a\u00f1os sin actualizaciones ni cambios, entonces, por supuesto, no habr\u00e1 Kubernetes. No es necesario all\u00ed.<\/p>\n

Todo lo relacionado con CI\/CD: en todos los lugares donde se requiere Continuous Delivery, donde es necesario actualizar versiones y realizar cambios activos, donde se necesita construir resiliencia, solo Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Sobre microservicios<\/h2>\n

\n\u2014 Aqu\u00ed me surge un peque\u00f1o disonancia. Para trabajar con Kubernetes, se necesita soporte externo o interno, ese es el primer punto. El segundo es que cuando reci\u00e9n comenzamos el desarrollo, somos una peque\u00f1a startup, no tenemos nada todav\u00eda, desarrollar para Kubernetes o incluso para una arquitectura de microservicios puede ser dif\u00edcil y no siempre justificado econ\u00f3micamente. Me interesa tu opini\u00f3n: \u00bfdeben las startups comenzar de cero escribiendo para Kubernetes o se puede escribir un monolito primero y luego pasar a Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Gran pregunta. Tengo una charla sobre microservicios \u00abMicroservicios: el tama\u00f1o importa\u00bb.<\/a><\/noindex> Me he encontrado muchas veces con que las personas intentan usar un microscopio para clavar clavos. La aproximaci\u00f3n en s\u00ed es correcta, nosotros tambi\u00e9n dise\u00f1amos nuestro software interno de esta manera. Pero cuando lo haces, debes comprender claramente lo que est\u00e1s haciendo. Lo que m\u00e1s odio en los microservicios es la palabra \u00abmicro\u00bb. Hist\u00f3ricamente se forj\u00f3 este t\u00e9rmino y, por alguna raz\u00f3n, la gente piensa que 'micro' significa muy peque\u00f1o, menos de un mil\u00edmetro, como un micr\u00f3metro. No es as\u00ed.<\/p>\n

Por ejemplo, hay un monolito que es escrito por 300 personas, y todos los que participaron en el desarrollo saben que hay problemas y que debe dividirse en micropedazos \u2014 alrededor de 10, cada uno de los cuales es escrito por un m\u00ednimo de 30 personas. Eso es importante, necesario y genial. Pero cuando llega a nosotros una startup donde 3 chicos muy geniales y talentosos han escrito 60 microservicios de manera improvisada, cada vez busco un calmante.<\/p>\n

Me parece que ya se ha hablado de esto miles de veces: hemos recibido un monolito distribuido en una u otra forma. Esto no es econ\u00f3micamente justificable, es muy complicado en general. Simplemente he visto esto tantas veces que me duele, por eso contin\u00fao hablando de ello.<\/p>\n

Volviendo a la pregunta inicial, hay un conflicto entre, por un lado, que Kubernetes es terrible de usar porque no est\u00e1 claro qu\u00e9 puede romperse o no funcionar, y por otro lado, es evidente que todo se dirige hacia all\u00ed y que nada, excepto Kubernetes, ser\u00e1 relevante. La respuesta es evaluar el volumen de beneficios que se obtienen y el volumen de tareas que se pueden resolver.<\/b>. Esto es un lado de la balanza. Por el otro lado est\u00e1n los riesgos asociados con el tiempo de inactividad o la disminuci\u00f3n del tiempo de respuesta, los niveles de disponibilidad, y la disminuci\u00f3n de los indicadores operativos.<\/p>\n

Aqu\u00ed es as\u00ed: debemos avanzar r\u00e1pidamente, y Kubernetes permite realizar muchas cosas mucho m\u00e1s r\u00e1pido y mejor, o utilizar soluciones confiables y probadas, pero avanzar mucho m\u00e1s lentamente. Cada empresa debe tomar esta decisi\u00f3n. Se puede ver esto como un sendero en la jungla: la primera vez que caminas, puedes encontrarte con una serpiente, un tigre o un tej\u00f3n furioso, pero despu\u00e9s de haberlo hecho 10 veces, has abierto el camino, quitado ramas y es m\u00e1s f\u00e1cil de transitar. Cada vez el sendero se hace m\u00e1s ancho. Luego se convierte en una carretera asfaltada, y m\u00e1s tarde en un bonito bulevar.<\/p>\n

Kubernetes no se detiene. Nuevamente surge la pregunta: Kubernetes, por un lado, son 4-5 binarios; por el otro lado, es todo un ecosistema. Es un sistema operativo que tenemos en nuestras m\u00e1quinas. \u00bfQu\u00e9 es esto? \u00bfUbuntu o Curios? Es el n\u00facleo de Linux, un mont\u00f3n de componentes adicionales. Todas estas cosas: aqu\u00ed han quitado una serpiente venenosa del camino, all\u00ed han puesto una valla. Kubernetes se desarrolla de manera muy r\u00e1pida y din\u00e1mica, y el volumen de riesgos y lo desconocido disminuye cada mes y, por lo tanto, estas balanzas se reequilibran.<\/p>\n

Al responder a la pregunta sobre qu\u00e9 hacer un startup, dir\u00eda: ven a \"Flant\", paga 150 mil rublos y obt\u00e9n un servicio DevOps f\u00e1cil llave en mano. Si eres una peque\u00f1a startup con unos pocos desarrolladores, esto funciona. En lugar de contratar tu propio DevOps, que necesitar\u00e1 aprender a resolver tus problemas y durante ese tiempo pagarle un salario, obtendr\u00e1s una soluci\u00f3n integral a todas tus inquietudes. S\u00ed, hay algunos inconvenientes. Como outsourcing, no podemos estar tan involucrados y reaccionar r\u00e1pidamente a los cambios. Pero tenemos mucha experiencia y pr\u00e1cticas listas. Garantizamos que en cualquier situaci\u00f3n, con certeza resolveremos r\u00e1pidamente y levantaremos cualquier Kubernetes desde el m\u00e1s all\u00e1. <\/p>\n

Recomiendo categ\u00f3ricamente el outsourcing a startups y negocios establecidos hasta el tama\u00f1o en que puedes destinar un equipo de 10 personas para operaciones, porque de lo contrario no tiene sentido. Categ\u00f3ricamente tiene sentido externalizar.<\/p><\/blockquote>\n

<\/p>\n

Sobre Amazon y Google<\/h2>\n

\n\u00bfSe puede considerar como outsourcing un hosting de soluciones de Amazon o Google?<\/b><\/p>\n

Dmitry<\/b>: S\u00ed, claro, esto resuelve algunos problemas. Pero nuevamente hay matices. A\u00fan hay que entender c\u00f3mo utilizarlo. Por ejemplo, hay mil detalles en el funcionamiento de Amazon AWS: el Load Balancer necesita ser precalentado o hay que solicitar previamente que \"compa\u00f1eros, nos llegar\u00e1 tr\u00e1fico, calienten nuestro Load Balancer!\" Estos matices deben ser conocidos.<\/p>\n

Cuando te diriges a personas que se especializan en esto, obtienes casi todas las cosas est\u00e1ndar cubiertas. Actualmente tenemos 40 ingenieros, para finales de a\u00f1o probablemente ser\u00e1n 60; claramente nos hemos encontrado con todas estas cuestiones. Incluso si en alg\u00fan proyecto nos encontramos nuevamente con este problema, ya preguntamos r\u00e1pidamente entre nosotros y sabemos c\u00f3mo resolverlo.<\/p>\n

Probablemente, la respuesta es as\u00ed: por supuesto, la historia de hosting facilita una parte. La pregunta es si est\u00e1s dispuesto a confiar en estos hosts y si resolver\u00e1n tus problemas. Amazon y Google se han ganado una buena reputaci\u00f3n. Para todos nuestros casos, definitivamente. No tenemos m\u00e1s experiencias positivas. Todos los dem\u00e1s nubes con las que hemos intentado trabajar crean muchos problemas: Ager, y todo lo que existe en Rusia, y varios OpenStack en diferentes implementaciones: Headster, Overage, lo que desees. Todos crean problemas que no queremos resolver.<\/p>\n

Por lo tanto, la respuesta es s\u00ed, pero, en realidad, no hay muchas soluciones de hosting maduras.<\/p>\n

\u00bfQui\u00e9n necesita Kubernetes?<\/h2>\n

\n\u2014 Sin embargo, \u00bfqui\u00e9n necesita Kubernetes? \u00bfQui\u00e9n deber\u00eda cambiarse a Kubernetes, qui\u00e9n es el cliente t\u00edpico de \"Flant\" que llega espec\u00edficamente por Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: La pregunta es interesante, porque ahora mismo, en la ola de Kubernetes, muchos se acercan a nosotros: \u00abChicos, sabemos que ustedes hacen Kubernetes, \u00a1h\u00e1ganlo para nosotros!\u00bb. Les respondemos: \u00abSe\u00f1ores, no hacemos Kubernetes, hacemos producci\u00f3n y todo lo que se relaciona con ello\u00bb. Porque hacer producci\u00f3n sin haber implementado todo el CI\/CD y toda esa historia es pr\u00e1cticamente imposible en la actualidad. Todos se han alejado de la separaci\u00f3n, donde el desarrollo es desarrollo y la operaci\u00f3n es operaci\u00f3n.<\/p>\n

Nuestros clientes esperan diferentes cosas, pero todos esperan alg\u00fan tipo de milagro, que tienen ciertas dificultades y ahora, \u00a1zas! \u2014 Kubernetes las resolver\u00e1. La gente cree en los milagros. Comprenden racionalmente que no habr\u00e1 milagro, pero espiritualmente esperan \u2014 \u00bfy si este Kubernetes nos resuelve todo ahora, se habla tanto de \u00e9l? \u00bfY si ahora es un \u00a1ach\u00eds! \u2014 y la bala de plata, un \u00a1ach\u00eds! \u2014 y tenemos 100% de tiempo de actividad, todos los desarrolladores pueden lanzar lo que sea a producci\u00f3n 50 veces y no se cae? En resumen, \u00a1un milagro!<\/p>\n

Cuando estas personas vienen a nosotros, decimos: \u00abLo siento, pero no hay milagros\u00bb. Para estar sano, uno necesita comer bien y hacer ejercicio. Para tener una producci\u00f3n confiable, debe hacerse de manera confiable. Para tener un CI\/CD conveniente, debe hacerse as\u00ed. Es un gran trabajo que debe realizarse.<\/p>\n

Al responder a la pregunta de qui\u00e9n necesita Kubernetes, Kubernetes no es necesario para nadie.<\/p><\/blockquote>\n

\nAlgunas personas tienen la err\u00f3nea sensaci\u00f3n de que necesitan Kubernetes. La gente necesita, tiene una profunda necesidad de dejar de pensar, hacer y preocuparse por todos los problemas de infraestructura y de implementar sus aplicaciones. Quieren que las aplicaciones simplemente funcionen y se desplieguen. Para ellos, Kubernetes es la esperanza de que dejar\u00e1n de escuchar historias como \u00abestuvimos atascados\u00bb o \u00abno podemos desplegar\u00bb, o cualquier otra cosa.<\/p>\n

Normalmente nos visita el director t\u00e9cnico. Se le preguntan dos cosas: por un lado, danos funciones, y por el otro, estabilidad. Proponemos que asumamos esto y lo hagamos. La bala de plata, o mejor dicho, la bala plateada, es que dejar\u00e1s de pensar en estos problemas y de perder tiempo. Tendr\u00e1s personas especializadas que se encargar\u00e1n de este asunto.<\/p>\n

La afirmaci\u00f3n de que necesitamos Kubernetes, o que alguien lo necesita, es incorrecta.<\/p><\/blockquote>\n

\nKubernetes es muy necesario para los administradores, porque es una herramienta realmente interesante con la que se puede jugar, experimentar. Seamos honestos: a todos nos gustan los juguetes. Todos seguimos siendo un poco ni\u00f1os, y cuando vemos algo nuevo, queremos jugar con ello. Algunas personas pueden haber perdido ese inter\u00e9s, como en la administraci\u00f3n, porque ya han jugado lo suficiente y les ha aburrido hasta el punto de no quererlo m\u00e1s. Pero eso no significa que nadie lo haya perdido por completo. Por ejemplo, aunque me haya cansado de jugar con herramientas en el \u00e1mbito de la administraci\u00f3n de sistemas y DevOps, sigo disfrutando de nuevos juguetes y sigo comprando algunos.<\/p>\n

No se debe jugar con producci\u00f3n. Lo que recomiendo encarecidamente no hacer y lo que veo que sucede masivamente es: \"Ah, un juguete nuevo!\" \u2013 corren a comprarlo, lo adquieren y luego dicen: \"Vamos a llevarlo a la escuela y mostrarlo a todos nuestros amigos\". No hagan eso. Disculpen, mis hijos est\u00e1n creciendo, y constantemente veo cosas en ellos y las reconozco en m\u00ed mismo, y luego generalizo sobre los dem\u00e1s.<\/p>\n

La respuesta definitiva: no necesitas Kubernetes. Necesitas resolver tus problemas.<\/p><\/blockquote>\n

\nSe puede lograr que:<\/p>\n