前書き

Kubernetesは、最新のコンテナ化されたアプリケーションを大規模に実行するためのシステムです。 これにより、開発者はマシンのクラスター全体にアプリケーションをデプロイおよび管理できます。 また、Kubernetesは、単一インスタンスアプリケーションのセットアップの効率と信頼性を向上させるために使用できますが、マシンのグループ間でアプリケーションの複数のインスタンスを実行するように設計されています。

Kubernetesでマルチサービス展開を作成する場合、多くの開発者はhttps://helm.sh/[Helm]パッケージマネージャーを使用することを選択します。 Helmは、これらのオブジェクトの相互作用を調整するチャートとテンプレートを提供することにより、複数のKubernetesリソースを作成するプロセスを合理化します。 また、人気のあるオープンソースプロジェクト用にあらかじめパッケージ化されたチャートも提供しています。

このチュートリアルでは、Helmチャートを使用して、MongoDBデータベースを含むhttps://nodejs.org/[Node.js]アプリケーションをKubernetesクラスターにデプロイします。 https://github.com/helm/charts/tree/master/stable/mongodb-replicaset [公式Helm MongoDBレプリカセットグラフ]を使用して、https://kubernetes.io/docs/concepts/workloads/を作成します。 controllers / statefulset / [StatefulSetオブジェクト] 3つのhttps://kubernetes.io/docs/concepts/workloads/pods/pod/[Pods]で構成されるhttps://kubernetes.io/docs/concepts/services-networking/ service /#headless-services [Headless Service]、および3つのhttps://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[PersistentVolumeClaims]。 また、カスタムアプリケーションイメージを使用してマルチレプリカNode.jsアプリケーションをデプロイするチャートを作成します。 このチュートリアルで作成するセットアップは、https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for-development-with-docker-composeで説明されているコードの機能をミラーリングします[Docker Composeを使用したNode.jsアプリケーションのコンテナー化]は、ニーズに合わせて拡張可能なMongoDBデータストアを備えた復元力のあるNode.jsアプリケーションを構築するための良い出発点となります。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • 役割ベースのアクセス制御(RBAC)が有効になっているKubernetes 1.10+クラスター。 このセットアップではhttps://www.digitalocean.com/products/kubernetes/[DigitalOcean Kubernetes cluster]を使用しますが、https://www.digitalocean.com/community/tutorials/how-to-create-を自由に使用できます。 a-kubernetes-1-11-cluster-using-kubeadm-on-ubuntu-18-04 [別の方法を使用してクラスターを作成]。

  • ローカルマシンまたは開発サーバーにインストールされ、クラスターに接続するように設定されたコマンドラインツール「+ kubectl 」。 ` kubectl +`のインストールの詳細については、https://kubernetes.io/docs/tasks/tools/install-kubectl/ [公式ドキュメント]をご覧ください。

  • https://www.digitalocean.com/community/tutorials/how-to-install-software-on-のステップ1および2に概説されている指示に従って、ローカルマシンまたは開発サーバーにインストールされたHelmとクラスターにインストールされたTiller kubernetes-clusters-with-the-helm-package-manager [Helm Package Managerを使用してKubernetesクラスターにソフトウェアをインストールする方法]。

  • ローカルマシンまたは開発サーバーにインストールされているhttps://www.docker.com/[Docker]。 Ubuntu 18.04を使用している場合は、https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04 [How To]のステップ1および2に従ってください。 Ubuntu 18.04にDockerをインストールして使用する];それ以外の場合は、https://docs.docker.com/install/ [公式ドキュメント]に従って他のオペレーティングシステムへのインストールに関する情報を確認してください。 リンクされたチュートリアルのステップ2で説明されているように、必ず非ルートユーザーを `+ docker +`グループに追加してください。

  • Docker Hubアカウント。 この設定方法の概要については、Docker Hubのhttps://docs.docker.com/docker-hub/ [この概要]を参照してください。

手順1-アプリケーションの複製とパッケージ化

Kubernetesでアプリケーションを使用するには、https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [+ kubelet + agent]がイメージをプルできるようにパッケージ化する必要があります。 ただし、アプリケーションをパッケージ化する前に、アプリケーションコードでMongoDB connection URIを変更して、アプリケーションがメンバーに接続できるようにする必要があります。 Helm `+ mongodb-replicaset +`チャートで作成するレプリカセットの。

最初のステップは、https://github.com/doからhttps://github.com/do-community/node-mongo-docker-dev.git[node-mongo-docker-dev repository]を複製することです。 -community [DigitalOcean Community GitHubアカウント]。 このリポジトリには、https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for-development-with-docker-compose [Node.jsアプリケーションのコンテナ化]で説明されているセットアップのコードが含まれています。開発用Docker Compose]。MongoDBデータベースを使用したデモNode.jsアプリケーションを使用して、Docker Composeで開発環境をセットアップする方法を示します。 アプリケーション自体の詳細については、https://www.digitalocean.com/community/tutorial_series/from-containers-to-kubernetes-with-node-js [Node.jsを使用したコンテナからKubernetesへのシリーズ]を参照してください。

リポジトリを `++`というディレクトリにクローンします:

git clone https://github.com/do-community/node-mongo-docker-dev.git

`++`ディレクトリに移動します:

cd

`++`ディレクトリには、ユーザー入力で動作するサメ情報アプリケーションのファイルとディレクトリが含まれます。 コンテナを操作するために近代化されました。機密性の高い特定の構成情報がアプリケーションコードから削除され、実行時にリファクタリングされ、アプリケーションの状態がMongoDBデータベースにオフロードされました。

最新のコンテナ化されたアプリケーションの設計の詳細については、https://www.digitalocean.com/community/tutorials/architecting-applications-for-kubernetes [Kubernetesのアーキテクティングアプリケーション]およびhttps://www.digitalocean.com/を参照してください。 community / tutorials / modernizing-applications-for-kubernetes [Kubernetesの近代化アプリケーション]。

