‫Entonces, ¿qué sigue para Kubernetes?
‫Esa es una pregunta que creo que muchos de
‫nosotros tenemos cuando observamos qué tan rápido ha crecido, y todo el ecosistema
‫que lo rodea, y cómo eso es demasiado para que
‫una persona lo pueda manejar.
‫Cual es el futuro
‫Bueno, la buena noticia es que si tuviera que
‫predecirlo, creo que el futuro es que debe
‫comenzar a aburrirse. Escucharás a muchos de los fundadores hablar
‫de esto cada vez que los veas en público.
‫Saben, solo hablarán sobre cómo debemos hacer que la
‫infraestructura sea lo más aburrida posible para que
‫podamos confiar más en las cosas que hacemos
‫además de eso. Porque realmente, todo esto está aquí solo para que
‫podamos sacar nuestras aplicaciones, ¿no?
‫El objetivo de Kubernetes no es ser Kubernetes en sí.
‫Es para permitirte hacer las cosas que quieres hacer más rápido.
‫Creo que para Kubernetes, si
‫miraste los últimos lanzamientos, realmente comenzó
‫a centrarse en la confiabilidad, la
‫estabilidad, la seguridad, básicamente, se volvió tan
‫estable que está ahí.
‫No tienes que preocuparte tanto por eso.
‫No tienes que arreglarlo tanto.
‫Tienen lanzamientos regulares, por lo que definitivamente
‫puedes consultar el calendario de lanzamiento y las notas de lanzamiento,
‫a las que me he vinculado en este video.
‫Una cosa que sucedió este año, en 2019, fue una gran
‫auditoría de seguridad de gran parte del código
‫central que reveló muchas cosas.
‫De hecho, en su blog, tienen un análisis completo y detallado
‫de lo que sucedió.
‫Creo que es genial que un proyecto de código
‫abierto tan importante y tan grande como este, no solo hiciera
‫el análisis de seguridad de un tercero, sino que revelara todos los posibles
‫problemas y resultados.
‫Creo que resultó en una gran cantidad de relaciones públicas que
‫fueron por adelantado para soluciones rápidas, pero también algunas cosas
‫que eventualmente solucionarán con el tiempo.
‫No es tanto que necesariamente se basara en la vulnerabilidad, pero
‫podría mejorarse más de esta área, por lo que vamos
‫a cambiarla con el tiempo.
‫Otra cosa que verá es que algunos de estos conceptos
‫más antiguos, de cuando era una herramienta más simple, comenzarán a desvanecerse
‫a medida que se eliminen. Creo que los complementos de almacenamiento
‫que no son CSI eventualmente se eliminarán, por lo que tendrá que
‫confiar en CSI para sus complementos de almacenamiento en lugar
‫de los elementos integrados.
‫Verá diferentes comandos como el cambio de ejecución de
‫kubectl y dejará de darnos advertencias porque, por defecto,
‫será un simple pod runner en lugar de tener todos los
‫generadores construidos de fábrica.
‫Luego verá otras cosas que mencioné aquí, como
‫el funcionamiento en seco del lado del servicio, la estabilidad y
‫más características a su alrededor. Porque creo que hay un fuerte
‫impulso para una mejor auditoría, una mejor comprensión del
‫cambio con el tiempo. Qué va a cambiar antes de
‫hacerlo, qué cambió después de que lo hice y ese
‫tipo de métricas de informes.
‫Cuando se trata de terceros, eso continuará aumentando y
‫creciendo, y es realmente más de lo que cualquiera de
‫nosotros podría saber.
‫Timón 3. 0 está por terminar.
‫Definitivamente vamos a tener más operadores que serán para herramientas
‫de terceros para que sea más fácil implementarlas
‫y administrarlas en Kubernetes.
‫Esto es realmente más una esperanza, pero creo que
‫vamos a centrarnos mucho más en los flujos
‫de trabajo declarativos.
‫Debido a que este nuevo tema en torno a DevOps, y más específicamente
‫git-ops, es git ops,
‫del que he hablado en mi podcast.
‫El flujo de trabajo de git-ops es un concepto relativamente nuevo, pero la
‫idea de que somos operadores, y
‫esa es la gente que administra estos
‫grupos de Kubernetes, realmente estamos actuando como operadores.
‫Los operadores están tomando los avances de los equipos
‫de software donde tuvieron que administrar el
‫código, y el cambio de código con el tiempo, y lanzamientos,
‫lo que ha dado lugar al surgimiento de herramientas
‫como GitHub, derecho, para usar esas mismas herramientas para administrar nuestra infraestructura en
‫una manera declarativa Me has escuchado hablar de eso.
‫Creo que cuando miras el conjunto de características a lo
‫largo del tiempo de Kubernetes, puedes ver cómo se
‫está volviendo más declarativo en estilo, y el conjunto de características y el foco están
‫en ese flujo de trabajo declarativo.
‫Espero que obtengamos mejores herramientas y los que
‫tenemos obtendremos más funciones con el tiempo.
‫Otra gran cosa aquí es el soporte de Windows Server.
‫2019 vio el gran anuncio sobre el soporte
‫de Windows Server para el servidor 2019, y
‫eso es solo en su infancia.
‫Eso es algo que Swarm está técnicamente por delante
‫de Kubernetes.
‫Donde Docker y Swarm han tenido soporte de Windows Server durante
‫años, y definitivamente ha mejorado con el tiempo.
‫Pero, comenzaron eso con Server 2016 y lo han
‫estado impulsando y mejorando.
‫Mientras que, Kubernetes ahora en Windows
‫Server 2019 realmente está diciendo que tienen soporte.
‫De las personas que escuché hablar sobre
‫el servidor en producción, Windows Server aún podría usar mucho
‫más trabajo en el mundo de Kubernetes para ser
‫igual a Linux. Por lo tanto, creo
‫que ese será un gran área de enfoque a medida que más
‫empresas de Windows adopten estos orquestadores de contenedores.
‫Unas pocas cosas aquí definitivamente son los casos de Edge en los
‫que se trabajará.
‫Cosas como el aprendizaje automático.
‫Cosas como Edge y una pequeña infraestructura que se enfocarán
‫porque al principio de Kubernetes, era muy grande y
‫muy engorroso, pero
‫están sacando mucho y haciendo
‫que sea más fácil de implementar.
‫Es por eso que está viendo que herramientas como kubeadm salen y
‫pueden implementar clústeres HA.
‫Es totalmente seguro y, si es tolerante a
‫fallas, listo para usar. Esas son todas las cosas que
‫están dando sus frutos ahora.
‫Parte de ese futuro es conocer otros proyectos
‫relacionados. Esta es realmente
‫una lista rápida de las cosas que no he mencionado
‫en este curso que tal vez desee consultar. Debido a que Kubernetes se ha
‫convertido en la plataforma en la que todas las demás
‫cosas comienzan a construirse. De hecho, ese fue realmente
‫el objetivo original de los autores del proyecto.
‫En realidad, nunca pretendieron que usemos Kubernetes directamente
‫en términos de Kubernetes sin procesar y de
‫código abierto.
‫Realmente querían que otras personas crearan abstracciones para que
‫podamos ejecutar nuestras cargas de trabajo.
‫Es por eso que ves distribuciones saliendo, en
‫muchos casos, porque están construyendo otra capa en la parte superior
‫para hacerlo. En este caso,
‫estamos viendo todo tipo de infraestructura para hacer otras
‫cosas. Primero, Knative.
‫Esto está alrededor de las listas de servidores, y
‫definitivamente es un proyecto oficial de CNCF, por lo que está estrechamente relacionado con el
‫mundo de Kubernetes.
‫Si está interesado en las listas de servidores, definitivamente es uno
‫de los proyectos que desea consultar.
‫A continuación, un par de proyectos de Rancher son
‫K3s y K3os.
‫K3s es
‫esencialmente su equipo que toma la compleja implementación y
‫administración de Kubernetes y lo simplifica, eliminando
‫todas las cosas innecesarias que conlleva.
‫Tal vez algunos de los comandos y códigos heredados.
‫Tal vez algunos de los controladores de almacenamiento que ya no
‫necesita si tiene CSI.
‫Ese tipo de cosas. Simplemente lo sacan todo y
‫te dan una base de datos realmente fácil.
‫Ni siquiera usa etcd fuera de la caja.
‫Utiliza una base de datos más simple.
‫Realmente está destinado a cosas originalmente como IoT.
‫Pero ahora, con su objetivo de hacer que Kubernetes sea
‫tan simple como Swarm, como dijo Darren
‫Shepherd, su CTO y cofundador, en DockerCon
‫este año. Fue una declaración bastante interesante.
‫Realmente estaba diciendo que, ya sabes, a Swarm le va
‫muy bien en la implementación, la facilidad de uso y el
‫impacto mínimo. Es un binario muy pequeño.
‫Tiene muy pocos gastos generales
‫en términos de infraestructura. Kubernetes es todo
‫lo contrario de eso. Están tratando de encontrar el término medio.
‫¿Es posible si eliminamos suficientes cosas y aún así lo
‫hacemos realidad Kubernetes, podemos hacer que sea muy fácil de implementar
‫en sistemas pequeños como ARM, Raspberry
‫Pis, cosas así? Entonces, ese es un proyecto para mirar.
‫K3os es un sistema operativo
‫con K3 encima.
‫Es una instalación mínima de
‫Linux diseñada para ejecutar K3 en
‫pequeños dispositivos. Esa es una muy nueva pero
‫un proyecto interesante, no obstante. Otra área de enfoque realmente
‫grande, de la que me oirán hablar mucho más en mi
‫podcast, es la malla de servicio, que es un concepto nuevo en los
‫últimos años y un término realmente nuevo.
‫Realmente no hemos usado esa palabra en la industria antes.
‫La malla de
‫servicio es la idea de esta capa proxy en todo
‫el clúster, no solo para las conexiones entrantes de Internet, sino
‫también para todas las partes de su aplicación.
‫Se convierte en un intermediario para controlar, en términos de
‫seguridad, en términos de monitoreo y enrutamiento a las
‫ubicaciones adecuadas, todo el tráfico
‫de todas las partes de su aplicación distribuida.
‫Es una serie de proyectos que surgieron del
‫problema de los microservicios. Si alguna
‫vez ha realizado microservicios, uno de los desafíos reales es lo que
‫había en un solo binario en un solo servidor y
‫relativamente fácil de solucionar se convierte en docenas de
‫contenedores, en docenas de servidores.
‫Eso se vuelve muy difícil de solucionar a menos que
‫tenga excelentes herramientas de red.
‫Por lo tanto, la malla de
‫servicio apunta a ese problema e intenta convertirse en
‫un estándar, con estándares detrás de
‫él, alrededor de colocar una capa allí para tener una mayor
‫visibilidad, monitoreo, resolución de problemas y seguridad alrededor de nuestras aplicaciones distribuidas
‫y nuestros microservicios.