コンテナアプリケーションで人気のツール「Kubernetes」は、ギリシャ語の「パイロット」または「船を操縦する人」という意味にちなんで命名されています。どんな旅でも操縦士は地図と同じくらい重要なものです。

アプリケーションのHelmchartとは操縦士の地図、つまりK8sリソースの関連セットを記述するHelm repositoryからデプロイできるファイルコレクションです。最適な方法でHelm chartを作成することができれば、Kubernatesが稼働環境でコンテナをデプロイする際に深みに嵌ることなく運用することができるでしょう。

しかし製品のデプロイ用に公開しているK8s chartを開発している時に私が見つけたように、他の方法で運用する方法もあります。プルリクエスト毎にHelmコミュニティからフィードバックをもらうことにより、コンテナの運用と更新の両方で最良の結果を得るHelm chartの実践的な活用方法を知ることができます。

コミュニティやユーザによって使用される本番環境のK8s chartを書く時に気をつけなければならないポイントを紹介します。特に気に留めておくべきことは以下のポイントです：

• どの依存関係を定義する必要があるか？
• アプリケーションは永続的な稼働が必要か？
• 機密事項と許可を通してセキュリティーをどう取り扱っていくか？
• 実行中のKubeletコンテナをどうやってコントロールするか？
• アプリケーションが稼働中でリクエストを受信できるということをどうやって確認するか？
• アプリケーションのサービスをどのように正式公開するか？
• Chartをどのようにテストするか？

これらに注意することで、実際にK8sがコンテナアプリケーションをdockにスムーズに展開してHelm chartを構成および作成するときに役立ちます。

最初のステップ

始める前にHelm chartを開発する必須手順についておさらいしましょう。

このガイドではExpress.jsを使ってMongoデータベースに2層コミットの作成、読み取り、更新、削除（CRUD）アプリケーションのデプロイを推奨する実践方法に基づいてHelm chartを作成します。

GitHubのexpress-crudにサンプルアプリケーションのソースコードを公開していますので参照ください。

Helm chartの作成

Helmクライアントのcreateコマンドを使ってHelm chartのテンプレートを作成してみましょう。

$ helm create express-crud

これでexpress-crudHelm chartのディレクトリ構造が作成されます。

開始するには、作成したChart.yamlファイルのchartメタデータを更新します。appVersion（dockerイメージタグとして使用されるアプリケーションのバージョン）、説明、バージョン（SemVer 2バージョン文字列）、ソース、メンテナーとアイコンに適切な情報を追加してください。

apiVersion: v1 appVersion: "1.0.0" description: A Helm chart for express-crud application name: express-crud version: 0.1.0 sources: -https://github.com/jainishshah17/express-mongo-crudmaintainers: - name: myaccount email: myacount@mycompany.com icon:https://github.com/mycompany17/mycompany.com/blob/master/app/public/images/logo.jpghome:https://mycompany.com/

依存関係の定義

アプリケーションに依存関係がある場合はそれらを明記するHelm chartのディレクトリにrequirements.yamlファイルを作成しなければなりません。アプリケーションはmongodbデータベースが必要なので作成するrequirements.yamlファイルの依存関係リストに明記する必要があります。

例えば以下のようにrequirements.yamlファイルに記述します：

dependencies: - name: mongodb version: 3.0.4 repository:https://kubernetes-charts.storage.googleapis.com/condition: mongodb.enabled

requirements.yamlファイル作成後はHelm chartでdependency updateコマンドを実行してください：

$ helm dep update

デプロイメントファイルの作成

Helm chartのデプロイメントファイルは\templatesサブディレクトリにあり、K8sがコンテナアプリケーションをデプロイする方法を指定しています。

また、デプロイメントファイルを開発する際に決めておくべきいくつかの重要事項があります。

DeploymentオブジェクトかStatefulSetオブジェクトか

作成するdeploymentファイルはアプリケーションがK8sを使用してDeploymentオブジェクトまたはStatefulSetオブジェクトとして管理するかどうかで違ってきます。