Helm `+ mongodb-replicaset +`チャートをデプロイすると、次のものが作成されます。

  • MongoDB https://docs.mongodb.com/manual/replication/ [レプリカセット]のメンバーである3つのポッドを持つStatefulSetオブジェクト。 各PodにはPersistentVolumeClaimが関連付けられており、再スケジュールの際に固定IDを維持します。

  • StatefulSetのPodで構成されるMongoDBレプリカセット。 セットには、1つのプライマリと2つのセカンダリが含まれます。 データはプライマリからセカンダリに複製され、アプリケーションデータの高可用性が維持されます。

アプリケーションがデータベースレプリカと対話するには、コード内のMongoDB接続URIにレプリカセットメンバーのホスト名とレプリカセット自体の名前の両方を含める必要があります。 したがって、これらの値をURIに含める必要があります。

データベース接続情報を指定するクローンリポジトリ内のファイルは、「+ db.js 」と呼ばれます。 ` nano +`またはお気に入りのエディターを使用して、そのファイルを開きます。

nano db.js

現在、ファイルには、実行時にデータベース接続URIで参照されるhttps://www.digitalocean.com/community/tutorials/understanding-variables-scope-hoisting-in-javascript#constants[constants]が含まれています。 これらの定数の値は、ノードのhttps://nodejs.org/api/process.html#process_process_env [+ process.env +]プロパティを使用して注入され、実行時にユーザー環境に関する情報を含むオブジェクトを返します。 アプリケーションコードで動的に値を設定することで、コードを基盤となるインフラストラクチャから切り離すことができます。これは、動的なステートレス環境で必要です。 この方法でアプリケーションコードをリファクタリングする方法の詳細については、https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for-development-with-docker-compose#step-2-を参照してください。 https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-forの%E2%80%94-configuring-your-application-to-work-with-containers [ステップ2] -development-with-docker-compose [Docker Composeを使用した開発用のNode.jsアプリケーションのコンテナ化]および関連するディスカッション(https://12factor.net/config[The 12-Factor App])。

現在、接続URIとURI文字列自体の定数は次のようになっています。

〜/ node_project / db.js

...
const {
 MONGO_USERNAME,
 MONGO_PASSWORD,
 MONGO_HOSTNAME,
 MONGO_PORT,
 MONGO_DB
} = process.env;

...

const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?authSource=admin`;
...

12FAアプローチを維持するために、レプリカインスタンスのホスト名またはレプリカセット名をこのURI文字列にハードコーディングしたくありません。 既存の + MONGO_HOSTNAME +`定数を展開して、複数のホスト名(レプリカセットのメンバー)を含めることができるため、そのままにしておきます。 ただし、レプリカセット定数をURI文字列のhttps://docs.mongodb.com/manual/reference/connection-string/#components [+ options +`セクション]に追加する必要があります。

URI定数オブジェクトと接続文字列の両方に「+ MONGO_REPLICASET +」を追加します。

〜/ node_project / db.js

...
const {
 MONGO_USERNAME,
 MONGO_PASSWORD,
 MONGO_HOSTNAME,
 MONGO_PORT,
 MONGO_DB

} = process.env;

