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模板，您可以集中執行最佳實踐：
專注於指定Kubernetes對象所需的內容，而不必在圖表中添加單個樣板YAML模板。這消除了常規舵機工作流程中常見的錯誤和維護。為了使船體渲染的輸出符合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部署。對於您為部署包創建的哪個類型的對像沒有限制。
但是，除了允許使用船體定義更複雜的應用程序之外，您還可以使用它來包裝您可以通過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 ）。啟用此開關大部分是為了調試，並且建議禁用此選項並在無效的內聯字段中努力失敗。 | 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 | 全局開關啟用RBAC對象進行安裝。 如果 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 |
配置和存儲API
| 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 |
元數據API
| 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 |
群集API
| 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.
