Chart 文件結構

chart 為一個目錄內的文件集合。目錄名稱是 chart 的名稱（沒有版本信息）。例如，描述 WordPress 的 chart 將被存儲在 wordpress / 目錄中。

在這個目錄里面，Helm 期望如下這樣一個的結構的目錄樹：

wordpress/Chart.yaml # 包含"chart"信息的YAML文件LICENSE # 可選項：包含"chart"許可證的純文本文件README.md # 可選：可讀的自述文件requirements.yaml # 可選：列出"chart"依賴項的YAML文件values.yaml # 此"chart"的默認配置值charts/ # 包含此'chart'所依賴的任何圖表的目錄。templates/ # 模板目錄，當與值結合時，將生成有效的Kubernetes清單文件。templates/NOTES.txt # 可選：包含簡短使用說明的純文本文件

Helm 保留使用 charts / 和 templates / 目錄以及上面列出的文件名稱。其他文件將被忽略。

?

Chart.yaml 文件

Chart.yaml?文件是 chart 所必需的。它包含以下字段：

apiVersion: # 圖表API版本，始終為“v1”（必需） name: # 圖表的名稱（必需） version: # SemVer 2版本（必需） kubeVersion: # 一系列兼容的Kubernetes版本（可選） description: # 本項目的一句話描述（可選） keywords:- # 有關此項目的關鍵字列表（可選） home: # 此項目主頁的URL（可選） sources:- # 指向此項目源代碼的URL列表（可選） maintainers: # 維護人員信息(可選)- name: # 維護者名稱（每個維護者必須填寫）email: # 維護者的電子郵件（每個維護者可選）url: # 維護者的URL（每個維護者可選） engine: gotpl # 模板引擎的名稱（可選，默認為gotpl） icon: # 要用作圖標的SVG或PNG圖像的URL（可選） appVersion: # 包含的應用程序版本（可選）。這不必是SemVer deprecated: # 此“chart”是否已棄用（可選，布爾值） tillerVersion: 此“chart”所需的“Tiller”版本。這應該表示為SemVer范圍：“>2.0.0”（可選）

如果熟悉?Chart.yaml?Helm Classic 的文件格式，注意到指定依賴性的字段已被刪除。這是因為新的 chart 使用 charts / 目錄表示依賴關系。

其他字段將被忽略。

?

Charts 和版本控制

每個 chart 都必須有一個版本號。版本必須遵循?SemVer 2?標準。與 Helm Class 格式不同，Kubernetes Helm 使用版本號作為發布標記。存儲庫中的軟件包由名稱加版本識別。

例如，nginx?version 字段設置為 1.2.3 將被命名為：

nginx-1.2.3.tgz

更復雜的 SemVer 2 命名也是支持的，例如 version: 1.2.3-alpha.1+ef365。但非 SemVer 命名是明確禁止的。

注意?：雖然 Helm Classic 和 Deployment Manager 在 chart 方面都非常適合 GitHub，但 Kubernetes Helm 并不依賴或需要 GitHub 甚至 Git。因此，它不使用 Git SHA 進行版本控制。

許多 Helm 工具都使用?Chart.yaml?的 version?字段，其中包括 CLI 和 Tiller 服務。在生成包時，helm package 命令將使用它在 Chart.yaml 中的版本名作為包名。系統假定 chart 包名稱中的版本號與?Chart.yaml?中的版本號相匹配。不符合這個情況會導致錯誤。

appVersion 字段

請注意，appVersion?字段與?version?字段無關。這是一種指定應用程序版本的方法。例如，drupal?chart 可能有一個?appVersion: 8.2.1，表示 chart 中包含的 Drupal 版本（默認情況下）是?8.2.1。該字段是信息標識，對 chart 版本沒有影響。

棄用 charts

在管理 chart tepo 庫中的 chart 時，有時需要棄用 chart。Chart.yaml?的 deprecated?字段可用于將 chart 標記為已棄用。如果存儲庫中最新版本的 chart 標記為已棄用，則整個 chart 被視為已棄用。chart 名稱稍后可以通過發布未標記為已棄用的較新版本來重新使用。廢棄 chart 的工作流程根據?helm/charts?項目的工作流程如下：

