Meta Framework para Kubernetes: TypeScript Meets Cluster Control

Todos, es un gran placer estar aquí. Y como entusiastas de TypeScript y escritores de JavaScript, quiero mostrarles algo nuevo que va a cambiar el juego en el mundo de la nube nativa, en el mundo de la nube híbrida. Pero primero que nada, ¿puedo ver una muestra de manos sobre quién está en Kubernetes ahora mismo? ¿Quién despliega en Kubernetes? Increíble. Todos, ¿verdad? Mucha gente, ¿verdad? Bien, eso es genial. Bien, genial. Así que aquí vamos.

Soy Case. Tengo dos aplicaciones en producción. Es una especie de broma, pero una de ellas es la aplicación Find My Car, porque vivo en un edificio alto y no tengo intranet. Y casi nunca conduzco porque vivo en Miami. Así que nunca lo recuerdo. Y voy a Find My Car y me pregunto, ¿en qué piso estaba? Hay como 13 pisos. Me encanta la infraestructura. Me encanta Kubernetes. Me encanta la nube híbrida. Construyo operadores y controladores de Kubernetes. Usualmente hablo con una persona y solo una persona. Y ese es el servidor Kube API. Así que si ustedes entienden eso. Vamos Heat y vamos Fence. No ha sido un buen año para el Fence. Pero de todos modos, una pequeña aplicación divertida. Garabateé mi coche, sin embargo. Pero podemos ver que estaba estacionado en el 535 y no había conducido durante 41 horas. Así que realmente no conduzco. Bien.

De acuerdo. Así que Kubernetes Fluent Client. Así que realmente no puedo entrar en Kubernetes Fluent Client sin hablar sobre Pepper. Porque Kubernetes Fluent Client es el motor detrás de Pepper.

En resumen, sin embargo, es completamente de código abierto. Está probado en batalla. Se utiliza a gran escala en muchos, muchos clústeres. Y es un framework de TypeScript. No Go, sino TypeScript diseñado para la simplicidad. Debería haber mencionado que me encanta Go. Y realmente nunca escribí tanto TypeScript hasta este trabajo, ya sabes, hace como tres años, comencé a escribir mucho TypeScript.

Pero primero es Pepper. Pepper es un controlador de admisión de Kubernetes en un framework de construcción de operadores. Si están familiarizados en la industria, es más similar a operator SDK o Kube Builder. Es algo similar a un Kybernaut o un OPA. Pero solo voy a darles una pequeña metáfora de lo que es la admisión de Kubernetes para que pueda realmente entrar en el KFC como lo llamamos.

Imaginen que están en un club y hay todos los que quieren entrar a este club. Es un club muy solicitado. Y hay básicamente dos tipos de porteros. Hay un portero mutante. Entonces, ¿qué hace el portero mutante? Cuando alguien está entrando al club y ven que esa persona, ya sabes, digamos que el club requiere que uses una chaqueta. Le darán a esa persona una chaqueta. Así que un portero mutante puede realmente cambiar la ropa o dar cosas a las personas, cambiar cosas, ¿verdad? Cambiar objetos de Kubernetes. En la admisión de Kubernetes, puede haber tantos webhooks mutantes como necesites. Así que un portero mutante te está dando una chaqueta. El otro portero mutante está verificando si tienes el tipo correcto de calzado.

portero mutante está verificando si tienes el tipo correcto de calzado. Después de todos los webhooks mutantes vienen los webhooks de validación. Entonces, lo que hace el trabajo de los webhooks de validación o los porteros de validación, es mirar tu vestimenta y decir, bien, ¿cumple con los criterios del código de vestimenta? Un portero de validación podría decir, déjame revisar los zapatos. ¿Funcionan los zapatos? Y luego hay otro portero de validación que podría estar buscando la chaqueta. En resumen, así es como decides qué puede entrar en el clúster. Y la razón de esto es más como, ya sabes, tener una postura de seguridad global en tu clúster. Nada entra en mi clúster que esté ejecutándose como root o con permisos altos.

