ホーム>プログラミング関連>その他のソースコード
ダウンロード

ハル - ヘルム均一層ライブラリ

このリポジトリには、ハルヘルムライブラリチャートが含まれています。ヘルムチャートのKubernetesオブジェクトの構築、維持、構成を容易にするように設計されており、既存のヘルムチャート構成を破るリスクなしに機能を強化するために、アドオンとしてヘルムチャートに追加できます。

チャート自体とそれに関連するすべてのドキュメントは、ハルライブラリヘルムチャートのルートフォルダーであるhullフォルダーにあります。

Kubernetes API JSONスキーマはkubernetes-json-schemaフォルダーに保存されています。

以下は船体チャートREADME.md ：

抽象化を維持する必要があります-Kelsey Hightower

導入

ヘルムの主要な設計の側面の1つは、ユーザーがアプリケーションのKubernetes構成の個々の抽象化を作成することを強制することです。ヘルムチャート/templatesフォルダーのYAMLテンプレートの形で実現される個々のヘルムチャート。これらのテンプレートファイルは、一方ではボイラープレートkubernetes yamlコードブロックと、GOテンプレート式を使用してカスタム構成マッピングを含む、中央values.yamlを介してアプリケーションの構成と目的のKubernetes yaml出力を介して接着剤を提供します。 。おそらく、アプリケーションごとの抽象化のこのアプローチは、最も専門的なアプリケーションでもテイラード構成パッケージを作成するのに適していますが、よりシンプル、繰り返し、既製のアプリケーションパッケージのユースケースのために大きなオーバーヘッドを獲得するコストがかかります。ヘルムチャートによって導入された抽象化の作成、維持、および理解 - 特にさまざまなソースからの多数の個別のヘルムチャートに直面している場合、退屈で挑戦的になる可能性があります。

Hullライブラリの主な機能は、ヘルムチャートワークフローから完全にカスタマイズされたYAMLテンプレートファイルを削除し、それによって抽象化のレベルを削除できることです。 Hull Libraryチャートを使用して、すべてのプロパティを含むKubernetesオブジェクトはvalues.yamlで完全かつ透過的に指定できます。ハルライブラリチャート自体は、これを実現するために、ヘルムチャートの仕様、構成、およびレンダリングを合理化するための均一なレイヤーを提供します。また、ヘルムチャートとKubernetes APIオブジェクト構成の間の仲介者を避けるために、Kubernetes APIの上の薄い層と考えることもできますが、各構成スイッチを追加する必要がある代わりに個々の構成オプションをカスタマイズする必要がある場合に柔軟性を提供することもできます。テンプレートに手動で。 JSONスキーマヘルムJSON検証機能（Via Via Via Via Via Via values.schema.json ）に基づくkubernetes api適合オブジェクトは、ライブJSONスキーマ検証をサポートするIDEを使用したときに最初からオブジェクトを正しく書くことを支援します。追加の利点（均一な継承可能なオブジェクトメタデータ、configMaps/secretsの簡略化された包含、 values.yaml内の相互参照値。yaml、...）は、主要な機能の概要で以下で読むことができるHULLで利用できます。しかし、最も重要なことは、船体ライブラリを既存のヘルムチャートへの依存関係として追加し、既存のヘルムチャートの機能を壊すことなく並べて使用できることです。詳細については、Hullライブラリチャートをヘルムチャートに追加することです。そして最後に、ライブラリチャート自体であることにより、Plain Helmが提供する機能内ですべてが100％機能します。追加のツールは導入または関与していません。

このプロジェクトに関するフィードバックは評価されるため、 Issuesセクションでコメントするか、議論を開始するか、機能の希望とバグレポートを作成してください。ありがとう！

ハルライブラリチャートのアイデアは、共通のヘルムチャートの概念とテストのために部分的に触発されています

。

クイックスタート - hull-demoチャート

船体の詳細に飛び込む前に、ここでそれがどのように機能するかを最初に垣間見ることができます。このページのリリースセクションからhull-demo Helmチャートの最新バージョンをダウンロードするだけで、HULLをテストするか、最小限の労力でハルに基づいて新しいヘルムチャートを設定するためにブートストラップされています。

hull-demoチャートは、 frontendとbackend展開とサービスペアで架空のアプリケーションmyapp包みます。 backendポッドに取り付けられたサーバー構成用の構成ファイルがあります。 frontendポッドは、環境変数を介してbackendサービスアドレスについて知る必要があります。さらに、セットアップは、デフォルトでdebugセットアップ（フロントエンドにアクセスするためのnodePortを使用）から制作のようなセットアップ（Clusterip Serviceおよびingressを使用）に簡単に切り替える必要があります。