• 更新 chart 的?Chart.yaml?以將 chart 標記為啟用，并且更新版本
• 在 chart Repository 中發布新的 chart 版本
• 從源代碼庫中刪除 chart（例如 git）

?

Chart 許可證文件，自述文件和說明文件

Chart 還可以包含描述 chart 的安裝，配置，使用和許可證的文件。

LICENSE 文件是一個純文本文件，包含 chart 的 [許可證]（https://en.wikipedia.org/wiki/Software_license）。?Chart 可以包含許可證，它可能在模板中具有編程邏輯，因此不僅僅是配置。 如果需要，還可以為 chart 安裝的應用程序提供單獨的許可證。

Chart 的自述文件應由 Markdown（README.md）語法格式化，并且通常應包含：

• chart 提供的應用程序或服務的描述
• 運行 chart 的任何前提條件或要求
• 選項?values.yaml?和默認值的說明
• 任何其他可能與安裝或配置 chart 相關的信息

chart 還可以包含一個簡短的純文本?templates/NOTES.txt?文件，在安裝后以及查看版本狀態時將打印出來。此文件將作為模板?template?進行評估 ，并可用于顯示使用說明，后續步驟或任何其他與發布 chart 相關的信息。例如，可以提供用于連接到數據庫或訪問 Web UI 的指令。由于運行時，該文件被打印到標準輸出?helm install?或?helm status，建議保持內容簡短并把更多細節指向自述文件。

?

Chart 依賴關系

在 Helm 中，一個 chart 可能依賴于任何數量的其他 chart。這些依賴關系可以通過 requirements.yaml 文件動態鏈接或引入?charts/?目錄并手動管理。

雖然有一些團隊需要手動管理依賴關系的優勢，但聲明依賴關系的首選方法是使用 chart 內部的?requirements.yaml?文件。

注意：?傳統 Helm 的 Chart.yaml?dependencies:?部分字段已被完全刪除棄用。

?

用?requirements.yaml?來管理依賴關系

requirements.yaml?文件是列出 chart 的依賴關系的簡單文件。

dependencies:- name: apacheversion: 1.2.3repository: http://example.com/charts- name: mysqlversion: 3.2.1repository: http://another.example.com/charts

• 該 name 字段是 chart 的名稱。
• version 字段是 chart 的版本。
• repository 字段是 chart repo 的完整 URL。請注意，還必須使用 helm repo add 添加該 repo 到本地才能使用。

有了依賴關系文件，你可以通過運行?helm dependency update?，它會使用你的依賴關系文件將所有指定的 chart 下載到你的?charts/?目錄中。

$ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo http://example.com/charts Downloading mysql from repo http://another.example.com/charts

當?helm dependency update?檢索 chart 時，它會將它們作為 chart 存檔存儲在?charts/?目錄中。因此，對于上面的示例，可以在 chart 目錄中看到以下文件：

charts/apache-1.2.3.tgzmysql-3.2.1.tgz

通過?requirements.yaml?管理 chart 是一種輕松更新 chart 的好方法，還可以在整個團隊中共享 requirements 信息。

?

requirements.yaml 中的?alias?字段

除上述其他字段外，每個 requirement 條目可能包含可選字段?alias。

為依賴的 chart 添加別名會將 chart 放入依賴關系中，并使用別名作為新依賴關系的名稱。

如果需要使用其他名稱訪問 chart，可以使用?alias。

# parentchart/requirements.yaml dependencies:- name: subchartrepository: http://localhost:10191version: 0.1.0alias: new-subchart-1- name: subchartrepository: http://localhost:10191version: 0.1.0alias: new-subchart-2- name: subchartrepository: http://localhost:10191version: 0.1.0

在上面的例子中，我們將得到 parentchart 的 3 個依賴關系

subchart new-subchart-1 new-subchart-2

實現這一目的的手動方法是?charts/?中用不同名稱多次復制 / 粘貼目錄中的同一 chart 。

?

requirements.yaml 中的?tags?和?condition?字段

除上述其他字段外，每個需求條目可能包含可選字段?tags?和?condition（條件）。

所有 charts 都會默認加載。如果存在?tags?或?condition?字段，將對它們進行評估并用于控制應用的 chart 的加載。