Deploymentオブジェクトはdeployment.yamlファイルで宣言され、kindパラメータをdeploymentとして指定するステートレスアプリケーションです。

Statefulオブジェクトは分散システムにおいて使用されるステートフルなアプリケーション用オブジェクトです。stateless.yamlファイルで宣言され、kindパラメータをstatefulとして指定します。

このアプリケーションでは状態を永続化する必要がないためdeploymentオブジェクトを使用しています。
deployment.yamlファイルはhelm createコマンドで既に作成されています。

アプリケーションのDockerイメージタグとしてAppVersionを使用します。そうすることでChart.yamlで値を変更するだけでアプリケーションの新しいバージョンでHelm chartをアップグレードできます。

image: "{{ .Values.image.repository }}:{{ default .Chart.AppVersion .Values.image.tag }}"

SecretかConfigMapか

どの資格情報や設定データをSecretとして保存して、どれをConfigMapに格納できるかを決める必要があります。

SecretとはK8sが暗号化形式で保存するパスワードなどの機密情報です。

ConfigMapはアプリケーションによって共有される可能性のある構成情報を含むファイルです。ConfigMapの情報は暗号化されていないため機密情報を含めないでください。

この例ではHelmがイメージプルsecretを使用してプライベートdockerレジストリからdockerイメージをプルできるようにします。

この手順ではリポジトリマネジャのログイン資格情報を規定するKubernatesクラスタで利用可能なsecretを持つことに依存しています。このsecretはkubectlコマンドで以下のように作成できます：

Helm chartのvalues.yamlファイルでsecret名に値を渡すことができます：

$ kubectl create secret docker-registry regsecret --docker-server=$DOCKER_REGISTRY_RUL --docker-username=$USERNAME --docker-password=$PASSWORD --docker-email=$EMAIL

Helm chartのvalues.yamlファイルでsecret名に値を渡すことができます：

imagePullSecrets: regsecret

次にこのsecretを利用してHelmがdeployment.yamlの次の行を介して码头工人レジストリにアクセスできるようにします:

{{- if .Values.imagePullSecrets }} imagePullSecrets: - name: {{ .Values.imagePullSecrets }} {{- end }}

アプリケーションで使用可能なsecretについては、その情報を直接values.yamlに追加する必要があります。

例えば事前に作成したユーザとデータベースでmongodbにアクセスするようにアプリケーションを構成するにはvalues.yamlにその情報を追加します。

mongodb:启用:真正的mongodbRootPassword: mongodbUsername: admin mongodbPassword: mongodbDatabase: test

Helm chartにデフォルトの資格情報をハードコーディングしないようにご注意ください。–set flagもしくはvalues.yamlでパスワードが提供されない場合にはlogicを使用しランダムのパスワードを生成します。

deployment.yamlの以下の行で、secretを使用してmongodbの資格情報をアプリケーションに渡します。

env: - name: DATABASE_PASSWORD valueFrom: secretKeyRef: name: {{ .Release.Name }}-mongodb key: mongodb-password

特別なInit ContainersやContainer Lifecycle Hooksを通してkubeletコンテナ実行をコントロールできます。

この例ではinitContainers仕様をdeployments.yamlに追加し、データベースが稼働するまでアプリケーションの起動をホールドします。

initContainers: - name: wait-for-db image: "{{ .Values.initContainerImage }}" command: - 'sh' - '-c' - > until nc -z -w 2 {{ .Release.Name }}-mongodb 27017 && echo mongodb ok; do sleep 2; done

Readiness ProbeとLiveness Probeの追加

多くの場合においてアプリケーションの継続的な健全性を確認するためにReadiness probeやLiveness probeを追加して確認することは適切な対処です。そうしないとアプリケーションは実行されているように見えても、呼び出しやクエリに対して反応せず失敗している場合があります。

以下のように定期的な確認をするためにprobeをdeployment.yamlファイルに追加します：

livenessProbe: httpGet: path: '/health' port: http initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 10 readinessProbe: httpGet: path: '/health' port: http initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 10

RBACサポートの追加