これらの側面をキャプチャするための裸のデフォルト構造は、このように見えるかもしれません（説明のためのラインコメントが追加されています）： 

 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に基づいてオブジェクトのセットをレンダリングします。

  • 中心に構成された画像tagセット（デフォルトではv23.1 ）を備えたmyapp-frontendの展開と、 myapp-backendのクラスタ内アドレスを指す環境変数
  • 中心に構成された画像tagセット（デフォルトでv23.1 ）とmyappconfig configMapからマウントされた構成を備えたmyapp-backendの展開
  • テンプレート式を組み込み、 values.yaml他の場所で定義されている値を参照することによって動的に構築されたJSONファイルを使用したmyappconfig configMap.yaml
  • myapp-backend展開に面したシンプルなClusteripサービス
  • タイプとポートの構成がセントラルdebugスイッチに依存しているmyapp-frontendデプロイメントのフリングサービス - debugセットアップモードのタイプNodePortまたは型ClusterIPは、非debugセットアップでのmyapp侵入と組み合わせてタイプ
  • debug: false値が設定されている場合にのみレンダリング/作成される侵入オブジェクトmyapp

この構成のあらゆる側面を、追加のvalues.yamlを使用して展開時間に変更または上書きすることができます。たとえば、YAMLオーバーレイファイルなど：

  • 設定によるdebugモードへの全体的な構成を切り替えるdebug: trueまたはdebug: false
  • 展開にリソース定義を追加します
  • イングレスのホスト名とパスを設定します
  • ポッドにさらに環境変数を追加します
  • myapp configmapsソース値（ rate_limitおよびmax_connections ）を変更するか、完全に上書きする
  • ...

すべてのオブジェクトとロジックは、 hull-demoのvalues.yamlに100行の全体的な構成コードを使用して作成されました。yaml。上記のすべての側面をテストするか、追加のvalues.yamlを追加するだけで実験することができます。YAMLオーバーレイファイルは、上記のhelm templateコマンドにファイルをオーバーレイします。 For bootstrapping your own Helm chart, just empty the values.yaml configuration, rename the charts folder and name in Chart.yaml to whatever you want and you are ready to go.

これは、Hullの使用方法の最初のデモですが、より多くの機能とサポートされているユースケースがあります。詳細については、主要な機能と詳細なドキュメントを確認してください。

重要な機能の概要

上記のように、ヘルムチャートに含まれる場合、ハルライブラリチャートは、 values.yamlファイルのみから与えられた仕様からKubernetesオブジェクトを動的にレンダリングする仕事を引き継ぐことができます。 YAMLオブジェクトの構造は、 /templatesフォルダー内のカスタムYAMLテンプレートの代わりに、ハルライブラリのGOテンプレート関数に延期されると、ベストプラクティスを中央に実施できます。

  • 個々のボイラープレートYAMLテンプレートをチャートに追加することなく、Kubernetesオブジェクトを指定するために必要なものに集中します。これにより、通常のヘルムワークフローからエラーとメンテナンスの一般的なソースが削除されます。 Hullのレンダリング出力をKubernetes API仕様に適合させるために、多数のユニットテストがKubernetes API JSONスキーマに対するハルレンダリング出力を検証します。

    詳細については、JSONスキーマ検証に関するドキュメントを参照してください。

  • HULLでサポートされているすべてのKubernetesオブジェクトタイプについて、 Kubernetesオブジェクトタイプのプロパティへの完全な構成アクセスが直接利用可能です。これにより、チャートメンテナーは、欠落している構成オプションを1つずつ追加する必要がなくなり、ヘルムチャートユーザーはヘルムチャートを分岐して構成に必要なプロパティのみを追加します。一致するKubernetes APIバージョンでHullチャートを新しいバージョンに更新するだけで、新しいAPIバージョンでKubernetesオブジェクトに追加されたプロパティの構成を有効にする必要があります。 Hullチャートは、それらがサポートする最小限のKubernetes APIバージョンを反映するようにバージョンされています。

    詳細については、アーキテクチャの概要に関するドキュメントを参照してください。

  • ハルライブラリの単一インターフェイスは、展開用のチャート内のオブジェクトを作成および構成するために使用されます。これは、チャートの作成者/メンテナーと消費者の相互理解を促進し、チャートが実際にどのように機能し、何が含まれているかについてです。ヘルムチャートの影響を理解するために/templatesフォルダーを掘り下げることはもう必要ありません。誤解を回避するために、ライブラリへのインターフェイス - ハルライブラリのvalues.yamlは完全にJSON検証されています。ライブJSONスキーマ検証（VSCODEなど）をサポートするIDEを使用する場合、HULLオブジェクトを作成するときにIDEガイダンスを取得できます。レンダリングの前に、JSONスキーマの適合性はハルライブラリによって検証されます。

    詳細については、JSONスキーマ検証に関するドキュメントを参照してください。

  • 均一でリッチなメタデータは、ハルライブラリによって作成されたすべてのオブジェクトに自動的に取り付けられています。

    • Kubernetesとヘ​​ルム用に定義されているKubernetes標準ラベルは、すべてのオブジェクトメタデータに自動的に追加されます。
    • 追加のカスタムラベルと注釈メタデータは、以下の階層的に設定できます。
      • すべて作成されたkubernetesオブジェクトまたは
      • 特定のタイプのすべてのKubernetesオブジェクトを作成しました
      • 個々のkubernetesオブジェクト。

    メタデータの上書きの詳細については、以下の高度な例を参照してください。

  • values.yamlのコンテンツのインライン指定を選択することにより、configMapと秘密の入力の柔軟な処理または大きなサイズのコンテンツの外部ファイルからインポート。ファイルからデータをインポートする場合、データはテンプレートエンジンを介して実行するか、消費アプリケーションに渡されるテンプレート式が既に含まれている場合、テンプレートのない「現状のように」インポートできます。標準シナリオの便利な取り扱いに焦点を当てることで、ファイルコンテンツをvalues.yamlの通常のYAML構造として定義することもできます。HULLは、ファイル拡張機能によってJSONまたはYAMLに自動的にシリアル化するか、選択した表現に説明します。 HullはSecretのBase64エンコードを処理するため、ConfigMapsとSecretsを作成することはまったく同じ方法で機能し、展開にConfigMapsまたはSecretを追加するには数行のコードのみが必要です。

    詳細については、ConfigMapsとSecretsのドキュメントを参照してください。

  • オブジェクトインスタンスをインスタンス化するための広範なデフォルト機能。すべてのオブジェクトインスタンスまたはインスタンスのグループにラベルや注釈、コンテナ環境変数、マウントボリュームなどの特定の側面を共有するかどうかにかかわらず、ハルは、不必要な構成の繰り返しを回避するオブジェクトインスタンスフィールドのデフォルト値を効率的に定義するサポートを提供します。

    詳細については、チャート設計アドバイスを参照してください。

  • ターゲットYAMLの実際の値がvalues.yaml構成の対象となるより複雑なシナリオの場合、YAMLでは、 values.yamlの値の代わりに定義されたGOテンプレート式を注入することにより、値を動的に入力するサポートがあります。たとえば、具体的なコンテナの引数がvalues.yamlの他のさまざまな設定に依存している場合。yaml条件を引数の計算に挿入するか、 values.yamlの他のフィールドを参照することができます。yaml。

    詳細については、変換に関するドキュメントを参照してください。

  • 参照されたConfigMapsとSecretの自動ハッシュを有効にして、必要に応じて構成の変更でPODの再起動を容易にします。

    詳細については、PODSのドキュメントを参照してください。