...
const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?authSource=admin`;
...

URIのオプションセクションでhttps://docs.mongodb.com/manual/reference/connection-string/#urioption.replicaSet [+ replicaSet + option]を使用すると、レプリカセットの名前を渡すことができます。これは、 `+ MONGO_HOSTNAME +`定数で定義されたホスト名とともに、セットメンバーに接続できるようにします。

編集が終了したら、ファイルを保存して閉じます。

レプリカセットで動作するようにデータベース接続情報を変更したら、アプリケーションをパッケージ化し、https://docs.docker.com/engine/reference/commandline/build/ [+ docker build +]コマンドでイメージをビルドできます。 、Docker Hubにプッシュします。

`+ docker build `および ` -t `フラグを使用してイメージをビルドします。これにより、覚えやすい名前でイメージにタグを付けることができます。 この場合、Docker Hubのユーザー名で画像にタグを付けて、「+」または独自に選択した名前を付けます。

docker build -t / .

コマンドの「。」は、ビルドコンテキストが現在のディレクトリであることを指定します。

イメージの構築には1〜2分かかります。 完了したら、画像を確認します。

docker images

次の出力が表示されます。

OutputREPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
/   latest              56a69b4bc882        7 seconds ago       90.1MB
node                                    10-alpine           aa57b0242b33        6 days ago          71MB

次に、前提条件で作成したDocker Hubアカウントにログインします。

docker login -u

プロンプトが表示されたら、Docker Hubアカウントのパスワードを入力します。 この方法でログインすると、Docker Hubの資格情報を使用して、非ルートユーザーのホームディレクトリに `+〜/ .docker / config.json +`ファイルが作成されます。

https://docs.docker.com/engine/reference/commandline/push/[`docker push + `command]を使用して、アプリケーションイメージをDocker Hubにプッシュします。 `+`を自分のDocker Hubユーザー名に置き換えることを忘れないでください:

docker push /

これで、Kubernetesでレプリケートされたアプリケーションを実行するためにプルできるアプリケーションイメージができました。 次のステップでは、MongoDB Helmチャートで使用する特定のパラメーターを構成します。

ステップ2-MongoDBレプリカセットのシークレットを作成する

`+ stable / mongodb-replicaset +`チャートは、Secretsの使用に関してさまざまなオプションを提供します。チャート展開​​で使用するために2つ作成します。

  • レプリカセットキーファイル。レプリカセットメンバー間の共有パスワードとして機能し、他のメンバーを認証できるようにします。

  • MongoDB管理ユーザーのシークレットは、 `+ admin +`データベース上でhttps://docs.mongodb.com/manual/reference/built-in-roles/#root[root user]として作成されます。 このロールを使用すると、アプリケーションを実稼働環境にデプロイするときに、制限された権限を持つ後続のユーザーを作成できます。

これらのシークレットを配置すると、専用の値ファイルに優先パラメーター値を設定し、HelmチャートでStatefulSetオブジェクトとMongoDBレプリカセットを作成できます。

まず、キーファイルを作成しましょう。 https://www.openssl.org/docs/man1.1.1/man1/openssl.html [`+ openssl `コマンド]と ` rand +`オプションを使用して、キーファイルの756バイトのランダムな文字列を生成します。

openssl rand -base64 756 > key.txt

コマンドによって生成された出力はhttps://en.wikipedia.org/wiki/Base64[base64]でエンコードされ、均一なデータ転送が保証され、「+ key.txt 」というファイルにリダイレクトされます。 https://github.com/helm/charts/tree/master/stable/mongodb-replicaset#authentication [` mongodb-replicaset +`チャート認証ドキュメント]。 key自体は、base64セットの文字のみで構成される6〜1024文字の長さである必要があります。

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create[`kubectl create + `]でこのファイルを使用して、「+」というシークレットを作成できるようになりました。

kubectl create secret generic  --from-file=key.txt

セットアップ用に特定の名前空間を作成していないため、これにより、 + default + namespaceにSecretオブジェクトが作成されます。

シークレットが作成されたことを示す次の出力が表示されます。

Outputsecret/keyfilesecret created

`+ key.txt +`を削除します:

rm key.txt

または、ファイルを保存する場合は、https://docs.mongodb.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/#create-a-keyfile [その権限を制限して] https://git-scm.com/docs/gitignore [+ .gitignore + file]に追加して、バージョン管理から外してください。

次に、MongoDB管理ユーザーのシークレットを作成します。 最初のステップは、目的のユーザー名とパスワードをbase64に変換することです。

データベースのユーザー名を変換します。

echo -n '' | base64

出力に表示される値を書き留めます。

次に、パスワードを変換します。

echo -n '' | base64

ここの出力の値にも注意してください。

シークレットのファイルを開きます。

nano secret.yaml

次のコードをファイルに追加して、作成したエンコード値で「+ user 」と「 password +」を定義するシークレットを作成します。 ここでダミーの値を独自の*エンコードされた*ユーザー名とパスワードに置き換えてください:

〜/ node_project / secret.yaml

apiVersion: v1
kind: Secret
metadata:
 name:
data:
 user:
 password:

ここでは、 + mongodb-replicaset`チャートが期待するキー名を使用しています: + user`と + password _。 Secretオブジェクトに「++」という名前を付けましたが、好きな名前を自由に付けることができます。

編集が終了したら、ファイルを保存して閉じます。

次のコマンドでシークレットオブジェクトを作成します。

kubectl create -f secret.yaml

次の出力が表示されます。

Outputsecret/mongo-secret created

繰り返しになりますが、 `+ secret.yaml `を削除するか、パーミッションを制限して ` .gitignore +`ファイルに追加することができます。

Secretオブジェクトを作成したら、使用するパラメーター値を `+ mongodb-replicaset +`チャートで指定し、MongoDBデプロイメントを作成することに進みます。

手順3-MongoDBヘルムチャートの構成と展開の作成

Helmには、使用するチャートを含む* stable *というアクティブに維持されるリポジトリが付属しています: + mongodb-replicaset +。 作成したばかりのシークレットでこのチャートを使用するには、 `+ mongodb-values.yaml +`という設定パラメーター値を持つファイルを作成し、このファイルを使用してチャートをインストールします。

+ mongodb-values.yaml +`ファイルは、デフォルトのhttps://github.com/helm/charts/blob/master/stable/mongodb-replicaset/values.yaml [+ values.yaml `ファイル]をほぼミラーリングします。 ` mongodb-replicaset +`チャートリポジトリ。 ただし、ファイルに次の変更を加えます。

  • データベースインスタンスがhttps://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-mongod-auth[authorization enabled]で始まるように、 `+ auth `パラメーターを ` true +`に設定します。 。 これは、すべてのクライアントがデータベースリソースと操作にアクセスするために認証する必要があることを意味します。

  • 前の手順で作成したシークレットに関する情報を追加して、チャートがこれらの値を使用してレプリカセットキーファイルと管理ユーザーを作成できるようにします。

  • StatefulSetの各Podに関連付けられたPersistentVolumesのサイズを小さくして、https://www.digitalocean.com/docs/volumes/overview/ [最小の実行可能なDigitalOceanブロックストレージユニット]、1GBを使用します。ただし、ストレージ要件に合わせてこれを変更します。

ただし、 `+ mongodb-values.yaml +`ファイルを記述する前に、ストレージをプロビジョニングするために作成および構成されたhttps://kubernetes.io/docs/concepts/storage/storage-classes/[StorageClass]があることを最初に確認する必要がありますリソース。 データベースStatefulSetの各Podには、スティッキーIDと関連付けられたhttps://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[PersistentVolumeClaim]があり、PodのPersistentVolumeが動的にプロビジョニングされます。 Podが再スケジュールされると、PersistentVolumeはPodがスケジュールされているノードにマウントされます(ただし、関連するPodまたはStatefulSetが完全に削除される場合、各ボリュームは手動で削除する必要があります)。

DigitalOcean Kubernetesで作業しているため、デフォルトのStorageClass `+ provisioner `は ` dobs.csi.digitalocean.com +`に設定されます-https:// www .digitalocean.com / products / block-storage / [DigitalOcean Block Storage]-次のように入力して確認できます。

kubectl get storageclass

DigitalOceanクラスターを使用している場合、次の出力が表示されます。

OutputNAME                         PROVISIONER                 AGE
do-block-storage (default)   dobs.csi.digitalocean.com   21m

DigitalOceanクラスターを使用していない場合は、StorageClassを作成し、選択した「+ provisioner +」を設定する必要があります。 これを行う方法の詳細については、https://kubernetes.io/docs/concepts/storage/storage-classes/ [公式ドキュメント]を参照してください。

StorageClassが設定されていることを確認したので、編集のために `+ mongodb-values.yaml +`を開きます。

nano mongodb-values.yaml

このファイルには、次のことを行う値を設定します。

  • 認証を有効にします。

  • “および “オブジェクトを参照します。

  • PersistentVolumesに「++」を指定します。

  • レプリカセット名を「++」に設定します。

  • セットに「3」レプリカを指定します。

  • 執筆時点で、 + mongo +`イメージを最新バージョンに固定します: `++

