Envío erróneo o controvertido, por favor lee los comentarios.
Si usas Docker, el siguiente paso natural parece ser Kubernetes, también conocido como K8s: así es como se manejan las cosas en la producción, ¿verdad? Bueno, tal vez. Las soluciones diseñadas para 500 ingenieros de software que trabajan en la misma aplicación son bastante diferentes a las soluciones para 50 ingenieros de software. Y ambas serán diferentes de las soluciones diseñadas para un equipo de 5. Si formas parte de un equipo pequeño, Kubernetes probablemente no es para ti: es mucho dolor con muy pocos beneficios. Veamos por qué.
|
etiquetas: kubernetes
Un articulo muy bueno. Con una reflexión profunda. La mayoría de los proyectos se van al traste cuando la complejidad de los sistemas se vuelve inmanejable. Yo estoy cansado de decir al inicio de los proyectos, que seamos realistas. Y por lo general, los responsables te miran mal, y das la sensación de que el problema es la carencia de conocimientos.
Un articulo muy bueno. Con una reflexión profunda. La mayoría de los proyectos se van al traste cuando la complejidad de los sistemas se vuelve inmanejable. Yo estoy cansado de decir al inicio de los proyectos, que seamos realistas. Y por lo general, los responsables te miran mal, y das la sensación de que el problema es la carencia de conocimientos.
Como si las necesidades del 99% de los proyectos fueran los de Google
Por poner un ejemplo claro, el primer "problema" es realmente absurdo. Kubernetes está diseñado para sistemas grandes en los cuales las tres o cuatro máquinas imprescindibles para que el clúster funcione suponen una parte muy pequeña de la infraestructura. Si necesitas un sistema distribuido de cuatro o cinco máquinas y utilizas Kubernetes el problema no es Kubernetes, sino tú por utilizar un software que no está diseñado para tus necesidades. PICNIC.
Lo de la DMZ, tal como lo has explicado, no entiendo bien cómo está configurado. ¿Que hay nodos de Kubernetes expuestos?
Ahora, si tienes la necesidad real (una intraweb de un ministerio por ejemplo no es una necesidad real) y los recursos tanto de máquina de humanos pues por supuesto Kubernetes es un gran producto que resuelve muchos problemas.
¿Fuentes para esa afirmación?
Si, virtualizar esta muy bien para crear rápido un host igual que tendrías si siguieras usando servidores físicos, pero en cuanto el sistema adquiere una complejidad real, el tiempo perdido entre despliegues y "orquestaciones" pasa a ser inasumible. Por no hablar de los balanceos de carga, healtchecks y demás que en un sistema kubernetes bien montado no son una preocupación y en uno virtualizado siempre hay que andar investigando.
Pero Kubernetes es un salto que no puedo... cada vez que lo pruebo me doy con una pared. Y cada vez que supero esa pared hay detrás otra más alta.
Yo espero que Docker Swarm tire para adelante y sobreviva a los cambios de dueños etc... porque a mi Swarm me da justo lo que necesito.
Hay mismo hay 3 opciones eres una empresa pequeña o desarollas para una empesa pequeña tiras de la nube,. Tu no tienes que tener la infraestructura desarrolas tus docker y microservicios y lo montas en la nube que quieras.
Eres una empresa grande miras que te sae más rentable. Puedes tener tu kubernetes si quieres para desarrolllar. Pero a la larga te sigue saliendo caro mantner tu propiesta infraestructura de kubernetes. Nuevamente debes tirar del servicio de cloud.
Quien entonces debe montar su kubernetes en producción. Pues quien por motivos de seguridad no puede fiarse de una nube de terceros.
Y en eso hablamos de proyectos de defensa, para la ESA o proyectos para empresas muy grandes.
Aqui puedes tener tu infraestructura propia.
Lo que esta claro que todo va a estar en la nube y por eso hay que tirar por microservicios.
En esos casos entiendo que podrías sacarle partido con una sola máquina, donde están todos los contenedores (y pods) que gestionar Kubernetes).
Sin embargo, supongo que habrá otros software que hagan eso mismo sin la complejidad de Kubernetes. Pero el caso es que siempre que oído hablar de estas cosas siempre remiten a Kubernetes. ¿Qué otras opciones habría?
Otra cosa es que lo que necesites sean 2 HAProxies apuntando a 2 jbosses que consumen 2 postgresql y vayas sobradísimo, pero kubernetes juega en otra liga donde hablamos de mucha más escala y de despliegues más rápidos.
La queja de que es grande, y que son muchas líneas de código: Si y no, el core de kubernetes es complejo, incluye un type system en el runtime, servidores agregados, gestión de APIs, gestión de permisos, etc. pero mismo tiempo es extremadamente modular y navegar por el código es bastante fácil.
Hay partes muy complejas (sobre todo en kubelet y apiserver) pero por lo general es fácil navegar por el código en parte por golang y las herramientas que tiene (véase gpls y compañía).
Los clientXXX.go tienen una interfaz estándar, es fácil leerlos y fácil encontrarlos incluso con CRDs y apiservers agregados.
Kubectl es el cli mejor escrito que he visto con diferencia (tanto por consistencia y modularidad por como calidad de uso para el usuario).
Etcd también es complejo de cojones.
La complejidad del desarrollo me parece una crítica acertada, aunque hay bastantes opciones para tener un kubernetes en local.
La complejidad de la arquitectura, sinceramente no lo veo tan complejo si lo comparamos con las alternativas que resuelven los problemas que kubernetes resuelve, OpenStack me parece muchísimo más complejo (y trabajé en OpenStack algo más de un año)
Sobre la esalabilidad, el diga que es facil escalar una máquina verticalmente, coger 8 TiB de RAM y ya está directamente no tiene ni puta idea ni se ha pegado con NUMA en su vida. Las máquinas grandes siempre traen problemas que uno no espera. Sobre escalar con heroku, pues como escalar con un kubernetes gestionado por un tercero.
El paradigma de trabajar con contenedores + kubernetes simplifica las operaciones tanto que sale muy muy muy a cuenta, y es muy facil construir con ello un sistema robusto y altamente automatizado
Otra cosa es que la gente intente meter todo con calzador ahi dentro, que no ... hay cosas que meterlas en kubernetes es complicarte la vida mogollón sin obtener grandes ventajas a cambio
Yo llevo 3 años con kubernetes en producción para muchas cosas y estoy SUPER contento
Otras cosas hemos intentado meterlas y hemos visto que era peor el remedio que la enfermedad, asi que se queda fuera, virtualizado y manejado con las herramientas tradicionales
Respuesta:
Montar 6 máquinas, con dos webservers (Apache), dos servidores de aplicaciones (JBoss) y una BBDD (Postgresql)
Más máquinas que administrativos,
Me empieza a recordar el chiste de los remeros, pero cambiando directores por máquinas.
Si sirve de consuelo le he votado positivo, estoy de acuerdo.
Para CI/CD en general, o DevOps, no necesitas Kubernetes, con Docker te vale (desde mi humilde punto de vista)
Si no necesitas 200 contenedores no necesitas Kubernettes. O algo así más o menos, no se donde poner el límite, pero está claro que para una aplicación "normalita" que no esté basada en microservicios y funcione con 3 ó 4 servidores no es necesario para nada.
Si tienes una solución tradicional que te cubre tus necesidades a un coste inferior, montalo. Tengo montados entornos clústers de Big Data de unos 10 nodos que podrían sustituirse con una mysql en HA de 2-3 nodos. Pero en su día mola menos.
Madre mia lo que hay que leer en Meneame y eso que yo no soy en mayor fan de Kubernetes
Si lo hicieras de la forma tradicional necesitarías montar un servidor -Físico o virtual-, instalarle el SO y luego montar el apache encima.
Si dockerizas el servidor apache, lo que estás haciendo es meterlo en un contenedor que va a tener lo esencial para correrlo y va a usar los recursos (Kernel, etc) de la máquina anfitriona. De esta forma es más ligero y tu puedes desarrollar tu docker en tu casa, con la versión 2.4 de apache aunque en la máquina anfitrioina, solo disponga de apache 2.2 en sus repositorios.
Kubernetes digamos que es un cluster dedicado a correr este tipo de contenedores, donde te dan balanceadores para que si un contenedor estaba corriendo la maquina 1 del cluster se levante en la 2, si es que la máquina 1 ha muerto. Digamos que es una capa para hacer más potente todo el tema de contenedores.
¿Es guay? Si, mucho, pero también es muy complejo, y yo, a no ser que tuviera que montar un huevo de microservicios preferiría montarme un apache en una maquina virtual pequeña, porque es trivial.
Lo que pasa que al final la gente quiere hacer cosas guays. Como pasearse por el pueblo con un Ferrari.
Hay entornos para los que merece la pena, otros para los que no, pero los vendehumos siempre te venderán lo complicado para intentar cobrarte 500 mil euros por el montaje de una arquitectura compleja cuando para lo que tu quieres te vale con un seat y te sobra.
Y si, aumenta el nivel de complejidad, pero si tu proyecto tiene una infraestructura suficientemente grande, compensa. Si no la tiene, mejor no complicarse la vida
En nuestro caso es una plataforma que tiene horarios valle y picos de que pueden superar los cientos de miles de usuarios, por ejemplo durante un partido de fútbol.
Es mas complejo K8s que docker? si, en nuestro caso nos facilita la vida ? si, a pesar de las complejidades añadidas donde antes teniamos corriendo 24 dockers ahora vemos que en algunos momentos con 2 nos basta y llegamos a escalar a 15 o 16. El tema de la red también es mucho más facil ahora. Podemos autogestionarnos de manera mas sencilla y tenemos una visión mas global y centralizada. En mi opinión el que ha escrito el articulo ha considerado que en su caso no es productivo pero como digo es solo su caso, no el nuestro
Y decir que necesita un Apache delante... Madre mía... Se nota que no tienes ni idea de usar un Windows Server.
Claro que si no sabes usarlo o crees que todo es siguiente, siguiente, siguiente y que Windows Server es igual que hace 20 años... Normal que pienses eso.
www.techempower.com/benchmarks/#section=intro&hw=ph&test=plain
Sobre seguridad, puedes buscar el número de fallos de seguridad de Windows Server del último año.
No os ancleis en el pasado, Windows ha mejorado mucho, quitaos de la cabeza el Blaster y demas...
Azure se usa porque es la mejor opción si quieres Windows.
Es un cambio de paradigma, de forma de pensar, y hay que analizar los pros y contras, pero en el 90+% de las empresas va a tener mucho sentido empezar a meterse en esto.
AWS funciona, pero estamos teniendo algunos problemas y resulta complicado saber qué pasa sin consultar a expertos... de hecho hemos tenido que delegar la configuración a una consultora porque íbamos con prisa (todo para ayer) y el departamento de informática de mi empresa somos tres personas y tenemos que llevar el desarrollo, mantenimiento y soporte a usuarios haciendo malabares.
No hay fuentes realistas objetivas
Si yo no digo que no, pero me gusta comprobar las cosas, no me basta con unos comentarios cortos en un foro cualquiera.
robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-
«Conclusions
Hosting applications using Linux and Docker in Azure Application Service Plan doesn’t affect negatively the performance of the application, unlike one may guess, given that Windows hosting is more mature. It is actually beneficial, performance-wise, especially for requests returning responses with small bodies.»
«El Windows da mucho más rendimiento de lo que te crees, y es más seguro que cualquier otro. »
Dejando de lado el signficado subjetivo de «más de lo que te crees», suena a que da incluso mejor rendimiento, cosa que me rasca un poco. Lo mismo con el tema seguridad. En realidad pido que me convenzan a mi.
Los 3 principales problemas.
Sólo apuntaba a que es "bastante mejor que antes". O debe serlo, porque hace lustros que no lo toco ni con un palo, así que yo no lo sé.
a) Un gestor gestiona, ayuda y facilita las tareas comunes, eso es un gestor.
b) Para usar un gestor hay que saber usarlo, como todo.
El articulo me parece pobre, y los argumentos no tienen mucho sentido. En lo único que tiene razón es que para levantar una aplicación no te hace falta Kubernetes, aunque si se piensa....
c) Para aprovechar un gestor tienes que tener algo que gestionar.
Y ya basta de obviedades
Por ejemplo. El famoso Big Data. Son clúster de bastantes máquinas con memoria y cpu's y lo que se hace es desarrollar algoritmos que pueden partirse en cachitos, y darles una parte a cada maquina en "contenedores". Realmente esto simplifica muchos escenarios.
Los dockers por ejemplo, para ciertos entornos no críticos también. Porque si funciona en tu "local" también funciona en tu cliente, porque es un paquetito que se autocontiene, no puede haber problemas de que esta biblioteca tal... Etc.
¿Cuando vienen los problemas? Cuando se quiere diseñar arquitecturas de Big Data para problemas que no los necesitan. O cuando quieres montar kubernetes para algo que con dos máquinas te sobra.
Yo creo que al final es un tema de ego empresarial. Si tal empresa lo ha montado, yo que soy grande no voy a tener menos. Y ahí van todos, a por algo que no necesitan porque otro lo ha hecho, y puede que este otro que lo hizo, reformulo toda su arquitectura para simplificarla en un unico punto convergente, y aquí si tenía sentido.
De todas formas yo estoy contigo, y me dedico a esto. La gente debería simplificar. Soy fan total de la filosofía KISS "Keep It Simple, Stupid"