ハルライブラリの一般的なアーキテクチャと機能の詳細については、アーキテクチャの概要を参照してください

重要な情報

図書館をより詳細に見る前に、最初に言及すべきいくつかの重要なこと：

ショ和ハルライブラリを介してYAMLをレンダリングすることにはいくつかの利点があるかもしれませんが、それがあなたのヘルムチャートへの壊れない追加であることに注意してください。 /templatesフォルダー内のYAMLテンプレートのレンダリングを含む通常のヘルムワークフローは、ハルライブラリチャートの統合により完全に影響を受けません。船体ライブラリが満たさない構成またはオブジェクトの仕様に非常に具体的な要件がある場合があるため、同じ標準的なニーズに合わせて通常のヘルムワークフローとハルライブラリを使用できます。ショ和

ショ和単一の静的ファイルであるhull.yaml 、埋め込まれたhullチャートルートフォルダーから親チャート/templatesフォルダーへの変更なしで「AS-IS」をコピーする必要があることに注意してください。ハルレンダリングパイプラインを開始するコードが含まれています。詳細については、Hullライブラリチャートをヘルムチャートに追加することを参照してください！ショ和

ショ和この時点で、船体リリースは、既存のすべての非ベタおよび非アルファヘルム3 CLIバージョンに対してテストされます。 Helm CLIバージョン3.0.xはHullと互換性がないことに注意してください。他のすべての既存の非ベタおよび非アルファバージョンは互換性があります。ショ和

ショ和これは、対応するハルリリースで最新の3つの主要なクベルネテスリリースをサポートすることを目的としています。この時点で、Kubernetesバージョン1.29および1.30および1.31には、一致して維持された船体放出があります。ショ和

新しい！船体チュートリアル

ハンズオンアプローチが好きなら、Dev.toの新しいHullチュートリアルシリーズをご覧ください！ Eigth Partチュートリアルは、ヘルムの設定と船体ベースのチャートを作成して、実際の船体ベースのヘルムチャートを段階的に完成させるための船体ベースのチャートを作成することから始まります。通常のヘルムチャートワークフローの違いを強調するために、チュートリアルは人気のあるkubernetes-dashboard Helmチャートをソースとして採用し、機能的に同等のHullベースのヘルムチャートに輸送します。最終的には、作成および維持するための構成のラインを減らすことが、通常のヘルムスタイルの執筆チャートの代わりに船体ベースのアプローチを使用する場合、50％以上削減できることを示しています。

船体ベースのチャートの作成と構成

