Helm Charts 開発の完全な例

Helm Charts 開発の完全な例

Helmの使用は比較的簡単ですが、主にgoテンプレートのせいで、Chartパッケージを自分で開発するのはまだかなり難しいです。

文法規則がユーザーフレンドリーではありません。ここでは、完全な例を使用して、Helm Chart パッケージを開発する方法を説明します。

応用

ここでは、Ghost ブログ アプリケーションを例に、完全な Helm Chart パッケージを開発する方法を説明します。 Ghost は、Node.js をベースにしたオープンソースのブログ プラットフォームです。 Helm Chart パッケージを開発する前に、最も必要なことは、独自のアプリケーションをどのように使用し、デプロイするかを知ることです。そうでなければ、対応する Chart パッケージを作成することは不可能です。

Ghost を起動する最も簡単な方法は、イメージを使用して直接起動することです。

  docker run -d --name my-ghost -p 2368: 2368 ゴースト

その後、http://localhost:2368 を通じて Ghost ブログにアクセスできるようになります。 Kubernetes クラスターに Ghost のコピーを 2 つデプロイする場合は、次のリソース マニフェスト ファイルを直接適用できます。

 # ゴースト/デプロイメント.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: ゴースト
仕様:
セレクタ:
一致ラベル:
アプリ: ゴーストアプリ
レプリカ: 2
テンプレート:
メタデータ:
ラベル:
アプリ: ゴーストアプリ
仕様:
コンテナ:
-名前: ゴーストアプリ
画像: ゴースト
ポート:
-コンテナポート: 2368
---
# ゴースト/サービス.yaml
APIバージョン: v1
種類: サービス
メタデータ:
名前: ゴースト
仕様:
タイプ: NodePort
セレクタ:
アプリ: ゴーストアプリ
ポート:
- プロトコル: TCP
ポート: 80
ターゲットポート: 2368

上記のリソース オブジェクトを kubectl 経由で適用するだけです。

  kubectl apply -f ghost/deployment。 yaml ゴースト/service。 ヤム
デプロイメント.apps/ ゴーストが作成されました
サービス/ ゴースト作成
kubectl get pod -l app= ゴーストアプリ
名前準備完了ステータス再起動年齢
ghost-dfd958cc9-4s9b9 1/ 1 ランニング0 2分54秒
ghost-dfd958cc9-84kmv 1/ 1 ランニング0 2分54秒
kubectl でサービスゴーストを取得
名前タイプクラスター IP 外部IP ポート年齢
ゴーストノードポート10.97.227。 160 <なし> 80:31950/ TCP 3分33秒

これで、http://:31950: 経由で Ghost にアクセスできるようになりました。

おばけ

Ghost の導入は非常に簡単なようですが、環境ごとに異なる設定を行う必要がある場合はどうすればよいでしょうか?たとえば、異なる環境 (ステージング、本番) にデプロイする場合、Kubernetes リソース マニフェスト ファイルを何度もコピーする必要がありますか?これは単なるシナリオの一つです。アプリケーションの展開が必要になるシナリオは数多くあります。この方法は維持するのが非常に困難です。このとき、ヘルムは私たちを解放することができます。

基本テンプレート

まず、新しい Helm Chart パッケージを作成します。 helm create コマンドを使用するだけです:

  ヘルム作成マイゴースト
my-ghostの作成
ツリーマイゴースト
私の幽霊
チャート.yaml
チャート
テンプレート
NOTES.txt
_helpers.tpl
デプロイメント.yaml
hpa.yaml
イングレス.yaml
サービス.yaml
サービスアカウント.yaml
テスト
テスト接続.yaml
values.yaml
3 つのディレクトリ10 個のファイル

このコマンドは、デフォルトの Helm Chart パッケージのスキャフォールディングを作成します。次の未使用ファイルを削除できます。

 テンプレート/ テスト/ テスト- connection.yaml
テンプレート/ serviceaccount.yaml
テンプレート/ ingress.yaml
テンプレート/ hpa.yaml
テンプレート/ NOTES.txt

次に、templates/deployment.yaml テンプレート ファイルを変更します。

 # テンプレート/デプロイメント.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: ゴースト