Quiero asegurarme de que estamos completamente seguros aquí. Pero ahora, ¿qué pasa si el club se abrió antes y había personas allí antes de que los porteros comenzaran a trabajar, antes de que el portero comenzara a trabajar? Ahí es donde entra el informer. El informer es como, imagina como tal vez un informante o un espía que dice, quiero asegurarme de que el club esté funcionando sin problemas. Quiero asegurarme de que, ya sabes, nadie esté peleando en el club o, ya sabes, no haya negocios turbios para que todos puedan asegurarse de que están pasando un buen rato. Así que el informer es para observar los recursos que ya existen en su clúster que no están pasando por la admisión porque la admisión es básicamente como crear, actualizar, eliminar. Bien.

Y honestamente, el informer es la parte KFC de Pepper. Entonces, ¿cuáles son los casos de uso de incluso considerar Kubernetes con TypeScript? Bueno, todos ustedes son prácticamente expertos en Kubernetes por la muestra de manos que vi. Y no sabía con qué tipo de personas estaría charlando. Si todos ustedes tendrían experiencia en la nube nativa. Pero uno, y esto va a ser tan obvio para todos ustedes ahora, pero para tener más control sobre su aplicación en producción, quiero asegurarme de que no me quede sin recursos. Quiero básicamente cuando algo entre en mi clúster, quiero replicarlo en un clúster secundario, en otra base de datos. Programación avanzada. Todos hemos oído hablar de la IA, ¿verdad? Así que la IA es como a veces puede haber múltiples agentes, ¿verdad? Puedes tener tu agente de Slack que puede, ya sabes, leer tus mensajes de Slack. Puedes tener tu agente de Gmail. Pero todos esos requieren recursos específicos. Y como sabemos, en Kubernetes, tal vez no todos los nodos tienen suficientes recursos en términos de memoria o CPU, pero tampoco es común que los nodos tengan GPUs. Así que tenemos que programar esas cargas de trabajo para que caigan en un lugar donde realmente puedan ejecutarse. Simplificando la complejidad alrededor de los despliegues, como esta es la razón principal para un operador. Y voy a aventurarme a decir que a medida que profundizamos más y más en la IA con las configuraciones volviéndose mucho más complejas, Anna quiere mirar cosas como métricas y scrapes y todo esto alrededor de todos estos componentes de la pila de IA. Creo que vamos a tener que abstraer esa complejidad con operadores. Y eso es básicamente como simplificar alrededor de los despliegues. Pruebas de integración, ¿verdad?

Así que despliego mi aplicación web. Quiero hacer una prueba de integración para mirar y ver si hay un despliegue en mi clúster. Ver si tengo un servicio en mi clúster, una cuenta de servicio, vinculación de roles, lo que sea. Pero pruebas de integración.

Entonces, ¿por qué construir algo nuevo? Y esto es algo sobre lo que mi CTO fue muy insistente cuando comenzó Pepper hace unos dos años y medio. Porque hay tantas herramientas por ahí. Y al principio fue porque estábamos tratando de hacer algo muy similar a Kiberna, que es otro controlador de admisión, pero queríamos todo el poder de un lenguaje de programación completamente tipado en admisión.

Así que antes de que un recurso de Kubernetes entre en admisión, quiero poder hacer literalmente cualquier cosa, cualquier cosa con él, ¿verdad? Hay un tiempo de espera del webhook, que suele ser de unos 10 segundos. Pero si eres muy estratégico con lo que quieres hacer, puedes hacer muchas cosas. Y si te preocupa el tiempo de espera del webhook, por supuesto puedes usar el patrón de informer y no hay limitaciones de tiempo de espera allí.

No tienes que ser un experto en la biblioteca go de cliente de Kubernetes para usarla porque hay mucho código repetitivo. Hay mucha extracción extracción. Esto literalmente parece inglés completamente sencillo, ¿verdad? Como cuando se crea un pod o kubectl, aplicar, un pod, un servicio, un stapleset. Así que es como inglés sencillo. Y hay algo llamado Kubernetes JavaScript client, o Kubernetes JavaScript. Olvidé qué biblioteca es esa. Pero realmente habríamos tenido que tomar completamente el control de esa biblioteca y cambiar gran parte de la superficie del API, lo que quiero decir, hay mucha gente usándola y no íbamos a intentar hacer eso. Era simplemente más fácil construir en este caso.