Condition - condition 字段包含一個或多個 YAML 路徑（用逗號分隔）。如果此路徑存在于頂級父級的值中并且解析為布爾值，則將根據該布爾值啟用或禁用 chart。只有在列表中找到的第一個有效路徑才被評估，如果沒有路徑存在，那么該條件不起作用。

Tags - 標簽字段是與此 chart 關聯的 YAML 標簽列表。在頂級父級的值中，可以通過指定標簽和布爾值來啟用或禁用所有帶有標簽的 chart。

# parentchart/requirements.yaml dependencies:- name: subchart1repository: http://localhost:10191version: 0.1.0condition: subchart1.enabled, global.subchart1.enabledtags:- front-end- subchart1- name: subchart2repository: http://localhost:10191version: 0.1.0condition: subchart2.enabled,global.subchart2.enabledtags:- back-end- subchart2 # parentchart/values.yamlsubchart1:enabled: true tags:front-end: falseback-end: true

在上面的示例中，所有帶有標簽的?front-end 的charts 都將被禁用，但由于?subchart1.enabled?的值在父項值中為 “真”，因此條件將覆蓋該?front-end?標簽，subchart1?會啟用。

由于?subchart2?被標記?back-end?和標簽的計算結果為?true，subchart2?將被啟用。還要注意的是，雖然?subchart2?有一個在?requirements.yaml?中指定的條件，但父項的值中沒有對應的路徑和值，因此條件無效。

?

使用命令行時帶有 tag 和 conditions

--set?參數可使用來更改 tag 和 conditions 值。

helm install --set tags.front-end=true --set subchart2.enabled=false

tags?和?conditions?解析

• Conditions (設置 values) 會覆蓋 tags 配置.。第一個存在的 condition 路徑生效，后續該 chart 的 condition 路徑將被忽略。
• 如果 chart 的某 tag 的任一 tag 的值為 true，那么該 tag 的值為 true，并啟用這個 chart。
• Tags 和 conditions 值必須在頂級父級的值中進行設置。
• tags:?值中的關鍵字必須是頂級關鍵字。目前不支持全局和嵌套?tags:?表格。

?

通過 requirements.yaml 導入子值

在某些情況下，希望允許子 chart 的值傳到父 chart 并作為通用默認值共享。使用這種 exports 格式的另一個好處是它可以使未來的工具能夠考慮用戶可設置的值。

要導入的值的鍵可以在父 chart 文件中?requirements.yaml?使用 YAML list 指定。list 中的每個項目都是從子 chart?exports?字段導入的 key。

要導入不包含在 exports key 中的值，請使用子父級?child-parent?格式。下面描述了兩種格式的例子。

使用 exports 格式

如果子 chart 的 values.yaml 文件 exports 在根目錄中包含一個字段，則可以通過指定要導入的關鍵字將其內容直接導入到父項的值中，如下例所示：

# parent's requirements.yaml file...import-values:- data # child's values.yaml file ... exports:data:myint: 99

由于我們在導入列表中指定了?data?鍵，因此 Helm 會在 exports 子圖的字段中查找 data 鍵并導入其內容。

最終的父值將包含我們的導出字段：

# parent's values file ... myint: 99

請注意，父鍵 data 不包含在父 chart 的最終值中。如果需要指定父鍵，請使用'child-parent'格式。

使用 child-parent 格式

要訪問未包含在子 chart 鍵值?exports?的中的值，需要指定要導入的值的源鍵（child）和父 chart 值（parent）中的目標路徑。

下面的例子中的?import-values?告訴 Helm 去拿在?child:?路徑發現的任何值，并將其復制到父值?parent:?指定的路徑

# parent's requirements.yaml file dependencies:- name: subchart1repository: http://localhost:10191version: 0.1.0...import-values:- child: default.dataparent: myimports

在上面的例子中，在 subchart1default.data?的值中找到的值將被導入到父 chart 值中?myimports?的鍵值，詳細如下：

# parent's values.yaml filemyimports:myint: 0mybool: falsemystring: "helm rocks!" # subchart1's values.yaml filedefault:data:myint: 999mybool: true

父 chart 的結果值為：

# parent's final valuesmyimports:myint: 999mybool: truemystring: "helm rocks!"

父 chart 的最終值現在包含從 subchart1 導入的?myint?和?mybool?字段。

