🥇Helm を使用して複数の Kubernetes クラスターにアプリケーションをデプロイする

Dailymotion での Kubernetes の使用方法: アプリケーションのデプロイメント

私たち Dailymotion は 3 年前に運用環境で Kubernetes の使用を開始しました。しかし、複数のクラスターにアプリケーションをデプロイするのは楽しいので、ここ数年、私たちはツールとワークフローの改善に努めてきました。

どこから始まったのですか

ここでは、世界中の複数の Kubernetes クラスターにアプリケーションをデプロイする方法について説明します。

複数の Kubernetes オブジェクトを一度にデプロイするには、次を使用します。ヘルメット、すべてのチャートは XNUMX つの git リポジトリに保存されます。複数のサービスから完全なアプリケーションスタックをデプロイするには、いわゆるサマリーチャートを使用します。基本的に、これは依存関係を宣言し、XNUMX つのコマンドで API とそのサービスを初期化できるようにするチャートです。

また、Helm 上に小さな Python スクリプトを作成して、チェックを実行し、グラフを作成し、シークレットを追加し、アプリケーションをデプロイしました。これらすべてのタスクは、Docker イメージを使用して中央の CI プラットフォームで実行されます。

本題に入りましょう。

注記。これを読んでいる時点で、Helm 3 の最初のリリース候補はすでに発表されています。メインバージョンには、過去に発生した問題のいくつかに対処するための多数の改善が含まれています。

チャート開発ワークフロー

私たちはアプリケーションに分岐を使用していますが、同じアプローチをチャートにも適用することにしました。

支店 devの 開発クラスターでテストされるチャートを作成するために使用されます。
プルリクエストが送信されると、 マスター、ステージングでチェックされます。
最後に、プルリクエストを作成してブランチに変更をコミットします。突くそしてそれらを本番環境に適用します。

各環境にはチャートを保存する独自のプライベートリポジトリがあり、チャートミュージアム非常に便利な API を備えています。このようにして、実稼働環境で使用する前に、環境間の厳密な分離とチャートの実世界でのテストが保証されます。

さまざまな環境のグラフリポジトリ

開発者が dev ブランチをプッシュすると、チャートのバージョンが自動的に dev Chartmuseum にプッシュされることに注意してください。したがって、すべての開発者が同じ開発リポジトリを使用するため、他の人の変更を誤って使用しないように、チャートのバージョンを慎重に指定する必要があります。

さらに、私たちの小さな Python スクリプトは、次を使用して Kubernetes OpenAPI 仕様に対して Kubernetes オブジェクトを検証します。クベヴァル、Chartmusem で公開する前に。

チャート開発ワークフローの一般的な説明

仕様に従ってパイプラインタスクを設定するガズリオ品質管理 (lint、単体テスト) 用。
アプリケーションをデプロイする Python ツールを使用して Docker イメージをプッシュします。
ブランチ名による環境のセットアップ。
Kubeval を使用した Kubernetes yaml ファイルの検証。
チャートとその親チャート (変更されるチャートに依存するチャート) のバージョンを自動的に上げます。
環境に一致するチャートミュージアムにチャートを送信する

クラスター間の差異の管理

クラスターの連合

使っていた時期もありました Kubernetes クラスターのフェデレーションここで、Kubernetes オブジェクトは単一の API エンドポイントから宣言できます。しかし、問題が生じました。たとえば、一部の Kubernetes オブジェクトはフェデレーションエンドポイントで作成できず、個々のクラスターのフェデレーションオブジェクトやその他のオブジェクトを維持することが困難になります。

この問題を解決するために、クラスターを個別に管理するようになり、プロセスが大幅に簡素化されました (フェデレーションの最初のバージョンを使用しましたが、XNUMX 番目のバージョンでは何かが変更されている可能性があります)。

地理的に分散されたプラットフォーム

当社のプラットフォームは現在、6 つのリージョン (ローカルに 3 つ、クラウドに 3 つ) に分散されています。

分散展開

グローバル Helm 値