Y esto sigue hablando mucho sobre el porqué. Pero hay un, en un stack tecnológico nativo de la nube, tenemos cosas como Prometheus para métricas. Tenemos cosas como Keycloak para autorización y autenticación. Tenemos cosas como Istio para el cifrado de tráfico de red de este a oeste. Pero la cosa es que, cuando una pieza de configuración cambia, es frecuente que haya un efecto en cascada. Así que tienes un sitio web y una base de datos y tu sitio web puede acceder a tu base de datos. Pones una política de red porque quieres que tu base de datos esté segura que dice que solo el servicio del sitio web puede hablar con el servicio de la base de datos. Todo lo demás es un denegar todo por defecto.

Así que solo el sitio web puede hablar con la base de datos. Bueno, ¿qué tal esto? Estás recibiendo mucho tráfico en tu sitio web y mucho tráfico en tu base de datos, y necesitas empezar a mirar algunas métricas. Así que necesitas ver como si tu base de datos se ha caído antes. Así que ahora empezamos, desplegamos Prometheus y desplegamos estas cosas llamadas monitores de servicio. Así que podemos realmente extraer los datos del sitio web y extraer los datos de Prometheus. Genial. Así que ahora lo que tenemos que hacer, sin embargo, es abrir la política de red. Así que ahora Prometheus puede acceder a estos dos. Así que ahora tenemos que el sitio web puede hablar con la base de datos. Ahora Prometheus puede hablar con ambos. OK, genial. A continuación, tenemos a nuestros jefes. Ellos vienen y dicen, como, ¿qué están haciendo? No estamos cumpliendo ahora mismo. Así que tenemos que cifrar todo el tráfico de red.

Así que estamos como, oh, wow, eso es genial. Así que ahora tenemos que implementar Istio y tenemos como una política estricta de autenticación de pares. Así que todo el tráfico de red está cifrado a través de mutual TLS. Pero ahora nuestros puertos de scrape han cambiado para los monitores de servicio para Prometheus. Así que ahora tenemos que hacer ese cambio. Correcto. Y estos son solo tres componentes.

Así que esto realmente, como, se encascada y simplemente es lo que es. Así que mira, si necesitamos estas cosas a la izquierda, a la derecha, si necesitamos, no sé, todas estas cosas, necesitamos métricas, necesitamos trazabilidad distribuida, necesitamos authN a través de authZ, necesitamos Istio. No sé. Necesitamos, como, lo último y lo mejor que hay por ahí. No queremos tener que configurar cosas a mano o en un repo. No es una mala idea en el repo usando código de infraestructura.

Pero, ¿qué pasa con la próxima aplicación? Así que lo que queremos poder hacer es decir que quiero implementar un recurso personalizado. Quiero implementar una abstracción de una aplicación para poder implementar la primera aplicación, una aplicación nueva o mi aplicación número cien de la misma manera exacta. No hay fatiga humana y no hay errores de tipeo.

Mi operador, mi controlador sabe cómo configurar Istio para lo que sea. Sabe cómo configurar Falco. Sabe cómo hacer Loki y logs y todo eso. Así que este era nuestro objetivo. Y por eso desarrollamos Pepper.

Y entonces, si pensamos en, como, ¿por qué hacemos cosas como esta es porque queremos delegar configuraciones complejas. ¿Debería tu propia aplicación manejar, como, autorización, autenticación, enrutamiento, crear sus propias métricas, recolectar sus propias métricas, verdad? Va a ser como la aplicación más grande que va a tener tanta lógica de negocio que no tiene nada que ver con la aplicación en sí.

Correcto. Como nosotros el pensamiento común es que quieres que tu aplicación se adhiera a su lógica de negocio. No debería preocuparse por las reglas de destino. No debería preocuparse por el ingreso de Kubernetes o la política de red.

Queremos delegar ese tipo de cosas a herramientas como Istio, política de red, Key Cloak, porque estas herramientas están hechas específicamente para eso y son excelentes en ello. Así que básicamente queremos impulsar la productividad de los desarrolladores delegando eso. Y entonces esto fue cien por ciento para la productividad del desarrollador. Así que ¿cuál es el resultado deseado? Uno, una iteración rápida desde una idea como, oye, creo que podemos hacer esto mejor y tengo una idea de cómo hacerlo hasta un POC rápido. No queremos que te preocupes por tener que buscar la sintaxis. Queríamos que fuera tan dolorosamente obvio para estar listo para producción. Así que esto es cien por ciento para la productividad del desarrollador. Y es para democratizar el desarrollo de operadores de Kubernetes para cualquiera, para cualquiera.

