Toda la información necesaria para crear el modelo está disponible en la siguiente documentación oficial:
Y la documentación del modelo de Kubernetes se encuentra aquí.
El archivo del modelo se encuentra en este enlace, bajo el nombre de “Kubernetes_manifest_v2.uvl”.
Determinar los hijos o padres de alguna característica es sencillo.
Para empezar, cualquier objeto definido en un manifiesto de Kubernetes tiene una serie de características comunes. Estas son apiVersion y kind (que son obligatorias), además de metadata y spec (que son opcionales). Las características en cuya descripción aparece “read only” no son definidas por el usuario al crear el archivo de configuración.
Poniendo como ejemplo al objeto Pod, la documentación nos muestra la siguiente información:
Se observan las características básicas que posee este objeto, y aquellas con subcaracteristicas añaden un enlace a la definicion de ese objeto justo debajo del nombre (como es el caso de “metadata” con “ObjectMeta” o “spec” con “PodSpec”). Haciendo clic en PodSpec nos muestra todas las características hijas. También nos muestra a que grupo y versión pertenece, y en qué otros objetos puede aparecernos también.
Esta jerarquía es como se ha definido las características del modelo; se creaban todas las características hijas, y después se empezaba a profundizar por la primera. Cuando esta tenia todas las subcaracterísticas, se continuaba con la segunda, y así hasta obtener el modelo actual. Es decir, se ha hecho un recorrido en profundidad para obtener el modelo.
De forma general, las características apiversion y Kind definen el tipo de objeto y grupo de la API de kubernetes al que pertenece dicho objeto, metadata y sus características hijas sirven para añadir información o etiquetas (básicamente metadatos para darle contexto) al objeto, y spec y sus características hijas para definir las cualidades de ese objeto.
El tipo de característica (Boolean, Integer o String) se ha obtenido mirando el tipo de dato especificado bajo el nombre del atributo en la documentación.
En caso de que se especificase otro tipo o no apareciese, se asignaba el tipo Boolean.
Existe una excepción. Cuando una característica tiene un tipo String o Integer, y sus posibles valores están limitados a unas pocas opciones, su tipo se cambia a Boolean, y se añaden tantas características hijas (con la obligatoriedad del tipo “alternative”) como valores pueda tomar la característica padre.
Si ocurre con una característica, se indica en la descripción de la misma en la documentación que solo puede tomar unos valores predefinidos.