通過?charts/?目錄手動管理依賴性

如果需要更多的控制依賴關系，可以通過將依賴的 charts 復制到?charts/?目錄中來明確表達這些依賴關系 。

依賴關系可以是 chart 歸檔（foo-1.2.3.tgz）或解壓縮的 chart 目錄。但它的名字不能從?_?或?.?開始。這些文件被 chart 加載器忽略。

例如，如果 WordPress chart 依賴于 Apache chart，則在 WordPress chart 的?charts/?目錄中提供（正確版本的）Apache chart：

wordpress:Chart.yamlrequirements.yaml# ...charts/apache/Chart.yaml# ...mysql/Chart.yaml# ...

上面的示例顯示了 WordPress chart 如何通過在其?charts/?目錄中包含這些 charts 來表示它對 Apache 和 MySQL 的依賴關系。

提示：?將依賴項放入 charts / 目錄，請使用?helm fetch?命令

使用依賴關系的操作方面影響

上面的部分解釋了如何指定 chart 依賴關系，但是這會如何影響使用?helm install?和?helm upgrade?的 chart 安裝？

假設名為 “A” 的 chart 創建以下 Kubernetes 對象

• namespace "A-Namespace"
• statefulset "A-StatefulSet"
• service "A-Service"

此外，A 依賴于創建對象的 chart B.

• namespace "B-Namespace"
• replicaset "B-ReplicaSet"
• service "B-Service"

安裝 / 升級 chart A 后，會創建 / 修改單個 Helm 版本。該版本將按以下順序創建 / 更新所有上述 Kubernetes 對象：

• A-Namespace
• B-Namespace
• A-StatefulSet
• B-ReplicaSet
• A-Service
• B-Service

這是因為當 Helm 安裝 / 升級 charts 時，charts 中的 Kubernetes 對象及其所有依賴項都是如下

• 聚合成一個單一的集合; 然后
• 按類型排序，然后按名稱排序; 接著
• 按該順序創建 / 更新。

因此，單個 release 是使用 charts 及其依賴關系創建的所有對象。

Kubernetes 類型的安裝順序由 kind_sorter.go 中的枚舉 InstallOrder 給出（the Helm source file)）。

模板 Templates 和值 Values

Helm chart 模板是用 Go 模板語言?Go template language?編寫的 ，其中添加了來自 Sprig 庫?from the Sprig library?的 50 個左右的附加模板函數以及一些其他專用函數?specialized functions。

所有模板文件都存儲在 chart 的 templates / 文件夾中。當 Helm 渲染 charts 時，它將通過模板引擎傳遞該目錄中的每個文件。

模板的值有兩種提供方法：

• chart 開發人員可能會在 chart 內部提供一個 values.yaml 文件。該文件可以包含默認值。
• chart 用戶可能會提供一個包含值的 YAML 文件。這可以通過命令行提供?helm install -f。

當用戶提供自定義值時，這些值將覆蓋 chart 中 values.yaml?文件中的值。

模板文件

模板文件遵循用于編寫 Go 模板的標準約定（請參閱文?the text/template Go package documentation?以了解詳細信息）。示例模板文件可能如下所示：

apiVersion: v1 kind: ReplicationController metadata:name: deis-databasenamespace: deislabels:app.kubernetes.io/managed-by: deis spec:replicas: 1selector:app.kubernetes.io/name: deis-databasetemplate:metadata:labels:app.kubernetes.io/name: deis-databasespec:serviceAccount: deis-databasecontainers:- name: deis-databaseimage: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}imagePullPolicy: {{.Values.pullPolicy}}ports:- containerPort: 5432env:- name: DATABASE_STORAGEvalue: {{default "minio" .Values.storage}}

上面的示例基于?此網址，是 Kubernetes replication controller 的模板。它可以使用以下四個模板值（通常在 values.yaml 文件中定義 ）：

• imageRegistry：Docker 鏡像的源。
• dockerTag：docker 鏡像的標簽。
• pullPolicy：Kubernetes 鏡像拉取策略。
• storage：存儲后端，其默認設置為?"minio"

所有這些值都由模板作者定義。Helm 不需要或指定參數。

要查更多 charts，請查看 Kubernetes charts 項目