船体ベースのヘルムチャートを作成および構成するタスクは、同じコインの2つの側面と見なすことができます。双方は同じインターフェイス（ハルライブラリ）と対話して、作成すべきオブジェクトを指定します。クリエイター/メンテナーズの観点からのタスクは、ヘルムチャートに包まれる特定のアプリケーションを構成するオブジェクトのグラウンド構造を提供するために最も重要です。チャートの消費者は、目標を達成するために必要に応じてオブジェクトを変更したり削除したりする自由を持っている地上構造に、システム固有のコンテキストを適切に追加することを任されています。展開時に、Creators Base構造が消費者システム固有のYAMLファイルとマージされ、完全な構成を構築します。同じライブラリインターフェイスを介して相互作用すると、両側のライブラリとの作業方法に関する一般的な理解が促進され、退屈なコピーと貼り付けの作成のほとんどを排除し、重い構成プロセスを調べます。

したがって、ハルに基づいてヘルムチャートを作成するために必要なのは、標準の足場ヘルムチャートディレクトリ構造です。ハルライブラリチャートをサブチャートとして追加し、 hull.yamlハルライブラリチャートから親ヘルムチャート/templatesフォルダーにコピーします。次に、 values.yamlを介して展開するようにデフォルトオブジェクトを構成するだけで、完了します。展開パッケージ用に作成するタイプのオブジェクトの数に制限はありません。

しかし、HULLでより複雑なアプリケーションを定義できることに加えて、それを使用して単純なKubernetesオブジェクトをラップすることもできます。これを達成するためのヘルムボイラープレートテンプレート。

hullが理解したvalues.yamlのベース構造は、次のセクションでここに示されています。これにより、船体ベースのチャートを生成および消費するための単一のインターフェイスが形成されます。任意のオブジェクトは、 values.yamlで定義および有効になっている場合にのみ作成されます。これは、使用したい場合に有効にする必要がある消費者向けのオブジェクトを事前に構成することを意味する場合があります。

YAML構造の上部レベルでは、ハルはconfigとobjectsを区別します。 configサブコンフィグレーションは、メタデータや製品設定などのチャート固有の設定を扱うことを目的としていますが、レンダリングされるコンクリートクベルネートオブジェクトはobjectsキーの下で指定されています。追加の3番目のトップレベルキーという名前のversionも許可されています。これがハルチャートバージョンに設定されている場合、親ヘルムチャートのリリースパイプラインでは、ハルバージョンを示すすべてのオブジェクトのラベルvidispine.hull/versionに自動的に入力されます。それはオブジェクトをレンダリングするために使用されました。

configセクション

configセクション内で、ヘルムチャートの一般的な設定を構成できます。 config.generalとconfig.specificの2つのサブセクションに分かれています。

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 Overrideという名前は、メタデータラベルapp.kubernetes.io/nameの値に適用されます。これを設定すると、ここでチャート名を効果的に置き換えます。
fullnameOverride値に設定すると、FullName Overrideがすべてのオブジェクト名のプレフィックスとして適用され、オブジェクト名の標準<release>-<chart>プレフィックスパターンを置き換えます。 myapp
namespaceOverride値に設定すると、作成されたすべてのオブジェクトの名前空間がこの値に設定されます。これが定義されていない場合、すべてのオブジェクトインスタンスの名前空間は、それぞれのヘルムコマンドに提供されるリリース名空間にデフォルトです。 my-namespace
noObjectNamePrefixes設定されている場合、オブジェクトインスタンスキーは、作成されたKubernetesオブジェクトの名前として直接機能し、プレフィックスされることはありません。これは、各オブジェクトでstaticName Trueを設定することと技術的に同等です。これをtrueに設定することにより、 config.general.fullnameOverrideの値を無関係にすることに注意してください。 false true
createImagePullSecretsFromRegistries trueの場合、このヘルムチャートで定義されているすべてのレジストリから画像プルシークレットが作成され、すべてのポッドに追加されます。 true false
globalImageRegistryServer空にしない場合、すべてのコンテナimageフィールドのregistryフィールドがここにある値に設定されます。 config.general.globalImageRegistryToFirstRegistrySecretServerの設定は、このフィールドが空でない場合に無視されます。 imageのすべての定義された明示的なregistry設定は、この値で上書きされます。

これの意図された使用は、展開シナリオのようなAIR-GAPの場合、すべての画像を中央のDockerレジストリから引き抜くために便利にすることです。

globalImageRegistryToFirstRegistrySecretServerをtrueに設定することとは反対に、この場合、レジストリシークレットは通常、このヘルムチャートの外側で定義され、レジストリシークレットのサーバーはその名前で直接参照されます。この機能を使用して、このヘルムチャートの外側のDockerレジストリシークレットを定義する場合、参照されたDockerレジストリが安全でない場合に備えて、PODにimagePullSecretsを追加する必要がある場合があります。		 "" mycompany.docker-registry.io
globalImageRegistryToFirstRegistrySecretServer trueおよびglobalImageRegistryServerが空の場合、すべてのコンテナimageフィールドのregistryフィールドは、最初に見つかったregistryオブジェクトのserverフィールドに設定されます。これは、複数のregistry obejctを提供する場合、最も低い英数字キー名を持つレジストリであることに注意してください。 Should normally be used together with setting createImagePullSecretsFromRegistries to true to benefit from autopopulated imagePullSecrets and accordingly set registry . imageの明示的なregistry設定は、この値で上書きされます。