次のコードをファイルに貼り付けます。

〜/ node_project / mongodb-values.yaml

replicas:
port: 27017
replicaSetName:
podDisruptionBudget: {}
auth:
 enabled:
 existingKeySecret:
 existingAdminSecret:
imagePullSecrets: []
installImage:
 repository: unguiculus/mongodb-install
 tag: 0.7
 pullPolicy: Always
copyConfigImage:
 repository: busybox
 tag: 1.29.3
 pullPolicy: Always
image:
 repository: mongo
 tag:
 pullPolicy: Always
extraVars: {}
metrics:
 enabled: false
 image:
   repository: ssalaues/mongodb-exporter
   tag: 0.6.1
   pullPolicy: IfNotPresent
 port: 9216
 path: /metrics
 socketTimeout: 3s
 syncTimeout: 1m
 prometheusServiceDiscovery: true
 resources: {}
podAnnotations: {}
securityContext:
 enabled: true
 runAsUser: 999
 fsGroup: 999
 runAsNonRoot: true
init:
 resources: {}
 timeout: 900
resources: {}
nodeSelector: {}
affinity: {}
tolerations: []
extraLabels: {}
persistentVolume:
 enabled: true
 #storageClass: "-"
 accessModes:
   - ReadWriteOnce
 size:
 annotations: {}
serviceAnnotations: {}
terminationGracePeriodSeconds: 30
tls:
 enabled: false
configmap: {}
readinessProbe:
 initialDelaySeconds: 5
 timeoutSeconds: 1
 failureThreshold: 3
 periodSeconds: 10
 successThreshold: 1
livenessProbe:
 initialDelaySeconds: 30
 timeoutSeconds: 5
 failureThreshold: 3
 periodSeconds: 10
 successThreshold: 1

`+ persistentVolume.storageClass `パラメータはここでコメント化されています:コメントを削除してその値を `”-“`に設定すると、動的プロビジョニングが無効になります。 この例では、この値を未定義のままにしているため、チャートはデフォルトの「 provisioner 」を選択します。この例では「 dobs.csi.digitalocean.com +」を選択します。

また、「+ persistentVolume 」キーに関連付けられた「 accessMode 」に注意してください。「 ReadWriteOnce +」は、プロビジョニングされたボリュームが単一のノードによってのみ読み書きできることを意味します。 さまざまなアクセスモードの詳細については、https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes [ドキュメント]をご覧ください。

ファイルに含まれる他のパラメーターの詳細については、レポジトリに含まれているhttps://github.com/helm/charts/tree/master/stable/mongodb-replicaset#configuration[configuration table]をご覧ください。

編集が終了したら、ファイルを保存して閉じます。

+ mongodb-replicaset +`チャートをデプロイする前に、https://helm.sh/docs/helm/#helm-repo-update [+ helm repo update +`コマンド]で* stable *リポジトリを更新する必要があります。 :

helm repo update

これにより、* stable *リポジトリから最新のチャート情報が取得されます。

最後に、次のコマンドでチャートをインストールします。

helm install --name  -f  stable/mongodb-replicaset

Helmに_release_ `+`という名前を付けていることに注意してください。 この名前は、指定した構成オプションを使用して、グラフのこの特定の展開を指します。 ` -f `フラグと ` mongodb-values.yaml +`ファイルを含めることで、これらのオプションを示しました。

また、 + helm install in`に -namespace`フラグを含めなかったため、チャートオブジェクトは ` default +`名前空間に作成されることに注意してください。

リリースを作成すると、そのステータスに関する出力と、作成されたオブジェクトに関する情報およびそれらと対話するための指示が表示されます。

OutputNAME:   mongo
LAST DEPLOYED: Tue Apr 16 21:51:05 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                              DATA  AGE
mongo-mongodb-replicaset-init     1     1s
mongo-mongodb-replicaset-mongodb  1     1s
mongo-mongodb-replicaset-tests    1     0s
...

次のコマンドを使用して、ポッドの作成を確認できます。

kubectl get pods

ポッドが作成されると、次のような出力が表示されます。

OutputNAME                         READY   STATUS     RESTARTS   AGE
mongo-mongodb-replicaset-0   1/1     Running    0          67s
mongo-mongodb-replicaset-1   0/1     Init:0/3   0          8s

ここの「+ READY 」および「 STATUS 」の出力は、StatefulSetのPodが完全に準備が整っていないことを示します。 Podのコンテナはまだ実行中です。 StatefulSetメンバーはhttps://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees [順次作成]であるため、StatefulSetの各Podは「 Running 」および「次のポッドが作成される前に Ready + `。

ポッドが作成され、関連するすべてのコンテナが実行されると、次の出力が表示されます。

OutputNAME                         READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0   1/1     Running   0          2m33s
mongo-mongodb-replicaset-1   1/1     Running   0          94s
mongo-mongodb-replicaset-2   1/1     Running   0          36s

+ Running` + STATUS`は、ポッドがノードにバインドされており、それらのポッドに関連付けられたコンテナが実行されていることを示します。 `+ READY +`は、Podで実行されているコンテナの数を示します。 詳細については、https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ [Podライフサイクルに関するドキュメント]を参照してください。

StatefulSetの各Podには、StatefulSetの名前とPodのhttps://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#ordinal-index[ordinal index]を組み合わせた名前があります。 3つのレプリカを作成したため、StatefulSetメンバーには0〜2の番号が付けられ、それぞれにhttps://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#stable-network-id[stable DNS entry]が含まれます。次の要素: + $()-$()。$()。$()。svc.cluster.local +

この場合、 `+ mongodb-replicaset +`チャートによって作成されたStatefulSetとhttps://kubernetes.io/docs/concepts/services-networking/service/#headless-services[Headless Service]は同じ名前を持ちます:

kubectl get statefulset
OutputNAME                       READY   AGE
  3/3     4m2s