4 つのグローバル Helm 値により、クラスター間の違いを識別できます。すべてのチャートにはデフォルトの最小値があります。

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

グローバルな価値観

これらの値は、アプリケーションのコンテキストを定義するのに役立ち、監視、トレース、ロギング、外部呼び出し、スケーリングなどのさまざまな目的に使用されます。

「クラウド」: ハイブリッド Kubernetes プラットフォームがあります。たとえば、当社の API は GCP ゾーンとデータセンターにデプロイされています。
「env」: 非本番環境では一部の値が変更される可能性があります。たとえば、リソース定義や自動スケーリング構成などです。
「region」: この情報はクラスターの場所を特定するのに役立ち、外部サービスの近くのエンドポイントを特定するために使用できます。
"clusterName": 個々のクラスターの値を定義する場合。

具体的な例を次に示します。

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

Helm テンプレートの例

このロジックは、Kubernetes YAML の煩雑さを避けるためにヘルパーテンプレートで定義されています。

申請のお知らせ

当社の展開ツールは複数の YAML ファイルに基づいています。以下は、クラスター内でサービスとそのスケーリングトポロジ (レプリカの数) を宣言する方法の例です。

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

サービス定義

これは、展開ワークフローを定義するすべての手順の概要です。最後のステップでは、アプリケーションを複数のワーカークラスターに同時にデプロイします。

Jenkins の導入手順

秘密についてはどうですか？

セキュリティに関しては、さまざまな場所からすべての秘密を追跡し、独自の保管庫に保管します。ボールトパリで。

当社のデプロイメントツールは、Vault からシークレット値を抽出し、デプロイメント時期が来ると、それらを Helm に挿入します。

これを行うために、Vault 内のシークレットとアプリケーションに必要なシークレットの間のマッピングを定義しました。

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

Vault にシークレットを記録するときに従うべき一般的なルールを定義しました。
シークレットが当てはまる場合 特定のコンテキストまたはクラスターへの、特定のエントリを追加する必要があります。 (ここでは、コンテキストcluster1にシークレットstack-app1-passwordの独自の値があります)。
それ以外の場合は値が使用されます デフォルトで.
このリストの各項目について、 Kubernetesの秘密 キーと値のペアが挿入されます。したがって、チャートのシークレットテンプレートは非常にシンプルです。

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

課題と制限

複数のリポジトリの操作

現在、チャートとアプリケーションの開発を分離しています。これは、開発者が 2 つの git リポジトリで作業する必要があることを意味します。2 つはアプリケーション用で、もう XNUMX つはアプリケーションの Kubernetes へのデプロイメントを定義するためです。 XNUMX つの git リポジトリは XNUMX つのワークフローを意味するため、初心者は混乱しやすいです。

一般化されたグラフの管理は面倒です

すでに述べたように、汎用チャートは依存関係を特定し、複数のアプリケーションを迅速にデプロイするのに非常に役立ちます。しかし、私たちは使用します --reuse-valuesこの一般化されたチャートの一部であるアプリケーションをデプロイするたびにすべての値を渡すことを避けるためです。

継続的デリバリーワークフローでは、定期的に変更される値は、レプリカの数とイメージタグ (バージョン) の XNUMX つだけです。その他、より安定した値は手動で変更しますが、これはかなり困難です。さらに、私たち自身の経験からわかるように、一般化されたチャートの展開において XNUMX つの間違いが重大な失敗につながる可能性があります。

複数の設定ファイルの更新

開発者が新しいアプリケーションを追加する場合、アプリケーションの宣言、シークレットのリスト、一般化されたチャートにアプリケーションが含まれている場合は依存関係としてアプリケーションを追加するなど、いくつかのファイルを変更する必要があります。

Jenkins 権限が Vault で拡張されすぎています

今では XNUMX つありますアプリロール、Vault からすべてのシークレットを読み取ります。

ロールバックプロセスは自動化されていません

ロールバックするには、複数のクラスターでコマンドを実行する必要がありますが、これにはエラーが多く発生します。正しいバージョン ID が指定されていることを確認するために、この操作を手動で実行します。