Así que está en TypeScript, pero ahora es con una API muy fluida. El segundo es que necesitamos que sea muy ligero y muy rápido porque sabíamos que iba a ejecutarse a escala. Así que una API sencilla, sin necesidad de frameworks pesados. Y luego no queríamos que fuera simplemente simple. Queríamos que tuviera cosas como server-side apply para reducir la presión de la red. Así que server-side apply es básicamente que solo estás enviando un pequeño parche al servidor API de Kubernetes del plano de control. Y no necesita el recurso completo. Así que si estás enviando miles de recursos todo el tiempo, vas a reducir mucha de la presión de la red.

Tenemos nuestro propio Kubernetes informer personalizado, que básicamente observa cosas en el clúster y reacciona a los cambios. Así que es básicamente como si llamaras al plano de control de Kubernetes y dijeras, necesito saber cada vez que un config map cambia en el namespace de la aplicación AI cool. Y entonces solo te trae el delta. Es como, esto fue añadido, esto fue actualizado, esta parte cambió. Entonces, ¿qué es tan bueno del Kubernetes Fluent Client, aparte de que es como el motor que impulsa Pepper, tiene el informer, utiliza estas mejores prácticas de Kubernetes. Bueno, este es muy interesante. Así que realmente me gusta LoveGo, como dije, y en Go, lo que puedes hacer es que tienes estos informers compartidos de Kubernetes y estos informers de Kubernetes que son como parte de la biblioteca Kubernetes Client Go. Así que si tienes un problema con tu informer, básicamente puedes decirle a la gente que diga, oye, ese no es realmente mi problema. ¿Por qué no presentas un problema en el upstream de Kubernetes y les dices que su informer no funciona? De todos modos, fue como una broma, pero es agradable poder delegar cosas a veces.

Todos en mi empresa decían, no, sabemos que podemos hacerlo mejor aquí. Bueno, nuestro informer de TypeScript en un momento estaba fallando. Básicamente, no voy a entrar realmente en el informer, pero lo que sucede es que haces lo que se llama un watch en un recurso, y eso crea una conexión de larga duración. Y luego, la razón por la que un informer es muy robusto es que cada vez que recibe un evento de vuelta, lo almacena en un caché efímero local, como en la aplicación.

Y luego, cada cierto tiempo, puedes decir cada 10 minutos hace un relist. Y eso trae de vuelta la lista de todo lo que estás observando. Y así, cuando obtienes la lista de vuelta, comparas las versiones de los recursos, la versión del recurso con la versión del recurso en el caché para ver si acabas de traer algo nuevo. Eso indicaría que hubo un cambio que tu informer se perdió. Así que lo que estaríamos haciendo en retraso es procesar la carga útil o ejecutar la carga útil.

Como, oh, Dios mío, llegamos 30 segundos tarde. En resumen, arreglamos nuestro informer de TypeScript. Era de la biblioteca node fetch. Había tantas preguntas. Había tantos problemas con eso. Y primero, lo cambiamos por HTTP2, que era más hacia donde queríamos ir. Era un poco más seguro y podíamos tener las conexiones de larga duración. Pero eso tenía una fuga de memoria C. De vuelta en los chicos de entrega e implementación estaban matando el pod.

Y cuando matas el pod, reinicias el informer y comienza con una lista y obtienes todo lo último. Así que funciona de esa manera. De todos modos, teníamos esta fuga de memoria. Así que decían, oye, ¿qué diablos? Está como filtrando memoria. Está reiniciando. Es como, sí, bueno, ahora no tienes que matar tus pods. Simplemente va a morir cuando alcance este límite de memoria.

Y luego fuimos a UDG. Y UDG es como la mejor biblioteca fetch que he visto. Es tan poderosa. Literalmente, en el momento en que obtuvimos UDG y estábamos haciendo pruebas de resistencia de nueve horas, desplegando pods cada cinco segundos y verificando si estaban allí como cinco segundos después, porque programamos a Pepper para decir, observa un pod. Y cuando se crea un pod, elimínalo.

