次の方法で共有


Helm 要件の概要

Helm は、アプリケーション ライフサイクル管理をシンプル化するのに役立つ Kubernetes 用パッケージ マネージャーです。 Helm のパッケージは、"チャート" と呼ばれ、YAML 構成ファイルとテンプレート ファイルから構成されます。 Helm の操作を実行すると、チャートがレンダリングされ、適切なアプリケーション ライフサイクル アクションをトリガーする Kubernetes マニフェスト ファイルが作成されます。 発行元が Azure Operator Service Manager (AOSM) との統合を最も効率的に実現するには、Helm チャートを開発する際、特定のベスト プラクティスに基づく考慮事項に従うことが推奨されます。

registryUrl と imagePullSecrets に関する考慮事項

通常は、すべての Helm チャートに registryUrl と imagePullSecrets が必要です。 最も一般的には、公開元が values.yaml にこれらのパラメーターを公開します。 AOSM は当初、これらの値が展開中に適切な Azure 値に置き換えられるように、公開元が値を厳密な方法で公開することを前提にしていました。 やがて、AOSM で必要なこれらの値の厳密な処理に、すべての公開元が簡単に準拠できるとは限らなくなりました。

  • たとえば、registryUrl と imagePullSecrets が条件文やその他の値制限の中に隠され、必ず有効になるとは限らないようなチャートがあります。
  • また、registryUrl や imagePullSecrets を、本来想定される名前付き文字列としてではなく配列として宣言しているようなチャートもあります。

公開元に対する厳密なコンプライアンス要件を軽減するために、AOSM は後に、これらの値を処理する 2 つの改良された方法を導入しました。 その 1 つ目は injectArtifactStoreDetail であり、2 つ目はクラスター レジストリです。 これら 2 つの新しい方法は、Helm パッケージ内に有効な registryUrl や imagePullSecrets の情報が含まれることを前提にしません。 これらの方法は、ポッド操作にこれらの値をネットワーク機能の代理として直接挿入します。

registryUrl と imagePullSecrets に関するメソッドの概要

この記事では、3 つの方法すべてに対応して説明しています。 公開元は、自分のネットワーク機能とユース ケースに最適なオプションを選ぶ必要があります。

レガシ。

  • registryUrl と imagePullSecrets が Helm の値と展開テンプレート内で置き換えられるようにするには、公開元が要件に準拠してパラメーター化する必要があります。
  • イメージは公開元の Azure Container Registry (ACR) 内でホストされます。

InjectArtifactStoreDetail。

  • Helm への依存を最低限に抑え、Webhook を使用して registryUrl と imagePullSecrets をポッドに直接挿入します。
  • イメージが公開元の ACR 内でホストされる点は従来どおりです。

クラスター レジストリ。

  • Helm に依存せず、Webhook を使用して registryUrl と imagePullSecrets をポッドに直接挿入します。
  • イメージは、ローカル NFO 拡張クラスター レジストリでホストされます。

Note

3 つのいずれのケースでも、AOSM は、AOSM 値を公開元がテンプレートで公開する値に置き換えます。 唯一の違いは、置き換える方法です。

レガシでの registryUrl と imagePullSecrets に関する要件

Azure Operator Service Manager (AOSM) は、Network Function Manager (NFM) サービスを使用して、コンテナー化されたネットワーク機能 (CNF) を展開します。 従来の方法では、NFM は AOSM コンテナーの registryUrl と imagePullSecrets の値をネットワーク関数 (NF) の展開中に Helm 操作に置き換えます。

従来の方法の使用

以下に示す Helm デプロイ テンプレートのサンプルでは、AOSM レガシ方式との互換性を確保するために registryPath と imagePullSecrets を公開しています。発行元にはこのような方法が推奨されます。

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: nginx-deployment 
  labels: 
    app: nginx 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      {{- if .Values.global.imagePullSecrets }} 
      imagePullSecrets: {{ toYaml .Values.global.imagePullSecrets | nindent 8 }} 
      {{- end }} 
      containers: 
      - name: contosoapp 
        image:{{ .Values.global.registryPath }}/contosoapp:1.14.2 
        ports: 
        - containerPort: 80 

以下に示す values.schema.json ファイルは、発行元が registryPath と imagePullSecretsvalue を簡単に設定して AOSM レガシ方式の要件を満たし、互換性を確保する方法の例です。

{ 
  "$schema": "http://json-schema.org/draft-07/schema#", 
  "title": "StarterSchema", 
  "type": "object", 
  "required": ["global"], 
  "properties": { 
      "global" : {
          "type": "object",
          "properties": {
              “registryPath”: {“type”: “string”}, 
              “imagePullSecrets”: {“type”: “string”}, 
          }
          "required": [ "registryPath", "imagePullSecrets" ], 
      } 
   } 
} 

