hull
hull-demo-1.31.2
Este repositorio contiene la tabla de la biblioteca Hull Helm. Está diseñado para aliviar la construcción, mantenimiento y configuración de objetos Kubernetes en los gráficos de timón y se puede agregar a cualquier gráfico de timón como un complemento para mejorar la funcionalidad sin ningún riesgo de romper las configuraciones de gráficos de timón existentes.
El cuadro en sí y toda la documentación relacionada con ella se puede encontrar en la carpeta hull , que es la carpeta raíz de la tabla de timón de la biblioteca del casco.
Los esquemas de Kubernetes API JSON se almacenan en la carpeta kubernetes-json-schema .
A continuación se muestra los gráficos de casco README.md :
Deben mantener las abstracciones: Kelsey Hightower
Un aspecto de diseño importante del timón es que obliga al usuario a crear abstracciones individuales de la configuración de aplicaciones de Kubernetes. Para cada cuadro de timón individual que se realiza en forma de plantillas YAML en una carpeta de gráficos de timón /templates . Estos archivos de plantilla, que contienen bloques de código Yaml Kubernetes y mapeos de configuración personalizados que utilizan expresiones de plantilla GO, por otro lado, proporcionan el pegamento entre la configuración de la aplicación a través de los values.yaml centrales. El archivo de configuración de yaml y el archivo de salida de kubernetes deseados . Podría decirse que este enfoque de la abstracción por aplicación es adecuada para crear paquetes de configuración a medida incluso para las aplicaciones más especializadas, pero tiene un costo de tener una gran sobrecarga para los casos de uso de envases de aplicaciones más simples, recurrentes y listos. Crear, mantener y (a menudo) comprender las abstracciones introducidas por los gráficos de timón, especialmente cuando se enfrenta a una gran cantidad de gráficos de timón individuales de varias fuentes, puede volverse tedioso y desafiante.
La característica principal de la biblioteca del casco es la capacidad de eliminar los archivos de plantilla YAML personalizados completamente de los flujos de trabajo del gráfico de timón y, por lo tanto, permitiendo eliminar un nivel de abstracción. Usando el gráfico de la biblioteca del casco, los objetos Kubernetes, incluidas todas sus propiedades, se pueden especificar de manera completa y transparente en los values.yaml . El cuadro de la biblioteca del casco proporciona la capa uniforme para agilizar la especificación, la configuración y la representación de los gráficos de timón para lograr esto. También puede pensarlo como una capa delgada en la parte superior de la API Kubernetes para evitar el intermediario entre la tabla de timón y la configuración del objeto de la API de Kubernetes, pero proporcionando flexibilidad cuando se requiere personalizar las opciones de configuración individuales en lugar de requerir que agregue cada interruptor de configuración manualmente a las plantillas. La validación del esquema JSON basada en la función de validación de Helm JSON (a través de values.schema.json ) ayuda a escribir los objetos de conformidad de la API de Kubernetes desde el principio cuando se usa un IDE que admite la validación de esquema Live JSON. Beneficios adicionales (metadatos de objeto hereditarios uniformes, inclusión simplificada de configmaps/secretos, valores de referencia cruzada dentro de los values.yaml , ...) están disponibles con el casco sobre el que puede leer a continuación en la descripción general de las características clave . Pero quizás lo más importante es que la biblioteca del casco se puede agregar como una dependencia de cualquier gráfico de timón existente y usarse de lado a lado sin romper las funcionalidades de gráficos de timón existentes, consulte Agregar el gráfico de la biblioteca del casco a un cuadro de timón para obtener más información. Y, por último, al ser una tabla de biblioteca en sí, todo funciona al 100% dentro de la funcionalidad que ofrece Plain Helm: no se introducen o involucran herramientas adicionales.
Se valoran sus comentarios sobre este proyecto, por lo tanto, comente o comente una discusión en la sección Issues o cree deseos de características e informes de errores. ¡Gracias!
La idea del gráfico de la biblioteca del casco se inspira en parte en el concepto de gráfico de timón común y para las pruebas
.
hull-demo Antes de sumergirse en los detalles de Hull, aquí hay una primera visión de cómo funciona. Simplemente puede descargar la última versión de la tabla de cascos hull-demo de la sección de lanzamientos de esta página, tiene todo arrancado para probar el casco o configurar un nuevo cuadro de timón basado en casco con un esfuerzo mínimo.
La tabla de hull-demo envuelve una aplicación ficticia myapp con un par frontend y backend implementación y servicio. Hay un archivo de configuración para la configuración del servidor que se monta en las cápsulas backend . Las cápsulas frontend deben saber sobre la dirección del servicio backend a través de variables de entorno. Además, la configuración debe ser fácilmente conmutable desde una configuración debug (usando un nodoPort para acceder al frontend) a una configuración similar a una producción (usando un servicio de clúster y un ingreso).
Una estructura predeterminada desnuda para capturar estos aspectos puede verse así (con comentarios de línea agregados para explicación):
hull : # HULL is configured via subchart key 'hull'
config : # chart setup takes place here for everything besides object definitions
specific : # central place for shared values specific to this chart
debug : true # a switch influencing creation of objects in this chart
application_version : v23.1 # a shared image tag for multiple container
myapp : # some exemplary configuration settings for the app, exposed here for transparency
rate_limit : 100
max_connections : 5
objects : # all objects to create are defined here
deployment : # create deployments
myapp-frontend : # the base part of the object name for frontend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # provide image reference
repository : mycompany/myapp-frontend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 80 # the port number
env : # environment variables
SERVER_HOSTNAME : # name of variable
value : _HT^myapp-backend # value is dynamically rendered reference to myapp-backend service name
SERVER_PORT : # name of variable
value : " 8080 " # backend service port
myapp-backend : # the base part of the object name for backend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # image reference
repository : mycompany/myapp-backend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 8080 # the port number
volumeMounts : # mounts of the container
appconfig : # context key is appconfig
name : myappconfig # the name needs to match a volume
mountPath : /etc/config/appconfig.json # mountPath
subPath : backend-appconfig.json # subPath
volumes : # volumes that may be mounted
myappconfig : # key matching a volumeMounts name
configMap : # configmap reference
name : myappconfig # the configmap to load, simply referenced by key name
configmap : # create configmaps
myappconfig : # the backend configuration
data : # data section
backend-appconfig.json : # key name is file name
serialization : toPrettyJson # serialize the dictionary content of inline to pretty Json
inline : # define the contents of the file as a dictionary for convenience
rate-limit : _HT*hull.config.specific.myapp.rate_limit
max-connections : _HT*hull.config.specific.myapp.max_connections
debug-log : _HT!{{ if _HT*hull.config.specific.debug }}true{{ else }}false{{ end }}
service : # create services
myapp-frontend : # frontend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port for type=ClusterIP
enabled : _HT?not _HT*hull.config.specific.debug # bind rendering to debug: false condition, use embedded transformation to reference field
port : 80 # regular port
targetPort : http # targetPort setting
http_nodeport : # http port for type=NodePort
enabled : _HT?_HT*hull.config.specific.debug # bind rendering to debug: true condition
port : 80 # regular port
nodePort : 31111 # the node port
targetPort : http # targetPort setting
type : |- # dynamically switch type based on hull.config.specific.debug setting
_HT!
{{- if _HT*hull.config.specific.debug -}}
NodePort
{{- else -}}
ClusterIP
{{- end -}}
myapp-backend : # backend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port
port : 8080 # regular port
targetPort : http # targetPort setting
type : ClusterIP # in cluster service
ingress : # create ingresses
myapp : # the central frontend ingress
enabled : _HT?not _HT*hull.config.specific.debug # rendering bound to debug: false
rules : # the ingress rules
myapp : # key-value dictionary of rules
host : SET_HOSTNAME_HERE # change the host at deployment time to actual one
http : # http settings
paths : # paths definition
standard : # a standard path definition
path : / # could be changed at deployment time
pathType : ImplementationSpecific # path type
backend : # backend config
service : # service targeted
name : myapp-frontend # key name suffices to reference service created in this chart
port : # target port
name : http # target port name Este es el ejemplo que constituye como values.yaml de hull-demo , si descarga la última versión y ejecución hull-demo :
helm template hull-demo-<version>.tgz
Presenta un conjunto de objetos basados en values.yaml anteriores.yaml que contiene:
myapp-frontend que tiene un conjunto tag de imagen configurado centralmente (por defecto v23.1 ), y las variables de entorno que apuntan a la dirección en clúster del servicio de myapp-backendmyapp-backend que tiene un conjunto tag de imagen configurada centralmente (por defecto v23.1 ) y una configuración montada desde el myappconfig configMapmyappconfig configMap con un archivo json que se construye dinámicamente incorporando expresiones de plantilla y referencia a valores definidos en otra parte de values.yamlmyapp-backendmyapp-frontend cuyo tipo y configuración de puerto dependen del interruptor debug central, ya sea tipo NodePort en un modo de configuración debug o tipo ClusterIP en combinación con un Ingress myapp en configuraciones no debugmyapp que solo se presenta/crea en caso de que se establezca el valor debug: false Cada aspecto de esta configuración se puede cambiar o sobrescribirse en el tiempo de implementación utilizando values.yaml adicionales. Aziles de superposición de Yaml, por ejemplo:
debug por configuración debug: true o debug: falsemyapp ConfigMaps ( rate_limit y max_connections ) o sobrescribirlo por completo Todos los objetos y la lógica se crearon con menos de cien líneas de código de configuración general en los values.yaml de hull-demo . Puede probar todos los aspectos mencionados anteriormente o simplemente experimentar agregando values.yaml adicionales. Los archivos de superposición de yaml al comando helm template anterior. Para el bootstrapping su propio gráfico de timón, simplemente vacíe la configuración values.yaml Yaml, cambie el nombre de la carpeta de gráficos y name en Chart.yaml a lo que desee y estará listo para comenzar.
Esta es una primera demostración de cómo se podría usar el casco, pero hay mucha más funcionalidad y casos de uso compatibles. Consulte las características clave y la documentación detallada para obtener más información.
Como se destacó anteriormente, cuando se incluye en una tabla de timón, el gráfico de la biblioteca del casco puede hacerse cargo del trabajo de representar dinámicamente los objetos de Kubernetes desde sus especificaciones dadas desde el archivo values.yaml solo. Con la construcción de objetos YAML diferidos a las funciones de plantilla GO de la Biblioteca del Hull en lugar de plantillas YAML personalizadas en la carpeta /templates puede hacer cumplir centralmente las mejores prácticas:
Concéntrese en lo que se necesita para especificar los objetos de Kubernetes sin tener que agregar plantillas yaml de calderas individuales a su gráfico. Esto elimina una fuente común de errores y mantenimiento del flujo de trabajo del timón regular. Para que la salida del casco se ajuste a la especificación de la API de Kubernetes, una gran cantidad de pruebas unitarias validan la salida de casco con el esquema de Kubernetes API JSON.
Para obtener más detalles, consulte la documentación sobre la validación del esquema JSON.
Para todos los tipos de objetos de Kubernetes compatibles con Hull, el acceso de configuración completo a las propiedades de los tipos de objetos de Kubernetes está directamente disponible . Esto alivia a los mantenedores de gráficos de tener que agregar opciones de configuración faltantes una por una y los usuarios de la tabla de timón de bifurcar el gráfico de timón para agregar solo las propiedades que necesitan para su configuración. Solo se requiere actualizar la tabla de casco a una versión más nueva con la versión API de Kubernetes coincidentes para habilitar la configuración de propiedades agregadas a los objetos Kubernetes, mientras tanto en versiones API más nuevas. Los gráficos de casco están versión para reflejar las versiones mínimas de la API de Kubernetes compatibles con ellos.
Para obtener más detalles, consulte la documentación sobre la descripción general de la arquitectura.
La interfaz única de la biblioteca del casco se utiliza para crear y configurar objetos en gráficos para la implementación. Esto fomenta la comprensión mutua de los creadores/mantenedores y los consumidores de los gráficos de cómo funciona realmente el gráfico y lo que contiene. No se requiere cavar en la carpeta /templates para comprender las implicaciones de los gráficos de timón. Para evitar cualquier configuración errónea, la interfaz a la biblioteca, los values.yaml de la biblioteca del casco, está completamente validada. Al usar una IDE que admite la validación de esquema Live JSON (por ejemplo, VSCODE) puede obtener la guía IDE al crear los objetos del casco. Antes de representar, la conformidad del esquema JSON es validada por la Biblioteca Hull.
Para obtener más detalles, consulte la documentación sobre la validación del esquema JSON.
Los metadatos uniformes y ricos se adjuntan automáticamente a todos los objetos creados por la biblioteca del casco.
Para obtener más detalles sobre la sobrescritura de metadatos, consulte el ejemplo avanzado a continuación.
Manejo flexible de configMap y entrada secreta eligiendo entre la especificación en línea de contenido en values.yaml o importar desde archivos externos para contenido de tamaños más grandes. Al importar datos de los archivos, los datos se pueden ejecutar a través del motor de plantilla o no importado "como está" si ya contiene expresiones de plantilla que se transmitirán a la aplicación consumidor. Con un enfoque en el manejo conveniente de escenarios estándar, también puede definir el contenido del archivo como una estructura YAML regular en los values.yaml y hacer que el casco lo sea serializar automáticamente a JSON o YAML por la extensión del archivo o explícitamente a cualquier representación de su elección. Hull se encarga de la codificación de secretos Base64, por lo que escribir configmaps and secrets funciona exactamente de la misma manera y agregar configmaps o secretos a su implementación requiere solo unas pocas líneas de código.
Para obtener más detalles, consulte la documentación sobre configMaps y secretos.
Capacidades de incumplimiento extensas para instancias de instancias de objetos. Ya sea que desee que todas sus instancias de objetos o grupos de instancias compartan ciertos aspectos, como etiquetas o anotaciones, variables de entorno de contenedores o volúmenes montados, Hull brinda soporte para definir eficientemente los valores predeterminados para campos de instancias de objetos que evitan las repeticiones de configuración innecesarias.
Para obtener más detalles, consulte los consejos de diseño del gráfico.
Para escenarios más complejos en los que los valores reales en el Target YAML están sujetos a configuraciones en los values.yaml , existe el soporte para completar los valores dinámicamente al inyectar expresiones de plantilla de plantilla definidas en lugar del valor en los values.yaml . Por ejemplo, si los argumentos de su contenedor concreto dependen de varias otras configuraciones en values.yaml values.yaml
Para obtener más detalles, consulte la documentación sobre transformaciones.
Habilite el hash automático de ConfigMaps y secretos referenciados para facilitar el POD se reinicia en los cambios de configuración cuando sea necesario.
Para obtener más detalles, consulte la documentación sobre las cápsulas.
Para obtener más información sobre la arquitectura general y las características de la biblioteca del casco, consulte la descripción de la arquitectura
Algunas cosas importantes a mencionar primero antes de mirar la biblioteca con más detalle:
/templates no se ve completamente afectada por la integración de la tabla de la biblioteca del casco. A veces puede tener requisitos muy específicos en su configuración u especificación de objetos que la biblioteca del casco no cumple, por lo que puede usar el flujo de trabajo de timón regular para ellos y la biblioteca del casco para sus necesidades más estándar, fácilmente en paralelo en el mismo gráfico de timón.
hull.yaml , debe copiarse 'como es' sin ninguna modificación de una carpeta raíz de arañas de casco incrustadas a la carpeta de gráficos /templates principales para poder renderizar cualquier YAML a través del casco. Contiene el código que inicia la tubería de renderizado del casco, ¡vea agregar la tabla de la biblioteca del casco a un gráfico de timón para más detalles!
3.0.x no son compatibles con el casco, todas las otras versiones no beta y no alfa actualmente existentes son compatibles.
1.29 y 1.30 y 1.31 tienen una versión de casco coincidente y mantenida.
Si le gusta un enfoque práctico, está invitado a echar un vistazo a la serie de tutoriales de New Hull en Dev.TO! El tutorial de la parte del Eigth comenzará desde el comienzo de configurar el timón y crear una tabla basada en el casco para finalizar una tabla de timón basada en un casco de la vida real paso a paso. Para resaltar las diferencias con el flujo de trabajo de la tabla de timón regular, los tutoriales toman el popular gráfico de timón kubernetes-dashboard como fuente y la transportan a un gráfico de timón basado en cascos funcionalmente equivalente. Al final, muestra que reducir las líneas de configuración para crear y mantener puede reducirse en más del 50% al usar un enfoque basado en el casco en lugar del estilo de timón regular de gráficos de escritura.
Las tareas de crear y configurar un gráfico de timón basado en el casco pueden considerarse como dos lados de la misma moneda. Ambas partes interactúan con la misma interfaz (la biblioteca del casco) para especificar los objetos que deben crearse. La tarea desde una perspectiva de creadores/mantenedores es principal para proporcionar la estructura del suelo para los objetos que componen la aplicación particular que se debe envolver en una tabla de timón. El consumidor de la tabla tiene la tarea de agregar adecuadamente su contexto específico del sistema a la estructura del suelo en la que tiene la libertad de cambiar e incluso agregar o eliminar objetos según sea necesario para lograr sus objetivos. En el tiempo de implementación, la estructura base de los creadores se fusiona con el archivo YAML específico del sistema de los consumidores para crear la configuración completa. Interactuar a través de la misma interfaz de la biblioteca fomenta la comprensión común de cómo trabajar con la biblioteca en ambos lados y puede eliminar la mayoría de los tediosos procesos de creación y examen de la configuración pesados.
Por lo tanto, todo lo que se necesita para crear una tabla de timón basada en el casco es una estructura de directorio de gráfico de timón de andamio estándar. Agregue el gráfico de la biblioteca del casco como un subgrama, copie el hull.yaml de la tabla de la biblioteca del casco a la carpeta de gráficos de timón /templates de su padre. Luego, simplemente configure los objetos predeterminados para implementar a través de values.yaml y ya está terminado. No hay límite en cuanto a cuántos objetos cuyo tipo crea para su paquete de implementación.
Pero además de permitir definir aplicaciones más complejas con Hull, también podría usarlo para envolver objetos simples de Kubernetes que de otro modo implementaría a través de Kubectl (estar fuera de línea desde la perspectiva de gestión con versiones de timón) o tener que escribir una cantidad significativa de Plantillas de calderas de timón para lograr esto.
La estructura base de los values.yaml entendido por el casco se da aquí en la siguiente sección. Esto esencialmente forma la interfaz única para producir y consumir gráficos basados en cascos. Cualquier objeto solo se crea en caso de que esté definido y habilitado en los values.yaml .
En el nivel superior de la estructura YAML, el casco distingue entre config y objects . Si bien la subfiguración config está destinada a tratar con configuraciones específicas de gráficos, como metadatos y configuraciones de productos, los objetos concretos de Kubernetes a representar se especifican en la tecla objects . También se permite una version adicional del tercer nivel con nombre de versión con nombre, cuando esto se establece en la versión de gráficos de casco, por ejemplo, durante la tubería de lanzamiento de los gráficos de timón principal, poblará automáticamente la etiqueta vidispine.hull/version en todos los objetos que indican la versión del casco Eso se usó para representar los objetos.
config Dentro de la sección config , puede configurar configuraciones generales para su gráfico de timón. Se divide en dos subsecciones, config.general y config.specific .
config.general A diferencia de la sección config.specific , que debe poblarse con datos arbitrarios que son específicos solo para un solo cuadro de timón, la sección config.general debe usarse para definir todo lo que no es particular para una aplicación única. Por un lado, contiene opciones de configuración que son relevantes para todos los gráficos basados en el casco, pero también deja espacio debajo de la entrada config.general.data para definir sus propios campos de datos que idealmente se modelan de la misma manera en otros gráficos de timón. Por ejemplo, si varias aplicaciones en un conjunto de productos dependen de los mismos puntos finales, puede modelar estos puntos finales de manera uniforme debajo de la propiedad general.data en todos los gráficos relevantes y, por lo tanto, tener su interfaz de gráficos de timón de la misma manera con, por ejemplo, una tubería de despliegue continua.
config.general solo tiene los siguientes subcampos:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| Parámetro | Descripción | Por defecto | Ejemplo |
|---|---|---|---|
nameOverride | La anulación de nombre se aplica a los valores de la etiqueta de metadatos app.kubernetes.io/name . Si establece esto, reemplaza efectivamente el nombre del gráfico aquí. | ||
fullnameOverride | Si se establece en un valor, la anulación de nombre completo se aplica como un prefijo a todos los nombres de objetos y reemplaza el patrón de prefijo estándar <release>-<chart> en los nombres de objetos. | myapp | |
namespaceOverride | Si se establece en un valor, el espacio de nombres de todos los objetos creados se establece en este valor. Si esto no está definido, el espacio de nombres de todas las instancias de objetos predeterminada al espacio de nombres de versión proporcionado al comando de timón respectivo. | my-namespace | |
noObjectNamePrefixes | Si se establece, las teclas de instancia de objeto sirven directamente como nombres para los objetos Kubernetes creados y nunca tienen prefijo. Esto es técnicamente equivalente a establecer staticName verdadero en cada objeto. Tenga en cuenta que al establecer esto en true el valor de config.general.fullnameOverride se vuelve irrelevante. | false | true |
createImagePullSecretsFromRegistries | Si es verdadero, los secretos de extracción de imágenes se crean a partir de todos los registros definidos en este gráfico de timón y se agregan a todos los pods. | true | false |
globalImageRegistryServer | Si no está vacío, el campo registry de todos los campos image del contenedor se establece en el valor dado aquí. La configuración de config.general.globalImageRegistryToFirstRegistrySecretServer se ignora si este campo no está vacío. Todas las configuraciones registry explícito definido para una image se sobrescriben con este valor.El uso previsto de esto es para tener convenientemente todas las imágenes extraídas de un registro de Docker central en caso de escenarios de implementación como la gapa del aire. Contrariamente a la configuración de globalImageRegistryToFirstRegistrySecretServer en true , en este caso, el secreto del registro se define típicamente fuera de este cuadro de timón y el servidor del secreto del registro se hace referencia directamente con su nombre. Si usa esta función y define el secreto del registro de Docker fuera de este gráfico de timón, además, es posible que necesite agregar imagePullSecrets a sus vainas en caso de que el Registro de Docker referenciado no sea inseguro. | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | Si True y globalImageRegistryServer está vacío, el campo registry de todos los campos image del contenedor se establece en el campo server del primer objeto registry encontrado. Tenga en cuenta que este es el registro con el nombre de la clave alfanumérica más bajo si proporciona múltiples obEJCT registry . Normalmente se debe usar junto con la configuración createImagePullSecretsFromRegistries a true para beneficiarse de imagePullSecrets autopopulados y, en consecuencia, establecer registry . Las configuraciones registry explícito para una image se sobrescriben con este valor.El uso previsto de esta configuración es tener convenientemente todas las imágenes extraídas de un registro central de Docker en caso de escenarios de implementación como la gapa del aire. | false | true |
errorChecks | Las opciones que determinan en qué casos Hull generará un error en helm install o helm template . Para obtener más detalles, consulte también la documentación detallada sobre la configuración de las verificaciones de erroresTiene solo los siguientes subcampos: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | Validar que no se representa el yaml roto | true | |
errorChecks.hullGetTransformationReferenceValid | Validar que todas las referencias _HT* apunten a una clave existente en el values.yaml | true | |
errorChecks.containerImageValid | Valide que todos containers de pod y las secciones image initContainers existen y tienen al menos un conjunto repository | true | |
errorChecks.virtualFolderDataPathExists | Validar que todos los archivos se refieren en un campo path data de config y secretal existen físicamente | true | |
errorChecks.virtualFolderDataInlineValid | Valide que no se establecen valores null o valores faltantes (que se convierten en cadenas vacías) para los campos de data de ConfigMap y Secret inline | false | |
debug | Opciones que pueden ayudar con los problemas de la tabla de depuración. Principalmente obsoletos y reemplazados por los mensajes de error predeterminados configurados en errorChecks .Tiene solo los siguientes subcampos: renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | Switch global que si está habilitado imprimirá una cadena:HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not foundincluyendo _HT*/hull.util.transformation.get reference ( xyz ) y la clave faltante ( y ) Si la transformación hace referencia a una clave de diccionario no existente. Esto es útil para depurar la representación del gráfico y reduce la búsqueda de referencias rotas porque normalmente la instalación aborta con un error en las referencias rotas (lo que puede dificultar la punta de las referencias problemáticas).NOTA: A estas alturas, cualquier referencia de Get Broken será señalado por un error del timón de habla por defecto, por lo que este interruptor está en su mayoría obsoleto para depurar referencias rotas. Se recomienda deshabilitar esta opción y fallar duro en las referencias rotas y analizar los problemas directamente desde el mensaje de error. | false | true |
debug.renderNilWhenInlineIsNil | Switch global que si está habilitado imprimirá una cadena:<nil>Como un valor de los campos de data cuando una especificación inline hace referencia a un puntero nil en un configMap o secreto. Si se establece en False, el valor nil se imprimirá como una cadena vacía en el campo ConfigMap o data Secret.NOTA: A estas alturas, cualquier error en línea no válido será señalado por un error del timón de habla por defecto (lo que significa que hull.config.general.errorChecks.virtualFolderDataInlineValid es true ). Habilitar este interruptor es principalmente obsoleto para la depuración y se recomienda deshabilitar esta opción y fallar duro en los campos en línea no válidos. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | Switch global que si está habilitado imprimirá una cadena:<path missing: the_missing_path>En un valor de campos data SecretMap o Secret, incluido el valor the_missing_path que no se resuelve en un archivo. Si False, el valor de los campos data se resolverá en una cadena vacía.NOTA: A estas alturas, cualquier archivo inexistente referenciado en un campo de ruta será señalado por un error del timón de habla por defecto (lo que significa que hull.config.general.errorChecks.virtualFolderDataPathExists es true ). Habilitar este interruptor es principalmente obsoleto para la depuración y se recomienda deshabilitar esta opción y fallar duro en las referencias de ruta de archivo inexistentes. | false | true |
render | Opciones para influir en cómo Hull ofrece objetos como YAML. Tiene solo los siguientes subcampos: emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | Si es true , Hull representa annotations: {} Si no existen anotaciones para un objeto, si se omite la clave annotations false . | false | true |
render.emptyLabels | Si es true , Hull repite labels: {} Si no existen etiquetas para un objeto, si se false la tecla labels . | false | true |
render.emptyTemplateAnnotations | Si es true , Hull representa annotations: {} en la template de un POD si no existen anotaciones para un objeto, si se omite la clave annotations false . | false | true |
render.emptyTemplateLabels | Si es true , Hull repite labels: {} En la template de pods if no labels exist for an object, if se omite the clave de las etiquetas. | false | true |
render.emptyHullObjects | Si es true , Hull repite matrices como matrices vacías si no existen elementos para algunos campos procesados por Hull. Si False, el par de valores clave está omitido.Esto afecta los campos que se asignan desde un diccionario en la configuración del casco a una matriz de Kubernetes en el YAML renderizado. La siguiente es una lista de campos afectados en la configuración del objeto de Hull:
| false | true |
postRender | Después de que el casco haya renderizado un objeto, es posible manipular la cadena YAML resultante. Las posibilidades de hacerlo se proporcionan como acciones postRender aquí.ADVERTENCIA: ¡Use con precaución, ya que esto puede corromper la estructura Yaml! | ||
postRender.globalStringReplacements | Un diccionario de posibilidades de reemplazo que se pueden aplicar al YAML del objeto renderizado. El caso de uso principal para esto está en combinación con un incumplimiento extenso en _HULL_OBJECT_TYPE_DEFAULT_ y sources instancias de objeto donde permite inyectar cadenas específicas de instancia en el YAML predeterminado. Las asignaciones preconfiguradas proporcionadas pueden estar enabled: true bajo demanda. Cada mapeo consiste en los siguientes campos:
| ||
postRender.globalStringReplacements.instanceKey | Si enabled , el valor string se reemplazará con la instance_key del objeto real como en hull.objects.<object_type>.<instance_key> . El valor de replacement es OBJECT_INSTANCE_KEY para esta asignación. | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | Si enabled , el valor string se reemplazará con la instance_key del objeto real como en hull.objects.<object_type>.<instance_key> o por hull.objects.<object_type>.<instance_key>.metadataNameOverride si esto se define. El valor de replacement es OBJECT_INSTANCE_KEY_RESOLVED para este mapeo. | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | Si enabled , el valor string se reemplazará con los metadata.name renderizados del objeto real. El valor de replacement es OBJECT_INSTANCE_NAME para esta asignación. | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | Opciones de serialización general. | ||
serialization.configmap.enabled | Si enabled , las extensiones de archivo asignadas en fileExtensions se serializan con el método de serialización dado de forma predeterminada. Si la clave data termina con una de las extensiones asignadas, el método de serialización en el valor se utiliza para escribir el contenido en cadena. Un campo serialization específico en una entrada data de configMaps sobrescribe cualquier configuración predeterminada. | true | |
serialization.configmap.fileExtensions | Un diccionario de asignaciones de extensiones de archivos a métodos de serialización. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | Si enabled , las extensiones de archivo asignadas en fileExtensions se serializan con el método de serialización dado de forma predeterminada. Si la clave data termina con una de las extensiones asignadas, el método de serialización en el valor se utiliza para escribir el contenido en cadena. Un campo serialization específico en una entrada data de secreta sobrescribe cualquier configuración predeterminada. | true | |
serialization.secret.fileExtensions | Un diccionario de asignaciones de extensiones de archivos a métodos de serialización. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | Switch global que permite objetos RBAC para la instalación. Si true todos los objetos RBAC habilitados se implementan en el clúster, si false no se crean objetos RBAC.Los objetos RBAC que son desplegables son: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | Campo de forma libre, mientras que los subcampos de este campo deben tener un significado claramente definido en el contexto de su conjunto de productos. Por ejemplo, suponga que todos sus productos o microservicios (cada uno viene como un gráfico de timón separado) depende de los mismos puntos finales dados (autenticación, configuración, ...). Es posible que tenga un trabajo de Kubernetes compartido ejecutado por cada cuadro de timón que se dirige a esos puntos finales. Ahora puede especificar un values.yaml de casco externos. Yaml que contiene la especificación de trabajo y la definición de punto final aquí de una manera que verá y construirá values.yaml superpuestos.yaml en la parte superior de cada implementación y tiene un mecanismo unificado. | {} | |
config.general.metadata | Los campos de metadatos definidos aquí se agregarán automáticamente a todos los metadatos de objetos. Tiene solo los siguientes subcampos: labelsannotations | ||
config.general.metadata.labels | Etiquetas que se agregan a todos los objetos. Las etiquetas common se refieren a las etiquetas comunes y las etiquetas comunes de Kubernetes y Helm y las etiquetas custom se pueden especificar libremente.Tiene solo los siguientes subcampos: commoncustom | ||
config.general.metadata.labels.common | Especificación de etiquetas comunes como se define en https://helm.sh/docs/chart_best_practices/labels/ y https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/. A menos que se sobrescriban específicamente con valores vacíos ( '' ), todas las etiquetas de metadatos se agregan automáticamente a todos los objetos de acuerdo con su definición predeterminada. Debe considerarse establecer un valor para config.general.metadata.labels.common.'app.kubernetes.io/part-of' si el gráfico de timón es parte de un conjunto de productos. | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | Gestionado por metadatos. | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | Versión metadatos. | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | Parte de metadatos. | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | Metadatos de nombre. | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | Metadatos de instancia. | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | Metadatos componentes. | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | Metadatos de timón. | `{{(printf"%s-%s ".chart.name .chart.version) | reemplazar "+" "_"}} ` |
config.general.metadata.labels.custom | Todas las etiquetas personalizadas especificadas se agregan automáticamente a todos los objetos de este gráfico de timón. | {} | |
config.general.metadata.annotations | Anotaciones que se agregan a todos los objetos. Las etiquetas custom se pueden especificar libremente.Tiene solo los siguientes subcampos: custom . | ||
config.general.metadata.annotations.custom | Todas las anotaciones personalizadas especificadas se agregan automáticamente a todos los objetos de este gráfico de timón. | {} | |
config.specific | Campo de forma gratuita que contiene opciones de configuración que son específicas del producto específico contenido en el gráfico de timón. Por lo general, los valores especificados aquí deben usarse para completar el contenido de los archivos de configuración que una aplicación particular lee su configuración desde el inicio del inicio. Por lo tanto, los campos config.specific . | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects Los objetos de nivel superior debajo hull.objects representan los tipos de objetos Kubernetes compatibles desde los que puede crear instancias. Cada tipo de objeto es un diccionario en el que los valores de las entradas son las propiedades de los objetos y cada objeto tiene su propia clave que es exclusiva del tipo de objeto al que pertenece. Se pueden agregar más tipos de objetos K8S según sea necesario para la biblioteca para que se pueda extender fácilmente.
Un aspecto importante es que para todos los tipos de objetos de nivel superior, las instancias de un tipo particular siempre se identifican por una clave que es exclusiva de la combinación de instancia y tipo de objeto. Sin embargo, la misma clave se puede usar para instancias de diferentes tipos de objetos.
Al tener claves que identifiquen instancias, puede:
Haga la fusión de múltiples capas de las propiedades de los objetos al apilar values.yaml . Archivos Yaml uno encima del otro. Puede comenzar con la definición de la estructura de objeto predeterminada de la aplicación o micro servicio definido en el gráfico de timón dado. Entonces puede agregar una capa de values.yaml para un entorno particular como la puesta en escena o la producción. Entonces puede agregar una capa values.yaml para credenciales. Etcétera. By uniquely identifying the instances of a particular K8s object type it becomes easy to adjust the objects properties through a multitude of layers.
use the key of an instance for naming the instance. All instance names are constructed by the following ground rule: {{ printf "%s-%s-%s" .Release.Name .Chart.Name key }} . This generates unique, dynamic names per object type and release + instance key combination.
For example, assuming the parent Helm chart is named my_webservice and the release named staging and given this specification in values.yaml :
hull :
objects :
deployment :
nginx :
pod :
containers :
nginx :
repository : nginx
tag : 1.14.2 a Kubernetes deployment object with the following metadata.name is created:
my_webservice-staging-nginx
Note that you can opt to define a static name for instances you create by adding a property
staticName: trueto your objects definition. If you do so the objects name will exactly match the key name you chose.
each particular instance can have an enabled sub-field set to true or false . This way you can predefine instances of object types in your helm charts values.yaml but not deploy them in a default scenario. Or enable them by default and refrain from deploying them in a particular environment by disabling them in an superimposed system specific values.yaml . Note that unless you explicitly specify enabled: false each instance you define will be created by default, a missing enabled key is equivalent to enabled: true .
cross-referencing objects within a helm chart by the instance key is a useful feature of the HULL library. This is possible in these contexts:
Note that you can in these cases opt to refer to a static name instead too. Adding a property
staticName: trueto the dictionary with your reference will force the referenced objects name to exactly match the name you entered.
The values of object instance keys reflects the Kubernetes objects to create for the chart. To specify these objects efficiently, the available properties for configuration can be split into three groups:
Basic HULL object configuration with hull.ObjectBase.v1 whose properties are available for all object types and instances. These are enabled , staticName , annotations and labels .
Given the example of a deployment named nginx you can add the following properties of hull.ObjectBase.v1 to the object instance:
hull :
objects :
deployment :
nginx : # unique key/identifier of the deployment to create
staticName : true # property of hull.ObjectBase.v1
# forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
enabled : true # property of hull.ObjectBase.v1
# this deployment will be rendered to a YAML object if enabled
labels :
demo_label : " demo " # property of hull.ObjectBase.v1
# add all labels here that shall be added
# to the object instance metadata section
annotations :
demo_annotation : " demo " # property of hull.ObjectBase.v1
# add all annotations here that shall be added
# to the object instance metadata section
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see below for details
Specialized HULL object properties for some object types. Below is a reference of which object type supports which special properties in addition to the basic object configuration.
Again given the example of a deployment named nginx you would want to add properties of the HULL hull.PodTemplate.v1 to the instance. With them you set the pod property to define the pod template (initContainers, containers, volumes, ...) and can add templateLabels and templateAnnotations just to the pods created metadata and not the deployment objects metadata section:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
templateLabels : # property of hull.PodTemplate.v1 to define
# labels only added to the pod
demo_pod_label : " demo pod "
templateAnnotations : # property of hull.PodTemplate.v1 to define
# annotations only added to the pod
demo_pod_annotation : " demo pod "
pod : # property of hull.PodTemplate.v1 to define the pod template
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx # specify repository and tag
# separately with HULL for easier composability
tag : 1.14.2
... # further properties (volumeMounts, affinities, ...)
Kubernetes object properties. For each object type it is basically possible to specify all existing Kubernetes properties. In case a HULL property overwrites a identically named Kubernetes property the HULL property has precedence. Even if a HULL property overrides a Kubernetes property it is intended to provide the same complete configuration options, even if sometimes handled differently by HULL.
Some of the typical top-level Kubernetes object properties and fields don't require setting them with HULL based objects because they can be deducted automatically:
apiVersion and kind are determined by the HULL object type and Kubernetes API version and don't require to be explicitly set (except for objects of type customresource ).metadata dictionary on objects is handled by HULL via the annotations and labels fields and the naming rules explained above. So the metadata field does not require configuration and is hence not configurable for any object.Some lower level structures are also converted from the Kubernetes API array form to a dictionary form or are modified to improve working with them. This also enables more sophisticated merging of layers since arrays don't merge well, they only can be overwritten completely. Overwriting arrays however can make it hard to forget about elements that are contained in the default form of the array (you would need to know that they existed in the first place). In short, for a layered configuration approach without an endless amount of elements the dictionary is preferable for representing data since it offers a much better merging support.
So again using the example of a deployment named nginx you can add the remaining available Kubernetes properties to the object instance which are not handled by HULL as shown below. For a deployment specifically you can add all the remaining properties defined in the deploymentspec API schema from deploymentspec-v1-apps which are minReadySeconds , paused , progressDeadlineSeconds , replicas , revisionHistoryLimit and strategy . If properties are marked as mandatory in the Kubernetes JSON schema you must provide them otherwise the rendering process will fail:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see above for details
replicas : 3 # property from the Kubernetes API deploymentspec
strategy : # property from the Kubernetes API deploymentspec
type : Recreate
... # further Kubernetes API deploymentspec options
Here is an overview of which top level properties are available for which object type in HULL. The HULL properties are grouped by the respective HULL JSON schema group they belong to. A detailed description of these groups and their properties is found in the documentation of this helm chart and the respective linked documents.
Workloads APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
deployment | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | deploymentspec-v1-appsminReadySecondspausedprogressDeadlineSecondsreplicasrevisionHistoryLimitstrategy |
job | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | jobspec-v1-batchactiveDeadlineSecondsbackoffLimitcompletionModecompletionsmanualSelectorparallelismselectorsuspendttlSecondsAfterFinished |
daemonset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | daemonsetspec-v1-appsminReadySecondsrevisionHistoryLimitupdateStrategy |
statefulset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | statefulsetspec-v1-appspodManagementPolicyreplicasrevisionHistoryLimitserviceNameupdateStrategyserviceNamevolumeClaimTemplates |
cronjob | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Job.v1 job | cronjobspec-v1-batchconcurrencyPolicyfailedJobsHistoryLimitschedulestartingDeadlineSecondssuccessfulJobsHistoryLimitsuspend |
Service APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
endpoints | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpoints-v1-coresubsets |
endpointslice | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpointslice-v1-discovery-k8s-ioaddressTypeendpointsports |
service | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Service.v1 ports | servicespec-v1-coreallocateLoadBalancerNodePortsclusterIPclusterIPsexternalIPsexternalNameexternalTrafficPolicyhealthCheckNodePortinternalTrafficPolicyipFamiliesipFamilyPolicyloadBalancerClassloadBalancerIPloadBalancerSourceRangespublishNotReadyAddressesselectorsessionAffinitysessionAffinityConfigtopologyKeystype |
ingress | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Ingress.v1 tlsrules | ingressspec-v1-networking-k8s-iodefaultBackendingressClassName |
ingressclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | ingressclassspec-v1-networking-k8s-iocontrollerparameters |
Config and Storage APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
configmap | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | configmap-v1-corebinaryDataimmutable |
secret | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | secret-v1-coreimmutablestringDatatype |
registry | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Registry.v1 serverusernamepassword | secret-v1-core |
persistentvolumeclaim | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumeclaimspec-v1-coreaccessModesdataSourceresourcesselectorstorageClassNamevolumeModevolumeName |
storageclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | storageclass-v1-storage-k8s-ioallowVolumeExpansionallowedTopologiesmountOptionsparametersprovisionerreclaimPolicyvolumeBindingMode |
Metadata APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
customresource | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.CustomResource.v1 apiVersionkindspec | |
limitrange | hull.ObjectBase.v1enabledannotationslabelsstaticName | limitrange-v1-corelimits |
horizontalpodautoscaler | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.HorizontalPodAutoscaler.v1 scaleTargetRef | horizontalpodautoscalerspec-v2-autoscalingbehaviormaxReplicasmetricsminReplicas |
mutatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.MutatingWebhook.v1 webhooks | |
poddisruptionbudget | hull.ObjectBase.v1enabledannotationslabelsstaticName | poddisruptionbudgetspec-v1-policymaxUnavailableminAvailableselector |
validatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.ValidatingWebhook.v1 webhooks | |
priorityclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | priorityclass-v1-scheduling-k8s-iodescriptionglobalDefaultpreemptionPolicyvalue |
Cluster APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
clusterrole | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | clusterrole-v1-rbac-authorization-k8s-ioaggregationRule |
clusterrolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | clusterrolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
namespace | hull.ObjectBase.v1enabledannotationslabelsstaticName | namespace-v1-corespecstatus |
persistentvolume | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumespec-v1-coreaccessModesawsElasticBlockStoreazureDiskazureFilecapacitycephfscinderclaimRefcsifcflexVolumeflockergcePersistentDiskglusterfshostPathiscsilocalmountOptionsnfsnodeAffinitypersistentVolumeReclaimPolicyphotonPersistentDiskportworxVolumequobyterbdscaleIOstorageClassNamestorageosvolumeModevsphereVolume |
role | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | role-v1-rbac-authorization-k8s-io |
rolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | rolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
serviceaccount | hull.ObjectBase.v1enabledannotationslabelsstaticName | serviceaccount-v1-coreautomountServiceAccountTokenimagePullSecretssecrets |
resourcequota | hull.ObjectBase.v1enabledannotationslabelsstaticName | resourcequotaspec-v1-corehardscopeSelectorscopes |
networkpolicy | hull.ObjectBase.v1enabledannotationslabelsstaticName | networkpolicyspec-v1-networking-k8s-ioegressingresspodSelectorpolicyTypes |
Other APIs
| CÁSCARA Object Type | CÁSCARA Propiedades | Kubernetes/External Propiedades |
|---|---|---|
servicemonitor | hull.ObjectBase.v1enabledannotationslabelsstaticName | ServiceMonitor CRDspec |
To test or install a chart based on HULL the standard Helm v3 tooling is usable. See also the Helm documentation at the Helm website.
To inspect the outcome of a specific values.yaml configuration you can simply render the templates which would be deployed to Kubernetes and inspect them with the below command adapted to your needs:
<PATH_TO_HELM_V3_BINARY> template --debug --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> --output-dir <PATH_TO_OUTPUT_DIRECTORY> <PATH_TO_CHART_DIRECTORY>
Installing or upgrading a chart using HULL follows the standard procedures for every Helm chart:
<PATH_TO_HELM_V3_BINARY> upgrade --install --debug --create-namespace --atomic --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> <RELEASE_NAME> <PATH_TO_CHART_DIRECTORY>
Using the nginx deployment example from the Kubernetes documentation https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment as something we want to create with our HULL based Helm chart:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx
labels :
app : nginx
spec :
replicas : 3
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
containers :
- name : nginx
image : nginx:1.14.2
ports :
- containerPort : 80 To render this analogously using the HULL library your chart needs to be setup for using HULL. In the following section we assume the parent Helm chart is named hull-test and we use the helm template command to test render the values.yaml 's.
A minimal example of creating the expected result from above would be to create a values.yaml like below in your parent chart (commented with some explanations). Note that some default features of HULL such as RBAC and dynamic naming are explicitly disabled here to obtain the output matching the above example closely:
hull :
config :
general :
rbac : false # Don't render RBAC objects. By default HULL would provide
# a 'default' Role and 'default' RoleBinding associated with
# a 'default' ServiceAccount to use for all pods.
# You can modify this as needed. Here we turn it off to not
# render the default RBAC objects.
objects :
serviceaccount :
default :
enabled : false # The release specific 'default' ServiceAccount created
# for a release by default is disabled here. In this case
# it will not be rendered out and automatically used as
# 'serviceAccountName' in the pod templates.
deployment :
nginx : # all object instances have a key used for naming the objects and
# allowing to overwrite properties in multiple values.yaml layers
staticName : true # forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : 1.14.2
ports :
http : # unique key per container here too. All key-value structures
# which are finally arrays in the K8S objects are converted to
# arrays on rendering the chart.
containerPort : 80 This produces the following rendered deployment when running the helm template command (commented with some brief explanations):
apiVersion : apps/v1 # derived from object type 'deployment'
kind : Deployment # derived from object type 'deployment'
metadata :
annotations : {}
labels : # standard Kubernetes metadata is created always automatically.
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
name : nginx # default name would be 'release-name-hull-test-nginx'
# but with staticName: true in the HULL spec it is just the key name
spec :
replicas : 3
selector : # selector is auto-created to match the unique metadata combination
# found also in the in the object's metadata labels.
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations : {}
labels : # auto-created metadata is added to pod template
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http # name 'http' derived from the key of the port
# object defined in the values.yaml
volumeMounts : []
imagePullSecrets : {}
initContainers : []
volumes : [] Now to render the nginx deployment example showcasing extra features of the HULL library you can could create the below values.yaml file in your parent chart. Note that this is a very advanced example of what is possible using this library chart.
This example highlights:
hull :
config :
general : # This time we are not setting rbac: false
# so RBAC default objects are created.
# If the default objects don't match the use-case
# you can tweak all aspects individually if needed
metadata :
labels :
custom : # Additional labels added to all K8S objects
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
annotations :
custom : # Additional annotations added to all K8S objects
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
specific : # Put configuration options specific to this chart here
nginx_tag : 1.14.2 # You can also use entries here to globally
# define values that are referenced in multiple
# places in your chart. See how this field
# is accessed below in the deployment.
objects :
deployment :
_HULL_OBJECT_TYPE_DEFAULT_ : # A special object key available for
# all object types allowing defining
# defaults for properties of all object
# type instances created.
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Default Annotation 2
general_custom_annotation_2 : Default Annotation 2 # overwriting this
# general annotation for
# all deployments
labels :
default_label_1 : Default Label 1
default_label_2 : Default Label 2
general_custom_label_2 : Default Label 2 # overwriting this
# general label for
# all deployments
nginx : # specify the nginx deployment under key 'nginx'
# This time we're not setting the metadata.name to be static so
# name will be created dynamically and will be unique
annotations :
general_custom_annotation_3 : Specific Object Annotation 3 # overwrite a
# general annotation
default_annotation_2 : Specific Object Annotation 2 # overwrite a default annotation
specific_annotation_1 : Specific Object Annotation 1 # add a specific annotation
# to the all this object's metadata
labels :
general_custom_label_3 : Specific Object Label 3 # overwrite a
# general label
default_label_2 : Specific Object Label 2 # overwrite a default label
specific_label_1 : Specific Object Label 1 # add a specific label
# to the all this object's metadata
templateAnnotations :
specific_annotation_2 : Specific Template Annotation 2 # this annotation will only appear
# in the pod template metadata
templateLabels :
specific_label_2 : Specific Template Label 2 # this label will only appear
# in the pod template metadata
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : _HT!{{ (index . "$").Values.hull.config.specific.nginx_tag }}
# Applies a tpl transformation allowing to inject dynamic data based
# on values in this values.yaml into the resulting field (here the tag
# field of this container).
# _HT! is the short form of the transformation that applies tpl to
# a given value. This example just references the value of the field
# which is specified further above in the values.yaml and will
# produce 'image: nginx:1.14.2' when rendered in the resulting
# deployment YAML but complex conditional Go templating logic is
# applicable too.
# There are some limitations to using this approach which are
# detailed in the transformation.md in the doc section.
ports :
http : # unique key per container here too. All key-value structures
# which are array in the K8S objects are converted to arrays
# on rendering the chart.
containerPort : 80
configmap : # this is to highlight the secret/configmap inclusion feature
nginx_configmap : # configmap objects have keys too
data : # specify for which contents a data entry shall be created
# within only a few lines of configuration. Contents can come from ...
an_inline_configmap.txt : # ... an inline specified content or ...
inline : |-
Top secret contents
spread over
multiple lines...
contents_from_an_external_file.txt : # ... something from an external file.
path : files/my_secret.txt
This produces the following rendered objects when running the helm template command (commented with some brief explanations):
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
kind : ServiceAccount
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # This is the default ServiceAccount created for this chart.
# As all object instances by default it will be assigned a
# dynamically created unique name in context of this object type.
# In the simple example we disabled this rendering by
# setting enabled: false for this object's key.
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # A default Role for RBAC.
rules : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : RoleBinding
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default
roleRef :
apiGroup : rbac.authorization.k8s.io/v1
kind : Role
name : release-name-hull-test-default
subjects :
- apiGroup : rbac.authorization.k8s.io/v1
kind : ServiceAccount
name : release-name-hull-test-default # A default RoleBinding for RBAC. It connects the
# default ServiceAccount with the default Role.
# By default RBAC is enabled in charts.
---
# Source: hull-test/templates/hull.yaml
apiVersion : apps/v1
kind : Deployment
metadata :
annotations :
default_annotation_1 : Default Annotation 1 # non-overwritten default_annotation
default_annotation_2 : Specific Object Annotation 2 # overwritten default_annotation by instance
general_custom_annotation_1 : General Custom Annotation 1 # non-overwritten general_custom_annotation
general_custom_annotation_2 : Default Annotation 2 # overwritten general_custom_annotation
# by default_annotation
general_custom_annotation_3 : Specific Object Annotation 3 # overwritten general_custom_annotation
# by specific_annotation
specific_annotation_1 : Specific Object Annotation 1 # added annotation for instance metadata only
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1 # non-overwritten default_label
default_label_2 : Specific Object Label 2 # overwritten default_label by instance
general_custom_label_1 : General Custom Label 1 # non-overwritten general_custom_label
general_custom_label_2 : Default Label 2 # overwritten general_custom_label by default_label
general_custom_label_3 : Specific Object Label 3 # overwritten general_custom_label
# by specific_label
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1 # added label for instance metadata only
name : release-name-hull-test-nginx
spec :
replicas : 3
selector :
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Specific Object Annotation 2
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : Default Annotation 2
general_custom_annotation_3 : Specific Object Annotation 3
specific_annotation_1 : Specific Object Annotation 1
specific_annotation_2 : Specific Template Annotation 2 # this annotation was added only
# for the pod template's metadata
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1
default_label_2 : Specific Object Label 2
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : Default Label 2
general_custom_label_3 : Specific Object Label 3
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1
specific_label_2 : Specific Template Label 2 # this label was added only
# for the pod template's metadata
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http
volumeMounts : []
imagePullSecrets : {}
initContainers : []
serviceAccountName : release-name-hull-test-default # the dynamically created name
volumes : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
data :
an_inline_configmap.txt : " Top secret contents n spread over n multiple lines... "
contents_from_an_external_file.txt : " Whatever was in this file ... "
kind : ConfigMap
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : nginx_configmap
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-nginx_configmapRead the additional documentation in the documentation folder on how to utilize the features of the HULL library to the full effect.