GitOps に向けて移行中

私たちの目的

チャートを、デプロイされているアプリケーションのリポジトリに返したいと考えています。

ワークフローは開発時と同じになります。たとえば、ブランチがマスターにプッシュされると、デプロイメントが自動的にトリガーされます。このアプローチと現在のワークフローの主な違いは次のとおりです。 すべては git で管理されます (アプリケーション自体と、それが Kubernetes にデプロイされる方法)。

いくつかの利点があります。

多くの より明確な 開発者にとって。ローカルチャートに変更を適用する方法を学ぶ方が簡単です。
サービスデプロイメント定義を指定できます コードと同じ場所 サービス。
一般化されたグラフの削除の管理。このサービスには独自の Helm リリースが存在します。これにより、他のサービスに影響を与えないように、アプリケーションのライフサイクル (ロールバック、アップグレード) を最小レベルで管理できるようになります。
git の利点 チャート管理用: 変更の取り消し、監査ログなど。チャートへの変更を取り消す必要がある場合は、git を使用してこれを行うことができます。デプロイメントは自動的に開始されます。
次のようなツールを使用して開発ワークフローを改善することを検討してください。足場を使用すると、開発者は運用環境に近いコンテキストで変更をテストできます。

XNUMX 段階の移行

当社の開発者はこのワークフローを 2 年間使用しているため、移行をできるだけ簡単にしたいと考えています。そこで、ゴールに向かう途中に中間ステップを追加することにしました。
最初の段階は単純です。

アプリケーションのデプロイメントを設定するために同様の構造を維持しますが、DailymotionRelease という単一のオブジェクト内にあります。

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

アプリケーションごとに 1 つのリリース (一般化されたチャートなし)。
アプリケーションの git リポジトリ内のグラフ。

すべての開発者と話し合いを行ったので、移行プロセスはすでに始まっています。最初のステージは引き続き CI プラットフォームを使用して制御されます。フェーズ XNUMX: GitOps ワークフローにどのように移行したかについては、すぐに別の記事を書く予定です。 Flux。すべてをどのように設定したか、そしてどのような困難に遭遇したか (複数のリポジトリ、シークレットなど) について説明します。ニュースをフォローしてください。

ここでは、GitOps アプローチについての考察につながる、過去数年間のアプリケーションデプロイメントワークフローの進歩について説明しようとしました。まだ目標には到達しておらず、結果については今後報告しますが、すべてを簡素化し、開発者の習慣に近づけるという決断をしたとき、今では正しいことをしたと確信しています。

出所： habr.com

Helm を使用した複数の Kubernetes クラスターへのアプリケーションのデプロイ

Dailymotion での Kubernetes の使用方法: アプリケーションのデプロイメント

どこから始まったのですか

チャート開発ワークフロー

チャート開発ワークフローの一般的な説明

クラスター間の差異の管理

クラスターの連合

地理的に分散されたプラットフォーム

グローバル Helm 値

申請のお知らせ

秘密についてはどうですか？

課題と制限

複数のリポジトリの操作

一般化されたグラフの管理は面倒です

複数の設定ファイルの更新

Jenkins 権限が Vault で拡張されすぎています

ロールバックプロセスは自動化されていません

GitOps に向けて移行中

私たちの目的

XNUMX 段階の移行

コメントを追加します返信をキャンセル

Helm を使用した複数の Kubernetes クラスターへのアプリケーションのデプロイ

Dailymotion での Kubernetes の使用方法: アプリケーションのデプロイメント

どこから始まったのですか

チャート開発ワークフロー

チャート開発ワークフローの一般的な説明

クラスター間の差異の管理

クラスターの連合

地理的に分散されたプラットフォーム

グローバル Helm 値

申請のお知らせ

秘密についてはどうですか？

課題と制限

複数のリポジトリの操作

一般化されたグラフの管理は面倒です

複数の設定ファイルの更新

Jenkins 権限が Vault で拡張されすぎています

ロールバックプロセスは自動化されていません

GitOps に向けて移行中

私たちの目的

XNUMX 段階の移行

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル