‫Permíteme contarte sobre carreras en seco y diferenciales, que
‫son cosas nuevas.
‫Las últimas versiones de Kubernetes que comienzan con 1. 13 tenemos
‫esta nueva opción que nos permite ver lo
‫que vamos a cambiar antes de cambiarlo.
‫Lo hemos visto antes.
‫Te he mostrado un par de ejemplos anteriormente en el curso.
‫Pero, este método de usarlo con
‫el comando apply es nuevo
‫y mejor. Lo que teníamos en el
‫pasado era que teníamos una carrera en seco, pero solo
‫en el cliente. El cliente en realidad no
‫habló con el servidor para decirle oye, ¿estos recursos ya están allí?
‫¿Necesito recrearlos, o se actualizarán o qué va a
‫pasar? Derecha.
‫Eso no sucedió antes.
‫Ahora hay una opción de ejecución en seco
‫del servidor que enviará nuestro YAML al servidor y comparará,
‫descubrirá lo que debe suceder realmente y luego informará
‫a la línea de comando qué va
‫a cambiar. Veamos eso en acción.
‫Estoy en el directorio K8s YAML como discutí anteriormente en una
‫conferencia, si estás en el repositorio de Docker Mastery y no tienes
‫este directorio, entonces necesitas hacer
‫un git-pull para obtener las últimas actualizaciones.
‫Este es un archivo que hemos visto en
‫una conferencia anterior, aplicación. yml. Este es un servicio,
‫más una implementación, en un archivo.
‫Técnicamente, se crean dos recursos con un
‫comando de aplicación y están relacionados.
‫El servicio utiliza un selector, del que
‫aún no hemos hablado. Los selectores son cómo un
‫objeto encuentra los recursos con los que quiere hablar
‫o hacer algo.
‫Un servicio necesita hablar con los pods, por lo que necesita encontrar una
‫manera de llegar a ellos.
‫Utiliza selectores como esencialmente coincidencia de patrones
‫para hacer coincidir las etiquetas de las claves
‫y los valores allí. Si hiciera la ejecución en
‫seco tradicional aquí, entonces todo lo que haría sería que el cliente mirara la
‫aplicación y dijera, sí, voy a crear estos objetos.
‫Todo bien. Siempre va a volver y decir creado.
‫Eso es porque la solicitud no es
‫muy específica. Si estaba utilizando una actualización, o
‫un comando crear, o eliminar, lo que de nuevo no
‫creo que sea un flujo de trabajo muy basado en DevOps.
‫Esos comandos solo se ejecutarían en seco y ya sabes
‫que la actualización diría que
‫sí, ambos se actualizarán. Pero, realmente no se sabe en
‫su clúster, ¿verdad? No ha hablado con el servidor para darse cuenta de eso.
‫Queremos probar la ejecución en seco del servidor que está habilitada
‫de forma predeterminada en cualquier cosa 1. 13 y más nuevos.
‫Cuando lo haga, irá a hablar con el servidor y me
‫dará una respuesta adecuada.
‫Avancemos y creemos esto.
‫Voy a sacar el servidor en seco.
‫Esto creará los dos recursos, la implementación y
‫el servicio.
‫Ahora, si presiono la flecha hacia arriba y vuelvo a la ejecución en
‫seco del servidor, verán que dice sin cambios para ambos.
‫No me dice qué cambió o si había
‫algo que iba a cambiar
‫lo que sería. Solo me dice que un
‫recurso se cambiará o no cambiará. Es una especie de alternar, sí o no.
‫¿Qué hay de obtener la diferencia real entre lo que
‫queremos darle al servidor y cuál es el
‫estado actual de nuestros recursos?
‫Ese es el comando kubectl diff.
‫Si simplemente le doy una diferencia en lugar
‫de una aplicación, comparará el YAML que tengo
‫con la especificación que está en los servidores que
‫se están ejecutando. ese estado vuelve y hará una
‫diferencia en eso. Vamos a hacer eso.
‫No dirá nada porque no hay diferencia.
‫Pero, ¿y si vamos a cambiar el YAML?
‫¿Qué pasa si cambio las réplicas a dos?
‫Luego agrego una etiqueta en los metadatos y le daré algo
‫así como ... algo como.
‫Servidores dmz.
‫Lo inventé. Realmente no importa.
‫Luego tenemos las réplicas de dos.
‫Si hago esa misma diferencia, vuelve con las ventajas
‫y desventajas.
‫Si estás acostumbrado a leer diferencias, esto tiene
‫mucho sentido para ti. Si no está acostumbrado a las diferencias,
‫el signo menos significa que esa línea desaparecería.
‫Entonces se agregarían estas líneas.
‫Luego, aquí abajo, le muestra qué línea y qué
‫carácter en la línea se
‫está eliminando.
‫Esto se está agregando.
‫Mantiene el formato YAML, lo cual es bueno.
‫Nos está haciendo saber que están ocurriendo múltiples cambios.
‫Excelente. Por supuesto, esto no está haciendo algo
‫como un canario, o prueba de implementación o algo así.
‫No está tratando de hacer la cosa y luego ver
‫cuál es el resultado. Realmente solo está mirando la
‫especificación que tiene registrada y la especificación que tenemos en
‫nuestro disco. Busque más
‫información sobre eso en los enlaces de recursos.
‫Es un artículo de blog del equipo de Kubernetes sobre
‫el futuro de estos y cómo se desarrollarán a medida que
‫salgan de la versión beta. Recuerde, estas características en este momento son
‫beta, al menos en 1. 15 son.
‫Con suerte, con eso, puede crear su propio flujo de
‫trabajo para crear YAML desde cero, administrar
‫las especificaciones en esos YAML y luego usar el comando de aplicar
‫una y otra vez para realizar sus cambios.
‫Esa es una infraestructura mucho más amigable para DevOps como
‫tipo de código para hacerlo.
‫Todo lo que haces está documentado, con suerte en Git.
‫Por lo tanto, es de esperar que realice un git-commit para cada cambio
‫que realice en su YAML antes de implementarlo en el servidor.
‫Luego tiene esa buena documentación en Git, así como la documentación
‫cuando hace algo como un diff para ver lo que tiene
‫frente a lo que realmente se está ejecutando.