Continuando con los objetos de tipo ReplicaSets, hoy vamos a ver unas notas adicionales que pueden ser de interés y que debemos tener en cuenta.
Como ya vimos en la anterior entrada sobre los objetos ReplicaSet, este tipo de objeto permite controlar de forma automática un conjunto de PODs. Esto implica que el KCP monitorizará en todo momento el número de PODs del ReplicaSet, asegurando que el estado del cluster coincida con la configuración que hemos aplicado y manteniendo el número de PODs que hayamos fijado en la configuración del objeto ReplicaSet.
En resumen, partiendo de una situación como la siguiente:
 |
| Objeto ReplicaSet en el cluster. |
Vemos que hemos definido un ReplicaSet en el que hemos fijado que siempre debe haber un total de 2 PODs corriendo en todo momento. Evidentemente este caso es muy sencillo y vemos rápidamente la relación entre los PODs y el ReplicaSet correspondiente, pero en entornos reales donde podemos tener cientos de PODs corriendo esto puede ser bastante más confuso, con lo que podemos comprobar como está gestionado un POD haciendo un describe del mismo:
 |
| Describe de un POD controlado por un ReplicaSet. |
Como vemos en la líinea Controlled By, este POD está controlado por el objeto superior ReplicaSet/webapp.
Sabemos que los PODs controlados por un objeto de tipo ReplicaSet están dados por el selector del ReplicaSet y la etiqueta de los PODs, es decir que todos los PODs que contengan la etiqueta que coincida con el selector definido serán controlados por un ReplicaSet determinado.
Esto nos puede llevar a situaciones en las que, si por alguna razón hay PODs con etiquetas coincidentes con las del campo selector de un ReplicaSet, dichos PODs pasen a estar bajo el control de dicho ReplicaSet. Por ejemplo, partiendo de la situación anterior, si arranco manualmente un POD basado en la siguiente descripción:
 |
| Definición de un POD simple. |
Al aplicar esta configuración debería existir un nuevo POD, con el nombre webserver-v1, corriendo en el cluster:
 |
| Estado del cluster. |
Pero, como podemos ver, el nuevo POD no aparece en la salida del comando get all así que ¿donde está el nuevo POD? Es importante que nos fijemos en que el campo selector del ReplicaSet coincide con el campo label asignado en el POD que hemos descrito, por tanto el KCP lo ha puesto directamente bajo el control del ReplicaSet webapp. Como el número de PODs establecido del ReplicaSet ya coincide con el número de PODs corriendo en el sistema, el nuevo POD con nombre webserver-v1 se ha borrado nada más arrancar. Podemos confirmar este hecho consultando la sección de Events del ReplicaSet con el subcomando describe de kubectl:
 |
| Descripción del ReplicaSet webapp. |
Podemos observar que la última línea muestra que se ha borrado el POD webserver-v1, lo que nos indica que nada más aplicar el fichero de descripción del mismo, el KCP ha puesto dicho POD bajo control del ReplicaSet webapp debido a que su etiqueta coincide con el campo selector del mismo.
Este punto debe tenerse en cuenta ya que implica que, si no identificamos correctamente las templates de PODs de diferentes objetos, podemos provocar conflictos en los cuales objetos de bajo nivel como PODs estén controlados por otros de alto nivel a los que no corresponden.
Hasta aquí lo más básico relacionado con los objetos de tipo ReplicaSet, en próximas entradas veremos como controlar este tipo de objetos con Deployments.
