キャプテンが舵を回すとき:7歩移動

🚢 海の寓話を続けましょうか.私は注目を集めるために驚くべき絵を作りました.
それが最新のソフトウェア版にアップグレードすることになるとき、大組織はしばしば全く保守的です.
もちろん、すべてが明確かつ正しく動作することを確認することは非常に重要です、特にCIのヘルムの広い使用を検討.移住の恐怖はあまり根拠がない.我々は、乗組員の乗組員のタイタニックwho didn't have binoculars , そうですか.あなたは舵を回して、船の方向を理解する必要があります!しかし、最初に物事!🧊
ヘルムV 2は2020年後半にレガシーになったが、最近ではバージョン2を使用している企業も存在する.

There are not many short and clear summaries on the Internet about migrating to Helm v3. Well, in this note, the author will try to break everything down into points.

⚓ ステージ0。バックアップ

すべての既存のリリースをバックアップ!移行を始める前にすべてのリリースのバックアップを取ることは重要です.移行の第一歩はヘルムV 2のリリース情報を削除しないが、バックアップを取るのは常に良い.

デフォルトでは、Helmkube-system クラスタの名前空間.このコマンドはヘルムV 2リリースをリストアップする

$ kubectl get configmap -n kube-system -l "OWNER=TILLER"

ヘルムV 3は、リリースの名前空間の既定のリリース情報ストレージを秘密に変更しました.ヘルムv 3リリースをリストする方法

$ kubectl get secret --namespace my-namespace | grep sh.helm.release

使用helm-backup plugin マールMororfrフリードマンによって.ヘルムのバックアップは、リリースのバックアップを取ることができるヘルムV 2のプラグインであり、また、それらを復元する機能を持っています.ここでどのようにバックアップを実現します.
それはTillerによって使用される記憶方法を見つけて、それからAとしてリリース名とともにConfigMapをバックアップします.tar ファイル.復元を行うときは、まず、configマップを適用します.それから、それはリリースを見つけますSTATUS=DEPLOYED Labelは、そのリリースのマニフェスト(YAML)を取得し、適用します.
別の方法は、リリース情報を保持するすべてのConfigMapをバックアップするだけです.最も簡単な方法は以下のコマンドを実行することです.

$ kubectl get configmaps \
    --namespace "kube-system" \
    --selector "OWNER=TILLER" \
    --output "yaml" > helm2-backup-cm.yaml

⚓ ステージ1 :リリースの変換

グラフをインストールまたは更新すると、クラスタ内に1つのヘルムリリースが作成されます.

それはConfigMap ヘルムV 2の場合クラスタ内で.これにより、ロールバックを行うことができますし、履歴を保持します.ヘルムV 3がリリース情報を格納する形式はV 2とは異なるV 3はストレージとして主に秘密を使用しています.マーティンヒッキーによって書かれた2 to 3プラグインは、これらのリリースを新しい形式に変換する作業を行います.
⚠️ にアクセスする重要な注意tiller namespace for required RBAC roles . Tillerlessセットアップでは、適切なクラスタ全体のRBACロールを持つサービスアカウントを使用する必要があります.使用しない場合、制限されたリソースにアクセスしようとすると、禁断のエラーがスローされます.
プラグインをインストール

$ helm3 plugin install https://github.com/helm/helm-2to3

⚓ ステージ2。ダンピングヘルムv 2

それはあなたの信頼のためにこのリストを持って良いです.

$ helm2 tiller run -- helm2 ls --max=0 | sed -n '1!p' | awk 'FNR > 1 { print $1 }' > releases.log
$ kubectl -n kube-system get configmap -l OWNER=TILLER,STATUS=DEPLOYED | awk 'FNR > 1 { print $1 }' | cut -f1 -d"." > releases.log

⚓ ステージ3。bashスクリプトによる自動移行の起動

#!/bin/bash

helm3_cmd="helm3"
if [[ -x "$(which helm 2>/dev/null)" ]]; then
  helm2_releases="$(helm ls --all --short)"
else
  echo "'helm' is not installed or not present in PATH. Using kubectl to get list of releases."
  # …
fi

echo -e "Found the following releases:\n${helm2_releases}\n"

for release in ${helm2_releases}; do
  ${helm3_cmd} 2to3 convert --dry-run "${release}"
  read -p "Convert '${release}'? [Y/n] " user_choice
  if [[ "${user_choice}" == "Y" ]]; then
    echo "Converting '${release}'."
    ${helm3_cmd} 2to3 convert "${release}"
    echo "Converted '${release}' successfully."
  else
    echo "Skipping conversion of '${release}'."
  fi
done

原作script Bhavinガンジーによって書かれます.

⚓ ステージ4。Kubernetes API検証問題の解決

Kerbernetes OpenAPIスキーマに対するレンダリングされたテンプレートのすべてを確認します.このアプローチは、Kubernetes APIに送信される前に、レンダリングされたテンプレートを検証します.これは、無効なフィールドが0以外の終了コードをトリガーし、リリースに失敗したことを意味します.フィールド不足は同じにつながる.
ラベルと注釈は[移行されたKubernetesオブジェクトに追加されなかった]を手動で追加する必要があります.

$ kubectl -n ${NAMESPACE} label deployment -l "app.kubernetes.io/instance=${RELEASE}" "app.kubernetes.io/managed-by=Helm"
$ kubectl -n ${NAMESPACE} annotate deployment -l "app.kubernetes.io/instance=${RELEASE}" "meta.helm.sh/release-name=${RELEASE}" "meta.helm.sh/release-namespace=${NAMESPACE}"

⚠️ ステージ4で有効なラベルと注釈の例

metadata:
  labels:
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: Helm
  annotations:
    meta.helm.sh/release-name: {{ .Release.Name }}
    meta.helm.sh/release-namespace: {{ .Release.Namespace }}

我々が完全にヘルムのバージョン2に頼る前に、我々はTillerが我々のクラスタにインストールされたので、我々は省略するかもしれません--tiller-out-cluster flag . 最も安全な方法--dry-run フラグ(シミュレーションのみ).

⚓ ステージ5。成功したかどうか調べる

ヘルムv 3は、次のように動作しますkubectl . ヘルムV 2では、すべての名前空間全体のすべてのリリースを入力するだけで入力することができますhelm2 ls . ヘルムV 3、ランニングhelm3 list は、デフォルトの名前空間のリリースだけを表示しますkubectl get pods でしょう.
デフォルトでない名前空間のリリースを一覧表示するには、-n 引数と名前空間は、Kubectlを使うときと同じです.

$ helm3 list -n <namespace>

⚓ ステージ6。ヘルムv 2クリーンアップ

指定しなかったので--delete-v2-releases flag , ヘルムV 2のリリース情報は、Tactで残っていた、それは後でヘルム3ツー3クリーンアップで削除することができます.

⚓ 7番線。バイバイティラー

結局、私たちはクラスタから耕うんを取り除くことができます.

$ kubectl delete deployment tiller-deploy --namespace kube-system

🔱 あなたのCISをチェックしてください

いくつかのCLIコマンドはヘルムv 3で改名されましたhelm2 delete はhelm3 uninstall , しかし、最初のものはhelm3 uninstall . また、ヘルム--purge フラグは、リリース設定を削除します.ヘルムv 3では、この機能はデフォルトで有効になっています.前の動作を保持するには、helm3 uninstall --keep-history .helm2 inspect コマンドをhelm3 show .helm2 fetch コマンドをhelm3 pull .

🔱 あなたのYAMLをチェックしてください

チャートのKubernetesのときapiVersion がv2 それは使用していることを意味するv2 ヘルムv 3で導入されるスキーマ.したがって、apiVersion: v2 はヘルムV 2ではレンダリングされない.あなたがより多くの互換性を必要とするならばv1 はい.
参考にしてください.PICのソース🇫🇷
あなたに無痛の移行!
ハッピーチャート!