この設定の意図された使用法は、展開のようなエアギャップの場合、すべての画像を中央のDockerレジストリから引き抜くために便利にすることです。		 false true
errorChecks

Hullがhelm installまたはhelm templateでエラーを生成する場合を決定するオプション。詳細については、エラーチェックの構成に関する詳細なドキュメントも参照してください

次のサブフィールドのみがあります：

objectYamlValid
hullGetTransformationReferenceValid
containerImageValid
virtualFolderDataPathExists
virtualFolderDataInlineValid
errorChecks.objectYamlValid壊れたYAMLがレンダリングされないことを確認しますtrue
errorChecks.hullGetTransformationReferenceValidすべての_HT*参照がvalues.yamlの既存のキーを指すことを検証するtrue
errorChecks.containerImageValidすべてのpodのcontainersとinitContainers imageセクションが存在し、少なくともrepositoryセットがあることを確認しますtrue
errorChecks.virtualFolderDataPathExists configmapおよびsecretのdata pathフィールドで参照されているすべてのファイルが物理的に存在することを検証しますtrue
errorChecks.virtualFolderDataInlineValid null値または欠損値（空の文字列に変換される）がconfigmapおよびSecretのdata inlineフィールドに設定されていないことを確認しますfalse
debug

チャートの問題のデバッグに役立つオプション。ほとんどが廃止され、 errorChecksで構成されたデフォルトのエラーメッセージを発話することに置き換えられました。

次のサブフィールドのみがあります：

renderBrokenHullGetTransformationReferences
renderNilWhenInlineIsNil
renderPathMissingWhenPathIsNonExistent
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 ）を含む変換が既存の辞書キーを参照する場合。これは、通常、インストールが壊れた参照にエラーが中止されるため、壊れた参照の検索をデバッグして削減するのに役立ちます（問題のある参照を特定するのが難しくなる可能性があります）。

注記：

これまでに、壊れたGetの参照は、デフォルトでスピーキングヘルムエラーによって信号が表示されるため、このスイッチは壊れた参照をデバッグするためにほとんど時代遅れです。このオプションを無効にし、Broken Get Referencesで激しく失敗し、エラーメッセージから問題を直接分析することが推奨されます。		 false true
debug.renderNilWhenInlineIsNil有効化されている場合、文字列を印刷するグローバルスイッチ：

<nil>

dataフィールドとして、 inline仕様がconfigMapまたはsecretでnilポインターを参照する場合。 falseに設定されている場合、 nil値はconfigmapまたはsecret dataフィールドに空の文字列として印刷されます。

注記：

これまでに、無効なインラインフィールドは、デフォルトではhull.config.general.errorChecks.virtualFolderDataInlineValidを意味trueことを意味するスピーキングヘルムエラーによって信号が表示されます。このスイッチを有効にすることは、ほとんどデバッグが時代遅れであり、このオプションを無効にし、無効なインラインフィールドで激しく失敗することが推奨されます。		 false true
debug.renderPathMissingWhenPathIsNonExistent有効化されている場合、文字列を印刷するグローバルスイッチ：

<path missing: the_missing_path>

ファイルに解決しないthe_missing_path値を含むconfigmapまたはsecret dataフィールドの値。 falseの場合、 dataフィールド値は空の文字列に解決します。

注記：

パスフィールドで参照されている存在しないファイルは、デフォルトで話すヘルムエラーによって信号が表示されます（ hull.config.general.errorChecks.virtualFolderDataPathExistsを意味trueます）。このスイッチを有効にすることは、ほとんどデバッグが時代遅れであり、このオプションを無効にし、存在しないファイルパス参照で懸命に失敗することが推奨されます。		 false true
renderハルがオブジェクトをYAMLとしてレンダリングする方法に影響を与えるオプション。

次のサブフィールドのみがあります：

emptyAnnotations
emptyLabels
emptyHullObjects
render.emptyAnnotations trueの場合、Hullはannotations: {}オブジェクトに注釈が存在しない場合、 annotationsキーが省略されているfalse 。 false true
render.emptyLabels trueの場合、Hullはlabels: {}オブジェクトにラベルが存在しない場合、 falseの場合、 labels​​ーは省略されています。 false true
render.emptyTemplateAnnotations trueの場合、Hullはannotations: {}オブジェクトに注釈が存在しない場合、 annotationsキーfalse省略されている場合、ポッドのtemplateで{}。 false true
render.emptyTemplateLabels trueの場合、Hullはlabels: {}ポッドのtemplateでif no labels exist for an object, if theのキーが省略されています。 false true
render.emptyHullObjects trueの場合、Hullは、ハルによって処理された一部のフィールドに要素が存在しない場合、空の配列として配列をレンダリングします。 falseの場合、キー価値ペアがemmidedされます。