Y luego diez segundos después, va cada cinco segundos. Diez segundos después, estábamos viendo si el pod todavía estaba allí. Y era literalmente como un fallo de observación. UDG era como increíble. Tan increíble. Pero yo estaba como, me pregunto si Go es mejor. Como me pregunto si el cliente de Kubernetes Go sigue siendo mejor. Así que hice dos experimentos. Primero, puse el Go en un sidecar. El Kubernetes share informer.

Y estaba usando DRP streaming. Y básicamente programaría el DRPC stream con una llamada unaria desde Pepper y el mismo contenedor y el otro contenedor en el pod. Y luego básicamente solo transmitía eventos de vuelta. Funcionó increíble. Correcto. Y luego hice una segunda implementación en Go con NATS, solo porque realmente quería jugar mucho con NATS. Pero básicamente crearía un tema en un servidor NAT. Los servidores NAT son externos. Pero todavía tenía mi sidecar Go para mi Pepper, y luego Pepper se suscribiría a un tema NATS. Y luego Go realmente enviaría eventos a través del canal y luego Pepper los recibiría. Así que era como un gran triángulo. Así que el DRPC streaming funcionó un poco mejor que el NATS, pero ninguno de ellos funcionó mejor que el TypeScript.

Estaba lanzando como 12,000 eventos al mismo tiempo. La cosa es, sí, tal vez Go es un poco más eficiente. Puede compilarse. Pero a esa escala, el factor limitante es la red. No es el lenguaje de programación. Es como 100% la red. Así que nos dimos cuenta de que nuestro TypeScript Informer, al igual que los de Go, no perdió ningún evento. Tenía perfiles de memoria muy similares. Todavía funcionaba increíble. Así que nos quedamos con TypeScript.

Bien, ahora me queda aproximadamente un minuto. Así que solo quiero mostrarles toda la superficie de la API. Les dije que todo se lee como inglés real. Así que miren, aquí están las operaciones CRUD. K8s, kind, namespace, apply, ¿verdad? Así que estoy aplicando algo. K8s, kind, dot, namespace, get. K8s, kind, dot, namespace, delete. Mejores prácticas, esto es server side apply.

Así que tienes estos field managers. No tienes que enviar toda la especificación. El Kube API server lo hace. Tienes estos subresources. ¿No es eso simple? Déjame revisar los logs aquí. Patching statuses, es como una cosa de controlador, pero todos los CRs tienen un status. Y si algo sale mal, al menos quieres tener un registro de eso.

Oh, accediendo a un proxy a un puerto dado en un pod. Está bien, es un proxy. Puedes ver por qué esto sería súper interesante para entornos de prueba. Debido a esto, déjame asegurarme a ciegas, como fallar la prueba de integración. Y por supuesto, los buenos viejos finalizers, ¿verdad? En resumen, un finalizer es como cuando dices, no quiero que puedas eliminar esta cosa. No quiero que nadie pueda eliminar esta cosa porque esto es crítico para mi infraestructura.

Así que le añades un finalizer. Así que cualquier cosa con un finalizer no puede ser eliminada por error. Protege las cosas. Es como k8s, kind.pod, en namespace, finalize. Elimina este finalizer que tenemos. Y luego evict. Evict respeta la programación mucho más que delete. Éramos un grupo de personas de Kubernetes, mantenedores de Kubernetes, contribuyentes de Kubernetes, y teníamos a este tipo realmente inteligente llamado Mache. Él decía, necesitamos hacer evict en lugar de delete. Así que lo añadimos al KFC.

Lo que me encantaría es que todos ustedes le dieran una estrella a los clientes fluidos de Kubernetes y a Pepper en GitHub. Eso es github.com barra diagonal defenseunicorns, barra diagonal kubernetes-fluent-client, y barra diagonal pepper, P-E-P-R. Estamos en Kubernetes slack.

Y ese es todo el tiempo que tengo. Así que muchas gracias a todos. Tenemos unos minutos para preguntas, así que no olviden que pueden ponerlas en slido.com.

La sesión en la que estamos todos es 1117, y estamos en la pista de residencia en esta sala, a diferencia de la pista de comunidad en la otra sala. Así que mientras la gente hace sus preguntas, gracias de nuevo por una charla tan genial. Tengo una pregunta probablemente no técnicamente interesante, relacionada con la misteriosa combinación de especias que va en KFC. Pregunta interesante. Nuestro CTO, él bebe tanto Dr. Pepper. También lo llamamos a veces Pepper Bear. ¿Qué tal, Jeff, si estás viendo? Bebe mucho Dr.