預定義值

通過?values.yaml?文件（或通過?--set?標志）提供的值可以從?.Values?模板中的對象訪問。可以在模板中訪問其他預定義的數據片段。

以下值是預定義的，可用于每個模板，并且不能被覆蓋。與所有值一樣，名稱區分大小寫。

• Release.Name：release 的名稱（不是 chart 的）
• Release.Time：chart 版本上次更新的時間。這將匹配?Last Released?發布對象上的時間。
• Release.Namespace：chart release 發布的 namespace。
• Release.Service：處理 release 的服務。通常是 Tiller。
• Release.IsUpgrade：如果當前操作是升級或回滾，則設置為 true。
• Release.IsInstall：如果當前操作是安裝，則設置為 true。
• Release.Revision：版本號。它從 1 開始，并隨著每個?helm upgrade?增加。
• Chart：Chart.yaml?的內容。chart 版本可以從?Chart.Version?和維護人員?Chart.Maintainers?一起獲得。
• Files：包含 chart 中所有非特殊文件的 map-like 對象。不會允許你訪問模板，但會讓你訪問存在的其他文件（除非它們被排除使用?.helmignore）。可以使用 index .Files "file.name" 或使用. Files.Get name 或 .Files.GetString name 功能來訪問文件。也可以使用. Files.GetBytes 訪問該文件的內容?[byte]
• Capabilities：包含有關 Kubernetes 版本信息的 map-like 對象（.Capabilities.KubeVersion)，Tiller（.Capabilities.TillerVersion) 和支持的 Kubernetes API 版本（.Capabilities.APIVersions.Has "batch/v1"）

注意:?任何未知的 Chart.yaml 字段將被刪除。它們不會在 chart 對象內部被訪問。因此，Chart.yaml 不能用于將任意結構化的數據傳遞到模板中。values 文件可以用于傳遞。

值 values 文件

考慮到上一節中的模板?values.yaml，提供了如下必要值的信息：

imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3"

values 文件是 YAML 格式的。chart 可能包含一個默認 values.yaml 文件。Helm install 命令允許用戶通過提供額外的 YAML 值來覆蓋值：

$ helm install --values=myvals.yaml wordpress

當以這種方式傳遞值時，它們將被合并到默認 values 文件中。例如，考慮一個如下所示的 myvals.yaml 文件：

storage: "gcs"

當它與 chart 中 values.yaml 的內容合并時，生成的內容將為：

imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs"

注意只有最后一個字段被覆蓋了，其他的不變。

注：?包含在 chart 內的默認 values 文件必須命名?values.yaml。但是在命令行上指定的文件可以被命名為任何名稱。

注：?如果在 helm install 或 helm upgrade 使用?--set，則這些值僅在客戶端轉換為 YAML。

注意：?如果 values 文件中存在任何必需的條目，則可以使用'required'功能?'required' function?在 chart 模板中聲明它們

然后可以在模板內部訪問任何這些?.Values?對象值 ：

apiVersion: v1 kind: ReplicationController metadata:name: deis-databasenamespace: deislabels:app.kubernetes.io/managed-by: deis spec:replicas: 1selector:app.kubernetes.io/name: deis-databasetemplate:metadata:labels:app.kubernetes.io/name: deis-databasespec:serviceAccount: deis-databasecontainers:- name: deis-databaseimage: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}imagePullPolicy: {{.Values.pullPolicy}}ports:- containerPort: 5432env:- name: DATABASE_STORAGEvalue: {{default "minio" .Values.storage}}

范圍 Scope，依賴 Dependencies 和值 Values

values 文件可以聲明頂級 chart 的值，也可以為 chart 的 charts / 目錄中包含的任何 chart 聲明值。或者，用不同的方式來描述它，values 文件可以為 chart 及其任何依賴項提供值。例如，上面的演示 WordPresschart 具有 mysql 和 apache 依賴性。values 文件可以為所有這些組件提供值：

title: "My WordPress Site" # Sent to the WordPress templatemysql:max_connections: 100 # Sent to MySQLpassword: "secret"apache:port: 8080 # Passed to Apache