これは、Hull構成の辞書からレンダリングされたYAMLのKubernetesアレイにマッピングされるフィールドに影響します。以下は、Hullのオブジェクト構成の影響を受けるフィールドのリストです。

  • secretおよびconfigmapオブジェクトのdata
  • cronjob 、 daemonset 、 deployment 、 job 、 statefulset podオブジェクトのinitContainers 、 containers 、 volumes and imagePullSecrets
  • envFrom 、 daemonset 、 deployment 、 job 、 statefulset podオブジェクトのinitContainers 、 containers and volumeMounts in initcontainers、containers volumes bolumes in initcontainers cronjob initcontainers env in containers in ports
  • serviceオブジェクトのports
  • ingressのrulesとtls
  • http.paths in ingressオブジェクトのrules
  • webhooks in validatingwebhookconfigurationとmutatingwebhookconfiguration
  • clusterroleとroleのrules
 false true
postRender Hullがオブジェクトを完全にレンダリングした後、結果のYAML文字列を操作することができます。そうする可能性は、ここでpostRenderアクションとして提供されます。

警告：YAML構造が破損する可能性があるため、注意して使用してください！
postRender.globalStringReplacementsレンダリングされたオブジェクトのYAMLに適用される可能性のある交換可能性の辞書。これの主なユースケースは、 _HULL_OBJECT_TYPE_DEFAULT_での広範なデフォルトと組み合わせたものと、デフォルトのYAMLに特定の文字列をインスタンスインスタンスに挿入できるsourcesオブジェクトインスタンスと組み合わせています。提供される事前に設定されたマッピングenabled: true On Demand。各マッピングは、次のフィールドで構成されています。
  • enabled ： trueの場合はマッピングを実行します
  • string ：交換する正確な文字列部分
  • replacement ： stringの代わりに挿入された値のタイプ。無料の文字列ではなく、次の値のいずれか： OBJECT_INSTANCE_KEY 、 OBJECT_INSTANCE_KEY_RESOLVEDまたはOBJECT_INSTANCE_NAME
postRender.globalStringReplacements.instanceKey enabledと、 hull.objects.<object_type>.<instance_key>のように、 string値は実際のオブジェクトのinstance_keyに置き換えられます。 replacementの値は、このマッピングのOBJECT_INSTANCE_KEYです。 instanceKey:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_KEY
postRender.globalStringReplacements.instanceKeyResolved enabledとhull.objects.<object_type>.<instance_key> instance_key hull.Objects string hull.objects.<object_type>.<instance_key>.metadataNameOverride replacementの値は、このマッピングに対してOBJECT_INSTANCE_KEY_RESOLVEDです。 instanceKeyResolved:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_KEY_RESOLVED
postRender.globalStringReplacements.instanceName enabledと、 string値は実際のオブジェクトのレンダリングされたmetadata.nameに置き換えられます。 replacementの値は、このマッピングのOBJECT_INSTANCE_NAMEです。 instanceName:
enabled: false
string: _HULL_OBJECT_TYPE_DEFAULT_
replacement: OBJECT_INSTANCE_NAME
serialization一般的なシリアル化オプション。
serialization.configmap.enabled enabledと、 fileExtensionsの下のマッピングされたファイル拡張子は、デフォルトで指定されたシリアル化方法でシリアル化されます。 dataキーがマッピングされた拡張機能の1つで終了する場合、値のシリアル化方法は、コンテンツを文字列に書き込むために使用されます。 ConfigMaps data入力の特定のserializationフィールドは、デフォルト設定を上書きします。 true
serialization.configmap.fileExtensionsファイル拡張機能からシリアル化方法へのマッピングの辞書。 fileExtensions:
json: toPrettyJson
yaml: toYaml
yml: toYaml
serialization.secret.enabled enabledと、 fileExtensionsの下のマッピングされたファイル拡張子は、デフォルトで指定されたシリアル化方法でシリアル化されます。 dataキーがマッピングされた拡張機能の1つで終了する場合、値のシリアル化方法は、コンテンツを文字列に書き込むために使用されます。 Secrets data入力の特定のserializationフィールドは、デフォルト設定を上書きします。 true
serialization.secret.fileExtensionsファイル拡張機能からシリアル化方法へのマッピングの辞書。 fileExtensions:
json: toPrettyJson
yaml: toYaml
yml: toYaml
config.general.rbacインストール用のRBACオブジェクトを可能にするグローバルスイッチ。

trueの有効なRBACオブジェクトがクラスターに展開される場合、 falseの場合、RBACオブジェクトはまったく作成されます。

展開可能なRBACオブジェクトは次のとおりです。
roles
rolebindings
clusterroles
clusterrolebindings		 true false
config.general.dataこのフィールドのサブフィールドは、製品スイートのコンテキストで明確に定義された意味を持つ必要があります。