Pepper. Le encanta. Tal vez haya un patrocinio en proceso algún día. O tal vez solo tengas que llamarlo Coronel Pepper de ahora en adelante. Tenemos aspiraciones de donar Pepper a la CNCF. Estamos un poco investigándolo ahora mismo. Dr. Pepper, si estás ahí y quieres inyectar algo de dinero en el proyecto, dínoslo. Increíble, increíble, increíble.

Me encanta. Así que estás desarrollando todo esto en abierto con la comunidad, parece. Eso es fabuloso. Siempre es genial escuchar sobre trabajos interesantes como este que se devuelven a la comunidad en lugar de mantenerse. Hay muchas soluciones brillantes que la gente ha ideado, pero se quedan aisladas en la organización.

Así que es muy genial ver eso. Consumimos tanto código abierto como Prometheus, Keyclo, Kubernetes, obviamente, SDO. Y realmente nos gusta que uno de nuestros grandes objetivos como empresa es devolver tanto como podamos. Tenemos 10 proyectos ahí fuera ahora mismo. Genial, genial.

Así que mientras nuestras preguntas comienzan a llegar, esta es una gran pregunta. Para los principiantes que podrían no tener mucha experiencia con Kubernetes, con este tipo de plataforma, ¿cuáles son buenos lugares para comenzar? ¿Cuál es un buen punto de partida que un principiante podría tener? Sí, creo que realmente... Cuando quiero aprender algo, quiero tener un objetivo muy claro. Y con Gen AI, realmente puede guiarte. Pero diría que quiero desplegar mi aplicación.

Quiero desplegar mi aplicación y luego quiero escribir pruebas de integración o pruebas de extremo a extremo con mi aplicación para ver cómo está funcionando. Y luego, después de que pueda desplegar mi aplicación cada vez, podría querer decir, tal vez solo necesito leer sobre Kubernetes. ¿Estoy desplegándolo en un pod? Porque un pod básicamente no tiene un controlador alrededor. No tiene un controlador de replicación. Así que si el pod muere, mi aplicación muere. Así que luego comienza a leer sobre las mejores prácticas de Kubernetes.

Pero primero necesitas tener tu bebé, tu aplicación, para que luego puedas jugar con tu aplicación, viendo si puedes aumentar su resiliencia, aumentar su rendimiento. Tal vez quieras métricas de ella y así puedes comenzar a desplegar cosas alrededor de tu aplicación. Pero ten una meta pequeña y un comienzo y simplemente sigue avanzando y luego aprenderás mucho mejor. Genial. Me gusta esa idea de tomar las cosas paso a paso.

Comienza con lo práctico. Esto es lo que queremos que haga en el camino feliz, tal vez. Y luego comienza a construir la infraestructura Me gusta esta idea, también. Es casi como si todos necesitáramos empezar a pensar más sobre esa tolerancia a fallos, especialmente algunas de las otras charlas de hoy se han centrado mucho en flujos de trabajo con AI y todo este tipo de salida no conocible de tu código. Así que es importante poder manejar cualquier cosa que se te presente, supongo.

En la misma línea, ¿qué pasa si quisieras eliminar a la empresa intermediaria? ¿Qué pasa si quieres control total? ¿Qué pasa si quisieras tener tantos servicios que básicamente solo presionaras enter y extraería tu aplicación? Tal vez quiero tener control sobre la resiliencia de mi aplicación y cómo funciona. Sí, fabuloso. Y así otra pregunta sobre este tipo de mejores prácticas o comenzar con este tipo de trabajo. ¿Hay algo que sugieras a las personas que recién comienzan como principiantes con este tipo de pensamiento? ¿Evitar o mantenerse alejado de patrones anti? ¿Peores prácticas? Creo que morder más de lo que puedes tragar o parálisis por análisis debido al exceso de análisis es algo realmente malo para los principiantes.