仕様:
セレクタ:
一致ラベル:
アプリ: ゴーストアプリ
レプリカ: {{ .Values.replicaCount }}
テンプレート:
メタデータ:
ラベル:
アプリ: ゴーストアプリ
仕様:
コンテナ:
-名前: ゴーストアプリ
画像: {{.Values. 画像}}
ポート:
-コンテナポート: 2368
環境:
-名前: NODE_ENV
値: {{.Values. ノード環境デフォルトは「production」です。
{{ - if .Values. url }}
-名前: URL
値: http ://{{ .Values. url }}
{{ - 終わり}}

これは、レプリカの値が ``.`Values`.`replicaCount` テンプレートに置き換えられていることを除けば、以前のリソース マニフェスト ファイルと非常によく似ています。つまり、レンダリングには replicaCount Values 値が使用されることになります。環境変数を設定して Ghost を構成することもできます。同様に、templates/service.yaml テンプレート ファイルの内容を変更します。

 # テンプレート/サービス.yaml
APIバージョン: v1
種類: サービス
メタデータ:
名前: ゴースト
仕様:
セレクタ:
アプリ: ゴーストアプリ
タイプ: {{ .Values.service.type }}
ポート:
- プロトコル: TCP
ターゲットポート: 2368
ポート: {{.Values.service.port}}
{{ - if (and (or (eq .Values.service. type "NodePort" ) (eq .Values.service. type "LoadBalancer" ) ) (not (empty .Values.service. nodePort) ) ) }}
ノードポート: {{.Values.service. ノードポート}}
{{ - そうでない場合、 eq.Values.service . 「ClusterIP」 と入力してください
ノードポート: null
{{ - 終わり}}

複数のシナリオに対応するために、ユーザーはサービス タイプをカスタマイズできます。 NodePort タイプの場合は、nodePort 値も設定できます。ただし、NodePort 型として構成されていても、ユーザーが積極的に nodePort を提供しない場合があるため、ここでの判断には注意が必要です。したがって、テンプレートでは条件付きの判断を行います。

 {{ - if ( and ( or ( eq . Values ​​. service . type "NodePort" ) ( eq . Values ​​. service . type "LoadBalancer" )) ( not ( empty . Values ​​. service . nodePort ))) }}

NodePort は、service.type が NodePort または LoadBalancer であり、service.nodePort が空でない場合にのみレンダリングされます。

次に最も重要なことは、values.yaml ファイルにデフォルトの Values 値を指定することです。以下は、私たちが提供するデフォルト値です。

 # 値.yaml
レプリカ数: 1
画像: ゴースト
node_env: プロダクション
URL: ghost.k8s.local
サービス:
タイプ: NodePort
ポート: 80

次に、 helm template コマンドを使用してテンプレート出力をレンダリングします。

  helm テンプレート--debug my-ghost
install.go:178: [デバッグ] 元のチャートバージョン: ""
install.go:195: [デバッグ] チャートパス: /Users/ych/devs/workspace/yidianzhishi/course/k8strain3/content/helm/manifests/ my-ghost

---
# ソース: my-ghost/templates/service.yaml
APIバージョン: v1
種類: サービス
メタデータ:
名前: ゴースト
仕様:
セレクタ:
アプリ: ゴーストアプリ
タイプ: NodePort
ポート:
- プロトコル: TCP
ターゲットポート: 2368
ポート: 80
---
# ソース: my-ghost/templates/deployment.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: ゴースト
仕様:
セレクタ:
一致ラベル:
アプリ: ゴーストアプリ
レプリカ: 1
テンプレート:
メタデータ:
ラベル:
アプリ: ゴーストアプリ
仕様:
コンテナ:
-名前: ゴーストアプリ
画像: ゴースト
ポート:
-コンテナポート: 2368
環境:
-名前: NODE_ENV
価値: 生産
-名前: URL
値: http : //ghost.k8s.local

上記のレンダリング結果は基本的に上記のリソース マニフェスト ファイルと同じですが、環境変数やサービス公開方法などを制御できるなど、柔軟性が向上しています。

命名テンプレート

Helm Charts テンプレートを使用して Ghost をレンダリングおよびインストールできるようになりましたが、上記のテンプレートにはまだ改善できる領域が数多くあります。たとえば、リソース オブジェクトの名前は固定されているため、同じ名前空間に複数のアプリケーションをインストールすることはできません。したがって、通常は、リソース オブジェクトの名前をチャート名またはリリース名に従って置き換えます。

上記で作成したデフォルトのテンプレートには、名前とタグに関連するいくつかの命名テンプレートを含む _helpers.tpl ファイルが含まれています。直接使用することができます。デフォルトで生成される既存の命名テンプレートは次のとおりです。

 {{ /*
チャートの名前を展開します。
*/ }}
{{ - 「my-ghost.name」 を定義します- }}
{{ - デフォルト.Chart. 名前.値. 名前オーバーライド| 切り詰め 63 | トリムサフィックス"-" }}
{{ - 終わり}}
{{ /*
デフォルトの完全修飾アプリ名を作成します。
一部の Kubernetes 名フィールドは 63 文字に制限されているため (DNS 命名仕様により)、63 文字で切り捨てます。
リリース名にチャート名が含まれている場合は、それがフルネームとして使用されます。
*/ }}
{{ - 「my-ghost.fullname」 を定義します- }}
{{ - if .Values. フルネームオーバーライド}}
{{ - .値。 フルネームオーバーライド| 切り詰め 63 | トリムサフィックス"-" }}
{{ - それ以外}}
{{ - $name := default .Chart. 名前.値. 名前オーバーライド}}
{{ - $name が含まれている場合。Release。 名前}}
{{ - 。リリース。 名前| 切り詰め 63 | トリムサフィックス"-" }}
{{ - それ以外}}
{{ - printf "%s-%s" .リリース。 名前$name | 切り詰め 63 | トリムサフィックス"-" }}
{{ - 終わり}}
{{ - 終わり}}
{{ - 終わり}}
{{ /*
チャート ラベルで使用されるチャート名とバージョンを作成します。
*/ }}
{{ - 「my-ghost.chart」 を定義- }}
{{ - printf "%s-%s" .チャート。 名前.チャート. バージョン| 「+」 「_」 を置き換えます| 切り詰め 63 | トリムサフィックス"-" }}
{{ - 終わり}}
{{ /*
一般的なラベル
*/ }}
{{ - 「my-ghost.labels」 を定義- }}
helm.sh/chart: {{ "my-ghost.chart" を含めます。 }}
{{ "my-ghost.selectorLabels" を含めます。 }}
{{ - if .Chart. アプリバージョン}}
app.kubernetes.io/バージョン: {{ .Chart. アプリバージョン| 引用}}
{{ - 終わり}}
app.kubernetes.io/ 管理者: {{ .Release. サービス}}
{{ - 終わり}}
{{ /*
セレクタラベル
*/ }}
{{ - 「my-ghost.selectorLabels」 を定義します- }}
app.kubernetes.io/name: {{ "my-ghost.name" を含めます。 }}
app.kubernetes.io/instance: {{ .Release. 名前}}
{{ - 終わり}}

次に、デプロイメントの名前とタグを置き換えます。

 # テンプレート/デプロイメント.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: {{ template "my-ghost.fullname" . }}
ラベル:
{{ "my-ghost.labels" を含めます| インデント 4 }}
仕様:
セレクタ:
一致ラベル:
{{ "my-ghost.selectorLabels" を含めます| インデント 6 }}
レプリカ: {{ .Values.replicaCount }}
テンプレート:
メタデータ:
ラベル:
{{ "my-ghost.selectorLabels" を含めます| インデント 8 }}
仕様:
# その他の仕様...

デプロイメントにラベル タグを追加します。また、labelSelector を置き換えるには、命名テンプレート my-ghost.selectorLabels を使用します。サービスにも対応する変更を加えます。

 APIバージョン: v1
種類: サービス
メタデータ:
名前: {{ template "my-ghost.fullname" . }}
ラベル:
{{ "my-ghost.labels" を含めます| インデント 4 }}
仕様:
セレクタ:
{{ "my-ghost.selectorLabels" を含めます| インデント 4 }}
タイプ: {{ .Values.service.type }}
# その他の仕様...

ここで、Helm テンプレート レンダリングを使用して結果が正しいことを確認できます。

  helm テンプレート--debug my-ghost
install.go:178: [デバッグ] 元のチャートバージョン: ""
install.go:195: [デバッグ] チャートパス: /Users/ych/devs/workspace/yidianzhishi/course/k8strain3/content/helm/manifests/ my-ghost

---
# ソース: my-ghost/templates/service.yaml
APIバージョン: v1
種類: サービス
メタデータ:
名前: リリース名-私のゴースト
ラベル:
helm.sh/chart: my-ghost-0 .1。 0
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
app.kubernetes.io/バージョン: "1.16.0"
app.kubernetes.io/ 管理者: Helm
仕様:
セレクタ:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
タイプ: NodePort
ポート:
- プロトコル: TCP
ターゲットポート: 2368
ポート: 80
---
# ソース: my-ghost/templates/deployment.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: リリース名-私のゴースト
ラベル:
helm.sh/chart: my-ghost-0 .1。 0
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
app.kubernetes.io/バージョン: "1.16.0"
app.kubernetes.io/ 管理者: Helm
仕様:
セレクタ:
一致ラベル:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
レプリカ: 1
テンプレート:
メタデータ:
ラベル:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
仕様:
コンテナ:
-名前: ゴーストアプリ
画像: ゴースト
ポート:
-コンテナポート: 2368
環境:
-名前: NODE_ENV
価値: 生産
-名前: URL
値: http : //ghost.k8s.local

バージョンの互換性

Kubernetes のバージョンは非常に急速に変更されるため、Chart パッケージを開発する際には、Kubernetes のさまざまなバージョンとの互換性を考慮する必要があります。最も明白なのは、Ingress リソース バージョンです。 Kubernetes はバージョン 1.19 で Ingress リソース用の新しい API (networking.k8s.io/v1) を導入しました。これは基本的に以前の networking.k8s.io/v1beta1 ベータ版と同じですが、使用方法は以前の extensions/v1beta1 バージョンとは大きく異なります。リソース オブジェクトのプロパティには一定の違いがあります。そのため、異なるバージョンとの互換性を保つためには、テンプレート内の Ingress オブジェクトに対して互換性のある処理を行う必要があります。

リソース オブジェクト形式の新しいバージョンは次のとおりです。

 APIバージョン: networking.k8s.io/ v1
種類: イングレス
メタデータ:
名前: 最小侵入
注釈:
nginx.ingress.kubernetes.io/ を書き換え-target : /
仕様:
イングレスクラス名: nginx
ルール:
- http :
パス:
-パス: / testpath
パスタイプ: プレフィックス
バックエンド:
サービス:
名前: テスト
ポート:
番号: 80

旧バージョンのリソース オブジェクト形式は次のとおりです。

 apiバージョン: extensions/ v1beta1
種類: イングレス
メタデータ:
名前: 最小侵入
注釈:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ を書き換え-target : /
仕様:
ルール:
- http :
パス:
-パス: / testpath
バックエンド:
サービス名: テスト
サービスポート: 80

次に、Ghost 用の Ingress テンプレートを追加しましょう。新しいテンプレート ファイル templates/ingress.yaml を作成し、Ingress テンプレートの v1 バージョンを追加します。

 APIバージョン: networking.k8s.io/ v1
種類: イングレス
メタデータ:
名前: ゴースト
仕様:
イングレスクラス名: nginx
ルール:
-ホスト: ghost.k8s.local
http://www.google.com/dp ...
パス:
-パス:​​ /
パスタイプ: プレフィックス
バックエンド:
サービス:
名前: ゴースト
ポート:
番号: 80

次に、名前とサービス名をテンプレート パラメータに置き換えます。

 apiバージョン: ネットワークk8sio / v1
種類: イングレス
メタデータ:
名前: {{ template "my-ghost.fullname" . }}
ラベル:
{{ "my-ghost.labels" を含めます| インデント4 }}
仕様:
イングレスクラス名: nginx
ルール:
- ホスト: {{ 。 価値観url }}
http://www.google.com/dp ...
パス:
- パス/
パスタイプ: プレフィックス
バックエンド:
サービス
名前: {{ template "my-ghost.fullname" . }}
ポート:
番号: {{ 。 価値観サービスポート}}

次に、他のバージョン形式との互換性を確保しましょう。ここでは Capabilities オブジェクトを使用する必要があります。 Chart パッケージの _helpers.tpl ファイルに、クラスターのバージョンまたは API を決定するためのいくつかの命名テンプレートを追加します。

 {{ /* KubeVersion をオーバーライドできるようにします。 */ }}
{{ - 「my-ghost.kubeVersion」 を定義します- }}
{{ - デフォルト.Capabilities.KubeVersion. バージョン.Values. kubeVersionOverride - }}
{{ - 終わり -
{{ /* Ingress API バージョンを取得 */ }}
{{ - "my-ghost.ingress.apiVersion" を定義します- }}
{{ - if and ( .Capabilities.APIVersions. Has "networking.k8s.io/v1" ) (semverCompare ">= 1.19-0" (include "my-ghost.kubeVersion" . ) ) - }}
{{ - "networking.k8s.io/v1" を印刷- }}
{{ - そうでなければ.Capabilities.APIVersions. 「networking.k8s.io/v1beta1」 があります- }}
{{ - "networking.k8s.io/v1beta1" を印刷- }}
{{ - それ以外 - }}
{{ - "extensions/v1beta1" を印刷- }}
{{ - 終わり - }}
{{ - 終わり - }}
{{ /* Ingress の安定性をチェック */ }}
{{ - "my-ghost.ingress.isStable" を定義します- }}
{{ - eq (include "my-ghost.ingress.apiVersion" . ) "networking.k8s.io/v1" - }}
{{ - 終わり - }}
{{ /* Ingress が pathType をサポートしているかどうか確認する */ }}
{{ /* pathType は Kubernetes 1.18 で networking.k8s.io/v1beta1 に追加されました */ }}
{{ - 「my-ghost.ingress.supportsPathType」 を定義します- }}
{{ - または(eq (include "my-ghost.ingress.isStable" . ) "true" ) (および(eq (include "my-ghost.ingress.apiVersion" . ) "networking.k8s.io/v1beta1" ) (semverCompare ">= 1.18-0" (include "my-ghost.kubeVersion" . ) ) ) - }}
{{ - 終わり - }}

上記では、使用すべき APIVersion を決定するために .Capabilities.APIVersions.Has を使用しています。バージョンがnetworking.k8s.io/v1の場合、isStableとして定義されます。さらに、バージョンに基づいて pathType 属性をサポートする必要があるかどうかも判断します。次に、Ingress オブジェクト テンプレートで、上で定義した命名テンプレートを使用して、以下に示すように、使用する属性を決定できます。

 {{ - if .Values.ingress. 有効}}
{{ - $apiIsStable := eq (include "my-ghost.ingress.isStable" . ) "true" - }}
{{ - $ingressSupportsPathType : = (include "my-ghost.ingress.supportsPathType" . ) "true" と等しい- }}
apiVersion: {{ include "my-ghost.ingress.apiVersion" . }}
種類: イングレス
メタデータ:
名前: {{ template "my-ghost.fullname" . }}
注釈:
nginx.ingress.kubernetes.io/ ssl -redirect : "false"
{{ - if および.Values.ingress. ingressClass ( $apiIsStable ではない) }}
kubernetes.io/ingress.class: {{.Values.ingress. イングレスクラス}}
{{ - 終わり}}
ラベル:
{{ - "my-ghost.labels" を含めます| ニンデント4
仕様:
{{ - if および.Values.ingress. イングレスクラス$apiIsStable }}
ingressClassName: {{.Values.ingress. イングレスクラス}}
{{ - 終わり}}
ルール:
{{ -でない場合( .Values. url) }}
-ホスト: {{.Values. url }}
http://www.google.com/dp ...
{{ - それ以外}}
- http :
{{ - 終わり}}
パス:
-パス:​​ /
{{ - $ingressSupportsPathType の場合}}
パスタイプ: プレフィックス
{{ - 終わり}}
バックエンド:
{{ - $apiIsStable の場合}}
サービス:
名前: {{ template "my-ghost.fullname" . }}
ポート:
番号: { { .Values.service.port }}
{{ - それ以外}}
サービス名: {{ template "my-ghost.fullname" . }}
サービスポート: {{.Values.service.port}}
{{ - 終わり}}
{{ - 終わり}}

一部のシナリオではサービスを公開するために Ingress は必要ないため、最初に ingress.enabled プロパティを使用してレンダリングが必要かどうかを制御し、次に現在のクラスターが API の安定したバージョンであるかどうかを示す $apiIsStable 変数を定義します。次に、この変数に基づいてさまざまな属性をレンダリングする必要があります。たとえば、ingressClass の場合、API の安定バージョンであれば spec.ingressClassName で指定され、それ以外の場合は kubernetes.io/ingress.class アノテーションで指定されます。次に、values.yaml ファイルに以下に示すようにデフォルトの Ingress 構成データを追加します。

進入:
有効: true
イングレスクラス: nginx

ここで、Helm Chart テンプレートを再度レンダリングして、リソース インベントリ データを検証します。

  helm テンプレート--debug my-ghost
install.go:178: [デバッグ] 元のチャートバージョン: ""
install.go:195: [デバッグ] チャートパス: /Users/ych/devs/workspace/yidianzhishi/course/k8strain3/content/helm/manifests/ my-ghost

---
# ソース: my-ghost/templates/service.yaml
APIバージョン: v1
種類: サービス
メタデータ:
名前: リリース名-私のゴースト
ラベル:
helm.sh/chart: my-ghost-0 .1。 0
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
app.kubernetes.io/バージョン: "1.16.0"
app.kubernetes.io/ 管理者: Helm
仕様:
セレクタ:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
タイプ: NodePort
ポート:
- プロトコル: TCP
ターゲットポート: 2368
ポート: 80
---
# ソース: my-ghost/templates/deployment.yaml
APIバージョン: アプリ/ v1
種類: デプロイメント
メタデータ:
名前: リリース名-私のゴースト
ラベル:
helm.sh/chart: my-ghost-0 .1。 0
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
app.kubernetes.io/バージョン: "1.16.0"
app.kubernetes.io/ 管理者: Helm
仕様:
セレクタ:
一致ラベル:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
レプリカ: 1
テンプレート:
メタデータ:
ラベル:
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
仕様:
コンテナ:
-名前: ゴーストアプリ
画像: ゴースト
ポート:
-コンテナポート: 2368
環境:
-名前: NODE_ENV
価値: 生産
-名前: URL
値: http : //ghost.k8s.local
---
# ソース: my-ghost/templates/ingress.yaml
APIバージョン: networking.k8s.io/ v1
種類: イングレス
メタデータ:
名前: リリース名-私のゴースト
注釈:
nginx.ingress.kubernetes.io/ ssl -redirect : "false"
ラベル:
helm.sh/chart: my-ghost-0 .1。 0
app.kubernetes.io/名前: my-ghost
app.kubernetes.io/インスタンス: リリース名
app.kubernetes.io/バージョン: "1.16.0"
app.kubernetes.io/ 管理者: Helm
仕様:
イングレスクラス名: nginx
ルール:
-ホスト: ghost.k8s.local
http://www.google.com/dp ...
パス:
-パス:​​ /
パスタイプ: プレフィックス
バックエンド:
サービス:
名前: リリース名-私のゴースト
ポート:
番号: 80

上記のリソース リストから、期待される要件を満たしていることがわかります。インストールして結果をテストできます:

  helm アップグレード--install my-ghost ./ my-ghost -n デフォルト
リリース「my-ghost」は存在しません。今インストールしています
名前: my-ghost
最終デプロイ日: 2022年3月17日(木) 13:11:15
名前空間: デフォルト
ステータス: 展開済み
改訂: 1
テストスイート: なし
helm ls -n デフォルト
名前名前空間リビジョン更新ステータスチャートアプリ バージョン
my-ghost デフォルト1 2022-03-17 13:11:15。 79828 + 0800 CSTmy-ghost-0.1 がデプロイされました0 1.16. 0
kubectl ポッドを取得 -n デフォルト
名前準備完了ステータス再起動年齢
my-ghost-7cf7fb6484-75hkk 1/ 1 実行中0 3分9秒
kubectl get svc -n デフォルト
名前タイプクラスター IP 外部IP ポート年齢
Kubernetes クラスターIP 10.96.0。 1 <なし> 443/ TCP 142d
my-ghost ノードポート10.108.125。 187 <なし> 80:32433/ TCP 3分20秒
kubectl get ingress -n デフォルト
名前クラスホストアドレスポート年齢
my-ghost nginx ghost.k8s。 ローカル192.168.31。 31 80 3分32秒

Ghost は正常にデプロイされ、ドメイン名 http://ghost.k8s.local を通じてアクセスできます。

おばけ

持続性

上記で使用した Ghost イメージはデフォルトで SQLite データベースを使用するため、データを永続化することが非常に重要です。もちろん、このスイッチをユーザーに選択させる必要があります。 templates/deployment.yaml テンプレート ファイルを変更し、ボリューム関連の構成を追加します。

 # その他の仕様...
仕様:
ボリューム:
-名前: ゴーストデータ
{{ - if .Values.persistence. 有効}}
永続ボリュームクレーム:
クレーム名: {{.Values.persistence. 既存のクレーム| デフォルト( 「my-ghost.fullname」を含めます。 ) }}
{{ - それ以外}}
空ディレクトリ: {}
{{ 終わり}}
コンテナ:
-名前: ゴーストアプリ
画像: {{.Values. 画像}}
ボリュームマウント:
-名前: ゴーストデータ
マウントパス: /var/lib/ghost/ コンテンツ
# その他の仕様...

ここでは、persistence.enabled を使用して、永続データを有効にする必要があるかどうかを判断します。有効になっている場合は、ユーザーが既存の PVC オブジェクトを直接提供するかどうかによって異なります。そうでない場合は、適切な PVC オブジェクトを自分で作成する必要があります。永続性が必要ない場合は、emptyDir:{} を使用して templates/pvc.yaml テンプレートを追加します。内容は以下のとおりです。

 {{ - if および.Values.persistence. 有効( .Values.persistence. existingClaim ではない) }}
種類: PersistentVolumeClaim
APIバージョン: v1
メタデータ:
名前: {{ template "my-ghost.fullname" . }}
ラベル:
{{ - "my-ghost.labels" を含めます| ニンデント4
仕様:
{{ - if .Values.persistence.storageClass }}
ストレージクラス名: {{.Values.persistence. ストレージクラス| 引用}}
{{ - 終わり}}
アクセスモード:
- {{.Values.persistence. アクセスモード| 引用}}
リソース:
リクエスト:
ストレージ: {{.Values.persistence. サイズ| 引用}}
{{ - 終わり - }}

アクセス モード、ストレージ容量、StorageClass、既存の PVC はすべて値を通じて指定されるため、柔軟性が向上します。対応する values.yaml 構成部分では、デフォルトの構成を指定できます。

 ## データの永続性を有効にするためにPVCを使用するかどうか
持続性:
有効: true
## storageClassを使用するかどうか。該当しない場合は設定してください
# ストレージクラス: "xxx"
##
## 既存のPVCオブジェクトを使用する場合は、それを以下の existingClaim 変数に直接渡します。
# 既存の請求: あなたの請求
accessMode: ReadWriteOnce # アクセスモード
サイズ: 1Gi # ストレージ容量

カスタムメイド

上記の主な要件に加えて、いくつかの追加のカスタマイズ要件があります。たとえば、ユーザーは更新戦略を構成したいと考えています。更新戦略は静的ではないため、以前のものとは異なります。新しい関数 toYaml を使用する必要があります。

 {{ - if .Values. 更新戦略}}
戦略: {{ toYaml .Values. アップデート戦略| ニンデント4
{{ - 終わり}}

これは、updateStrategy Values の値を YAML 形式に変換し、4 つのスペースを保持することを意味します。次に、nodeSelector、tolerance、affinity などを追加するかどうかなどの他の構成を追加します。ここでは、次に示すように、toYaml 関数を使用してスペースを制御します。

 {{ - if .Values. ノードセレクタ}}
ノードセレクター: {{ - toYaml .Values. ノードセレクター| ニンデント8 }}
{{ - 終わり - }}
{{ - .Values を使用親和性
アフィニティ: {{ - toYaml . | ニンデント8 }}
{{ - 終わり}}
{{ - .Values を使用許容範囲}}
許容範囲: {{ - toYaml . | ニンデント8 }}
{{ - 終わり}}

次のステップは、もちろんイメージの構成です。プライベートリポジトリの場合は、imagePullSecrets も指定する必要があります。

 { { - if .Values.image.pullSecrets }}
イメージプルシークレット:
{{ - 範囲.Values.image. プルシークレット}}
-名前:``.``
{{ - 終わり}}
{{ - 終わり}}
コンテナ:
-名前: ゴースト
画像: {{ printf "%s:%s" .Values.image. 名前.Values.image. タグ}}
imagePullPolicy: {{.Values.image. プルポリシー| 引用}}
ポート:
-コンテナポート: 2368

対応する値は次のとおりです。

画像:
名前: ゴースト
タグ: 最新
プルポリシー: IfNotPresent
## プライベートリポジトリの場合は、imagePullSecretsを指定する必要があります
# プルシークレット:
# - レジストリキーシークレット名

次はリソース宣言です。ここでは、デフォルトのリソース値を定義し、toYaml 関数を使用してスペースを制御します。

リソース:
{{ toYaml .Values. リソース| インデント 10 }}

最後に、ヘルスチェックの部分です。これまで livenessProbe を実行したことはありませんが、チャート テンプレートを開発する際には、できるだけこれを考慮する必要があります。ここでは、生存性、読み取り可能性、起動の 3 つのプローブを追加します。また、livenessProbe.enabled、readinessProbe.enabled、startupProbe.enabled の 3 つの値に基づいてプローブを追加するかどうかを決定します。プローブに対応するパラメータも値を通じて構成されます。

 {{ - if .Values.startupProbe. 有効}}
スタートアッププローブ:
httpGet:
パス: /
ポート: 2368
初期遅延秒数: {{.Values.startupProbe. 初期遅延秒数}}
期間秒数: {{.Values.startupProbe. 期間秒数}}
タイムアウト秒数: {{.Values.startupProbe. タイムアウト秒数}}
失敗しきい値: {{.Values.startupProbe. 失敗しきい値}}
成功しきい値: {{.Values.startupProbe. 成功しきい値}}
{{ - 終わり}}
{{ - if .Values.livenessProbe. 有効}}
ライブネスプローブ:
httpGet:
パス: /
ポート: 2368
InitialDelaySeconds: {{ .Values.livenessProbe. 初期遅延秒数}}
periodSeconds: {{ .Values.livenessProbe. 期間秒数}}
timeoutSeconds: {{ .Values.livenessProbe. タイムアウト秒数}}
失敗しきい値: {{.Values.livenessProbe. 失敗しきい値}}
successThreshold: {{ .Values.livenessProbe. 成功しきい値}}
{{ - 終わり}}
{{ - if .Values.readinessProbe. 有効}}
準備プローブ:
httpGet:
パス: /
ポート: 2368
初期遅延秒数: {{.Values.readinessProbe. 初期遅延秒数}}
期間秒数: {{.Values.readinessProbe. 期間秒数}}
タイムアウト秒数: {{.Values.readinessProbe. タイムアウト秒数}}
失敗しきい値: {{.Values.readinessProbe. 失敗しきい値}}
成功しきい値: {{.Values.readinessProbe. 成功しきい値}}
{{ - 終わり}}

デフォルトの values.yaml ファイルは次のようになります。

レプリカ数: 1
画像:
名前: ゴースト
タグ: 最新
プルポリシー: IfNotPresent
node_env: プロダクション
URL: ghost.k8s.local
サービス:
タイプ: ClusterIP
ポート: 80
進入:
有効: true
イングレスクラス: nginx
## データの永続性を有効にするためにPVCを使用するかどうか
持続性:
有効: true
## storageClassを使用するかどうか。該当しない場合は設定してください
# ストレージクラス: "xxx"
##
## 既存のPVCオブジェクトを使用する場合は、それを以下の existingClaim 変数に直接渡します。
# 既存の請求: あなたの請求
accessMode: ReadWriteOnce # アクセスモード
サイズ: 1Gi # ストレージ容量
ノードセレクタ: {}
親和性: {}
許容範囲: {}
リソース: {}
スタートアッププローブ:
有効: false
ライブネスプローブ:
有効: false
準備プローブ:
有効: false

それではリリースを更新しましょう:

  helm アップグレード--install my-ghost ./ my-ghost -n デフォルト
リリース「my-ghost」がアップグレードされましたヘルミングを楽しんでください
名前: my-ghost
最終デプロイ日: 2022年3月17日(木) 16:03:02
名前空間: デフォルト
ステータス: 展開済み
改訂: 2
テストスイート: なし
helm ls -n デフォルト
名前名前空間リビジョン更新ステータスチャートアプリ バージョン
my-ghost デフォルト2 2022-03-17 16:05:07。 123349 + 0800 CSTmy-ghost-0.1 がデプロイされました0 1.16. 0
kubectl ポッドを取得 -n デフォルト
名前準備完了ステータス再起動年齢
my-ghost-6dbc455fc7-cmm4p 1/ 1 ランニング0 2分42秒
kubectl get pvc -n デフォルト
名前ステータスボリューム容量アクセスモードストレージクラス 年齢
my-ghost バウンドpvc-2f0b7d5a-04d4-4331-848b-af21edce673e 1Gi RWO nfs-client 4m59s
kubectl get ingress -n デフォルト
名前クラスホストアドレスポート年齢
my-ghost nginx ghost.k8s。 ローカル192.168.31。 31 80 3時間24分

この時点で、このシンプルな Helm Charts パッケージの開発は基本的に完了しました。もちろん、将来的には新たな要件が発生する可能性があり、反復と最適化を継続する必要があります。

共有チャート

Helm Charts パッケージが開発されました。他の人が私たちのパッケージを使いたい場合、それを共有する必要があります。 Chart リポジトリを通じて共有できます。 Helm Charts は、リモート リポジトリまたはローカル環境/リポジトリで使用できます。リモート リポジトリは、Bitnami Charts などのパブリック リポジトリ、または Google Cloud Storage や GitHub などのホストされたリポジトリにすることができます。デモンストレーションの便宜上、ここでは GitHub を使用して Charts パッケージをホストします。

GitHub Pages を使用して Charts リポジトリを作成できます。 GitHub では、静的 Web ページを 2 つの異なる方法で提供できます。

  • docs/ ディレクトリの内容は、プロジェクトを構成することによって提供されます。
  • 特定のブランチを提供するようにプロジェクトを構成します。

ここでは2番目の方法を採用します。まず、GitHub にコード リポジトリを作成します: https://github.com/cnych/helm101、上記で作成した my-ghost パッケージをリポジトリの charts ディレクトリに送信し、チャート パッケージをパッケージ化します:

  helm パッケージチャート/ my-ghost
チャートを正常にパッケージ化し、次の場所に保存しました: /Users/ych/devs/workspace/yidianzhishi/course/k8strain3/content/helm/manifests/helm101/ my-ghost-0 .1.0.tgz

パッケージ化された圧縮パッケージを別のディレクトリ repo/stable に置くことができます。現在、倉庫の構造は次のようになっています。

  

ライセンス
README.md
チャート
マイゴースト
チャート。 ロック
Chart.yaml
チャート
テンプレート
_ヘルパー。 tpl
デプロイメント.yaml
ingress.yaml
pvc.yaml
サービス.yaml
テスト
values.yaml
└─── レポ
└─── 安定
└───my -ghost- 0.1.0 . tgz

インデックス ファイルを生成するには、次のコマンドを実行します。

  helm リポジトリインデックスrepo/ stable --url https://raw.githubusercontent.com/cnych/helm101/main/repo/ stable

上記のコマンドを実行すると、以下に示すように、repo/stable ディレクトリに index.yaml ファイルが生成されます。

 APIバージョン: v1
エントリー:
私の幽霊:
- APIバージョン: v2
アプリバージョン: 1.16.0
作成日時: "2022-03-17T17:40:21.093654+08:00"
説明: Kubernetes用のHelm チャート
ダイジェスト: f6d6308d6a6cd6357ab2b952650250c2df7b2727ce84c19150531fd72732626b
名前: my-ghost
タイプ: アプリケーション
URL:
- https://raw.githubusercontent.com/cnych/helm101/main/repo/stable/my-ghost-0 .1.0.tgz
バージョン: 0.1.0
生成日時: "2022-03-17T17:40:21.090371+08:00"

index.yaml ファイルは、リポジトリを通じて Chart パッケージを取得するための鍵となります。次に、コードを GitHub にプッシュします。

  git ステータス
ブランチメイン
ブランチは'origin/main' 最新です
追跡されていないファイル:
(コミットする内容を含めるには、 「git add <file>...」を使用します)
チャート/
リポジトリ/
コミットには何も追加されていませんが、追跡されていないファイルが存在します( 追跡するには「git add」を使用します)
git commit -m "チャートとindex.yamlを追加"
[ main aae1059 ] チャートとインデックス.yamlを追加
11 ファイルが変更され、 431 個の挿入( + )
作成モード100644 チャート/ my-ghost /。 ヘルミニョレ
モード100644 チャート/ my-ghost /Chart を作成します。 ロック
作成モード100644 チャート/ my-ghost / Chart.yaml
作成モード100644 チャート/ my-ghost /templates/ _helpers.tpl
作成モード100644 charts / my-ghost /templates/deployment.yaml
作成モード100644 charts / my-ghost /templates/ ingress.yaml
作成モード100644 チャート/ my-ghost /templates/ pvc.yaml
作成モード100644 charts / my-ghost /templates/ service.yaml
モード100644 チャート/ my-ghost / values.yamlを作成します
モード100644 リポジトリ/stable/ インデックス.yamlを作成します
モード100644 リポジトリ/stable/ my-ghost-0 .1.0.tgzを作成します
git プッシュorigin メイン
オブジェクトの列挙: 18、完了。
オブジェクトのカウント100% (18 / 18) 、完了。
書き込みオブジェクト: 100% (18 / 18) 、8. 71 KiB | 2. 18 MiB /s、完了。
合計 18 (デルタ0)再利用 0 (デルタ0)
github .com:cnych/helm101 へギット
9c389a6.. aae1059 メイン - > メイン

次に、リポジトリ用に GitHub Pages を設定します。まず、ローカルに新しい gh-pages ブランチを作成します。

  git チェックアウト-b gh-pages

ルート ディレクトリに repo/stable/index.yaml ファイルのみを保持し、他のファイルは無視して、リモート リポジトリにプッシュします。

  git プッシュorigin gh-pages
オブジェクトの列挙: 2、完了。
オブジェクトのカウント100% (2/2 、完了。
オブジェクトの書き込み: 100% (2 / 2)301 バイト| 301.00 KiB /s、完了。
合計 2 (デルタ0)再利用 0 (デルタ0)
リモート:
リモート: GitHub にアクセスして、 「gh-pages」 プルリクエストを作成します:
リモート: https://github.com/cnych/helm101/pull/new/gh-pages
リモート:
github .com:cnych/helm101 へギット
* [ 新しいブランチ] gh-pages - > gh-pages

GitHub Pages ページで、gh-pages ブランチを選択します。

ページ

これで、https://cnych.github.io/helm101/ から Chart パッケージを入手できるようになりました。

次のコマンドを使用して、repo リポジトリを追加します。

  helm リポジトリに helm101 を追加しますhttps://cnych.github.io/helm101/
「helm101」リポジトリに追加されました

また、 helm search を使用してリポジトリ内の Chart パッケージを検索することもできます。これには通常、上記の my-ghost が含まれます。

  helm 検索リポジトリ helm101
名前チャートバージョンアプリバージョン説明
helm101/ my-ghost 0.1。 0 1.16. 0 Kubernetes用のHelm チャート

次に、チャート パッケージを通常どおりインストールして使用できます。

  helm をインストールmy-ghost helm101/


<<:  あらゆるシナリオでデジタルインテリジェンスを活用することで、U9cloudは従来のERPアップグレードの「ハーベスター」となりました。

>>:  CNCF は Knative プロジェクトを承認しました。これはクラウド ネイティブ エコシステムにとって何を意味するのでしょうか?

推薦する

加盟店コレクション: 香港VPS、Alipay決済

このサイトでは、香港の VPS を推奨しています。主に、国内ユーザーが購入するのに便利な Alipa...

仮想マシン保護技術についてお話しましょう

[[224947]]仮想マシンの概要いわゆる仮想マシン保護技術とは、コードを機械や人間が認識できない...

中小規模の販売業者はどのようにして独自のプラットフォームを選択するのでしょうか?

『兵法書』にはこうあります。「三十六計の中で、最善のものが最良である。」どのような戦略であっても、必...

百度の「汎懲罰的」仮説

最近、多くの初心者ウェブマスターが同じ質問をしています。「なぜ Baidu にまだ私のサイトが含まれ...

ブログにトラフィックを集める10の方法

コアヒント: ブログは一般的なウェブサイトとは大きく異なり、ブログのプロモーション方法もウェブサイト...

Baiduライブラリ外部リンク愛してると言うのは簡単じゃない

Baidu の最適化を行う国内 SEO 担当者の間では、Baidu は常に自社の製品をより大切に扱う...

CIOがマネージドクラウドサービスプロバイダーの新たなベンチマークを設定

[[335395]] IT は意図的な変革の真っ只中にあります。かつては、企業の IT 部門が主に資...

実践分析フォーラムのプロモーションで最高の結果を達成する方法

フォーラムのプロモーションのために投稿する場合、人々は通常、Tianya、Kaidi、Mop For...

Google検索結果からGoogle最適化スキルについて語る

今日、CNZZのトラフィックをチェックしていたとき、Googleに戻ってクリックしたところ、「QQシ...

天一クラウドとCDSキャピタルクラウドがクラウドゲーム「IaaS+PaaS」のワンストップソリューション構築に向けた戦略的契約を締結

近年、業界の大手企業はクラウドコンピューティングの分野で競争し、技術革新産業の配置を強化しています。...

クラウド コンピューティング監視の使用例にはどのようなものがありますか?

オンプレミスからクラウドまで、アプリケーションとネットワークのパフォーマンスをエンドツーエンドで可視...

Hostgator ホスティングは 6 か月間 $0.1 のみ

Godaddy の顧客を獲得するために、Hostgator は 6 か月間のホスティングを 0.1 ...

Baidu ウェブマスターコミュニティ情報の解釈: タイムリーなリソース収集に関する問題

Baidu Webmaster Community が昨日ひっそりと立ち上げられました。また、Bai...

高級品はオンライン化に慎重:第三者は認可を得るのに困難に直面

鄭爽インターネットに対する当初の恐怖から徐々に「オンライン化」へと移行し、高級品はこの道をゆっくりと...

SEOにおけるウェブサイトタイトル修正の実践と経験

すべての SEO チュートリアルでは、「ウェブサイトのタイトルは簡単に変更できない」と教えられます。...