たとえば、すべての製品またはマイクロサービス（それぞれが別のヘルムチャートとして登場）が、同じ指定されたエンドポイント（認証、構成など）に依存すると仮定します。これらのエンドポイントをターゲットにする各ヘルムチャートによって実行された共有Kubernetesジョブがある場合があります。これで、外部の船体values.yamlを指定することができます。ここでは、ジョブ仕様とエンドポイント定義を含むYAMLフィットしてオーバーレイvalues.yamlを構築する方法で、各展開の上にレンダリングされ、統一されたメカニズムが配置されています。		 {}
config.general.metadataここで定義されたメタデータフィールドは、すべてのオブジェクトメタデータに自動的に追加されます。

次のサブフィールドのみがあります：

labels
annotations
config.general.metadata.labelsすべてのオブジェクトに追加されるラベル。 commonラベルは、KubernetesとHelm Common Labelsを参照し、 customラベルを自由に指定できます。

次のサブフィールドのみがあります：

common
custom
config.general.metadata.labels.common https://helm.sh/docs/chart_best_practices/labels/およびhttps://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/で定義されている一般的なラベルの仕様。

空の値（ '' ）で明確に上書きされない限り、すべてのメタデータラベルは、デフォルトの定義に従ってすべてのオブジェクトに自動的に追加されます。 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ヘルムチャートに含まれる特定の製品に固有の構成オプションを保持するフリーフォームフィールド。通常、ここで指定されている値は、特定のアプリケーションがスタートアップから構成を読み取る構成ファイルの内容を入力するために使用する必要があります。したがって、 config.specificフィールドは通常、configmapsまたはsecretで消費されています。 {} maxDatepickerRange: 50
defaultPoolColor: "#FB6350"
updateInterval: 60000

objectsセクション

hull.objectsの下のトップレベルのオブジェクトタイプは、インスタンスを作成する可能性のあるサポートされているKubernetesオブジェクトタイプを表します。各オブジェクトタイプは、エントリ値がオブジェクトのプロパティであり、各オブジェクトに属するオブジェクトタイプに固有の独自のキーを持っている辞書です。さらにK8Sオブジェクトタイプを必要に応じてライブラリに追加できるため、簡単に拡張できます。

オブジェクトインスタンスのキー

重要な側面の1つは、すべてのトップレベルオブジェクトタイプで、特定のタイプのインスタンスが常にインスタンスとオブジェクトタイプの組み合わせに固有のキーによって識別されることです。ただし、同じキーを使用して、異なるオブジェクトタイプのインスタンスに使用できます。

インスタンスを識別するキーを持つことによって：

  • 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: true to 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:

    • when a reference to a ConfigMap or Secret comes into play you can just use the key of the targeted instance and the dynamic name will be rendered in the output. This is possible for referencing
    • a ConfigMap or Secret behind a Volume or
    • a Secret behind an Ingress' TLS specification or
    • a ConfigMap or Secret behind an environment value added to a container spec.
    • when referencing Services in the backend of an ingress' host you can specify the key to reference the backend service.

    Note that you can in these cases opt to refer to a static name instead too. Adding a property staticName: true to the dictionary with your reference will force the referenced objects name to exactly match the name you entered.

Values of object instances

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:

  1. 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

  2. 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, ...)

  3. 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:

    • the 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 ).
    • the top-level 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

Composing objects with HULL

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.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 deploymentspec-v1-apps
minReadySeconds
paused
progressDeadlineSeconds
replicas
revisionHistoryLimit
strategy
job hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 jobspec-v1-batch
activeDeadlineSeconds
backoffLimit
completionMode
completions
manualSelector
parallelism
selector
suspend
ttlSecondsAfterFinished
daemonset hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 daemonsetspec-v1-apps
minReadySeconds
revisionHistoryLimit
updateStrategy
statefulset hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.PodTemplate.v1
templateAnnotations
templateLabels
pod		 statefulsetspec-v1-apps
podManagementPolicy
replicas
revisionHistoryLimit
serviceName
updateStrategy
serviceName
volumeClaimTemplates
cronjob hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Job.v1
job		 cronjobspec-v1-batch
concurrencyPolicy
failedJobsHistoryLimit
schedule
startingDeadlineSeconds
successfulJobsHistoryLimit
suspend

Service APIs

HULL
オブジェクトタイプ
HULL
プロパティ		Kubernetes/External
プロパティ
endpoints hull.ObjectBase.v1
enabled
annotations
labels
staticName		 endpoints-v1-core
subsets
endpointslice hull.ObjectBase.v1
enabled
annotations
labels
staticName		 endpointslice-v1-discovery-k8s-io
addressType
endpoints
ports
service hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Service.v1
ports		 servicespec-v1-core
allocateLoadBalancerNodePorts
clusterIP
clusterIPs
externalIPs
externalName
externalTrafficPolicy
healthCheckNodePort
internalTrafficPolicy
ipFamilies
ipFamilyPolicy
loadBalancerClass
loadBalancerIP
loadBalancerSourceRanges
publishNotReadyAddresses
selector
sessionAffinity
sessionAffinityConfig
topologyKeys
type
ingress hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Ingress.v1
tls
rules		 ingressspec-v1-networking-k8s-io
defaultBackend
ingressClassName
ingressclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 ingressclassspec-v1-networking-k8s-io
controller
parameters