更高級別的 chart 可以訪問下面定義的所有變量。所以 WordPresschart 可以訪問 MySQL 密碼?.Values.mysql.password。但較低級別的 chart 無法訪問父 chart 中的內容，因此 MySQL 將無法訪問該?title?屬性。同樣的，也不能訪問?apache.port。

值是命名空間限制的，但命名空間已被修剪。因此對于 WordPresschart 來說，它可以訪問 MySQL 密碼字段?.Values.mysql.password。但是對于 MySQL chart 來說，這些值的范圍已經減小了，并且刪除了名 namespace 前綴，所以它會將密碼字段簡單地視為?.Values.password。

全局值

從 2.0.0-Alpha.2 開始，Helm 支持特殊的 “全局” 值。考慮前面例子的這個修改版本：

title: "My WordPress Site" # Sent to the WordPress templateglobal:app: MyWordPressmysql:max_connections: 100 # Sent to MySQLpassword: "secret"apache:port: 8080 # Passed to Apache

上面添加了一個 global 區塊，值?app: MyWordPress。此值可供所有 chart 使用?.Values.global.app。

比如，該 mysql 模板可以訪問?app?如. Values.global.app，apache chart 也同樣的。上面的 values 文件是這樣高效重新生成的：

title: "My WordPress Site" # Sent to the WordPress templateglobal:app: MyWordPressmysql:global:app: MyWordPressmax_connections: 100 # Sent to MySQLpassword: "secret"apache:global:app: MyWordPressport: 8080 # Passed to Apache

這提供了一種與所有子 chart 共享一個頂級變量的方法，這對設置 metadata 中像標簽這樣的屬性很有用。

如果子 chart 聲明了一個全局變量，則該全局將向下傳遞 （到子 chart 的子 chart），但不向上傳遞到父 chart。子 chart 無法影響父 chart 的值。

此外，父 chart 的全局變量優先于子 chart 中的全局變量。

參考

當涉及到編寫模板和 values 文件時，有幾個標準參考可以幫助你。

• Go templates
• Extra template functions
• The YAML format

使用 Helm 管理 chart

該 helm 工具有幾個用于處理 chart 的命令。

它可以為你創建一個新的 chart：

$ helm create mychart Created mychart/

編輯完 chart 后，helm?可以將其打包到 chart 壓縮包中：

$ helm package mychart Archived mychart-0.1.-.tgz

可以用?helm?來幫助查找 chart 格式或信息的問題：

$ helm lint mychart No issues found

Chart repo 庫

chart repo 庫是容納一個或多個封裝的 chart 的 HTTP 服務器。雖然 helm 可用于管理本地 chart 目錄，但在共享 chart 時，首選機制是 chart repo 庫。

任何可以提供 YAML 文件和 tar 文件并可以回答 GET 請求的 HTTP 服務器都可以用作 repo 庫服務器。

Helm 附帶用于開發人員測試的內置服務器（helm serve）。Helm 團隊測試了其他服務器，包括啟用了網站模式的 Google Cloud Storage 以及啟用了網站模式的 S3。

repo 庫的主要特征是存在一個名為的特殊文件?index.yaml，它具有 repo 庫提供的所有軟件包的列表以及允許檢索和驗證這些軟件包的元數據。

在客戶端，repo 庫使用?helm repo?命令進行管理。但是，Helm 不提供將 chart 上傳到遠程存儲服務器的工具。這是因為這樣做會增加部署服務器的需求，從而增加配置 repo 庫的難度。

Chart 起始包

helm create?命令采用可選?--starter?選項，可以指定 “起始 chart”。

起始 chart 只是普通的 chart，位于 $HELM_HOME/starters。作為 chart 開發人員，可以創作專門設計用作起始的 chart。記住這些 chart 時應考慮以下因素：

• Chart.yaml?將被生成器覆蓋。
• 用戶將期望修改這樣的 chart 內容，因此文檔應該指出用戶如何做到這一點。
• 所有 templates 目錄下的匹配項?<CHARTNAME>?將被替換為指定的 chart 名稱，以便起始 chart 可用作模板。另外,?values.yaml?的?<CHARTNAME>?也會被替換.
• 目前添加chart的唯一方法是手動將其復制到$HELM_HOME/starters。在chart的文檔中，你需要解釋該過程。

?

?

?

?

總結

以上是生活随笔為你收集整理的k8s chart的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。