以下に示す NFDVersion request payload は、発行元が registryPath と imagePullSecretsvalue の値を設定して AOSM レガシ方式との互換性を確保する方法の例です。

"registryValuesPaths": [ "global.registryPath" ], 
"imagePullSecretsValuesPaths": [ "global.imagePullSecrets" ], 

以下に示す values.yaml は、発行元が registryPath と imagePullSecretsvalue の値を設定して AOSM レガシ方式との互換性を確保する方法の例です。

global: 
   imagePullSecrets: [] 
   registryPath: “” 

Note

  • registryPath の設定値に https://oci:// などのプレフィックスは含まれていません。 Helm パッケージ内では、発行元が必要に応じてプレフィックスを定義します。
  • imagePullSecrets と registryPath は、NFDVersion のオンボード手順において指定する必要があります。

従来の方法に関するその他の考慮事項

従来の方法を使用するときは、公開元が次の推奨事項を追加で考慮する必要があります。

  • 外部レジストリへの参照を回避する
  • 手動検証を実行する
  • 静的イメージ リポジトリとタグを確保する

外部レジストリへの参照を回避する

ユーザーが外部レジストリへの参照を使用することは望ましくありません。 たとえば、deployment.yaml にハードコードされたレジストリ パスや外部レジストリ参照が含まれていると、検証でエラーになります。

手動検証を実行する

作成されたイメージとコンテナーの仕様を確認し、イメージに registryURL のプレフィックスが付いていること、imagePullSecrets に secretName が設定されていることを確認します。

 helm template --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryURL>" <release-name> <chart-name> --dry-run

OR

 helm install --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryURL>" <release-name> <chart-name> --dry-run
 kubectl create secret <secretName> regcred --docker-server=<registryURL> --dockerusername=<regusername> --docker-password=<regpassword>

静的イメージ リポジトリとタグを確保する

静的イメージ リポジトリとタグは、個々の Helm チャートに含まれている必要があります。 静的値の設定方法は以下のとおりです。

  • image 行で設定する。または、
  • values.yaml で設定し、それらの値がネットワーク機能設計バージョン (NFDV) 内で公開されないようにする。

1 つのネットワーク機能設計バージョン (NFDV) は、Helm チャートとイメージの静的な 1 セットと対応している必要があります。 チャートとイメージを更新する方法は、新しいネットワーク機能設計バージョン (NFDV) を公開することのみです。

 image: "{{ .Values.global.registryPath }}/contosoapp:1.14.2“

または

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}“
 
YAML values.yaml
image:
  repository: contosoapp
  tag: 1.14.2
 image: http://myURL/{{ .Values.image.repository }}:{{ .Values.image.tag}}

injectArtifactStoreDetails での registryUrl と imagePullSecrets に関する要件

場合によっては、サード パーティの Helm チャートが AOSM の registryURL に対する要件に完全に準拠していないことがあります。 この場合、injectArtifactStoreDetails 機能を使って、Helm パッケージのコンプライアンスが変わらないようにできます。 injectArtifactStoreDetails を有効にすると、 Webhook メソッドを使用して、ポッド操作中に適切な registryUrl と imagePullSecrets が動的に挿入されます。 これにより、Helm パッケージで構成されている値がオーバーライドされます。

injectArtifactStoreDetails メソッドの使用

injectArtifactStoreDetails を有効にするには、次の例に示すように、NF リソースの roleOverrides セクションの installOptions パラメーターを true に設定します。

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}

Note

Helm チャート パッケージには、適切に書式設定された registryURL と imagePullSecrets の値を引き続き公開する必要があります。

クラスター レジストリでの registryUrl と imagePullSecrets に関する要件

クラスター レジストリの使用については、概念のドキュメントを参照してください。

チャートの不変性制限

ファイルやディレクトリの変更は、不変性制限によって防止されます。 たとえば、不変ファイルの内容や名前を変更することはできません。 変更可能タグ (例: latest、dev、stable など) をユーザーが使用することは望ましくありません。 たとえば、deployment.yaml の .Values.image.tag に 'latest' が使用されていると、デプロイは失敗する可能性があります。

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}“

チャート CRD に関する宣言と使用の分離

更新をサポートするために、カスタム リソース定義 (CRD) の宣言と使用を分離して別々の Helm チャートにすることをおすすめします。 詳細については、method-2-separate-charts を参照してください。