kubectl get svc
OutputNAME                              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE
kubernetes                        ClusterIP   10.245.0.1   <none>        443/TCP     42m
         ClusterIP   None         <none>        27017/TCP   4m35s
mongo-mongodb-replicaset-client   ClusterIP   None         <none>        27017/TCP   4m35s

これは、StatefulSetの最初のメンバーが次のDNSエントリを持つことを意味します。

mongo-mongodb-replicaset-.mongo-mongodb-replicaset.default.svc.cluster.local

各MongoDBインスタンスに接続するにはアプリケーションが必要であるため、サービスではなくポッドと直接通信できるように、この情報を取得することが不可欠です。 カスタムアプリケーションヘルムチャートを作成するとき、環境変数を使用して各ポッドのDNSエントリをアプリケーションに渡します。

データベースインスタンスを起動して実行すると、Nodeアプリケーションのチャートを作成する準備が整います。

手順4-カスタムアプリケーションチャートの作成とパラメーターの構成

Nodeアプリケーション用にカスタムHelmチャートを作成し、作成したばかりのレプリカセットでアプリケーションが動作できるように、標準チャートディレクトリ内のデフォルトファイルを変更します。 また、アプリケーションのConfigMapおよびSecretオブジェクトを定義するファイルを作成します。

最初に、次のコマンドで「++」という新しいチャートディレクトリを作成します。

helm create

これにより、次のリソースを持つ「〜/ +」フォルダーに「+」というディレクトリが作成されます。

  • チャートに関する基本情報を含む `+ Chart.yaml +`ファイル。

  • MongoDBデプロイメントで行ったように、特定のパラメーター値を設定できる `+ values.yaml +`ファイル。

  • チャートをパッケージ化するときに無視されるファイルおよびディレクトリパターンを含む `+ .helmignore +`ファイル。

  • Kubernetesマニフェストを生成するテンプレートファイルのある `+ templates / +`ディレクトリ。

  • テストファイル用の `+ templates / tests / +`ディレクトリ。

  • このチャートが依存するチャート用の `+ charts / +`ディレクトリ。

これらのデフォルトファイルから変更する最初のファイルは、 `+ values.yaml +`です。 今すぐそのファイルを開きます。

nano /values.yaml

ここで設定する値は次のとおりです。

  • レプリカの数。

  • 使用するアプリケーションイメージ。 私たちの場合、これはhttps://www.digitalocean.com/community/tutorials/how-to-scale-a-node-js-application-with-mongodb-で作成した `+ node-replicas +`イメージになりますusing-helm#step-1-%E2%80%94-cloning-and-packaging-the-application [ステップ1]。

  • ServiceType。 この場合、https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer [LoadBalancer]を指定して、テスト目的でアプリケーションへのアクセスポイントを作成します。 DigitalOcean Kubernetesクラスターで作業しているため、チャートを展開するときにhttps://www.digitalocean.com/products/load-balancer/[DigitalOcean Load Balancer]が作成されます。 本番環境では、https://kubernetes.io/docs/concepts/services-networking/ingress/ [Ingress Resources]およびhttps://kubernetes.io/docs/concepts/services-networking/ingressを使用するようにチャートを設定できます-controllers / [Ingress Controllers]-トラフィックをサービスにルーティングします。

  • targetPortを使用して、アプリケーションが公開されるポッドのポートを指定します。

