hull
hull-demo-1.31.2
该存储库包含船体头盔库图。它旨在在掌舵图中简化，维护和配置Kubernetes对象，并可以将其添加到任何Helm图表中，以增强功能性，而不会破坏现有的Helm图表配置。
图表本身以及与其相关的所有文档都可以在hull文件夹中找到，该文件夹是Hull Library Helm Chart的根文件夹。
Kubernetes API JSON模式存储在kubernetes-json-schema文件夹中。
以下是船体图表README.md ：
需要维护抽象-Kelsey Hightower
头盔的一个主要设计方面是，它迫使用户对应用程序的Kubernetes配置创建单个抽象。对于每个单独的掌舵图表，这些图表以舵机图/templates夹中的YAML模板形式实现。这些模板文件一方面包含kubernetes kubernetes yaml代码块，另一方面是使用GO模板表达式的自定义配置映射，通过中央values.yaml提供了应用程序配置之间的胶水。YAML配置文件和所需的Kubernetes yaml yaml输出。可以说，这种全应用抽象的方法非常适合为即使是最专业的应用程序创建型号配置软件包，但以更简单，重复的和现成的应用程序包装用例，以大开销为代价。创建，维护和（通常）理解Helm图表所引入的抽象（尤其是在面对来自各种来源的大量个人掌舵图表时）可能会变得乏味和挑战。
船体库的主要功能是能够完全从Helm Chart Workfrows中删除自定义的YAML模板文件，从而可以删除抽象水平。使用赫尔库图，可以在values.yaml中完全透明地指定包含所有属性的kubernetes对象。赫尔库图本身提供了统一的图层，以简化舵图表的规范，配置和渲染以实现这一目标。您还可以将其视为Kubernetes API顶部的薄层，以避免掌舵图和Kubernetes API对象配置之间的中间人，但当需要自定义单个配置选项而不是需要您添加每个配置开关时，可以提供灵活性手动到模板。 JSON模式验证基于Helm JSON验证功能（通过values.schema.json ）有助于编写Kubernetes API从一开始就使用支持Live JSON Schema验证的IDE时就可以符合对象。 values.yaml可以使用其他好处（均匀的遗传对象元数据，简化的配置/秘密包含configmaps/秘密，跨引用值。但是也许最重要的是，可以将船体库作为对任何现有舵图的依赖性添加，并并排使用而不破坏任何现有的Helm Charts功能，请参阅将Hull Library图表添加到Helm Chart中的更多信息。最后，通过作为图书馆图表本身，一切都可以在普通舵提供的功能中100％起作用 - 不引入或涉及其他工具。
您对该项目的反馈是重视的，因此请在Issues部分发表评论或开始讨论或创建功能愿望和错误报告。谢谢你！
赫尔库图的想法部分受到共同掌舵图概念和测试的启发
。
hull-demo图表在深入研究赫尔的细节之前，这是对其运作方式的首次瞥见。您可以简单地从此页面的“发行版”部分中下载最新版本的hull-demo头盔图表，它可以用来测试船体或以最小的努力来基于船体的新掌舵图。
hull-demo图将虚构的应用程序myapp与frontend部署和服务backend结合在一起。有一个用于服务器配置的配置文件，该文件安装在backend吊舱上。 frontend吊舱需要通过环境变量了解backend服务地址。此外，默认情况下应轻松从debug设置（使用nodePort访问前端）转换为类似生产的设置（使用群集服务和入口）。
捕获这些方面的裸露默认结构可能看起来像这样（带有说明的行注释）：
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这是构成hull-demo hull-demo的values.yaml的示例。
helm template hull-demo-<version>.tgz
它基于上述values.yaml渲染一组对象。包含：
myapp-frontend的部署，该部署具有中央配置的图像tag集（默认情况下为v23.1 ），以及指向myapp-backend的服务集群内地址的环境变量myapp-backend的部署，该部署具有中央配置的图像tag集（默认情况下为v23.1 ）和从myappconfig Configmap安装的配置myappconfig Configmap，该文件是通过合并模板表达式和引用值在values.yaml中其他位置定义的值而动态构建的。myapp-backend部署中的简单群集服务myapp-frontend部署中的服务，其类型和端口配置取决于中央debug开关 - 要么在debug设置模式下键入NodePort ，要么与非debug设置中的myapp Intress结合使用类型ClusterIPmyapp ，仅在debug: false值设置的情况下呈现/创建可以使用其他values.yaml在部署时间更改或覆盖此配置的每个方面。YAML覆盖文件，例如：
debug: true或debug: false将整体配置从和调试模式切换到debug模式myapp configmaps源值（ rate_limit和max_connections ）或完全覆盖它所有对象和逻辑均在hull-demo的values.yaml中使用一百行总体配置代码创建。您可以测试上述所有方面，或者简单地通过将其他values.yaml添加到上面的helm template命令中来实验。对于启动自己的头盔图表，只需清空values.yaml配置，将图表文件夹和name重命名为Chart.yaml中的任何内容，并准备好使用。
这是如何使用船体的第一个演示，但是功能和支持的用例有更多的功能。检查关键功能和详细文档以获取更多信息。
如上所述，当包含在掌舵图中时，赫尔库图可以从其从给定的规格中从values.yaml文件中从给定的规格中动态渲染kubernetes对象的作业。将YAML对象构造推迟到船体库的GO模板功能，而不是/templates文件夹中的自定义YAML模板，您可以集中执行最佳实践：
Concentrate on what is needed to specify Kubernetes objects without having to add individual boilerplate YAML templates to your chart. This removes a common source of errors and maintenance from the regular Helm workflow.为了使船体渲染的输出符合Kubernetes API规范，大量的单位测试验证了针对Kubernetes API JSON模式的船体渲染的输出。
有关更多详细信息，请参阅有关JSON Schema验证的文档。
对于所有由赫尔支持的Kubernetes对象类型，直接可用对Kubernetes对象类型属性的完整配置访问。这使图表维护者不必一个一个一个一个添加缺少的配置选项，而Helm Chart用户则从拨出头盔图表中仅添加了他们的配置所需的属性。仅需要将船体图表更新到具有匹配的kubernetes API版本的较新版本，以启用添加到Kubernetes对象的属性的配置，同时在较新的API版本中。船体图的版本是版本的，以反映其支持的最小Kubernetes API版本。
有关更多详细信息，请参阅架构概述的文档。
船体库的单个接口用于在图表中创建和配置对象进行部署。这促进了图表创建者/维护者和消费者对图表实际工作方式以及其包含的内容的相互了解。不再需要挖掘/templates文件夹以了解掌舵图表的含义。为避免任何错误配置，库库库的values.yaml yaml的接口已完全验证。使用支持实时JSON架构验证（例如VSCODE）的IDE时，您可以在创建船体对象时获得IDE指南。在渲染之前，JSON模式一致性由赫尔库验证。
有关更多详细信息，请参阅有关JSON Schema验证的文档。
统一和富含元数据会自动连接到赫尔库创建的所有对象。
有关元数据覆盖的更多详细信息，请参阅下面的高级示例。
通过在values.yaml中的内容规范之间选择“ configmap”和“秘密输入”的灵活处理。yaml或从外部文件中导入较大尺寸的内容。从文件导入数据时，可以通过模板引擎运行数据，也可以通过“原样”导入的“原样”，如果它已经包含应传递给消费应用程序的模板表达式。侧重于方便地处理标准方案，您还可以将文件内容定义为values.yaml的常规YAML结构。YAML，并通过文件扩展名或明确地将其自动序列到JSON或YAML，或将其明确地序列化为您选择的任何表示形式。赫尔照顾秘密的基本64编码，因此编写ConfigMaps和Secrets的工作方式完全相同，并且在部署中添加ConfigMaps或秘密仅需要几行代码。
有关更多详细信息，请参阅有关ConfigMaps和Secrets的文档。
实例化对象实例的广泛默认功能。无论您是否要拥有所有对象实例或实例组共享某些方面，例如标签或注释，容器环境变量或安装的卷，Hull都提供了支持，以有效地定义对象实例字段的默认值，以避免进行不必要的配置重复。
有关更多详细信息，请参阅图表设计建议。
对于更复杂的方案，目标yaml中的实际值values.yaml values.yaml的配置。例如，如果您的混凝土容器参数取决于values.yaml中的其他各种设置。YAML您可以将条件注入参数的计算，或者简单地将其他values.yaml引用。
有关更多详细信息，请参阅有关转换的文档。
启用自动放大引用的配置图和秘密，以促进在需要时重新启动配置的更改。
有关更多详细信息，请参阅有关POD的文档。
要了解有关船体库的一般体系结构和功能的更多信息，请参阅“体系结构概述”
在更详细地查看图书馆之前，首先要提及一些重要的事情：
/templates夹中的Yaml模板渲染的常规头盔工作流程完全不受船体库图表的集成的影响。有时，您可能对船体库不符合的配置或对象规范有非常具体的要求，因此您可以为他们使用常规的Helm Workflow和Hull库来满足您的标准需求 - 在同一头盔图中很容易并行。
hull.yaml ，而不会从嵌入式的船体图表root文件夹到父图表/templates文件夹中进行任何修改，以便能够通过船体渲染任何YAML。它包含启动船体渲染管道的代码，有关更多详细信息，请参见将赫尔库图表添加到舵表图中！
3.0.x与船体不兼容，所有其他现有的非β和非阿尔法版本都是兼容的。
1.29和1.30和1.31具有匹配和维护的船体释放。
如果您喜欢动手方法，请邀请您查看Dev.to的新船体教程系列！特定部分教程将从设置头盔并创建基于船体的图表的最初开始，以逐步确定基于现实船体的头盔图。为了强调与常规的Helm Chart工作流程的差异，教程将流行的kubernetes-dashboard Helm Chart作为源，并将其运输到功能等效的基于船体的头盔图。最后，它表明，当使用基于船体的方法而不是常规的写作图表样式时，减少以创建和维护的配置线可以减少50％以上！
创建和配置基于船体的头盔图的任务可以视为同一硬币的两个方面。双方都与相同的接口（船体库）进行交互以指定应创建的对象。从创建者/维护者的角度来看，任务最重要的是为组成要包装在掌舵图中的特定应用程序的对象提供地面结构。图表的消费者的任务是适当地将其系统的特定环境添加到地面结构中，在这种情况下，他可以根据需要自由更改甚至添加或删除对象以实现其目标。在部署时间，创建者的基础结构与消费者系统特定的YAML文件合并以构建完整的配置。通过相同的库接口进行交互，可以使人们对如何与双方的图书馆一起工作，并可以消除大多数乏味的复制和粘贴创建和考试重型配置过程。
因此，创建基于船体的盔制图所需的一切都是标准脚手架图表目录结构。将船体库图添加为子图表，将hull.yaml从赫尔库图将其复制到您的父级舵图/templates文件夹。然后，只需配置默认对象以通过values.yaml部署。 There is no limit as to how many objects of which type you create for your deployment package.
但是，除了允许使用船体定义更复杂的应用程序之外，您还可以使用它来包装您可以通过kubectl部署的简单kubernetes对象（从掌舵发行的管理角度出发）或必须写大量数量舵机样板模板以实现这一目标。
下一节在此处给出了赫尔所理解的values.yaml的基础结构。这本质上构成了生产和消耗基于船体的图表的单个接口。任何对象都是在values.yaml中定义和启用的任何对象。YAML，这意味着您可能需要为消费者预先配置对象，如果他们想使用它们，这些对象只需要启用它们即可。
在YAML结构的顶层，赫尔区分config和objects 。虽然config配置旨在处理图表特定的设置，例如元数据和产品设置，但要渲染的混凝土kubernetes对象在objects密钥下指定。当将其设置为赫尔图表版本时，例如在父级舵表释放管道中，它将自动填充标签vidispine.hull/version在所有对象上，指示船体版本时，也允许使用额外的第三个顶级version 。它用于渲染对象。
config部分在config部分中，您可以为您的头盔图配置一般设置。它分为两个小节， config.general和config.specific 。
config.general部分与config.specific部分相反，该部分应使用仅特定于单个掌舵图表的任意数据填充， config.general部分应用于定义对唯一应用程序不具体的所有内容。一方面，它具有与所有基于船体的图表相关的配置选项，但也在config.general.data条目下留出空间，以定义您自己的数据字段，理想情况下以其他掌舵图表相同的方式建模。例如，如果产品套件中的多个应用程序取决于相同的端点，则可以在所有相关图表中的general.data属性下均匀地对这些端点进行建模，从而使您的舵表图与连续部署管道以相同的方式接口。
config.general只有以下子场：
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| 范围 | 描述 | 默认 | 例子 |
|---|---|---|---|
nameOverride | 该名称覆盖物应用于元数据标签app.kubernetes.io/name的值。如果设置此设置有效地在此处替换图表名称。 | ||
fullnameOverride | 如果设置为一个值，则将全名覆盖作为所有对象名称的前缀应用，并替换标准<release>-<chart>对象名称中的前缀模式。 | myapp | |
namespaceOverride | 如果设置为一个值，则所有创建对象的名称空间都设置为此值。如果未定义，则所有对象实例的名称空间默认为提供给相应Helm命令的发行名称空间。 | my-namespace | |
noObjectNamePrefixes | 如果设置，则将对象实例键直接用作创建的Kubernetes对象的名称，并且永远不会被前缀。从技术上讲，这等同于在每个对象上设置staticName为true。请注意，通过将其设置为true config.general.fullnameOverride的值无关紧要。 | false | true |
createImagePullSecretsFromRegistries | 如果是真的，则从此掌舵图中定义的所有注册表中创建图像拉秘密，并将其添加到所有POD中。 | true | false |
globalImageRegistryServer | 如果不为空，则将所有容器image字段的registry字段设置为此处给出的值。如果此字段是非空的，则忽略了config.general.globalImageRegistryToFirstRegistrySecretServer 。 image的所有定义的显式registry设置都被此值覆盖。预期的用法是在诸如部署场景（例如部署场景）的情况下，方便地将所有图像从中央码头注册表中取出。 与将 globalImageRegistryToFirstRegistrySecretServer设置为true相反，在这种情况下，注册表的秘密通常在此Helm图表之外定义，并且注册表Secret的服务器由其名称直接引用。如果您使用此功能并在此掌舵图表之外定义Docker注册表秘密，则可能需要在吊舱中添加imagePullSecrets ，以防引用的Docker注册表并非不安全。 | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | 如果True和globalImageRegistryServer为空，则所有容器image字段的registry字段都设置为第一个找到的registry对象的server字段。请注意，如果您提供多个registry OBEJCTS，这是具有最低字母数字键名的注册表。通常，应将设置createImagePullSecretsFromRegistries与true一起使用，以从自动填充的imagePullSecrets中受益并因此设置registry 。 image的显式registry设置被此值覆盖。此设置的预期用法是，如果有机隙（如部署场景），则可以方便地从中央码头注册表中提取的所有图像。 | false | true |
errorChecks | 确定船体在哪些情况下会产生错误 helm install或helm template的选项。有关更多详细信息，请参见有关配置错误检查的详细文档只有以下子场： objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | 验证没有破裂的yaml被渲染 | true | |
errorChecks.hullGetTransformationReferenceValid | 验证所有_HT*引用指向values.yaml中的现有键。 | true | |
errorChecks.containerImageValid | 验证所有pod的containers和initContainers image部分都存在，并且至少具有repository集 | true | |
errorChecks.virtualFolderDataPathExists | 验证在configmap和秘密的data path字段中确实存在的所有文件 | true | |
errorChecks.virtualFolderDataInlineValid | 验证是否为ConfigMap和Secret的data inline字段设置了没有null值或缺失值（已转换为空字符串） | false | |
debug | 可以帮助调试图表问题的选项。主要是过时的，并替换为在 errorChecks下配置的默认错误消息。只有以下子场： renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | 全局开关如果启用将打印出一个字符串：HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not found包括 _HT*/hull.util.transformation.get参考（ xyz ）和缺少键（ y ），如果转换引用了非现有字典键。这对于调试图表渲染并减少搜索破裂的引用很有用，因为通常在破损的引用中以错误的方式中止安装（这可能会使问题引用有问题的参考文献）。笔记： 到目前为止，默认情况下，任何损坏的获取参考都会通过语言头盔错误发出信号，因此此开关大部分是为了调试损坏的引用。建议禁用此选项，而在损坏的情况下失败，而是直接从错误消息中分析问题。 | false | true |
debug.renderNilWhenInlineIsNil | 全局开关如果启用将打印出一个字符串：<nil>作为 data字段值，当inline规格引用configmap或秘密中的nil指针时。如果设置为false，则nil值将在ConfigMap或Secret data字段中打印为一个空字符串。笔记： 到目前为止，任何无效的内联字段都会通过默认情况下的语言掌舵错误来发出信号（含义 hull.config.general.errorChecks.virtualFolderDataInlineValid是true ）。 Enabling this switch is mostly obsolete for debugging and it is recomended to disable this option and fail hard on invalid inline fields. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | 全局开关如果启用将打印出一个字符串：<path missing: the_missing_path>在ConfigMap或秘密 data字段中值，包括the_missing_path值，该值无法解析为文件。如果为false， data字段值将解析为一个空字符串。笔记： 到目前为止，路径字段中引用的任何不存在的文件都将通过默认情况下的语言掌舵错误发出信号（意思是 hull.config.general.errorChecks.virtualFolderDataPathExists是true ）。启用此开关大多是为了调试而过时，并且建议禁用此选项，并且在不存在的文件路径参考上失败。 | false | true |
render | 影响船体如何将对象呈现为YAML的选项。 只有以下子场： emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | 如果为true ，则赫尔会呈现annotations: {}如果对象不存在注释，则如果false省略了annotations密钥。 | false | true |
render.emptyLabels | 如果为true ，船体将呈现labels: {}如果对象不存在标签，则false了labels键。 | false | true |
render.emptyTemplateAnnotations | 如果是true ，则赫尔会呈现annotations: {}在吊舱template中，如果对象不存在注释，则false了annotations键。 | false | true |
render.emptyTemplateLabels | 如果为true ，则赫尔将labels: {}在吊舱template中if no labels exist for an object, if省略了标签the 。 | false | true |
render.emptyHullObjects | 如果为true ，则赫尔将数组作为空数组呈现，如果赫尔处理的某些字段不存在元素。如果是错误的，则将键值对。这会影响从船体配置中的字典映射到渲染YAML中的Kubernetes数组的字段。以下是赫尔对象配置中受影响字段的列表：
| false | true |
postRender | 赫尔完全渲染对象后，可以操纵所得的yaml字符串。这样做的可能性是在这里作为postRender行动提供的。警告：谨慎使用，因为这可能会破坏YAML结构！ | ||
postRender.globalStringReplacements | 可以应用于渲染对象的YAML的替换可能性的字典。主要用例与_HULL_OBJECT_TYPE_DEFAULT_中的广泛默认值结合使用sources并在其中允许将实例特定的字符串注入默认的YAML中。可以enabled: true 。每个映射包括以下字段：
| ||
postRender.globalStringReplacements.instanceKey | 如果enabled ，则如hull.Objects中的实际对象的instance_key替换string值hull.objects.<object_type>.<instance_key> 。 replacement的值是此映射的OBJECT_INSTANCE_KEY 。 | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | 如果enabled ，则如hull.objects中的实际对象的instance_key替换string值hull.objects.<object_type>.<instance_key>或通过hull.objects.<object_type>.<instance_key>.metadataNameOverride replacement的值是用于此映射的OBJECT_INSTANCE_KEY_RESOLVED 。 | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | 如果enabled ，将用实际对象的渲染metadata.name替换string值。 replacement的值是此映射的OBJECT_INSTANCE_NAME 。 | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | 一般序列化选项。 | ||
serialization.configmap.enabled | 如果enabled ，则默认情况下，使用给定的序列fileExtensions方法序列化了映射的文件扩展名。如果data键以映射扩展之一结束，则该值中的序列化方法用于将内容写入字符串。 ConfigMaps data条目上的特定serialization字段覆盖任何默认设置。 | true | |
serialization.configmap.fileExtensions | 从文件扩展到序列化方法的映射字典。 | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | 如果enabled ，则默认情况下，使用给定的序列fileExtensions方法序列化了映射的文件扩展名。如果data键以映射扩展之一结束，则该值中的序列化方法用于将内容写入字符串。秘密data条目上的特定serialization字段覆盖任何默认设置。 | true | |
serialization.secret.fileExtensions | 从文件扩展到序列化方法的映射字典。 | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | Global switch which enables RBAC objects for installation. 如果 true所有启用的RBAC对象都部署到群集，则false没有创建RBAC对象。可部署的RBAC对象是： rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | 自由表单字段，而该字段的子场在产品套件的上下文中应具有明确定义的含义。 例如，假设您的所有产品或微服务（每次作为单独的头盔图表）都取决于相同的给定端点（身份验证，配置，...）。您可能会通过每个掌舵图表执行共享的Kubernetes作业，该工作针对这些端点。现在，您可以指定一个外部船体 values.yaml包含作业规范和端点定义的方式，您可以看到合适并构造覆盖values.yaml在每个部署的顶部呈现的YAML呈现，并具有统一的机制。 | {} | |
config.general.metadata | 这里定义的元数据字段将自动添加到所有对象元数据中。 只有以下子场： labelsannotations | ||
config.general.metadata.labels | 添加到所有对象的标签。 common标签是指可以免费指定的Kubernetes和Helm Common标签和custom标签。只有以下子场： commoncustom | ||
config.general.metadata.labels.common | https://helm.sh/docs/chart_best_practices/labels/和https://kubernetes.io/docs/docs/conepts/conepts/overing-withering-with-with-with-bomp----------------/--sh/chart_best_practices/labels/-com-sh/chart_best_practices/labels/working-with-with-objects/Common-Labels/ 除非专门用空值覆盖（ '' ）所有元数据标签将根据其默认定义自动添加到所有对象中。如果helm图是产品套件的一部分，则应考虑为config.general.metadata.labels.common.'app.kubernetes.io/part-of'设置值。 | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | 由元数据管理。 | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | 版本元数据。 | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | 元数据的一部分。 | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | 名称元数据。 | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | 实例元数据。 | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | 组件元数据。 | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | 掌舵元数据。 | `{{（printf“％s-％s” .chart.name .chart.version） | 替换“+”“ _”}}' |
config.general.metadata.labels.custom | 所有指定的自定义标签都会自动添加到此头盔图的所有对象中。 | {} | |
config.general.metadata.annotations | 添加到所有对象的注释。可以免费指定custom标签。只有以下子场： custom 。 | ||
config.general.metadata.annotations.custom | 所有指定的自定义注释将自动添加到此掌舵图的所有对象中。 | {} | |
config.specific | 保留特定于Helm图中包含的特定产品的配置选项的免费表单字段。通常，此处指定的值应该用于填充特定应用程序从启动时读取其配置的配置文件的内容。因此，通常在ConfigMaps或Secrets中消耗config.specific字段。 | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects部分hull.objects下方的顶级对象类型表示您可能想创建实例的支持的Kubernetes对象类型。每个对象类型都是字典，其中条目值为对象属性，每个对象都有其自己的键，它是其属于对象类型所独有的。可以根据需要添加更多K8S对象类型，以便可以轻松扩展它。
一个重要的方面是，对于所有顶级对象类型，特定类型的实例始终由实例和对象类型组合所独有的键识别。但是，相同的密钥可用于不同对象类型的实例。
通过拥有识别实例的键，您可以：
通过将对象属性进行多层合并，通过堆叠values.yaml文件彼此之间。您可能会从定义给定舵图中定义的应用程序或微服务的默认对象结构开始。然后，您可以为特定环境（例如分阶段或生产）添加一个values.yaml 。然后，您可以添加一个values.yaml 。等等。 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
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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 |
其他API
| HULL 对象类型 | HULL 特性 | Kubernetes/External 特性 |
|---|---|---|
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.