アプリケーションで必要な場合にはロールベースのアクセス制御 (RBAC)サポートがchartに追加されます。

ステップ1：次のコンテンツをrole.yamlファイルに追加することでロールを作成します：
ロールは単一のネームスペース内のリソースへのアクセスを許可するためにのみ使用できます。

{{- if .Values.rbac.create }} apiVersion:rbac.authorization.k8s.io/v1kind: Role metadata: labels: app: {{ template "express-crud.name" . }} chart: {{ template "express-crud.chart" . }} heritage: {{ .Release.Service }} release: {{ .Release.Name }} name: {{ template "express-crud.fullname" . }} rules: {{ toYaml .Values.rbac.role.rules }} {{- end }}

ステップ2：次のコンテンツをrolebinding.yamlファイルに追加することでRoleBindingを作成します：
ClusterRoleはロールとして同じ権限を付与できますが、cluster-scopedであるため次のアクセス権を付与するためにも使用できます：

• cluster-scopedリソース（ノードなど）
• non-resourceエンドポイント（“/healthz”など）
• すべてのネームスペースにおけるnamespacedリソース（podsなど）

{{- if .Values.rbac.create }} apiVersion:rbac.authorization.k8s.io/v1kind: RoleBinding metadata: labels: app: {{ template "express-crud.name" . }} chart: {{ template "express-crud.chart" . }} heritage: {{ .Release.Service }} release: {{ .Release.Name }} name: {{ template "express-crud.fullname" . }} subjects: - kind: ServiceAccount name: {{ template "express-crud.serviceAccountName" . }} roleRef: kind: Role apiGroup: rbac.authorization.k8s.io name: {{ template "express-crud.fullname" . }} {{- end }}

ステップ3：次のコンテンツをserviceaccount.yamlファイルに追加することでServiceAccountを作成します：

サービスアカウントはPodで実行されるプロセスIDを提供します。

{{——如果.Values.serviceAccount。创建}}apiVersion: v1 kind: ServiceAccount metadata: labels: app: {{ template "express-crud.name" . }} chart: {{ template "express-crud.chart" . }} heritage: {{ .Release.Service }} release: {{ .Release.Name }} name: {{ template "express-crud.serviceAccountName" . }} {{- end }}

ステップ4：helperテンプレートを使用してServiceAccount名を設定します。
_helpers.tplに次のコンテンツを追加することで設定します。

{{/* Create the name of the service account to use */}} {{- define "express-crud.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "express-crud.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}}

サービスの追加

次にサービスを介してアプリケーションを一般公開します。

サービスはIPアドレスを通してアプリケーション側でトラフィックを受信します。type指定することでサービスをさまざまな方法で公開できます：

次のコンテンツをservice.yamlに追加することで実現します：

apiVersion: v1 kind: Service metadata: name: {{ template "express-crud.fullname" . }} labels: app: {{ template "express-crud.name" . }} chart: {{ template "express-crud.chart" . }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} spec: type: {{ .Values.service.type }} ports: - port: {{ .Values.service.externalPort }} targetPort: http protocol: TCP name: http selector: app: {{ template "express-crud.name" . }} release: {{ .Release.Name }}

上記ではサービスのtypeについてvalues.yamlの設定を参照しています：

service: type: LoadBalancer internalPort: 3000 externalPort: 80

Values.yamlの概要

values.yamlでいろいろな設定を定義し試してみることはHelm chartをメンテナンスする上でも良いことです。

この例ではvalues.yamlファイルがどのように表示されるかを示しており、上記で説明した多くの機能に対して定義したさまざまな設定を表示しています：