このファイルには環境変数を入力しません。 代わりに、ConfigMapおよびSecretオブジェクトのテンプレートを作成し、これらの値をアプリケーションの展開マニフェスト(「+〜/ node_project // templates / deployment.yaml +」にある)に追加します。

`+ values.yaml +`ファイルで以下の値を設定します:

〜/ node_project / nodeapp / values.yaml

# Default values for nodeapp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount:

image:
 repository: /
 tag:
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type:
 port: 80

...

編集が終了したら、ファイルを保存して閉じます。

次に、 + / templates`ディレクトリで + secret.yaml`ファイルを開きます:

nano /templates/secret.yaml

このファイルでは、 `+ MONGO_USERNAME `および ` MONGO_PASSWORD `アプリケーション定数の値を追加します。 これらは、データベース接続ファイル ` db.js `で指定されているように、アプリケーションが実行時にアクセスすることを期待する定数です。 これらの定数の値を追加するときは、https://www.digitalocean.com/community/tutorials/how-to-scale-a-node-jsで以前に使用したbase64- * encoded *値を使用することを忘れないでください-application-with-mongodb-using-helm#step-2-%E2%80%94-creating-secrets-for-the-mongodb-replica-set [ステップ2]を使用して、 `+`オブジェクトを作成します。 これらの値を再作成する必要がある場合は、手順2に戻り、関連するコマンドを再度実行できます。

ファイルに次のコードを追加します。

〜/ node_project / nodeapp / templates / secret.yaml

apiVersion: v1
kind: Secret
metadata:
 name: {{ .Release.Name }}-auth
data:
 MONGO_USERNAME:
 MONGO_PASSWORD:

このSecretオブジェクトの名前は、Helmリリースの名前に依存します。Helmリリースは、アプリケーションチャートを展開するときに指定します。

完了したら、ファイルを保存して閉じます。

次に、ファイルを開いて、アプリケーションのConfigMapを作成します。

nano /templates/configmap.yaml

このファイルでは、アプリケーションが期待する残りの変数を定義します: + MONGO_HOSTNAME ++ MONGO_PORT ++ MONGO_DB +、および + MONGO_REPLICASET +。 `+ MONGO_HOSTNAME +`変数には、レプリカセットの*各*インスタンスのDNSエントリが含まれます。これはhttps://docs.mongodb.com/manual/reference/connection-string/[MongoDB接続URIが必要]であるためです。

Kubernetes documentationによると、アプリケーションが活性と準備チェックを実装する場合、https:/ /kubernetes.io/docs/concepts/services-networking/dns-pod-service/#srv-records[SRV records]は、ポッドに接続するときに使用する必要があります。 ステップ3、Pod SRVレコードは次のパターンに従います: `+ $()-$()。$()。$()。svc cluster.local + `。 MongoDB StatefulSetは活性とレディネスチェックを実装しているため、 `+ MONGO_HOSTNAME +`変数の値を定義するときにこれらの安定した識別子を使用する必要があります。

次のコードをファイルに追加して、 + MONGO_HOSTNAME ++ MONGO_PORT ++ MONGO_DB +、および `+ MONGO_REPLICASET `変数を定義します。 ` MONGO_DB `データベースには別の名前を自由に使用できますが、 ` MONGO_HOSTNAME `と ` MONGO_REPLICASET +`の値はここに表示されるとおりに記述する必要があります。

〜/ node_project / nodeapp / templates / configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
 name: {{ .Release.Name }}-config
data:
 MONGO_HOSTNAME: "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local,mongo-mongodb-replicaset-1.mongo-mongodb-replicaset.default.svc.cluster.local,mongo-mongodb-replicaset-2.mongo-mongodb-replicaset.default.svc.cluster.local"
 MONGO_PORT: "27017"
 MONGO_DB: ""
 MONGO_REPLICASET: "db"

StatefulSetオブジェクトとレプリカセットは既に作成されているため、ここにリストされているホスト名は、この例に示されているとおりにファイルにリストされている必要があります。 これらのオブジェクトを破棄し、MongoDB Helmリリースの名前を変更した場合、このConfigMapに含まれる値を修正する必要があります。 MongoDBリリースでレプリカセット名を指定したため、同じことが `+ MONGO_REPLICASET +`にも当てはまります。

また、ここにリストされている値は引用符で囲まれていることに注意してください。これはhttps://github.com/helm/helm/blob/master/docs/charts_tips_and_tricks.md#quote-strings-dont-quote-integers [環境変数の期待値兜]。

編集が終了したら、ファイルを保存して閉じます。

チャートパラメーター値を定義し、SecretおよびConfigMapマニフェストを作成したら、アプリケーションのデプロイメントテンプレートを編集して、環境変数を使用できます。

手順5-環境変数をHelm展開に統合する

アプリケーションSecretおよびConfigMapのファイルを配置したら、アプリケーションDeploymentがこれらの値を使用できることを確認する必要があります。 また、デプロイメントマニフェストで既に定義されているhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/[liveness and readiness probe]もカスタマイズします。

編集のためにアプリケーションデプロイメントテンプレートを開きます。

nano /templates/deployment.yaml

これはYAMLファイルですが、Helmテンプレートはマニフェストを生成するために標準のKubernetes YAMLファイルとは異なる構文を使用します。 テンプレートの詳細については、https://helm.sh/docs/chart_template_guide/#the-chart-template-developer-s-guide [Helm documentation]を参照してください。

このファイルで、最初にアプリケーションコンテナの仕様に、「+ imagePullPolicy 」キーの下、「 ports 」の上に「 env +」キーを追加します。

〜/ node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
       imagePullPolicy: {{ .Values.image.pullPolicy }}

       ports:

次に、次のキーを `+ env +`変数のリストに追加します。

〜/ node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
       imagePullPolicy: {{ .Values.image.pullPolicy }}
       env:

各変数には、https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables [+ secretKeyRef + key]のいずれかによって定義された値への参照が含まれます秘密の値、またはhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data [+ configMapKeyRef +] ConfigMap値。 これらのキーは、前の手順で作成したSecretファイルとConfigMapファイルを指します。

次に、 `+ ports `キーの下で、 ` containerPort +`定義を変更して、アプリケーションが公開されるコンテナーのポートを指定します。

〜/ node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
   ...
     env:
   ...
     ports:
       - name: http
         containerPort:
         protocol: TCP
     ...

次に、この展開マニフェストにデフォルトで含まれている活性チェックと準備チェックを変更しましょう。 これらのチェックにより、アプリケーションポッドが実行され、トラフィックを処理する準備ができていることが確認されます。

  • レディネスプローブは、ポッドがトラフィックを処理する準備ができているかどうかを評価し、チェックが成功するまでポッドへのすべてのリクエストを停止します。

  • Livenessプローブは、基本的なアプリケーションの動作を確認して、コンテナ内のアプリケーションが実行され、予想どおりに動作しているかどうかを判断します。 活性プローブが失敗すると、Kubernetesはコンテナを再起動します。

両方の詳細については、https://www.digitaloceanのhttps://www.digitalocean.com/community/tutorials/architecting-applications-for-kubernetes#implementing-readiness-and-liveness-probes [関連するディスカッション]を参照してください。 .com / community / tutorials / architecting-applications-for-kubernetes [Kubernetesのアーキテクトアプリケーション]。

このケースでは、https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request [+ httpGet +`リクエスト] Helmがデフォルトで提供し、アプリケーションが `+ / sharks +`エンドポイントでリクエストを受け入れているかどうかをテストします。 https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [+ kubelet ` service]は、アプリケーションPodのコンテナで実行されているNodeサーバーにGETリクエストを送信することでプローブを実行します。ポート ` 8080 `でリッスンします。 応答のステータスコードが200〜400の場合、「 kubelet 」はコンテナが正常であると結論付けます。 そうでない場合、400または500ステータスの場合、 ` kubelet +`は、レディネスプローブの場合はコンテナへのトラフィックを停止するか、活性プローブの場合はコンテナを再起動します。

次の変更を、活性プローブとレディネスプローブの指定された「+ path +」に追加します。

〜/ node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
   ...
     env:
   ...
     ports:
       - name: http
         containerPort: 8080
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: http
     readinessProbe:
       httpGet:
         path: /
         port: http

編集が終了したら、ファイルを保存して閉じます。

これで、Helmを使用してアプリケーションリリースを作成する準備ができました。 次のhttps://helm.sh/docs/helm/#helm-install[`+helm install + `コマンド]を実行します。これには、リリースの名前とチャートディレクトリの場所が含まれます。

helm install --name  ./

https://www.digitalocean.com/community/tutorials/how-toで説明されているように、最初に `-dry-run +`および `-debug `オプションを指定して ` helm install +`を実行できることを忘れないでください-scale-a-node-js-application-with-mongodb-using-helm#step-3-%E2%80%94-configuring-the-mongodb-helm-chart-and-creating-a-deployment [ステップ3 ]、リリース用に生成されたマニフェストを確認します。

繰り返しになりますが、 + helm install in`には -namespace`フラグが含まれていないため、チャートオブジェクトは ` default +`名前空間に作成されます。

リリースが作成されたことを示す次の出力が表示されます。

OutputNAME:   nodejs
LAST DEPLOYED: Wed Apr 17 18:10:29 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME           DATA  AGE
nodejs-config  4     1s

==> v1/Deployment
NAME            READY  UP-TO-DATE  AVAILABLE  AGE
nodejs-nodeapp  0/3    3           0          1s

...

繰り返しになりますが、出力には、作成されたオブジェクトとその操作方法に関する情報とともに、リリースのステータスが示されます。

ポッドのステータスを確認します。

kubectl get pods
OutputNAME                              READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0        1/1     Running   0          57m
mongo-mongodb-replicaset-1        1/1     Running   0          56m
mongo-mongodb-replicaset-2        1/1     Running   0          55m
nodejs-nodeapp-577df49dcc-b5fq5   1/1     Running   0          117s
nodejs-nodeapp-577df49dcc-bkk66   1/1     Running   0          117s
nodejs-nodeapp-577df49dcc-lpmt2   1/1     Running   0          117s

Podを起動して実行したら、サービスを確認します。

kubectl get svc
OutputNAME                              TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
kubernetes                        ClusterIP      10.245.0.1     <none>            443/TCP        96m
mongo-mongodb-replicaset          ClusterIP      None           <none>            27017/TCP      58m
mongo-mongodb-replicaset-client   ClusterIP      None           <none>            27017/TCP      58m
nodejs-nodeapp                    LoadBalancer   10.245.33.46           80:31518/TCP   3m22s

`+ nodejs-nodeapp `サービスに関連付けられた ` EXTERNAL_IP `は、クラスターの外部からアプリケーションにアクセスできるIPアドレスです。 ` EXTERNAL_IP `カラムに ` <pending> +`ステータスが表示される場合、これはロードバランサーがまだ作成されていることを意味します。

その列にIPが表示されたら、ブラウザーでそのアドレスに移動します: + http:// +

次のランディングページが表示されます。

image:https://assets.digitalocean.com/articles/docker_node_image/landing_page.png [アプリケーションのランディングページ]

レプリケートされたアプリケーションが機能するようになったので、テストデータを追加して、レプリカセットのメンバー間でレプリケーションが機能していることを確認します。

ステップ6-MongoDBレプリケーションのテスト

アプリケーションを実行し、外部IPアドレスを介してアクセスできるようにすることで、テストデータを追加し、MongoDBレプリカセットのメンバー間で複製されることを確認できます。

まず、ブラウザからアプリケーションのランディングページに移動していることを確認します。

image:https://assets.digitalocean.com/articles/docker_node_image/landing_page.png [アプリケーションのランディングページ]

  • Get Shark Info *ボタンをクリックします。 サメの名前とそのサメの一般的なキャラクターの説明を入力できるエントリフォームのページが表示されます。

image:https://assets.digitalocean.com/articles/node_mongo/shark_form.png [サメ情報フォーム]

フォームに、選択した最初のサメを追加します。 デモンストレーションのため、「Shark Name」フィールドに「」を追加し、「Shark Character」フィールドに「」を追加します。

image:https://assets.digitalocean.com/articles/node_mongo/shark_filled.png [サメの塗りつぶしフォーム]

[送信]ボタンをクリックします。 このサメの情報が表示されたページが表示されます:

image:https://assets.digitalocean.com/articles/node_mongo/shark_added.png [サメ出力]

上部のナビゲーションバーで* Sharks *をクリックして、サメ情報フォームに戻ります。

image:https://assets.digitalocean.com/articles/node_mongo/shark_form.png [サメ情報フォーム]

お好みの新しいサメを入力してください。 「」と「」を使用します。

image:https://assets.digitalocean.com/articles/node_docker_dev/whale_shark.png [新しいサメを入力]

[送信]をクリックすると、データベース内のサメコレクションに新しいサメが追加されていることがわかります。

image:https://assets.digitalocean.com/articles/node_docker_dev/persisted_data.png [サメの完全コレクション]

入力したデータがレプリカセットのプライマリメンバーとセカンダリメンバー間で複製されたことを確認しましょう。

ポッドのリストを取得します。

kubectl get pods
OutputNAME                              READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0        1/1     Running   0          74m
mongo-mongodb-replicaset-1        1/1     Running   0          73m
mongo-mongodb-replicaset-2        1/1     Running   0          72m
nodejs-nodeapp-577df49dcc-b5fq5   1/1     Running   0          5m4s
nodejs-nodeapp-577df49dcc-bkk66   1/1     Running   0          5m4s
nodejs-nodeapp-577df49dcc-lpmt2   1/1     Running   0          5m4s

ポッドでhttps://docs.mongodb.com/manual/reference/program/mongo/#bin.mongo [+ mongo + shell]にアクセスするには、https://kubernetes.io/docs/を使用できます。 reference / generated / kubectl / kubectl-commands#exec [+ kubectl exec + command]およびhttps://www.digitalocean.com/community/tutorials/how-to-で `+`の作成に使用したユーザー名node-js-application-with-mongodb-using-helm#step-2-%E2%80%94-creating-secrets-for-the-mongodb-replica-set [ステップ2] 次のコマンドを使用して、StatefulSetの最初のポッドで ` mongo +`シェルにアクセスします。

kubectl exec -it mongo-mongodb-replicaset- -- mongo -u  -p --authenticationDatabase admin

プロンプトが表示されたら、このユーザー名に関連付けられているパスワードを入力します。

OutputMongoDB shell version v4.1.9
Enter password:

管理シェルにドロップされます。

OutputMongoDB server version: 4.1.9
Welcome to the MongoDB shell.
...

db:PRIMARY>

プロンプト自体にはこの情報が含まれていますが、https://docs.mongodb.com/manual/reference/command/isMaster/#dbcmd.isMaster [`+ rsを使用して、どのレプリカセットメンバーがプライマリであるかを手動で確認できます。 isMaster()+ `メソッド]:

rs.isMaster()

次のような出力が表示され、プライマリのホスト名が示されます。

Outputdb:PRIMARY> rs.isMaster()
{
       "hosts" : [
               "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
               "mongo-mongodb-replicaset-1.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
               "mongo-mongodb-replicaset-2.mongo-mongodb-replicaset.default.svc.cluster.local:27017"
       ],
       ...
       "primary" : "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
       ...

次に、 `++`データベースに切り替えます。

use
Outputswitched to db sharkinfo

データベース内のコレクションをリストします。

show collections
Outputsharks

コレクション内のドキュメントを出力します。

db.sharks.find()

次の出力が表示されます。

Output{ "_id" : ObjectId("5cb7702c9111a5451c6dc8bb"), "name" : "Megalodon Shark", "character" : "Ancient", "__v" : 0 }
{ "_id" : ObjectId("5cb77054fcdbf563f3b47365"), "name" : "Whale Shark", "character" : "Large", "__v" : 0 }

MongoDBシェルを終了します。

exit

プライマリのデータを確認したので、セカンダリに複製されていることを確認しましょう。 次のコマンドで「+ kubectl exec」を「+ mongo-mongodb-replica set-1 +」に追加します。

kubectl exec -it mongo-mongodb-replicaset- -- mongo -u  -p --authenticationDatabase admin

管理シェルに入ったら、 `+ db.setSlaveOk()+`メソッドを使用して、セカンダリインスタンスからの読み取り操作を許可する必要があります。

db.setSlaveOk(1)

`++`データベースに切り替えます:

use sharkinfo
Outputswitched to db sharkinfo

`+ sharks +`コレクション内のドキュメントの読み取り操作を許可します。

db.setSlaveOk(1)

コレクション内のドキュメントを出力します。

db.sharks.find()

これで、プライマリインスタンスでこのメソッドを実行したときに見たのと同じ情報が表示されるはずです。

Outputdb:SECONDARY> db.sharks.find()
{ "_id" : ObjectId("5cb7702c9111a5451c6dc8bb"), "name" : "Megalodon Shark", "character" : "Ancient", "__v" : 0 }
{ "_id" : ObjectId("5cb77054fcdbf563f3b47365"), "name" : "Whale Shark", "character" : "Large", "__v" : 0 }

この出力は、アプリケーションデータがレプリカセットのメンバー間で複製されていることを確認します。

結論

これで、Helmチャートを使用して、Kubernetesクラスターに複製された可用性の高いサメ情報アプリケーションをデプロイできました。 このチュートリアルアプリケーションで説明されているこのデモアプリケーションとワークフローは、アプリケーションのカスタムチャートを作成し、Helmの* stable *リポジトリとhttps://github.com/bitnami/charts/tree/master/を利用する際の出発点として機能します。 bitnami [その他のチャートリポジトリ]。

本番環境に移行するときは、次の実装を検討してください。

  • 集中ログおよび監視https://www.digitalocean.com/community/tutorials/modernizingのhttps://www.digitalocean.com/community/tutorials/modernizing-applications-for-kubernetes#deploying-on-kubernetes [関連するディスカッション]をご覧ください。 -applications-for-kubernetes [Kubernetesのアプリケーションの近代化]一般的な概要。 https://www.digitalocean.com/community/tutorials/how-to-set-up-an-elasticsearch-fluentd-and-kibana-efk-logging-stack-on-kubernetes [設定方法]もご覧ください。 https://www.elastic.co/ [Elasticsearch]、https://www.fluentd.org/ [でロギングスタックを設定する方法を学ぶために、Elasticsearch、FluentdおよびKibana(EFK)ロギングスタックをKubernetesにアップ] Fluentd]、およびhttps://www.elastic.co/products/kibana[Kibana]。 また、https://istio.io/ [Istioのようなサービスメッシュの詳細については、https://www.digitalocean.com/community/tutorials/an-introduction-to-service-meshes [サービスメッシュの概要]も参照してください。 ]この機能を実装します。

  • トラフィックをクラスターにルーティングするためのIngressリソース。 これは、それぞれ独自のLoadBalancerを必要とする複数のサービスを実行している場合、またはアプリケーションレベルのルーティング戦略(A / Bおよびカナリアテストなど)を実装する場合に、LoadBalancerの代替として適しています。 詳細については、https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes [セットアップ方法]をご覧ください。 DigitalOcean KubernetesのCert-Managerを使用したNginx Ingress]およびhttps://www.digitalocean.com/community/tutorials/an-introduction-to-service-meshes#routing-and-traffic-configuration [関連ディスカッション]ルーティングhttps://www.digitalocean.com/community/tutorials/an-introduction-to-service-meshes [サービスメッシュの概要]のサービスメッシュコンテキストで。

  • * Kubernetesオブジェクトのバックアップ戦略*。 DigitalOceanのKubernetes製品でhttps://github.com/heptio/velero[Velero](以前のHeptio Ark)を使用してバックアップを実装する方法については、https://www.digitalocean.com/community/tutorials/how-to-を参照してください。バックアップおよび復元-a-kubernetes-cluster-on-digitalocean-using-heptio-ark [Heptio Arkを使用してDigitalOceanでKubernetesクラスターをバックアップおよび復元する方法]。

Helmの詳細については、https://www.digitalocean.com/community/tutorials/an-introduction-to-helm-the-package-manager-for-kubernetes [KubernetesのパッケージマネージャーであるHelmの概要]を参照してください。 、https://www.digitalocean.com/community/tutorials/how-to-install-software-on-kubernetes-clusters-with-the-helm-package-manager [Helmパッケージを使用してKubernetesクラスターにソフトウェアをインストールする方法マネージャー]、およびhttps://helm.sh/docs/[Helm documentation]。