Config and Storage APIs

HULL
オブジェクトタイプ
HULL
プロパティ		Kubernetes/External
プロパティ
configmap hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.VirtualFolder.v1
data		 configmap-v1-core
binaryData
immutable
secret hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.VirtualFolder.v1
data		 secret-v1-core
immutable
stringData
type
registry hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Registry.v1
server
username
password		 secret-v1-core
persistentvolumeclaim hull.ObjectBase.v1
enabled
annotations
labels
staticName		 persistentvolumeclaimspec-v1-core
accessModes
dataSource
resources
selector
storageClassName
volumeMode
volumeName
storageclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 storageclass-v1-storage-k8s-io
allowVolumeExpansion
allowedTopologies
mountOptions
parameters
provisioner
reclaimPolicy
volumeBindingMode

Metadata APIs

HULL
オブジェクトタイプ
HULL
プロパティ		Kubernetes/External
プロパティ
customresource hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.CustomResource.v1
apiVersion
kind
spec
limitrange hull.ObjectBase.v1
enabled
annotations
labels
staticName		 limitrange-v1-core
limits
horizontalpodautoscaler hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.HorizontalPodAutoscaler.v1
scaleTargetRef		 horizontalpodautoscalerspec-v2-autoscaling
behavior
maxReplicas
metrics
minReplicas
mutatingwebhookconfiguration hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.MutatingWebhook.v1
webhooks
poddisruptionbudget hull.ObjectBase.v1
enabled
annotations
labels
staticName		 poddisruptionbudgetspec-v1-policy
maxUnavailable
minAvailable
selector
validatingwebhookconfiguration hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.ValidatingWebhook.v1
webhooks
priorityclass hull.ObjectBase.v1
enabled
annotations
labels
staticName		 priorityclass-v1-scheduling-k8s-io
description
globalDefault
preemptionPolicy
value

Cluster APIs

HULL
オブジェクトタイプ
HULL
プロパティ		Kubernetes/External
プロパティ
clusterrole hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Rule.v1
rules		 clusterrole-v1-rbac-authorization-k8s-io
aggregationRule
clusterrolebinding hull.ObjectBase.v1
enabled
annotations
labels
staticName		 clusterrolebinding-v1-rbac-authorization-k8s-io
roleRef
subjects
namespace hull.ObjectBase.v1
enabled
annotations
labels
staticName		 namespace-v1-core
spec
status
persistentvolume hull.ObjectBase.v1
enabled
annotations
labels
staticName		 persistentvolumespec-v1-core
accessModes
awsElasticBlockStore
azureDisk
azureFile
capacity
cephfs
cinder
claimRef
csi
fc
flexVolume
flocker
gcePersistentDisk
glusterfs
hostPath
iscsi
local
mountOptions
nfs
nodeAffinity
persistentVolumeReclaimPolicy
photonPersistentDisk
portworxVolume
quobyte
rbd
scaleIO
storageClassName
storageos
volumeMode
vsphereVolume
role hull.ObjectBase.v1
enabled
annotations
labels
staticName

hull.Rule.v1
rules		 role-v1-rbac-authorization-k8s-io
rolebinding hull.ObjectBase.v1
enabled
annotations
labels
staticName		 rolebinding-v1-rbac-authorization-k8s-io
roleRef
subjects
serviceaccount hull.ObjectBase.v1
enabled
annotations
labels
staticName		 serviceaccount-v1-core
automountServiceAccountToken
imagePullSecrets
secrets
resourcequota hull.ObjectBase.v1
enabled
annotations
labels
staticName		 resourcequotaspec-v1-core
hard
scopeSelector
scopes
networkpolicy hull.ObjectBase.v1
enabled
annotations
labels
staticName		 networkpolicyspec-v1-networking-k8s-io
egress
ingress
podSelector
policyTypes

他のAPI

HULL
オブジェクトタイプ
HULL
プロパティ		Kubernetes/External
プロパティ
servicemonitor hull.ObjectBase.v1
enabled
annotations
labels
staticName		 ServiceMonitor CRD
spec

Testing and installing a HULL based chart

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.

Testing a HULL based chart

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>

Install or upgrade a release:

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>

First Examples

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.

Minimal Example

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 : []

Advanced Example

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:

  • hierarchical metadata handling
  • default RBAC setup of objects
  • dynamic naming mechanism
  • 変換
  • easy inclusion of ConfigMaps and/or Secrets 
 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_configmap

Read the additional documentation in the documentation folder on how to utilize the features of the HULL library to the full effect.

拡大する
追加情報
関連アプリ
おすすめ
関連情報 すべて