# Default values for express-mongo-crud. # This is a YAML-formatted file. # Declare variables to be passed into your templates. ## Role Based Access Control ## Ref:https://kubernetes.io/docs/admin/authorization/rbac/rbac: create: true role: ## Rules to create. It follows the role specification rules: - apiGroups: - '' resources: - services - endpoints - pods verbs: - get - watch - list ## Service Account ## Ref:https://kubernetes.io/docs/admin/service-accounts-admin/## serviceAccount: create: true ## The name of the ServiceAccount to use. ## If not set and create is true, a name is generated using the fullname template name: ## Configuration values for the mongodb dependency ## ref:https://github.com/kubernetes/charts/blob/master/stable/mongodb/README.md## mongodb: enabled: true image: tag: 3.6.3 pullPolicy: IfNotPresent persistence: size: 50Gi # resources: # requests: # memory: "12Gi" # cpu: "200m" # limits: # memory: "12Gi" # cpu: "2" ## Make sure the --wiredTigerCacheSizeGB is no more than half the memory limit! ## This is critical to protect against OOMKill by Kubernetes! mongodbExtraFlags: - "--wiredTigerCacheSizeGB=1" mongodbRootPassword: mongodbUsername: admin mongodbPassword: mongodbDatabase: test # livenessProbe: # initialDelaySeconds: 60 # periodSeconds: 10 # readinessProbe: # initialDelaySeconds: 30 # periodSeconds: 30 ingress: enabled: false annotations: {} #kubernetes.io/ingress.class: nginx #kubernetes.io/tls-acme: "true" path: / hosts: - chart-example.local tls: [] # - secretName: chart-example-tls # hosts: # - chart-example.local initContainerImage: "alpine:3.6" imagePullSecrets: replicaCount: 1 image: repository: jainishshah17/express-mongo-crud # tag: 1.0.1 pullPolicy: IfNotPresent service: type: LoadBalancer internalPort: 3000 externalPort: 80 resources: {} # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'. # limits: # cpu: 100m # memory: 128Mi # requests: # cpu: 100m # memory: 128Mi nodeSelector: {} tolerations: [] affinity: {}

Helm Chartのテストとインストール

Helm lintコマンドを使用してHelm chartをテストすることは非常に重要です。

$ helm lint ./ ## Output ==> Linting ./ Lint OK 1 chart(s) linted, no failures

Helminstallコマンドを使用してKubernetesのhelm chartを使ったアプリケーションをデプロイします。

$ helm install --name test1 ./ ## Output NAME: test1 LAST DEPLOYED: Sat Sep 15 09:36:23 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE test1-mongodb 1 1 1 0 0s ==> v1beta2/Deployment test1-express-crud 1 1 1 0 0s ==> v1/Secret NAME TYPE DATA AGE test1-mongodb Opaque 2 0s ==> v1/PersistentVolumeClaim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE test1-mongodb Pending standard 0s ==> v1/ServiceAccount NAME SECRETS AGE test1-express-crud 1 0s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE test1-mongodb ClusterIP 10.19.248.205 27017/TCP 0s test1-express-crud LoadBalancer 10.19.254.169 80:31994/TCP 0s ==> v1/Role NAME AGE test1-express-crud 0s ==> v1/RoleBinding NAME AGE test1-express-crud 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE test1-mongodb-67b6697449-tppk5 0/1 Pending 0 0s test1-express-crud-dfdbd55dc-rdk2c 0/1 Init:0/1 0 0s NOTES: 1. Get the application URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. You can watch the status of by running 'kubectl get svc -w test1-express-crud' export SERVICE_IP=$(kubectl get svc --namespace default test1-express-crud -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echohttps://$SERVICE_IP:80

上記のhelm installコマンドを実行するとロードバランサにExternal_IPが生成されます。そのIPを使ってアプリケーションを実行できます。

これは実行時にアプリケーションがどのように表示されるかを表しています：

最後に

この例からもわかるようにHelmはchartの構成と開発方法に高い柔軟性がある、非常に汎用性の高いシステムです。Helmコミュニティを活用することでHelm chartを公開して使用するプロセスが容易になり、アプリケーションを更新する際のメンテナンスがはるかに簡単になります。

このサンプルプロジェクトで完成したHelm chartはGitHubのexpress-crudリポジトリからダウンロードできますので、サンプルで機能を確認してどのように動くか理解してみてください。

Kubernetesに製品をデプロイするためのサンプルプロジェクトをもっと見つけるにはHelm chartのサンプルリポジトリを参照ください。