Kubernetes 101

1. Introducción: De acuerdo, hola y bienvenidos a Kubernetes Warner uno. Esto va a ser bueno. Y entonces sí, vamos a estar aprendiendo algunas cosas, pero absolutamente nos vamos a divertir haciéndolo. Ahora pues, justo fuera del bate. De acuerdo, vamos a nivel establecer un objetivo en este curso a aquellos de ustedes que son nuevos para Kubernetes. De hecho, ni siquiera realmente tienes que tener uso Docker ahora en TI o un fondo de desarrollador podría ser útil, pero sabes qué, no es un requisito. Por lo que no es necesaria ninguna experiencia previa. También, como dice el título, es un curso de 1.0.1. Esto significa que cuando no lo haces, no te vas a ir caminando como gurú de Kubernetes, lo siento por eso. Pero te vas a alejar sabiendo qué es Kubernetes y cómo funciona. Y tendrás una idea de algunas de las cosas que puede hacer por ti para que esperemos que tú, busques dar tus primeros pasos con Kubernetes. Bueno, ¿quién soy yo? Yo soy Nigel, y si no lo sabes ya, paso mi vida enseñando al mundo, Docker y Kubernetes. Es como si todas estas cosas de aquí fueran mías. Y además de esto, estoy fuera y por ahí en el circuito de altavoces y estoy entregando talleres y eventos como Docker Con y lo que tienes. Ahora. Obviamente recomiendo mucho mis otras cosas para dar los siguientes pasos. Pero entonces otra vez, no me gustaría decir, es mío tienen razón. Pero te diré lo que eres el juez, ver cómo te sientes después de este curso. Y si te gusta esto, déjame decirte, te van a encantar esos. De todos modos, esta soy yo en Twitter y tengo ganas de conectarme y hablar de tecnología. Pero tengo que decir esto ¿verdad? Estoy ocupado como el resto de ustedes, así que no puedo ser un soporte técnico gratuito. Es decir, estoy feliz de hablar de tecnología, pero solución de problemas complejos. Sí, de verdad lo siento. Simplemente no tengo tiempo. De todos modos. Se ve, llevo haciendo este tipo de cosas desde hace mucho tiempo. Entonces tengo confianza cuando digo, creo que te va a gustar. Y estoy igualmente seguro de que te alejarás sintiendo que has aprendido mucho. Pero mira, estoy bebiendo. Así es como estamos haciendo las cosas. Cortar en el curso más o menos por el medio, el primer tiempo. Entonces tal vez una hora más o menos. Vamos a clavar la teoría como las cosas de la arquitectura Kubernetes aquí. Entonces en el segundo tiempo se pondrá de manos a la obra. Ahora, mira, es un curso de video, ¿verdad? Es tu llamada si sigues junto con las cosas prácticas o si solo estás viendo totalmente tu núcleo. Pero lo que no quiero que hagas OK. Y confía en mí en esto, no te saltes la teoría porque es realmente importante, como lo estaré usando para poner la escena y prepararte para las cosas prácticas. ¿ Porque sabes qué? Tengo 0 interés en que puedas seguir y ser brillante o escribir comandos si realmente no entiendes lo que está pasando, créeme, ¿verdad? Yo mismo he estado ahí. Se pavimenta curso de readiestramiento. Sigues todos los ejercicios. A veces ni siquiera haces un solo error tipográfico puesto al final cuando no lo haces, realidad no eres el más sabio. Realmente no has aprendido nada. Entonces como si alguien te preguntara cuáles son los comandos en las cosas realmente muertos. Quiero decir, quién sabe, ¿verdad? Entonces no quiero que sea tú sigues la teoría. Bueno, hablando de la teoría, sí, describiremos qué es en realidad una aplicación de microservicios nativa en la nube. Entonces averiguaremos qué es Kubernetes. Ya veremos cómo es un clúster y luego veremos cómo es un orquestador de aplicaciones, h2. Y lo sé, bien, eso son muchas palabras de moda, pero todo está bien porque te explicaremos cada una de ellas a medida que vamos y así contextualizaremos las cosas con una mirada a un flujo de trabajo típico de cómo tomas aplicación de código en la laptop de un desarrollador para estar realmente en una aplicación en ejecución. De todos modos, cuando terminemos con la teoría, entonces será la práctica. Vamos a dar vuelta una prueba rápida. entorno de Kubernetes desplegará una aplicación, conectará a ella, probará una falla y dirá algo de la autocuración que continúa. Estamos escalando hacia arriba y hacia abajo, conéctate a un equilibrador de carga y haremos una actualización rodante. Ahora. Sé que eso podría sonar como un montón de cosas, pero lo estaremos manteniendo simple y estaremos explicando todo a medida que avancemos. Suena bien. Hagámoslo. 2. Microservicios naturales: De acuerdo, así que hablemos de qué carajo, un microservicios nativos en la nube hasta igual que ahora, hay una tonelada de definiciones por ahí, así que voy a bajarlo por ti. Pon primero las cosas. Devolvamos un poco el reloj. Dices, atrás en el día, construimos nuestras aplicaciones donde agregamos todas las características y la lógica y los diferentes bits en un solo programa como un único binario. Ahora, estoy siendo de alto nivel aquí. Pero tomamos pueden ser los bits de la interfaz de usuario, todas las cosas del middleware, esas cosas del backend de la base de datos y los sistemas de informes y todo lo que la aplicación alguna vez soñó hacer. Y nos habíamos agrupado en un solo programa enorme y lo instalábamos y lo respaldaríamos y lo ejecutábamos y todo ese jazz, Sí. Y era la forma en que siempre hacíamos las cosas. Y fue terrible. Y cuando digo terrible, estoy hablando de perder fines de semana enteros de tu vida ante ello, pero no fines de semana ordinarios. Estos eran por lo general los fines de semana de vacaciones largos. Por lo que un tema común era actualizar la cosa. Es decir, era tan complejo que ninguna sola persona o Ting realmente nuevo en absoluto o fue responsable de ello. cual es un poco un problema aún cuando se considera que todo el asunto fue agrupado y agrupado como una sola unidad. De todos modos. Entonces digamos que si necesitábamos parchear pueden ser los componentes de informes. Sí. Bueno, no es broma. Era todo de manos en cubierta para esos fines de semana largos, serías como precalentamiento de proveedores y clientes y cualquiera que usara el sistema y les dijera que bajaría desde las cinco de la tarde del viernes y no respaldarían hasta 10:00 PM del domingo. Y los jefes tienen el número de celular de CIO en marcación rápida y la mitad del departamento de TI estará en la oficina todo el fin de semana y viviendo de pizza y café. Y era cosa alta y preciosa. De todos modos. Los temas que forzaron que eran arquitectónicos ¿verdad? Todo estaba bien acoplado. Al igual que no podíamos simplemente derribar los bits de informes y parchear los independientes del resto del sistema. Ahora bien, si queríamos parchear el sistema de informes, teníamos que acabar con todo. De todos modos. Mira, así es como usamos la fila. Y tenemos palabras para aplicaciones como esa, ¿verdad? Nosotros los llamamos monolitos. Y en TI moderna, eso es como una palabra maldición, sí, como si ejecutas monolitos en tu organización, te avergüenzas apropiadamente. Definitivamente no se lo cuentas a la gente. Sí. De todos modos, suerte. Estoy bromeando, ¿verdad? Y ahora la mayoría de nosotros todavía tenemos monolitos dando patadas y eso está bien, ¿verdad? En fin, las cosas están cambiando y bastante diferentes en estos días porque ahora tenemos microservicios nativos en la nube. De acuerdo, vamos a descomponer eso. Entonces el bit de microservicios significa que tomamos toda la lógica que dijimos, sí, fue como web frontend y middleware y backend y bits de reporting aquí. Y los codificamos, y los hemos enviado de forma independiente. Entonces tenemos la misma experiencia general de aplicación aquí o los mismos bits, pero el rol independiente, como tal vez haya un equipo especial dedicado que codifica y cuida la apuesta web y otro equipo para el Datastore y otro para el sistema de presentación de informes. Por lo que todos están codificados y enviados de forma independiente, pero se hablan entre sí y forman un útil. Ahora, he dibujado la línea alrededor de ellos en guiones a propósito porque todos están sueltos esta vez. Entonces lo que eso significa es que podemos rev cada componente de forma independiente. Al igual que un poco tiene un error o una vulnerabilidad de seguridad y no, digamos el reportaje pero de nuevo, sí. Bueno, podemos bajar eso y actualizarlo sin tocar ni impactar ninguna de las otras apuestas. No obstante, como dijimos, todo sigue funcionando en conjunto para crear la misma aplicación comercial útil. Bueno, esa es la parte de los microservicios, ¿verdad? Un montón de diferentes servicios pequeños o micro que hablan entre sí y conforman una app más grande. Bueno, el bit nativo de la nube. Esto significa que está construido para demandas como la nube. Por lo que puede escalar rápidamente hacia arriba y hacia abajo. Y estoy hablando de que cada micro servicio aquí puede escalar de forma independiente. Bueno, además de que se puede autogranizar y podemos hacer actualizaciones rodantes y retrocesos de versiones y todo ese tipo de cosas aquí. Pero conozco muchas palabras de moda y las explicaré todas a su debido tiempo. Entonces simplemente no te abrumes por las palabras de moda de aquí. Ahora, algo interesante que podría no ser tan intuitivo. Nube nativa absolutamente no significa que solo se ejecute en la nube pública. Por el contrario, de hecho, e incluso llegaría tan lejos como decir un requisito de una aplicación nativa en la nube es que se ejecutará en cualquier lugar de la noche su centro de datos en las instalaciones. Entonces eso es microservicios nativos en la nube. Sí, nos acumulamos a partir de pequeños componentes especializados. Llamamos a estos microservicios, y todos estos hablan entre sí sobre API generalmente, y forman una aplicación útil o significativa. Y los beneficios, cada parte individual o micro servicio se puede escalar de forma independiente y actualizar de forma independiente. Y se pueden autogranizar y correr prácticamente en cualquier lugar. Cosas buenas. 3. cluster de Kubernetes: De acuerdo, hora de enfocarnos en Kubernetes. Ahora, vamos a pensar en Kubernetes como dos cosas. Uno como clúster y dos es un orquestador de aplicaciones. Entonces en el frente del clúster, sabes qué, un clúster es. Un cúmulo, ¿verdad? Es un montón de máquinas. Y mientras el Linux, sabes qué, a Kubernetes realmente no le importa. Por lo que podrías haberlos robado. O sea, no es que me esté recomendando estable, claro, pero solo para ser claros, a las comunidades no le importa. Podrían ser instancias en la Nube, VMs en tu centro de datos o ¿sabes qué? Incluso podría haber metales prohibidos en tu propio centro de datos solo mientras ejecuten Linux, Kubernetes es como, sí, lo que sea. Ahora, estoy diciendo Linux, pero en realidad Windows es algo con Kubernetes en estos días. De hecho, el soporte de Windows en Kubernetes fue GA, por lo que generalmente disponible y totalmente soportado en Kubernetes es 1.So 14 en el verano de 2019. Entonces sí, de todos modos, bloquear un clúster de Kubernetes es un cúmulo de nodos. Y al igual que con la mayoría de los clústeres, siguen aplicándose las mismas reglas antiguas. Por lo que podemos ver en la imagen que dividimos el clúster en dos partes. Aquí. A la izquierda tenemos los nodos del plano de control, y a la derecha tenemos los nodos del trabajador o supongamos palabras. Ok, entonces el plano de control, piense en esto como donde existen los cerebros Kubernetes o los smarts de Kubernetes. Sí. Entonces el trabajo está aquí. Aquí es donde ejecutamos nuestras aplicaciones de usuario y columnistas como el mejillón cluster, sí, al que acudiré en un minuto. Ahora, cuando decimos avión de control y Kubernetes es inteligente, estamos hablando de las cosas que hacen de Kubernetes. Kubernetes. Ahora cavaremos un poco más profundo en un segundo. Pero por ahora vamos a querer dejar claro que este es un tipo típico de clúster, lo que significa que aún se aplican todas las reglas habituales, como que no hay magia oculta, eso significa que ya no tienes que preocuparte por cosas como el rendimiento y la disponibilidad . No, siguen aplicando. Yo quiero ser claro. Estás honrado por el tiempo. Las reglas de clúster de producción probadas en batalla siguen aplicándose. Entonces como en la imagen de aquí, conseguimos tres notas en el plano de control. Disponibilidad, tres o cinco probablemente se recomienda y uno es mejor que evitar Split Brains. Sí. Ahora, no dejes que el balbuceo techno te confunda. El punto de llevar a casa es que necesitas asegurarte de que tus nodos de clúster sean lo suficientemente potentes. Y debes asegurarte de que si uno de ellos falla, las cosas seguían funcionando. De todos modos. Esos son los bits del plano de control. Y los nodos que componen este plano de control generalmente se llaman nodos de maestría o a veces Head. Todo es sólo jerga sin embargo, sobre los trabajadores. Ahora, la razón por la que me estoy refiriendo a estos como el músculo del clúster es aquí donde ejecutamos nuestras aplicaciones de usuario. Entonces, qué tan rápido se ejecutan tus aplicaciones, qué tan bien pueden escalar. Eso depende mucho de cómo proveamos a estos trabajadores. Por lo que dependiendo de los requerimientos particulares de tu aplicación, algunos de estos trabajadores podrían ser grandes máquinas pesadas y algunos podrían ser máquinas más pequeñas. Pero recuerda, cuando digo máquinas, estoy hablando de máquinas Linux y Windows en la nube o en prime, y pueden ser máquinas VMs o metales BAM. Ahora entonces mencionar windows me recuerda, las máquinas Windows solo son compatibles como nodos de trabajo. Entonces los nodos del plano de control aquí, siempre han tenido que ser Linux, pero los nodos de trabajo aquí, estos pueden ser una mezcla de Linux y Windows, que creo que es el nivel súper alto. Echemos un vistazo más de cerca a H hará maestros primero. 4. Maestros de Kubernetes: Muy bien entonces maestros. Por lo que se trata de un explotado el aceite como un zoom a la vista de una nota maestra. Entonces en realidad uno de estos aquí, sí. De acuerdo, bueno, a partir de arriba, un recordatorio sobre terminología. Normalmente llamamos a estos nodos el máster. Pero sabes qué, a veces oirás otros nombres como notas de cabeza o lo que sea. Todo significa lo mismo, un nodo de clúster que ejecuta los bits del plano de control, ese es el cerebro del clúster. Sí. Ahora, si está ejecutando un clúster de alta disponibilidad con tres o cinco maestros, cada uno estará ejecutando el mismo conjunto de servicios replicados. De esta forma, si alguno de ellos falla, los demás mantienen el clúster en ejecución. Ahora, hay más servicios que estos, pero por un costo de 101, estos son los principales. Entonces el servidor API se acostumbra a éste, ¿verdad? Es como la puerta de entrada al clúster. Entonces en cualquier momento queremos consultar el clúster o hacer un cambio de configuración o incluso implementar una aplicación y luego actualizarla y todo ese jazz con, hacer todo eso a través del servidor API. Entonces o enviando comandos al servidor API. Ahora, sin llegar demasiado profundo para este curso, correcto, expone una interfaz HTTP RESTful y cada comandado que recibe se autentica o autoriza y prácticamente cheques de cordura. Pero hablando de emitir comandos, necesito dar un paso atrás por un segundo. Entonces dijimos cuando emitimos comandos, Kubernetes es que vienen aquí al servidor API, ¿verdad? De acuerdo, pero ¿cómo realmente enviamos esos comandos? Bueno, en su mayor parte, correcto, ciertamente a un nivel 101, utilizamos la herramienta de línea de comandos Kubernetes llamada Cube CTL. Ahora, en la verdadera tradición Kubernetes en su probablemente acostumbrarse a esto. Hay como un millón de formas de pronunciarlo y vas a escuchar a todos, como digo Cubo CTL. Pero mucha gente dice ley de control de cubos, corte de cubo Locke, que se abrazan yo, y cómo lo llamas, ¿verdad? Cualquier cosa va. Lo importante, correcto, es la herramienta de línea de comando Kubernetes. Entonces son comandos como Cube CTL crean esto y Cube CTL describen eso. Y Cube CTL borrar algo. Y no nos adelantemos, ¿verdad? Lo verá todo en una cosa práctica más adelante. Yo sólo quería llenar un vacío potencial ahí, ¿verdad? En fin, estábamos diciendo que sí los comandos de Cube CTL van al servidor API y se autentican o autorizan y validan. Entonces como ejemplo, correcto, tal vez emitamos un comando para, no sé, tal vez implementar una aplicación o actualizar una aplicación. Sí, bueno, cualquiera que sea el comando que le esté diciendo a Kubernetes que haga eso se graba en la tienda de clústeres como un registro de intenciones. Ahora, el cluster store es una base de datos distribuida que generalmente se basa en el producto de código abierto llamado Etsy day. Y es el único componente con estado del plano de control, lo que significa que mantiene los datos de configuración localmente en el disco. Ahora, una vez que se persista la intención del comando en la tienda, Kubernetes pide entonces al programador que asigne el trabajo. Entonces creo que por el bien de la simplicidad, vamos a suponer que estamos implementando una aplicación web. Sí, y digamos que queremos cinco instancias ejecutadas de la misma. Bueno, el trabajo del programador es ir y encontrar el mejor trabajo en notas para ejecutar esos cinco servidores web. Ahora, este horario está buscando cosas como, bueno, nodos sanos es un buen comienzo. Sí, Está buscando nodos con los recursos adecuados y suficientes de esos recursos. Una vez que se encuentra algunos nodos, emite las tareas de trabajo a esos y se despliega la aplicación. Y eso es brillante, ¿verdad? Poner. Y este es el cubo mágico que es no se detiene ahí. Después implementa bucles de control de fondo que constantemente observaban el Estado del clúster. Y se aseguran de que lo que hemos pedido es lo que tenemos. Ahora, volveremos a esto apropiadamente en un minuto, ¿verdad? Pero en este ejemplo, creo que dijimos que pedimos cinco servidores web. Bueno, Kubernetes implementó bucle de control. Eso asegura que siempre tengamos cinco de todos modos, ¿verdad? Creo que para nosotros, ese es el avión de control. Es el cerebro del clúster y querrás que esté altamente disponible. Enviamos nuestras solicitudes o comandos al componente del servidor API del mismo. Estos se registran en la tienda de cluster es nuestro estado deseado. Entonces lo que queremos, el programador encuentra los nodos para ejecutar el trabajo. Y luego al fondo hay bucles vigilados asegurándose de que las cosas no se rompan. Y si lo hacen, debo decir cuando lo hagan, Kubernetes lo arregla. Brillante. Bueno, eso servirá para el avión de control por ahora. Cambiemos a los nodos de trabajo ahora. 5. Nodos Kubernetes: De acuerdo, así que al igual que la vista explotada del maestro, esto es un zoom a la vista de un trabajador. Y cada nodo de trabajador en el clúster ejecuta estos mismos tres componentes principales. Ahora, desde una perspectiva terminológica, definitivamente puedes llamar a estos trabajadores y la gente sabe a qué te refieres. Pero en su mayor parte sólo los llamamos nodos. Entonces maestros para el plano de control, sí, uh, nodos para donde ejecutamos nuestras aplicaciones. De hecho, a veces llamamos cubeletos a las notas. Así de importante es este pedacito de cubeletos aquí. Piensa en los cubeletos como el principal agente Kubernetes. Cualquier nodo que desee como parte del clúster necesita ejecutar un cubo. Pero ahora, supongo que inicialmente los cubeletos hablan con el plano de control y hace que el nodo CPU y RAM y los likes estén disponibles para el clúster. Para que ese trabajo pueda programarse al nodo, sí. Pero también está viendo el avión de control y le está hablando. Por lo que los cubeletos vigila el plano de control para nuevas tareas de trabajo que necesita ejecutar, y luego reporta de nuevo el estado de esa obra. Y curiosamente, correcto, todo esto hablando con el plano de control es a través del servidor API. Yo quiero ser muy claro al respecto. Toda la comunicación con el plano de control pasa por el servidor API. Es como la Gran Estación Central. Sí. Entonces los humanos de Assad hablando vía Cube, CTL o lo que sea. Pero entonces también, todos los Kubernetes, bits y piezas, literalmente, todo lo que habla con cualquier cosa en el plano de control tiene que ir a través del servidor API. En fin, mira, los cubeletos, es el principal agente de Kubernetes. Se ejecuta en cada nodo que quiere ser miembro del clúster. Si se detiene como falla o lo que sea, sí, intentará reiniciarse. Perfecto, continentes muertos en el agua que el nodo cae fuera del clúster y su tiempo de solución de problemas. Ok, bueno mira en medio del diagrama, tenemos el Container Runtime. Ahora, las actitudes cubanas es un orquestador de aplicaciones. Sí, puede orquestar cosas como VM y cargas de trabajo sin servidor. Pero en su mayor parte, en un nivel uno a uno, ok, orquesta aplicaciones contenerizadas. Entonces esas son las apps que se ejecutan como contenedores como los contenedores Docker. Sí. Ahora entonces estamos mirando una obra y anotamos aquí, y sabemos que aquí es donde las de Kubernetes son apps. Y acabamos de decir en su mayor parte, esos contenedores corredores africanos. Entonces tiene sentido entonces que cada nodo necesita algún software para ejecutar y administrar contenedores. Hablo de cosas básicas como cómo sacar una imagen de contenedor de un registro y luego cómo iniciar y detener y actualizar contenedores. Bueno, esa pieza de software, ese es el Container Runtime aquí. Ahora, en el inicio de Kubernetes, ese Container Runtime siempre fue Docker. Por lo que diríamos como aún, jugadas de Kubernetes ejecutan nuestra aplicación. El programador encontraría el nodo que podría ejecutarlo. El cubo encendido en ese nodo aceptaría el trabajo y luego se optaría a Docker como el Container Runtime. Tire de la imagen e inicie el contenedor. Pero eso fue entonces, y esto es ahora. Y en lugar de que el Container Runtime siempre sea Docker, tenemos esta cosa llamada Container Runtime Interface o el CRI. Si eres como eres acrónimos. Cortando directamente a la persecución sin embargo, esta es una capa de plugin. La carta dice, oye, tal vez no queremos Docker en este nodo, podríamos necesitar un Container Runtime diferente. Bueno, el CI lo hace posible. Por lo que ahora es realmente fácil decir, hey, en este nodo, vamos a correr puede ser g visor y aquí puede ser cortador, y aquí puede estar contenido un día. Ahora, sí, mira, somos un curso de 101, así que voy a mantener esto lo más simple posible en este caso, correcto, entre todos estos diferentes tiempos de ejecución de contenedores como Katherine, contenedor d, y qué elección más pesada es algo bueno. Cada Container Runtime ofrece potencialmente diferentes características de rendimiento, así como cosas como diferentes tipos de aislamiento de carga de trabajo. Entonces, por ejemplo, en el aislamiento desde la derecha, algo como gee, visor o cata podría ofrecer un entorno de tiempo de ejecución más aislado que algo así como Docker. Entonces si ejecutas dos cargas de trabajo una al lado de la otra, ¿verdad? A veces es importante el aislamiento de esas cargas de trabajo. ¿ Sabemos qué? Es decir, todo un tema propio y no vamos a ir ahí en este curso. Baste decir que el Container Runtime aquí es el bit que gira hacia arriba contenedores y los gestiona. Bueno. Por último pero definitivamente no menos importante, el proxy de cubo. Esto asegura que las redes de Kubernetes funcionen. Ahora un poco de un paso a un lado aquí, ¿no? Cuando construyes un clúster de Kubernetes, parte de esa operación es construir una Red POD. Y ya sabes, bueno, es muy simple, ¿verdad? El POD Network es una gran red plana que abarca cada nodo. Entonces como puedes tener totalmente un cluster donde todos los nodos están en diferentes redes en los Likes. Pero luego Kubernetes superpone esta gran red plana a través de todos los nodos. Ahora digo superposición, ¿verdad? Por lo general es una superposición de tierra VX, pero también puede ser BGP. Sabemos qué, lo importante es esta Red POD es en lo que se sientan todas nuestras aplicaciones. Y es bonito y sencillo y plano, ¿verdad? Por lo que todos nuestros componentes de la aplicación se sientan en él y pueden hablar entre sí. Brillante. De todos modos, mira detrás de bambalinas, ¿verdad? Q proxy aquí realiza toda la magia para que esa Red POD suceda. Cosas como tablas IP y reglas IPBES si te interesa. Pero eso son nodos. Ahora estamos a punto de pasar a Kubernetes como orquestador. Está bien. Pero muy rápido, antes de que hagan eso, solo quiero echar un vistazo rápido a algo que es realmente popular en estos días. Acogido Kubernetes. 6. Organizado K8s: Entonces tenemos esta imagen, sí, nuestro clúster Kubernetes y está rebanado aquí como un plano de control y una especie de plano de datos como los cerebros de Kubernetes viven en este bit y luego aplicaciones uno solo aquí. ¿ Sabes qué son los refrigeradores? Kubernetes Tech es un me encanta, ¿verdad? Soy realista y sé que la tecnología sólo existe realmente para ejecutar aplicaciones y construir negocios, y por supuesto, también cosas de cuidado de la salud y humanitarias. Sí. Pero mi punto es que nadie despliega Kubernetes sólo para que puedan decir, hey, tenemos Kubernetes es al menos una esperanza que nadie hace. Dices que lo despliegas para que tus aplicaciones se puedan ejecutar a escala y actualización de Healon y todas esas cosas, ¿verdad? Entonces todo se trata de la aplicación. Pero en este mundo de enfoque de aplicaciones, realmente sólo nos importan estos bits aquí. Quiero decir, todas las cosas del avión de control tan cool como es, ¿verdad? Simplemente se interpone en el camino, como solo pasar tiempo y esfuerzo planeando e implementando todas las cosas de alta disponibilidad y tal vez algunas de las cosas de rendimiento. Sí. decir, todo lo que está haciendo es distraernos de construir aplicaciones, que es exactamente donde entra en juego Kubernetes alojado. Entonces un servicio de Kubernetes alojado toma aquí los bits del avión de control, separados, dibuja una especie de línea de demarcación y dice, les diré qué. Gestionaremos todas estas cosas del avión de control para ti. Y acabaremos de exponer los bits de los trabajadores. Por lo que a un nivel alto sin entrar en detalle, no hay que darle un solo pensamiento al plano de control. Todo está gestionado para ti. Por lo que las actualizaciones, disponibilidad, rendimiento todo eso, todo cuidado por su proveedor de la nube. Hablando de lo cual todos los principales proveedores cuentan con un servicio de Kubernetes alojado. Los verdaderos grandes o el servicio de Kubernetes elástico de Amazon IQ AS, servicio Azure Kubernetes, aka S y G k0, el motor Google Kubernetes. Pero así, océano digital, IBM Cloud, estos tipos también los tienen todos. Ahora tengo que decir que es la nube. Por lo que aplican los costos. Nada es gratis, ¿verdad? Y tan bien como son los beneficios, como puedes hacer girar un clúster administrado de Kubernetes en poco tiempo y no tienes toda la preocupación del avión de control. Sí. Bueno, al otro lado, te rindes al control. Entonces, por ejemplo, estás limitado a las versiones de Kubernetes es compatible con un proveedor de nube. Y digamos que si necesitas establecer alguna configuración funky en el plano de control, lo más probable es que estés fuera de bloqueo. Entonces es genial, ¿verdad? Ponlo a espada de dos filos. El sencillez viene a costa de la configurabilidad. Ahora pues, y es difícil no entrar en detalle porque quiero decirte que suenas mucho, pero no quiero abrumar quieres 101 curso. De todos modos, podrías estar haciendo la pregunta, sobre todo si eres desarrollador. ¿ Por qué siquiera tengo que preocuparme por las apuestas del nodo trabajador? Al igual, ¿por qué no puedo simplemente dar mi solicitud a Kubernetes? Y que Kubernetes se encargue de todo por mí. Y esa es una gran pregunta. Y el, algo llamado los cubeletos virtuales que se dirige en esa dirección. Entonces no hay nodos reales en tu clúster, como cosas realmente geniales y un día potencialmente, no hay Kubernetes impíos lo es. Pero creo que para nosotros, correcto, eso es potencialmente realmente cosas de la mente soplando. Si te interesa sin embargo. Google cubeletos virtuales. Bullock, estoy wafflando. Kubernetes es un clúster de máquinas, principalmente Linux, y pueden ejecutarse en cualquier lugar. Esas máquinas individuales operan ya sea como maestros o maestros de trabajadores implementan toda la astucia Kubernetes y necesitan estar altamente disponibles y todo el costo habitual a la bondad. Pero no ejecutamos nuestras aplicaciones ahí en los nodos de trabajo del maestro. Ahí es donde ejecutamos nuestras aplicaciones. Los servicios Kubernetes bien alojados existen en la mayoría de las plataformas en la nube y principalmente nos ocultan el plano de control. A pesar de que existen otras opciones alojadas. ¿ Verdad? Magia. Veamos ahora cómo Kubernetes es un orquestador de aplicaciones. 7. Kubernetes como orchestrator: De acuerdo, Kubernetes como orquestador de aplicaciones. Entonces primero arriba, orquestador, que supongan palabra, entonces, ¿qué significa? Ok, aguanta conmigo en esto un minuto. Es un poco cursi, pero creo que realmente conduce a casa el punto. Entonces esto de aquí es una orquesta sinfónica, ya sabes, un montón de instrumentos diferentes que se unen y hacen música esperanzadamente increíble. Sólo que ahora mismo, están por todas partes y no tienen música para tocar. Entonces sí, tal vez Cool, no le pongas mucho uso. Bueno, vamos a traer al conductor. Entonces ella entra, pone cada instrumento en su lugar, reparte la música, y en general, organiza todo. Al igual que cuando el inicio, cuando para interpretar tu parte en particular fue un velocímetro, se fue a ir alto o callar todo ese jazz, Sí, jazz. Oh querida. No se pretendía juego de palabras ahí. De todos modos. Con sólo un par de cosas, el conductor y algo de música como partituras. Bueno, hemos pasado de Chaos a todos haciendo su parte y potencialmente creando una pieza musical conmovedora. Y no es demasiado difícil dar el salto a Kubernetes, donde tenemos un montón de diferentes servicios de aplicaciones aquí, todos simplemente chill in, en Medellín y realmente no tener ni idea de qué hacer o cuándo correr y dónde correr. Entonces tal vez motor X en radio y algunos OAuth y algunos bits personalizados aquí, todo código legal y micro servicios, ¿verdad? Pero no hay ni idea de cómo se unen todos y cuáles son sus partidos particulares. Entonces lanzamos Kubernetes es en la mezcla, como la conducta del aire. Y luego algunas configs de aplicación, piensa partituras. Y de pronto tenemos este correcto funcionando que hace algo, ojalá algo útil. Ahora, en el caso de la orquesta, necesitaba que los conducidos vinieran y los organizaran, les dijeran dónde decirlo, quién seguir fue venir en cómo tocar todo ese año. Y es algo igual en Kubernetes con nuestra app. Por lo que Kubernetes es, por ejemplo, programado cada componente. Entonces como les dice en qué nodos ejecutar, qué redes conectar a los puertos para exponer toda esa bondad. Y en el ejemplo de orquesta, todos necesitaban una copia de la música. Bueno, en la aplicación aquí, cada pieza necesita su propia configuración. Entonces lo que se supone que haga, y eso pueden ser cosas como servir páginas web, hacer autenticación, tal vez hacer búsquedas contra la base de datos. Sí. Que lo que por su cuenta, estos trabajos individuales podrían no parecer mucho. Pero cuando todos están corriendo juntos, obtendríamos una aplicación útil. Bien. Sí, espero así porque definitivamente fue cursi. Pero ¿sabes qué? Cuando he hecho esto, vivir en talleres y me gusta, todo el mundo siempre me ha dicho que era bueno. Por lo que ojalá te fuera útil. De todos modos. A continuación, vamos a echar un vistazo a conseguir código desde la laptop de un desarrollador hasta correr en Kubernetes. 8. flujo de trabajo de desarrollo: De acuerdo, entonces un flujo de trabajo de aplicación. Por lo que ese proceso de obtener código desde la laptop de un desarrollador todo el camino hasta ejecutarse en un sistema en vivo. Bueno, se ve algo así. Se escribe algún código de la parte posterior de un requisito o una idea. Sí. Ahora, a Kubernetes no le importa cómo escribes tu código ni en qué idiomas está. Siempre y cuando se ejecutara en Linux o Windows, deberíamos ser buenos. Bueno, una vez hecho el código, lo empaquetamos como una imagen de contenedor post-doc a un registro, y luego estamos listos para ejecutarlo, razón por la que entra Kubernetes. Ahora, bloqueo como mucho más simplificado. Entonces vamos a añadir un poco de detalle. Como dijimos, escribes tu código en los idiomas que quisieras, eso no cambia. Pero entonces este bit aquí, empaquetándolo como una imagen de contenedor. Sí, eso podría ser nuevo para ti. Por lo que un flujo de trabajo típico sería un desarrollador con escritorio Docker en su computadora portátil Mac o Windows. Escriben ese código de lo que usan las herramientas Docker para construir eso en una imagen, lo que podría sonar elegante, pero es más o menos simplemente poner su código de aplicación más cualquier dependencias en una carpeta de su computadora portátil, ejecutar un comando de compilación de imagen docker contra eso. Felder y Docker hacen el arduo trabajo de construir una imagen. Cuando se complete la construcción, tienes esta cosa que llamamos imagen, ¿verdad? Al igual que hemos insinuado que la magia de la imagen es que tiene todo dentro de ella que necesita tu app. Entonces tu código op, claro, sí. Ponga su bien, tiene todas las dependencias como bibliotecas y construcciones del sistema de archivos del sistema operativo. Significa que todo lo que tu app necesita para poder correr está dentro de esa imagen. Significado de nuevo, prácticamente puedes ejecutarlo en cualquier lugar y solo funcionará. Por lo que escribes tu código, usas las herramientas Docker para empaquetarlo como una imagen, luego usas Docker image push para guardarlo en un registro en algún lugar. Ahora un registro es solo un lugar para almacenar sus imágenes de contenedor y mirar. Puedes agotarte en prem o en tu propia nube privada virtual, o puedes usar un registro basado en internet como Docker Hub. El punto de comida para llevar sin embargo, una vez que tus imágenes en un registro, está listo para ser sacado y ejecutado en producción. Ahora. Producción, sí, claro, correcto. Entonces en este proceso nos estamos perdiendo un ridículo número de pasos. Di Sí, como todas las cosas que hacemos en el mundo real con una integración continua o un ducto de entrega continua. Entonces eso son cosas como construcciones automatizadas, pruebas, escaneos de vulnerabilidades, todo eso, bondad, sí, solo lo estamos ignorando para que el ejemplo sea simple. Pero sí, asuma que todas esas cosas no todas las construcciones y pruebas y escaneos de lo que tu imagen entra en un repositorio de producción y tu registro, y estás listo para desplegar, que es donde entra Kubernetes. Entonces en este punto su flujo de trabajo de desarrollo está hecho y aquí es donde los bits de operaciones toman el control. Ahora mira, hay mucho para Kubernetes y no hay escapatoria del hecho de que es una curva de aprendizaje bastante empinada. Pero quiero tomarme un segundo solo para darte una muestra de algunas de las cosas que Kubernetes ofrece para ayudarte a ejecutar tus apps. En la imagen aquí estamos viendo tres recursos Kubernetes en el set Daymond, en el despliegue, y un conjunto con estado. No quiero que te concentres en ningún detalle aquí. Tan solo quítate el panorama grande. ¿ De acuerdo? Por lo que un conjunto de daemon se asegura de que una instancia de un micro servicio en particular siempre se esté ejecutando en cada nodo en el clúster son ejemplo realmente común sería como servicios de registro o monitoreo. Sí, lo necesitas para ejecutarse en cada nodo. Bueno, ¿adivina qué? Usa un conjunto de daemon para lograr eso. Entonces tendrías tu servicio de registro o monitoreo, ¿verdad? Lo envolverías en un set de Damon de Kubernetes. Dáselo a Kubernetes para desplegar. Y Kubernetes se asegurará de que una instancia de la misma se ejecute en cada nodo del clúster. Brillante. Pero si agrega más nodos en el futuro, no se preocupe. Kubernetes ve eso y se asegura de que los nuevos nodos obtengan una instancia. Cosas buenas. Bueno, un despliegue es diferente. Todo esto se trata de poder escalar, autogranizar y realizar actualizaciones rodantes. Y los vamos a decir más tarde en la sección práctica. Entonces solo voy a estacionar despliegues por ahora, ¿verdad? Entonces el último que estamos mostrando y recordar hay montones más. ¿De acuerdo? Ponga conjuntos con estado se trata de desplegar y administrar las partes con estado de nuestras aplicaciones. Por lo que estos nos dan cosas como nombres de pod confiables y startups pedidas y los gustos. Sí. Pero mira donde de alto nivel o no quieren perderse en el detalle solo señalando bien, Kubernetes ofrece montones de formas de implementar y administrar los diferentes bits de nuestras aplicaciones. Enfriar, veremos en resumen, tenemos tres partes principales al flujo de trabajo. Codificas tu app. Utilizas Docker para empaquetarlo todo como una imagen de contenedor y empujarlo a un registro. Después utilizas Kubernetes para desplegarlo y administrarlo. Simple. Bueno, una fue que fueron lección y luego nos meteremos en los ejemplos. 9. Estado deseado: Justo entonces una cosa que absolutamente necesitamos saber es que la unidad atómica de despliegue o escalado y Kubernetes es algo llamado vaina. Y las contraseñas pueden escribir unidad atómica de programación. Sí, ¿verdad? Bueno en la pantalla aquí, podemos decir que VMware completo, la unidad atómica de programación, es la máquina virtual para Docker, es un contenedor y para Kubernetes visita el pod. Brillante. Bueno, lo que eso significa es que si implementamos una aplicación en VMware vSphere, estampillamos como máquinas virtuales. Si desplegamos una aplicación a Docker, estampilamos como contenedores en adivinar qué? ¿ Si desplegamos las comunidades? Lo estampilamos como vainas. Ahora, tropezándolo. Sí. Lo que digo es que todas las diferentes partes de nuestras apps en Kubernetes estarán funcionando como vainas. Entonces no sé si tenemos como un front-end web a nuestra aplicación. Sí, necesitamos escalarlo. Lo escalamos agregando más partes o si estamos bajando, nos llevamos partes. Brillante. Ahora bien, sí, Kubernetes es un orquestador de aplicaciones contenerizadas. Es decir, puede orquestar máquinas virtuales y cargas de trabajo sin servidor también. Pero en su mayor parte, Kubernetes orquesta aplicaciones contenerizadas. Por lo que las aplicaciones tanto de nodos son contenedores. Sólo. En realidad no se puede desplegar un contenedor directamente en Kubernetes. En serio, para que los contenedores se ejecuten en Kubernetes, necesita ser envuelto en una vaina, Sí. Y para el sistema operativo intensivo ahora en su curso 101, solo piensa en una olla es una envoltura ligera alrededor del contenedor. Todo lo que hace es dejar que contenga una corrida en Kubernetes. Y ahora los vamos a ver más tarde en unos pedacitos prácticos y todo quedará claro entonces. Pero tengo una última teoría mejor. Despliegues declarativos, estado no deseado versus estado real o bocado adecuado. Bueno, a Kubernetes nos encanta describirle las cosas de manera declarativa. Bingo Buzzword, ¿verdad? Simplemente me encantarían estas palabras de moda. Sí. Bueno, en la pantalla, tenemos algunos requisitos. Esto es lo que queremos. Por lo que diez copias de algún servicio basado en lo que sea imagen expuesta en el puerto 8080 con una etiqueta en particular. Eso es lo que queremos. Y el término técnico para eso es estado deseado. Bueno, escribimos eso en un archivo config y se lo damos a Kubernetes, diez réplicas de cualquier contenedor en este puerto con esa etiqueta, Sí. Y básicamente estamos diciendo, oye, Kubernetes, solo ve y haz que esto suceda jugadas. Y eso es todo ahora mismo. Podría parecer nada más que pensar en ello. Compara eso con el esfuerzo y el dolor de escribir algún guión enorme con todos los comandos y toda la lógica para gustar, bueno, decidir cuál de los nodos a uno las diez réplicas encendidas para empezar, además de todos los comandos y lógica para tirar de las imágenes, todos los comandos y lógica para iniciar los contenedores se unieron a las redes exponen los puertos, son las etiquetas, todas esas cosas, ¿no? Pues bien, este modelo declarativo no tiene nada de eso. Simplemente anota lo que quieras, dáselo a Kubernetes. Deja que Kubernetes se encargue de las cosas duras. Sí. Y eso es realmente brillante, ¿verdad? Pero ¿sabes qué? Es sólo la mitad de la historia. Porque ya ves, porque estamos declarando lo que queremos a las comunidades en lugar de solo decir, oye, ejecuta esta larga lista de comandos. Bueno, porque le decimos lo que queremos, Kubernetes registra este estado deseado como un registro de intención en el cluster store, entonces hace que suceda. Pero después de eso, gira hacia arriba. Observa bucles que vigilan el clúster y constantemente asegurándose de que lo que realmente se está ejecutando en el clúster coincida con lo que queremos. Ahora, si lo hace, entonces si el estado real coincide con el estado deseado, Brillante, ¿verdad? Si no lo hace sin embargo, como tal vez sólo tenemos ocho réplicas en lugar de diez. ¿ Hará Kubernetes lo que pueda para arreglar esa magia? Bueno, mira sólo en pasteles fuera snooty, ¿verdad? Digamos que un nodo falló y perdemos dos réplicas con él. Y qué diablos, ¿verdad? Sucede a las tres de la mañana. Bueno, Kubernetes es sabe que necesitamos diez réplicas. Acabamos de perder tres y ha bajado a siete. Por lo que gira tres más arriba y volvemos a diez. Estado real coincide con el problema del estado deseado solucionado, ¿verdad? Y ninguna llamada telefónica para ti en medio de la noche. Lavett? Bueno, este modelo es absolutamente integral a cómo funciona Kubernetes y es una de las cosas que lo hace tan grande. Y esto de aquí, así es como se ve en realidad. Ahora bien, si antes no has visto un archivo YAML como este y parece un poco aterrador, una promesa te, no está bien. Como nunca escribes estos archivos desde cero. De hecho, ya sabes, siempre solo tomo uno viejo y lo modifico. Sí. Pero la cosa es que, una vez que has visto algunos, empiezan a parecer mucho más simples. De todos modos, mira, estamos diciendo diez réplicas, así que diez pods, Sí, ejecutando esta imagen en particular y escuchando en este puerto ASI, post-doc al servidor API, asumiendo que pasa toda la autenticación y la autorización se pone registrado en la tienda de clústeres como nuestro estado deseado y se despliega en el clúster. Fabuloso. Pero entonces, como dijimos, esos bucles de reconciliación se están ejecutando en segundo plano y siempre están viendo el clúster todo el día, toda la noche, sin embargo probablemente con un café para mantenerlo despierto o lo que sea. Ponlo constantemente vigilando el clúster. Y en cualquier momento el estado observado varía del estado deseado, Kubernetes intenta arreglarlo. Una promesa brillante, ¿verdad? Te va a encantar. Y algo más que amas. Terminamos con la teoría. Es hora de mirar algunos ejemplos. 10. Cómo hacer Kubernetes: De acuerdo, entonces si quieres seguir adelante, vas a necesitar un clúster de Kubernetes y la app de muestra y los archivos de laboratorio. Entonces lo que haremos es mostrarte algunas maneras realmente fáciles de conseguir Kubernetes. Después te mostraremos cómo obtener los archivos del laboratorio. Por lo que en el frente Kubernetes mirará el escritorio Docker, jugará con el motor Kubernetes y Google Kubernetes. Ahora por supuesto, existen otras opciones, y supongo que si ya tienes un clúster, tal vez solo puedas usar eso sin embargo. Asegúrate de que no sea tu clúster de producción. De todos modos, busca el escritorio Docker. Acabas de llegar a la página web de Docker. O aún mejor, puedes simplemente Google Docker desktop. Pero de cualquier manera terminarás en algún lugar así. Y luego sólo tienes que descargar la versión para ti. Ahora, estoy en un Mac ahora mismo. Entonces les saltaré Cisne. Y luego cuando eso se descarga, realmente es solo un poco de clicky click Next, Next, Next. Honestamente, no podría ser más fácil. En fin, cuando no lo hagas, conseguirás esta ballena o pera o estará abajo en la esquina derecha si estás en Windows. Pero al hacer clic en él te trae esta elegante interfaz de usuario donde vienes y habilitas a Kubernetes. Ahora puede tardar un minuto o dos en empezar, pero cuando esté hecho, bingo, estás en el negocio y ya estás listo para ir por los archivos del laboratorio y seguir adelante con el curso. Ahora, el escritorio Docker es solo para propósitos de desarrollo y prueba y solo obtienes un clúster de nodo único C it aquí una sola nota actuando como maestro y trabajador. Ahora, obviamente no es lo que quieres para la producción, pero definitivamente es lo suficientemente bueno con el desarrollo. De acuerdo, así que juega con Kubernetes. Nuevamente, solo arrebatar contra Google y seguir el enlace. Quiere que inicies sesión con, ya sea GetHub en Docker hub, y luego solo sigues las instrucciones en pantalla y construyes un clúster. Ahora, mira, jugar con Kubernetes es gratis y es genial. Honestamente, me encanta. Pero a veces no es súper sensible o no puede llegar a ser bastante frustrante. Pero recuerda, es gratis y los chicos detrás de él en realidad están haciendo fue un servicio sólo por apagarlo que oh, ya sabes qué también. Si miras aquí arriba, este es un temporizador que cuenta atrás hasta que se elimine tu clúster. Entonces de nuevo, como el escritorio Docker, es solo un patio de recreo. Y por supuesto este tiene algunos problemas de desempeño a veces. Pero la cosa es que es de tiempo limitado. Entonces cuando no contador golpea 0, nace como no eligió a tu clúster y cualquier cosa que se ejecute en él. Pero una vez que te agrupas bote, honestamente, son archivos de laboratorio y ya estás listo para irte. De acuerdo, por último pero no menos importante, para conseguir un clúster y recordar, existen otras opciones. Pero el motor Google Kubernetes es una opción sólida para Kubernetes alojados en la nube. Y en realidad estaré ejecutando muchas de las demos en el curso sobre ello. De todos modos. Mira, es servicio en la nube, por lo que cuesta dinero. No, bajo ninguna circunstancia, girar un clúster para este curso y luego olvidarse de él. Porque si lo haces, obtendrás una propia bienvenida Bill. De todos modos, siempre y cuando tengas una cuenta de Google Cloud con facturación habilitada, solo es cloud dot google.com iniciar sesión en la consola aquí, motor Kubernetes y luego pasar por los movimientos de crear un clúster. Así que llámalo como quieras, decide dónde lo quieres. Tiendo a ir por lo que sea más ligero cuando estoy haciendo un laboratorio. Y luego debajo de la piscina de nodos aquí, depende de ti. Pero normalmente recomiendo tres nodos y un camino que va. Ahora, tomará un minuto o lo que sea construir. Pero cuando esté hecho, te pagaré copia este solo comando G-Cloud. Y mientras tengas instalado el SDK de Google con G Cloud, entonces solo dale un Ródano rápido. Y un Cube CTL consigue nodos, te muestra en marcha y listo para agrietarse. Entonces de nuevo, en este punto, tienes un clúster Kubernetes. Y una vez que tengas los archivos de laboratorio, estás listo para el rock and roll. Pero como dije antes, por favor, hagas lo que hagas, no olvides eliminar el clúster cuando termines. De acuerdo, así que tenemos una aplicación de ejemplo en algunos archivos de configuración en GitHub. Y por cierto, no te preocupes si realmente no sabes qué es GetHub, no necesitas solo apuntar el pelo de tu navegador. Si te interesa. El app está en esta carpeta. Y luego estos son los archivos de configuración aquí abajo en la raíz del repo. Pero todo lo que realmente necesitas es este enlace aquí, presiona el botón del portapapeles, y luego en una ventana terminal escribe git clon y pega en el enlace. Y eso es todo. O en realidad no, sabes qué, tienes una carpeta nueva. Frío. Kubernetes es 101 cuota de habilidad o Scotia para abreviar. O de todos modos, entra ahí. Y esa es la app en los archivos de configuración. Entonces mira, con un clúster en los archivos del laboratorio, estás todo listo para ir, oh, soy terrible en esto. Y asegúrate de que cualquier comando que ejecutes más tarde en el curso en cualquiera de los escenarios de laboratorio, ¿de acuerdo? Ejecutarlos desde en esta carpeta porque necesitas acceso al archivo, di que sí, bueno, eso es todo. Vamos. Vamos a agrietarnos. 11. Deploying un Pod: De acuerdo, entonces nos vamos a tranquilizar suavemente. Ya dijimos que la unidad atómica de despliegue en Kubernetes es la vaina. Y que una vaina es sólo una envoltura alrededor de un contenedor que lo deja funcionar en Kubernetes. Por lo que más fotos. Pensé que habíamos terminado con las diapositivas en serio, ¿verdad? Si crees que estás harto de ellos, son la ruina de mi vida. Entonces éste será uno realmente rápido. Empezamos con código, lo construimos como contenedor, lo envolvemos en una vaina. Encantador. Entonces esto es lo que parece conseguir. Ahora estamos hablando, este es un archivo Kubernetes es YAML. En ocasiones lo llamamos archivo manifiesto, pero éste está describiendo un pod. Entonces, empezando por la parte inferior, esto es lo que llamamos la especificación del contenedor. Entonces es el contenedor, la vaina va a correr. Y luego las cosas de aquí arriba, este es el envoltorio POD, Bueno, el contenedor, pero es bastante simple. Si has hecho algún Docker, le das un nombre tan arbitrario, ¿verdad? Llámalo como quieras. Esta es la imagen en la que se basa. Entonces esto es lo que contiene todo su código de aplicación y sus dependencias, Sí, y exponerlo en el puerto 8080, muerto fácil. Las apps de aquí lo ejecutan como contenedor, acceda a él en este puerto y dale este nombre amistoso, boom, que es u container. Pero para poder ejecutarlo en Kubernetes, necesita todas estas cosas aquí. Sí, el envoltorio de vaina por falta de un mejor término. Ahora, creo que caminaremos por este, correcto, porque es similar en todos los objetos Kubernetes. Siempre empezamos con la versión API y amable puedes tenerlos en cualquiera de los dos ordenes, ¿verdad? Pero API versión v1 y pod tipo, ¿sabes qué? No es ciencia de cohetes, le estamos diciendo a Kubernetes se le factura como una vaina y construirlo sobre lo que es esencialmente una versión uno del esquema de pod. Si alguna vez hay como un esquema v2, esperaríamos que tuviera unas campanas y silbatos más, como es la norma con versiones posteriores de las cosas. Pero sí, danos un pod basado en V1 del esquema de pod o especificación de pod. Entonces metadatos aquí, le estamos dando un nombre y lo usaremos en un minuto. Después le dimos algunas etiquetas. Ahora verá el poder de las etiquetas un poco más tarde. Pero por ahora, sólo déjame decir que son escandalosamente poderosos. Pero eso es todo, ¿verdad? Ese es nuestro estado deseado sobre el que nos golpeamos antes. Entonces en lugar de escribir a un hombre que subscript con toneladas de comandos para hacer cosas como tirar de la imagen del contenedor en comandos para iniciar el contenedor, que por cierto será diferente si usas diferentes tiempos de ejecución del contenedor, sí. Pero también necesitarás comandos para adjuntarlo a una red exponiendo el 8080. Todo ese aire de complejidad, bueno, no gracias. No queremos nada de eso. En cambio, solo pondremos aquí lo que queremos, lo enviaremos a Kubernetes y dejaremos que Kubernetes descubra cómo hacerlo. Hablando de lo cual sin embargo, enviémoslo a Kubernetes. Ahora tengo una copia del archivo aquí en mi directorio de trabajo. Si lo estás siguiendo, clone aquí el repo de GitHub con este comando, o copie el texto y colóquelo en un archivo de su directorio de trabajo llamado Pod dot yaml. Y luego mira el nombre del archivo es arbitrario, pero sólo voy a estar mostrando ejemplos con él llamado Pod dot yaml. Entonces Cube CTL aplicar archivo Pod dot yaml, Y eso es todo. Ahora detrás de bambalinas Cube CTL tiene un archivo de config. Está en un directorio oculto en tu perfil llamado cubo. Y luego ahí dentro tiene un archivo config, convenientemente llamado config. Si bien ahí dentro, tiene cosas como los clústeres, API, endpoint y credenciales y esas cosas. Para que Cube CTL sepa dónde enviar el comando y pueda hacer autenticación. Sí, bueno, si hacemos Cube CTL conseguir vainas, ahí está 101 pod y está funcionando. Por lo que el servidor API aceptó nuestro YAML como una nueva tienda de estado deseada, la copia y la tienda de clústeres, y el programador encontró un nodo sano para ejecutar el Piton. Brillante. Ahora podemos ejecutar un Cube CTL, conseguir vainas con el cuidado de mosca ancha para ver en qué nodo se está ejecutando. Y un Cube CTL describió vainas 101 pod. Y eso nos dará una vista más detallada que está realmente muy bien formateada. Ahora, estos dos comandos, Cube CTL get y Cube CTL describen. Estos van a ser tus mejores amigos, como lo fuiste, literalmente confían en ellos todo el tiempo. Ahora, una pregunta que me hacen todo el tiempo en talleres en el me gusta es, cómo escribimos estos archivos YAML y ahí como un número de campos y opciones. Bueno, al primero sobre ¿cómo los escribimos? La respuesta es bastante sencilla. En su mayor parte. Simplemente tomas uno viejo, tal vez incluso de la web o en algún lugar y lo modificas como hasta ese super simple pod yaml que acabamos de hacer. No escribí eso desde cero. Entonces sí, normalmente copiarás uno viejo y lo ajustarás. Ahora, la pregunta sobre conocer todos los campos y opciones posibles y esas cosas. Ya sabes qué, esta respuesta sencilla muerta a eso también. Sí, la mayoría de los objetos tienen una lista desalentadora adecuada de opciones que puedes poner en la AML, pero no tienes que ponerlas. Acabas de poner los que necesitas. Entonces las que has dejado fuera, Kubernetes se expande con valores por defecto. Entonces sabes qué, si ejecutamos otro Cube CTL obtenemos vainas aquí, pero cambiamos esta opción aquí de ancho a YAML. Echa un vistazo a eso. Ese es el YAML totalmente ampliado de la tienda de clústeres. Y quiero decir, es mucho más largo que las diez o 15 líneas o lo que sea que enviamos al servidor API. Entonces hay anotaciones y espacio de nombres bajo la especificación del contenedor. Ahí está bien, hay un tono, ¿verdad? Entonces sí, Kubernetes rellena cualquier espacio en blanco donde no establecemos valores explícitamente. Ahora, jaja, sí, también aunque, un poco más abajo, aquí está toda esta sección de status que nunca especificamos a nuestros animales. Pero me encanta, ¿verdad? Porque es una gran manera de reforzar ese estado deseado versus estado observado que nos agrietamos sobre antes. Por lo que la sección de especificaciones es básicamente nuestro estado deseado. Lo que le hemos preguntado a Kubernetes es cuatro. El estado está bloque aquí sin embargo, esto representa el estado observado actual del clúster o el estado observado en el momento en que ejecutamos el comando, Sí. Bueno, aquí tenemos un contenedor basado en nuestra imagen. Esto es lo que lo llamábamos. Ya está listo para correr. Este es su Ip, literalmente una tonelada de cosas. Y sí, eso es una vaina. describimos de manera declarativa en un sencillo archivo YAML. Tenía una especificación de contenedor y lo envolvimos como vaina. Después usamos Cube CTL para enviar ese YAML al servidor API de costa. Obviamente fuimos autenticados en base a lo que hay en el archivo de config del cubo. El YAML se expandió con todos los valores por defecto y cosas que no especificamos. Y se almacenó en una tienda de clústeres. Entonces el pod definido en él se programó al clúster y se está ejecutando. Maravilloso. Bueno, en la siguiente lección, veremos cómo conectarnos a ella. 12. Conectar a través de un servicio: Entonces tenemos un pod funcionando, y dentro de eso hay contenedor corriendo, una sencilla aplicación web, pero nunca nos conectamos directamente a ese pod. Por lo que nunca tomamos su IP ni lo que sea y le abrimos un socket. Ahora, hay un montón de razones para esto y vamos a cubrir algunas de ellas en breve. Lo que necesitamos saber ahora sin embargo, es que para acceder a aplicaciones en un pod, necesitamos otro Kubernetes es objeto llamado servicio. Y ese muerto simple, ¿verdad? Piensa en un servicio como tararear un front-end y back-end. En el front-end, cada servicio obtiene un nombre, una IP y un puerto. Y Kubernetes da una garantía de hierro fundido de que estos valores nunca cambiarán. Después en el back-end, tienen un puerto y el selector de etiquetas. El tráfico entra en el front-end. Mi servicio en puerto 30,001 o lo que sea. Y se empuja fuera del backend en el puerto 8080 en este ejemplo, y la carga balanceada en todos los pods del clúster con la aplicación, una etiqueta Web no podría ser ESEA. Entonces el ejemplo que abriremos se puso como, no sé, diez partes pueden ser, pero el servicio solo está enviando tráfico a las que tienen la app es igual a magia de etiqueta Web. Bueno, aquí hay un yaml de servicio. Empezamos con la versión API y amables de nuevo, así que eso es decir, Hey, Kubernetes, Dame un servicio, por favor, y basarlo en la definición V1 de un servicio. Sí. Pero luego la configuración front-end justo primero arriba, le daremos un nombre. Ahora, esto se registra con el servicio interno de DNS Kubernetes. Eso significa que el nombre del servicio se va a resolver desde dentro del clúster es SVCs A101. Este está escuchando en dos puertos. Este sigue siendo el front-end, ¿recuerdas? Por lo que está disminuyendo dentro del clúster en el puerto 8080 aquí y fuera del clúster. Por lo que para las conexiones que llegan de fuentes externas en el puerto 30,001. Por lo que las aplicaciones dentro del clúster pueden golpear S-phase A101 en el puerto 8080 aquí y llegar al front-end del servicio. Asi que. Aunque. Este puerto de nodo aquí dice que también escuche en el puerto 30,001 en cada nodo del clúster. Entonces podemos entrar desde fuera del clúster y golpear cualquier nodo del clúster usando su nombre o su IP en el puerto 30,001 y mismo resultado, golpeamos el servicio, ¿verdad? Bueno esa es la configuración front-end, la configuración de backend como ¿a dónde se enruta el tráfico? Bueno, se sale de la espalda en el 8080. Nuevamente, en este ejemplo, no tiene que escribir una copia un puerto diferente, pero irá a cualquier pod del clúster con la etiqueta web de API, que creo si miramos aquí nuestro pod. Sí, está escuchando en 8080 y está etiquetado como AP igual a Web. Entonces si desplegamos ese servicio y te vas a acostumbrar a esto, ¿verdad? Tengo el archivo FVC YAML localmente aquí. Si lo estás siguiendo, asegúrate de que también lo tienes localmente. Ahora, puedes llamar a los nombres de los archivos lo que quieras, ¿verdad? No tiene que ser SBC dot yaml. Pero cuando escribas los comandos, si has cambiado el nombre del archivo, asegúrate de no solo escribir lo que estoy escribiendo. Sí. Bueno, mira, de nuevo, se envía al servidor API, autenticado y autorizado. Obtenemos una actualización a nuestro estado deseado persistió en la tienda de clústeres y se crea el servicio. ve bien. Ahora, servicios y no como pods, en realidad no ejecutan ninguno de nuestro código de aplicación. Básicamente, hay un montón de red en cosas, ¿verdad? Entonces al igual que las tablas IP o las reglas IP VS que atrapan en el uso de los servicios dirección IP y hacen cualquier magia de red que se requiera para reenviar o cargar balanceado ese tráfico a los pods correctos que están ejecutando nuestras aplicaciones. Ahora como antes, y te acostumbrarás a todo esto, ¿verdad? Pero se pueden ver con el Cubo CTL habitual conseguir en Cubo CTL describir comandos. Entonces ahí está, SVCs A101, y describen nos da una salida muy bien formateada con un poco más de detalle. Pero no olvidemos por qué creamos esto, correcto. Dijimos que nunca hablábamos directamente con las vainas. Siempre ponemos un servicio frente a ellos y platicamos con el servicio. Por lo tanto, si eres una aplicación que se ejecuta en el clúster o sabes qué, incluso podrías tener una sesión exacta en un pod de aplicación que se ejecuta en tu clúster. Podrían llamar al nombre del servicio. El nuestro es SBC 1.0.1 en el puerto de servicios. Ahora el puerto interno, recuerda era 8080 y llegarías al servicio. Ahora, si estás fuera del clúster, tal vez estás en tu portátil o en tu cliente de aplicación externa o algo así, entonces simplemente golpeas la IP pública o el DNS público, cualquiera de los nodos del clúster en ese puerto, 30,001, y lo alcanzarás también. Bueno, mira, hablar es barato, ¿verdad? Mi clúster Kubernetes está en la nube de Google. Entonces busco la IP pública de uno de estos nodos. Gracias como siempre, Gk por tus nombres de nodo horrenamente largos que joden mis columnas. Y tendré esta IP externa aunque. Y pondremos eso en una nueva sesión de navegador, 30,001. Y ahí estamos como por arte de magia. Ahora pues mira, uh, realmente no quiero trabajar el punto, pero de verdad, de verdad quiero que te alejes de este curso entendiendo los fundamentos. Entonces déjame ser claro, ¿verdad? Este servicio obtiene un nombre estable y una dirección IP en el clúster. Cuando digo estable, correcto, Kubernetes es súper meñky promete que estos valores nunca cambiarán mientras exista el servicio. El nombre del servicio se registra con los clústeres DNS interno, lo que significa que cualquier parte de su aplicación en el clúster puede enviar tráfico al nombre de la IP del servicio en su puerto, y llegará al servicio. Una vez que llega al servicio, tráfico se equilibra entonces la carga a través de las vainas del clúster con una etiqueta coincidente. Pero no estamos terminados, ¿verdad? Porque este servicio en particular que hemos creado es un servicio de puerto de nodo. Otros sí existen, ¿verdad? Pero este es un servicio de puerto de nodo, y eso significa que obtiene un puerto extra, 30,001 en nuestro ejemplo que está expuesto al mundo exterior a través de cada nodo de un clúster. Significa que si tienes un cliente externo, como mi navegador web que acabamos de ver, puedes golpear cualquier nodo del clúster en ese puerto y llegar a la superficie. Y eventualmente la aplicación, que como dijimos, entonces la carga equilibra el tráfico, deponiendo el clúster con la API va etiqueta web, y llegar a la aplicación. Ahora, finalmente, creo que bien, podemos golpear cualquier nodo del clúster en ese puerto. Ese nodo no necesita estar ejecutando una réplica del pod. ¿ Quién? De acuerdo, una última cosa. Entonces, ¿por qué son Nigel, necesitamos hablar con un servicio en lugar de directamente con vainas? Quién sí, gran guía de preguntas que hiciste. Entonces imagina de nuevo este escenario. Escribe un montón de vainas en el clúster y sabes qué, perdamos las que no coinciden con nuestra etiqueta. De acuerdo, a mí me parece cinco. Digamos que el hosting nuestro front-end web y aumenta la demanda causan lo que sea, ¿verdad? Tenemos una promoción o algo así, quizá sea Black Friday. Sí. Por lo que sumamos más para hacer frente a la demanda. Will, ¿cómo sabían las otras partes de nuestra app de estas nuevas vainas que acabamos de agregar? Y funciona el mismo. Bajamos la escala y hacemos que algunos de ellos se vayan. Es decir, no queremos que nuestros desarrolladores hinchen su código escribiendo lógica para rastrear cosas así. Ahora, entonces en su lugar construimos servicio. Esto se sienta frente a las vainas y ofrece ese nombre garantizado, IP y puerto. que a medida que agregamos y quitamos vainas en la parte inferior aquí, el servicio mantiene el seguimiento congelado y literalmente esconde toda la escala hacia arriba y hacia abajo que está pasando en la parte inferior aquí. ¿ Verdad? Entonces, sí, como dijimos sobre los bucles de reloj de fondo antes, hay un bucle de control para el objeto de servicio en segundo plano que solo está sentado ahí día tras noche tras Día tras Noche, comiendo palomitas de maíz, vigilando las vainas nuevas que coincidan con las etiquetas en el servicio. A medida que se agregan nuevos pods coincidentes, el servicio actualiza su lista de puntos finales. Y adivina qué? A medida que desaparecen las vainas, hace lo mismo. Siempre manteniendo una lista actualizada de vainas coincidentes saludables. Cosas buenas. Y ya terminamos. Sí. A continuación, vamos a hablar de la autocuración. 13. Uso de implementos: Ahora entonces hasta el momento hemos desplegado un pod y servicio. El bote es donde se ejecuta nuestra aplicación y el servicio es cómo nos conectamos únicamente a ella. Y esto me muele cada vez que tuve la conversación. En realidad nunca desplegamos vainas directamente. Y aquí es por qué escribir esto. Aquí hay una vaina envolviendo un contenedor y ¿sabes qué? Literalmente lo único que una dosis de vaina primero es dejar que el contenedor dentro de ella funcione en Kubernetes. Probablemente recuerden, dijimos que los contenedores no pueden correr directamente en Kubernetes. Tenemos que envolverlos en una vaina. Will magic, eso es genial. Ponga vainas nos dan diddly en cuclillas. Entonces absolutamente 0 cuando se trata de cosas como la autocuración, escalado, la ejecución de actualizaciones y los rollbacks versionados. Para todas esas cosas buenas que necesitamos desplegar, que como muestra la imagen, envuelve alrededor de una vaina. Por lo que es poco como pasar el paquetería este año. Tenemos contenedores envolviendo nuestro código de aplicación, vainas, envolviendo nuestros contenedores, y ahora un despliegue envolviendo un pod. Y como dice la imagen, el despliegue es lo que nos da todas las cosas buenas. Bueno, así es como se ve. Ahora, a partir de abajo aquí, tenemos el mismo contenedor viejo ¿verdad? Sin cambios. Entonces ya deberíamos estar acostumbrándonos a eso. Y luego tipo de envolver no tenemos un montón de las cosas de la vaina. Entonces estas son las etiquetas que obtiene el POD para que este servicio que creamos pueda enviarle tráfico. Sí, igual que antes, ¿verdad? Y luego finalmente, tenemos el material de despliegue justo en la parte superior aquí que está envolviendo alrededor del POD. Bueno, yendo desde lo más alto esta vez tenemos nuestra aversión de esquema habitual y tipo de recursos. Entonces denos un despliegue, por favor. Kubernetes se basa en la definición del esquema V1 en el subgrupo API de aplicaciones. Dale un nombre al despliegue en sí y algunas etiquetas. Ahora estos no se deben confundir con las etiquetas POD más abajo. ¿ De acuerdo? Pero luego llegamos a algunas cosas interesantes. Seleccionar un rótulos de coincidencia. Esto de aquí es como la etiqueta seleccionada que vimos en el archivo YAML de servicios, ¿verdad? Entonces está diciendo que este objeto de implementación va a administrar pods en el clúster con esta etiqueta API llamadas web. Entonces tenemos réplicas igual a una. Entonces, cuando enviemos esto al servidor API, va a programar exactamente un pod basado en la definición a continuación. Ahora, ese es el bit de escalado, ¿verdad? Y volveremos a ello más tarde. De hecho, en realidad es parte de la autocuración también. Pero antes de que todo ese tipo de estrategia está rodando actualización. Entonces cuando llegue el momento de actualizar algo de esto aquí abajo en la definición de pod, Kubernetes va a hacer lo que se llama Rolling Update. Ahora, sé mucho que digerir aquí, ¿verdad? Y llegará a cada bit en turno. Entonces no te preocupes, pensando que estoy esperando que te lo grok todo ahora mismo, no escribas llegará a todo a su debido tiempo. Por ahora, estos son los despliegues aquí atrás, definiendo todo lo bueno que nos da auto-curación, actualizaciones, todo ese tipo de jazz, ¿no? Envolver alrededor de un pod, que a su vez está hospedando un solo contenedor. Ahora entonces una pregunta que me hacen todo el tiempo es, ¿puede un pod tener más de un contenedor? Y la respuesta es, sí, definitivamente. Pero ese es un caso de uso bastante avanzado, ¿verdad? Donde 101 curso. Por lo que solo estamos mirando el contenedor de un modelo por pod. Pero permítanme decir bien, el contenedor múltiple por modelo de pod es realmente poderoso y está fuertemente apalancado por cosas como mallas de servicio. Ahora, hay otras cosas que lo aprovechan también. Pero ya sabes qué mallas de servicio es un tema candente en este momento y sabes cuánto nos encanta una buena palabra de moda. De todos modos, mira, tengo el archivo localmente. Si te estás siguiendo, te necesitarás a sí misma. Por lo que ya o has clonado el repositorio de GitHub o copiado y pegado el contenido de GitHub en un archivo. Y luego es solo nuestro confiable Cube CTL comando apply. Y sé que ahora me estoy poniendo como un récord roto, ¿verdad? Pero eso va al servidor API, autenticado y autorizado, almacenado en ETC, día no programado al clúster. Entonces Cube CTL solo para asegurarse de que se está ejecutando, lo cual es, sí. Y luego un Cubo CTL consigue vainas. Boom. Ahí está. Un pod totalmente nuevo siendo manejado por el despliegue con todas las superpotencias que vienen con eso, ¿verdad? Entonces como decimos, autocuración, escalado, ejecutar actualizaciones, retrocesos, todo eso, bondad, sí. De hecho, vieja vaina uno-a-uno aquí, probablemente esté llenando un poco inferior, pero como estar parado junto a Tony Stark. Sí. En fin, ya sabes qué, Hablando de superpoderes, a continuación, vamos a ver algo de autocuración. 14. Self: Está bien, tenemos un par de vainas corriendo. Este de aquí está siendo gestionado por un despliegue. Entonces todo es Tony Stark WAR con superpoderes como la autocuración y esas cosas. Sí. Pero la vieja 101 parte aquí, eso es como yo, un poco de un anciano con superpoderes c rho. Es decir, hace poco me retiré de jugar al futbol o al futbol dependiente de donde vivas. Básicamente, porque mis rodillas tienen 0 poder curativo en estos días. De todos modos. Un pod administrado por un despliegue y el otro no. Entonces si hacemos esto aquí a 101 pod, se fue ¿verdad? Si ponemos un reloj y traemos vainas aquí. Está bien. No se ha ido, pero le va a dar unos segundos para que haga. Es justo decir que no está regresando 0 superpotencias. Ahora pues si miramos aquí nuestro despliegue que está gestionando nuestro POD restante. Lo que está diciendo aquí arriba, siempre es asegurarse de que haya uno de este pod corriendo en el clúster. Y podría parecer bastante simple, ¿verdad? Pero créeme, la maquinaria y el fondo, como todos los bucles de reloj y todas las demás cosas. ¿ Quién consiguió Italia? Este es el ingrediente secreto para las superpotencias. Esto le da invencibilidad a nuestro POD restante. Bueno, algo así lo veremos de todos modos. Entonces si tratamos de matarlo con uno de estos, lleva deshielo, Homero a ella. Volveremos a ver la acción en vivo. Ah, ¿qué es esto? ¿ Mirar dentro? Al igual que dos contenedores. Y qué es todo esto terminando autoridades empresariales tenían superpoderes. Bueno, lo que está pasando aquí es que en realidad acabamos de matar al martillo de deshielo de la vaina. Sí. Y como cabría esperar con esos martillo, la vaina murió. Pero lo que hacen los despliegues en Lockerbie de alto nivel un poco de pelo, ¿verdad? Pero ha creado una vaina nueva idéntica en su lugar. La única diferencia en realidad siendo este bit al final de su nombre aquí. Entonces ahora uno puede escribir de una manera que estamos haciendo trampa. El pod sí murió y fue reemplazado por otro idéntico. Entonces los viejos se fueron y un nuevo clon, si quieres, está en su lugar. Pero sabes qué, desde la perspectiva de la aplicación, no es hacer trampa. Continúa la aplicación. Es decir, a tu solicitud no le molesta los nombres POD ni nada, ¿verdad? Desde la perspectiva de la app, la evidencia sigue funcionando. Y sabes qué, ¿verdad? Esto es mucho mejor cuando hay como múltiples réplicas corriendo aquí y una muere y se reemplaza de inmediato. Por lo general en esa situación, la app no se salta latido. Ahora también, ¿verdad? Esto es lo mismo si algo se rompe en el clúster, como sé que acabamos de hacer un asesinato manual de la parte de la bala de escritura a mano. Digamos que un nodo muere en el clúster y se lleva algunas vainas con él. Bueno, si esas vainas, Raúl Tony se abasteció con el despliegue. Ahora pánico ¿verdad? reemplazan las vainas perdidas y el mundo sigue girando, lo cual es brillante justo fuera cerradura, ¿sabes qué? Incluso podemos refrescar nuestra pestaña del navegador aquí sin cambiar ninguna de la URL. Porque lo que ha pasado bien es el objeto de servicio que está haciendo todo el networking para el Palladia está ofreciendo ese endpoint súper estable. Supongo que podríamos llamar al endpoint Tony Stark también. Sí, eso está garantizado para nunca cambiar su invencible, ¿verdad? Y siempre tiene una lista actualizada de vainas que coinciden con las etiquetas que busca. Y obviamente el nuevo público se giró hacia arriba que acabamos de ver ahí. Eso tiene las mismas etiquetas. Sí, así que todos estamos bien. Y esa gente es un aspecto del año de autocuración. Pero lo genial, ¿verdad? Eso podría haber ocurrido a las tres de la mañana. Y Kubernetes lo arregló sin despertarnos de algo de eso. Pero sabes qué, estamos lejos de hacer a continuación, escalar. 15. Escala: Entonces otra cosa que nos dan los despliegues es escalar esa capacidad de decir que necesito más o menos de un pod en particular. Algo que Gus dijo antes, tal vez sea fin de mes y reportar para hacerlo, tengamos más vainas que apoyen la infraestructura de informes. O tal vez tenemos algunas ofertas en o algo así y estamos esperando un aumento del tráfico. Entonces vamos a escalar los bits que soportan la navegación y las búsquedas en los Likes. Bueno, si miramos lo que tenemos, sí, un solo despliegue llamado despliegue uno-a-uno y tiene una réplica. Entonces la forma en que lo escalamos para decir cinco, para abrir el despliegue yaml aquí y mirar en el mundo real, ¿verdad? Vas a estar manejando esto de la misma manera que administras tu código esperanzadamente. Entonces en control de fuentes o algo así, sí, pero lo comprobarás y todo ese jazz, sí. Y entonces esperamos que estas réplicas cuenten aquí hasta cinco. Sube aquí y guardaremos nuestros cambios. Y luego simplemente reaplicamos eso al clúster y lo revisamos de nuevo en el control de versiones, Por supuesto, sí. Pero literalmente es actualizar ese Yammer, que es nuestra fuente de verdad, y luego reemitirlo al servidor API que se registra como un nuevo estado deseado hasta de una réplica a cinco. El bucle de control de fondo se avisa, oye, queremos cinco, pero en realidad sólo tenemos uno. Por lo que gira para más. Y ahí lo tenemos cinco vainas. Ahora, podemos, si queremos escala usando el comando Cube CTL scale. Pero no creo que ese sea el camino de los Kubernetes. Y te diré por qué, ¿verdad? Hacerlo así es la vía imperativa, no la declarativa. Entonces imagina conmigo, cierto, que manejas un clúster de Kubernetes con un montón de apps y hay un P1 pasando. Sí. Entonces es como alerta roja todas las manos a las estaciones de batalla y estás escribiendo lejos mirando eventos y registros y tus jefes colgando sobre tu hombro y sus jefes constantemente al teléfono en su Bedlam, cierto. Pero es genial. Sí. Es decir, tienes por todas partes pagar uno. Son realmente difíciles de vencer a la acción y la emoción. ¿ Y sabes qué? Tiendes a aprender una tonelada. De todos modos, mira, todo está bajando así, ¿verdad? Usted haciendo cambios sobre la marcha imperativamente. Sí. Simplemente cambiando cosas a medida que avanza. Y digamos que el tema y yo estoy inventando esto, cierto, pero digamos que el problema era el puerto de red en el que está operando tu aplicación no está funcionando. En fin, cambias el puerto que usas sobre la marcha. Entonces en la línea de comandos sin revisar tu archivo YAML, sin actualizar el archivo Yammer, y sin volver a aplicar eso al clúster. De todos modos, entonces cambias el puerto de red sobre la marcha y son festejos Q, ¿verdad? Has estado alto cinco los jefes por nuevas bebidas después trabajo y en medio de toda la adoración y general enloqueciendo, te olvidas que cambias el puerto en vivo a como 9 mil o algo así, te pusiste a la izquierda. Es 8080 en tu expediente YAML. Y la razón por la que esto es malo, ¿verdad? Es porque lo que está en vivo en el clúster ya no te corresponde. Yaml y Kubernetes no tiene forma de saber esto. Bueno, enrollemos un poco el reloj hacia adelante y digamos que es una semana o lo que sea más tarde y estás empujando una nueva imagen a la app. Entonces si todo lo que procedimiento normal, correcto, porque esto ya no es un P1, entonces todo esto está controlado. Sí. Se echa un vistazo al YAML, se actualiza la versión de la imagen utilizada, y se empuja el YAML al clúster. Sólo. No te diste cuenta que la Yamaha aún dice el viejo puerto 8080, que está roto y ya no funciona. Entonces cuando lo vuelves a desplegar, sí, te obtienes nueva imagen, pero también recuperas el viejo puerto roto. Ahora una promesa aquí. ¿ Cuál es el año de alta quincena o comprando tus bebidas esta vez? Por lo tanto, hacer un imperativo cambios como ese no es generalmente recomendable. Sabemos lo que estoy bebiendo. Ahora tenemos cinco réplicas con un vigilante de fondo simplemente mirando el clúster todo el día, asegurándonos de que el estado deseado coincida con nuestro estado observado real. Ahora, por supuesto, es lo mismo si bajamos el número, escribimos, actualizamos el YAML, lo empujamos de nuevo al servidor API. Fabuloso. Sólo, sabes qué, todo es un poco manual, ¿no? O sea, me requiere o eres un ser humano para hacer el trabajo. Bueno, afortunadamente, Kubernetes tiene tecnologías de autoescalado. El escalador automático de pod horizontal que puede buscar qué tan ocupados están tus vainas y escalar hacia arriba y hacia abajo dinámicamente. Y hay un escalador automático de clúster que puede escalar hacia arriba y hacia abajo el número de nodos en su clúster. De nuevo, dinámicamente basado en si hay suficiente capacidad en el conjunto actual del clúster para girar nuevas vainas en los Likes. Ahora, desafortunadamente, esos temas están más allá del alcance de este curso 101. De todos modos, bloquee por ahora en este yo una causa que es escalar. Próximamente. A continuación, vamos a integrar la aplicación con un equilibrador de carga basado en la nube. Tráelo. 16. load-balancers de carga en nube: Ahora pues, lo siento. Si estás siguiendo en tu portátil con el escritorio Docker, o si estás siguiendo junto con jugar con Kubernetes, no podrás seguir a este laboratorio. Este laboratorio solo funcionará si tu clúster está en una nube pública o en un Sandbox mágico también, que se ejecuta en una nube pública. De todos modos, las mentes en la nube de Google, en el motor Google Kubernetes. Entonces ya estoy bien para ir, no poder seguir adelante. De verdad lo siento pero ¿sabes qué? Basta con ver. Está bien. Todavía lo tienes. Esto no es difícil lo que estamos a punto de hacer. De todos modos, mira, tenemos una sencilla aplicación implementada, cinco réplicas aquí de un simple servidor web. Y tenemos un servicio Kubernetes que está brindando redes estables para las réplicas. Pero el tipo de servicio que tenemos es un servicio de puerto de nodo, que si volvemos la mente, nos permite acceder a nuestra aplicación a través de un nombre o una IP desde dentro del clúster en el puerto 8080, lo cual es todo bueno. Pero si queremos acceder desde fuera, entonces necesitamos el nombre o la IP pública de al menos uno de nuestros nodos. Entonces con nuestra configuración, lo golpeamos en el puerto 30,001 y entraremos. Eso está bien, verdad. Pero seamos honestos, es un poco basura en realidad. Es decir, ¿quién quiere hacer un seguimiento de nombres de nodos o IPA? Sí. Por lo que una forma mucho más reñida sería frendar a todos con un equilibrador de carga. Y en serio, hacer eso no podría ser más fácil. De hecho, me da vergüenza lo fácil que es. Entonces este YAML aquí, que va a parecer muy familiar, Se va a integrar aquellos con un balanceador de carga Cloud. Entonces, de todos modos, luce igual fuera de mi antigua versión API y amable sabemos todo de esas. Dale un nombre y una etiqueta. Y luego una configuración front-end aquí diciendo el puerto 8080 en lo que sea que obtengamos como nuestro equilibrador de carga en la nube. Y luego el equilibrio de carga fuera del backend del servicio en 8080 a cualquier pod con la API es igual a la etiqueta wed. Entonces hemos visto todo esto, ¿verdad? La única diferencia real con respecto al último servicio que implementamos es este tipo de equilibrador de carga aquí. Entonces como dije, si estás en una plataforma en la nube y todos los grandes aplican AWS Azure, Google, océano digital, IBM Cloud, lo nombra bien estableciendo una sola palabra aquí. Balanceador de carga, Kubernetes se va a ir, hablar con tu nube. Disposición de hábito, un equilibrador de carga orientado a internet que acepta tráfico en el puerto 8080 y asegúrate de que se balancee la carga en todos los pods que ejecutan tu aplicación también en el puerto 8080. Es decir, qué guay es eso ahora mismo, la póliza, no tengo demasiado, ¿verdad? Creo que el punto de llevar a casa es que con vergonzosamente poco esfuerzo, obtenemos un equilibrador de carga frente a internet completo y de alta disponibilidad integrado con nuestra aplicación. De nuevo, un freakin, me encanta. De todos modos, mira, tengo el archivo localmente. Sí. Significa que es hora de que nuestro viejo amigo Cube CTL aplique. Dile el archivo y se va. Ahora bien, si le pongo un reloj a este comando aquí, probablemente sean similares en menos de un minuto. Y yo voy a editar el video, ¿no? Para que no tengas que mirar la pantalla esperando, poner en cerca de un minuto, estos valores pendientes aquí bajo la IP externa va a cambiar a una IP pública válida adecuada como esa. Y podemos golpear eso en el puerto 8080, a quien y como por arte de magia, correcto, esa es nuestra app. Por lo que toda la aplicación web que se ejecuta en un contenedor, envuelta en un pod a su vez, envuelta en un despliegue en nuestro clúster privado Kubernetes, frente por un servicio Kubernetes que da un punto IPN estable integrado con un nativo de nube equilibrio de carga, ¿verdad? Es decir, eso es un montón de cosas buenas, ¿verdad? Ponga usted sabe qué? Es tan sencillo, lo estamos viendo aquí en una causa de uno a uno. O sea, ¿qué tan excelente es eso? Creo que estarás de acuerdo en que es lo más excelente. Y sabes qué, ¿verdad? No olvidemos que el servicio está constantemente vigilando para asegurarnos de que tiene la última lista de vainas para equilibrar a o.Y sabes qué, solo carga equilibra a vainas sanas. Y literalmente estamos rascando la superficie. Vamos. Ojalá eso no fuera demasiado ruidoso si estás escuchando en auriculares. Pero sabes qué, todavía no hemos terminado. O sea, casi nos r, pero no del todo. Una última cosa, una actualización rodante. 17. Actualizaciones de balanceos: De acuerdo, última lección adecuada. Tenemos una sencilla aplicación web ejecutándose en Kubernetes, y nos hemos visto a sí misma, escalaremos y solo que la hemos visto conectarse a un equilibrador de carga de Cloud frente a internet. Bueno, veamos cómo podemos hacer una actualización rodante. Entonces como están las cosas, si miramos el despliegue, deberíamos ver en los contenedores, la versión de imagen. En fin, aquí arriba tenemos cinco réplicas. Por lo que cinco vainas corriendo un contenedor basado en esa imagen. Pero digamos que hemos hecho una imagen actualizada y ha pasado todas las pruebas de integración y los gustos. Y el último paso es lanzarlo al clúster. Bueno, despliegue, haz esto sin siquiera romper un sudor. Y la forma en que lo hacemos es la forma declarativa. Entonces volvemos al YAML aquí y c aquí en las réplicas, tenemos una estrategia Rolling Update. Bueno en realidad voy a pegar estas líneas en. Está bien. Entonces este bloque que estoy destacando, esto nos da algún control sobre cómo sucede la actualización rodante. Lo que estamos diciendo es que cuando actualizamos algo en el bloque de plantillas más abajo, hacemos una actualización rodante. Eso significa una réplica a la vez. Hombres listos segundos aquí dice, Después de actualizar cada réplica, antes de hacer la siguiente, espera diez segundos. Ahora, tal vez en el mundo real dirías unos minutos o algo así. La idea sin embargo, es darte un poco de control y dejarte pegar el año de despliegue. Bueno, Max no disponible dice mientras está sucediendo la actualización, nunca vaya más de uno por debajo de lo que estamos pidiendo. Ahora. Estamos pidiendo cinco. Por lo que nunca vayas más de uno por debajo de eso. Por lo que sin embargo que por ahora con máximo disponible era como dos, entonces se permitiría a Kubernetes bajar a tres durante la actualización. Y de igual manera para el aumento de Mac, nunca vayas más de uno más de lo que estamos pidiendo. Ahora. Sabes qué, ¿verdad? Hay muchas más opciones incluyendo sondas y pruebas y me gusta que se aseguran de que después de haber actualizado un pod, en realidad está funcionando. Sí. Pero ¿sabes qué? Primero ahora tenemos algunos ajustes de Rolling Update. Y creo que probablemente la que dirá tener más efecto es la espera de 10 segundos después de cada actualización. Pero bajemos aquí y cambiemos la versión de la imagen de 1.So 0 a dos. Guarda eso. Ahora, cuando lo publiquemos en el servidor API tendrá un nuevo estado deseado de sí, cinco pods. Pero esta vez, los cinco estarán queriendo ejecutar la 2.0. imagen, el bucle de reconciliación de fondo. Notaremos que no coincide con lo que en realidad está en el clúster. Por lo que arreglará las cosas solo los segundos min listos y los demás valores que mencionamos ejercerán control sobre cómo ocurre la actualización. Entonces hagámoslo, ¿verdad? Y tengo aquí un comando que monitoreará la actualización que está lista para salir. Y lejos vamos. Vamos a correr este. Está bien. Mira, soy un, adelante y acelera el video en segundo plano porque tenemos este periodo de enfriamiento de 10 segundos. Sí. Y una promesa. No sería divertido escucharme cantar para llenar el tiempo. Entonces sí, Bueno, mira, podemos ver que está pisando metódicamente cada réplica. Ahora. Está pasando por dos a la vez aquí porque max no disponible y Max surge están ambos fijados en 11 más uno es dos. En fin, si empiezo a refrescar la pestaña del navegador aquí, deberíamos ver a veces obtengo la versión actualizada y a veces la más antigua. Y eventualmente o cinco réplicas estarán actualizadas. A todo lo que obtendrá es la nueva versión. Y que damas y caballeros cuatro filas en curso 101. Eso servirá. Ahora. Honestamente, hay una tonelada más como si pareciera que nunca termina. Kubernetes es una vasta plataforma y sigue evolucionando. Y luego hay cosas que hemos mirado es estable y podemos confiar en todas esas cosas. Ponga Kubernetes hace mucho más y no voy a mentir. Puede ser desalentador y la curva de aprendizaje puede ser dura. En fin, hemos cubierto mucho. Así que quédate para un rápido recapitulación de los puntos principales de toma a casa. Además, te señalaré algunos lugares que te ayudarán a llevarte al siguiente nivel. 18. un recap realmente rápido: De acuerdo, entonces ¿por dónde empezamos? Sí, definimos lo que es una aplicación nativa de microservicios en la nube. Es solo una forma moderna de construir una aplicación útil a partir de un montón de partes especializadas que unimos libremente usando API en solo porque se les llama nativa de la nube no significa que sean solo para la nube. De hecho, incluso llegaría tan lejos como decir que un principio de nativa de la nube es probablemente la capacidad de ejecutarse en cualquier lugar incluyendo sus centros de datos locales. Quiero decir, siempre y cuando estés dirigiendo Kubernetes ahí, sí. En fin, dijimos que Kubernetes es la plataforma de facto para ejecutar aplicaciones nativas en la nube. Y que Kubernetes es dos cosas. Se trata de un clúster y es un orquestador de aplicaciones. Entonces el clúster es como el sustrato o la plataforma, si se quiere, en la que hemos puesto en marcha nuestras aplicaciones. Consiste en maestros que ejecutan todos los Kubernetes es inteligente y lógica. Y tiene un montón de nodos de trabajo donde ejecutamos nuestras aplicaciones de usuario. Ahora, mira, es un clúster mundial irregular al final del día. Por lo que necesitamos pensar en cosas como disponibilidad y seguridad y rendimiento y todo eso. Dios, sí. Ahora, en la aplicación orquestar diferentes Kubernetes pueden desplegar y administrar nuestras aplicaciones. Para nosotros, dijimos que el patrón preferido se llama el patrón declarativo, donde definimos lo que queremos cualquier archivo YAML. Y nosotros en Kubernetes haremos el duro trabajo por nosotros. Entonces la forma en que funciona es Kubernetes mantiene un registro de lo que queremos como algo llamado estado deseado. Y ejecuta un montón de bucles observados que miran los diferentes aspectos de nuestro clúster y nuestras aplicaciones. Y básicamente, están comprobando constantemente que lo que se está ejecutando en el clúster es lo que queremos. Siempre que el estado observado se aleje de ese estado deseado, Kubernetes hace todo lo que está a su alcance para que todo vuelva a alinearse con el estado deseado. ¿ Y qué más dijimos? Sí, dijimos que escribimos nuestras aplicaciones como normales, usamos herramientas Docker para construirlas como imágenes de contenedor y luego usamos Kubernetes para desplegarlas y ejecutarlas. Ahora, sí, Kubernetes orquesta la aplicación contenerizada, que es sólo jerga techno para aplicaciones que se ejecutan dentro de contenedores. Sí, sólo los contenedores no pueden correr directamente más allá de Kubernetes. En primer lugar, necesitamos empaquetarlos como Potts. Ahora, podemos aumentar aún más las vainas con un montón de cosas, ¿verdad? Pero el que miramos fue el despliegue. Y eso le da a las vainas superpoderes, Sí, como la capacidad de vender, fallar y escalar e incluso hacer 0 actualizaciones de tiempo de inactividad. Y eso fueron esos. Eso es todo para lo que tenemos tiempo. Pero oh Dios mío, hay mucho más. Pero es un buen momento para estar aprendiendo Kubernetes. Ahora bien, si te gustan los libros de Dios, a alguien le podría gustar Quickstart Kubernetes, ESEA está al nivel de este curso. Pero si estás listo para pasar al siguiente nivel que el libro de Kubernetes aquí aparece regularmente como bestseller en Amazon y tiene las calificaciones más estrellas de cualquier libro en Kubernetes. Ah, y se actualiza anualmente, por lo que siempre está al día. Ahora, puedes conseguirlo como un eBook en Kindle y Leanpub, un libro de tapa blanda en Amazon. Hay ediciones en español, chino simplificado y ruso disponibles y una versión en audio, pero eso es solo un inglés. Oh, Dios mío. ¿ Sabes qué? Incluso hay un aferramiento a la adición de tributo. Sin embargo, sin chiste. El edición klingon, es sólo la portada y la intro que están en llamar a los descansos en inglés. De todos modos, mira, el tiempo es corto y estoy empezando a gofres. Siéntete libre de conectarte conmigo. Soy un soporte técnico no puede ser gratuito, pero estoy más que dispuesto a conectarte y ayudarte a trabajar tus primeros pasos. Entonces no seas tímido. Vamos a conectarnos de todos modos. Mira, gracias por pasar tu tiempo conmigo. Buena suerte con tu carrera. Y como dije, mantente en contacto.