¿Hay algo que sugieras a las personas que recién comienzan como principiantes con este tipo de pensamiento? ¿Evitar o mantenerse alejado de patrones anti? ¿Peores prácticas? Creo que morder más de lo que puedes tragar o parálisis por análisis debido al exceso de análisis es algo realmente malo para los principiantes. Como, ya sabes, para comenzar con Pepper o Kubernetes, ve al readme de Pepper, ya sabes, simplemente comienza allí o, ya sabes, hay tantas cosas fáciles que puedes hacer para comenzar. Y luego vas a gravitar naturalmente. Y si estás interesado, querrás aprender más. Digo, simplemente mantenlo simple. Como no, no trates de construir Roma en un día. Genial. Sí. Y me encanta, me encanta esa idea también de, ya sabes, comenzar con la documentación y comenzar con los, si no sé si hay tutoriales y cosas así, pero sé, sé que a veces me emociono demasiado y estoy como, puedo simplemente saltar directamente a hacer la gran cosa y siempre termino volviendo y simplemente leyendo las introducciones porque podría haber algunos conceptos clave. Algunos bocados allí siempre. Exactamente. Sí.

Bien. Y hablando de este lado de código abierto de Pepper y KFC, ¿hay algunas áreas particulares de KFC en las que estés buscando contribuciones o próximos objetivos para Pepper que tal vez la comunidad de código abierto podría contribuir? Sabes, hay, hay. Invitamos al 100% y amamos a nuestros contribuyentes. Hemos tenido algunos contribuyentes realmente buenos. Hay muchas cosas. Así que diría, primero que nada, entra, úsalo, encuentra un caso de uso para ello, ¿verdad? Ya sea pruebas de integración o realmente construir un controlador de Kubernetes para hacer cumplir algún tipo de comportamiento en tu clúster, tal vez postura de seguridad o lo que sea, ¿verdad? O simplemente para facilitar los despliegues. Tienes una aplicación de AI loca que tiene 10 o 20 agentes y sabes, eso puede ser difícil. Pero si puedes abstraer eso en como un CR deploy AI app y todo se levanta, sí. Así que, hey, cualquier cosa, damos la bienvenida a los contribuyentes. Diría que entra, mira los problemas, juega con ello, haz solicitudes de características. Si quieres eliminar una solicitud de característica tú mismo, bienvenido, simplemente etiquétenos en el repositorio y así es como funciona. Y si, si hace, era como en la hoja de ruta, ¿verdad? A menos que fuera como reescribir KFC en Rust. Entonces tendrías que rehacer la diapositiva. Eso no sería justo.

Genial. Bien. Y probablemente nuestra última pregunta para la que tenemos tiempo es, ¿cómo ayuda un auto-escalador a mitigar fallos en el clúster? ¿Podrías hablar un poco sobre eso? Un auto-escalador. Entonces, lo que hace un auto-escalador es que puedes asignarle algún recurso que diga, cuando mi aplicación alcance como un 30% de capacidad de memoria, quiero crear otra réplica, ¿verdad? O otra réplica. Así que cuando hay múltiples réplicas, solo una réplica tiene que estar disponible para atender la solicitud del servidor API de Kubernetes. Así que te da más resiliencia y redundancia y tú dijiste, dijiste, dijiste horizontal o dijiste vertical. Bueno, creo que solo en general. Bien. Bien. Haciendo que eso no sea una cosa. Entendido. Sí. Así que sí, un auto-escalador de pods horizontal generará más pods, más réplicas. Y entonces, tendrás más disponibles para básicamente atender tu solicitud. Si estás siendo bombardeado, si estás siendo golpeado por toneladas de solicitudes. También hay algo llamado auto-escalación vertical de pods en el lugar. Y creo que el recurso se llama política de recursos en Kubernetes, pero solo busca auto-escalación vertical en el lugar. Es realmente interesante porque puede escalar verticalmente la CPU sin volver a desplegar tu pod. Así que eso es realmente interesante. Un auto-escalador de pods vertical regular volverá a desplegar, desencadenará un redepliegue. Pero este es realmente bueno. Es algo nuevo, pero es, es realmente impresionante. Interesante. De acuerdo. Sí. Y, y también un gran recordatorio de que la nube son solo las computadoras de otras personas, ¿verdad? Sí. Genial. Fabuloso. Bueno, creo que estamos, estamos a solo unos segundos de nuestro tiempo asignado para el día, pero todos, si pudiéramos por favor dar otro gran agradecimiento a Case por venir aquí y nos veremos en GitHub, ¿verdad? Sí, absolutamente. Gracias a todos. Bien. Muchas gracias.