|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
自動アップグレード
概要
RancherのUpgrade Controllerを使用してK3sクラスターのアップグレードを管理できます。これはクラスターアップグレードのためのKubernetesネイティブなアプローチです。https://github.com/rancher/system-upgrade-controller/blob/master/doc/plan.md#planspec[Plan]カスタムリソースを利用して、どのノードをアップグレードし、どのバージョンにするかを宣言的に記述します。
プランはアップグレードポリシーと要件を定義します。また、https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/[ラベルセレクター]を通じてどのノードをアップグレードすべきかを定義します。K3sクラスターのアップグレードに適したデフォルトのプランについては、以下を参照してください。より高度なプラン設定オプションについては、上記のプランのドキュメントを参照してください。
システムアップグレードコントローラーは、プランを監視し、アップグレードhttps://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/[ジョブ]を実行するノードを選択することによってアップグレードをスケジュールします。ジョブが正常に完了すると、コントローラーはそれが実行されたノードに適切なラベルを付けます。
|
K3sクラスターがRancherによって管理されている場合、アップグレードを管理するためにRancher UIを使用する必要があります。
|
システムアップグレードコントローラーの使用
アップグレードを自動化するには、次のことを行う必要があります。
-
システムアップグレードコントローラーをクラスターにインストールします。
-
どのノードグループをアップグレードし、どのようにアップグレードするかを説明するプランを作成します。
システムアップグレードコントローラーの設計とアーキテクチャ、またはK3sとの統合に関する詳細については、以下のGitリポジトリを参照してください：
|
新しいバージョンのK3sにアップグレードしようとする際には、https://kubernetes.io/docs/setup/release/version-skew-policy/[Kubernetesバージョンのポリシー]が適用されます。アップグレード時に中間のマイナーバージョンをスキップしないように、プランを確認してください。システムアップグレードコントローラー自体は、Kubernetesバージョンへのサポートされていない変更から保護しません。 |
インストール
システムアップグレードコントローラーのマニフェストは、カスタムリソース定義、デプロイメント、サービスアカウント、クラスター役割バインディング、およびコンフィグマップをインストールします。これらのコンポーネントをインストールするには、次のコマンドを実行します：
kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/crd.yaml -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yamlコントローラーは、前述のコンフィグマップを介して設定およびカスタマイズできますが、変更を適用するにはコントローラーポッドを削除する必要があります。
設定
サーバーノードは常にエージェントノードの前にアップグレードする必要があります。この理由から、サーバー（コントロールプレーン）ノードをアップグレードするための計画と、エージェントノードをアップグレードするための計画の少なくとも2つを作成することをお勧めします。ノード全体でのアップグレードの展開を制御するために、必要に応じて追加の計画を作成できます。プランが作成された後、コントローラーはそれらを取得し、クラスターのアップグレードを開始します。
以下の2つの例のプランは、安定したリリースチャネルをターゲットにして、クラスターを現在の安定リリースに継続的にアップグレードします：
# Server plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: server-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: In
values:
- "true"
serviceAccountName: system-upgrade
upgrade:
image: rancher/k3s-upgrade
channel: https://update.k3s.io/v1-release/channels/stable
---
# Agent plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: agent-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: DoesNotExist
prepare:
args:
- prepare
- server-plan
image: rancher/k3s-upgrade
serviceAccountName: system-upgrade
upgrade:
image: rancher/k3s-upgrade
channel: https://update.k3s.io/v1-release/channels/stableこれらのプランに関して重要な点がいくつかあります：
-
プランは、コントローラーがデプロイされているのと同じネームスペースで作成する必要があります。
-
`concurrency`フィールドは、同時にアップグレードできるノードの数を示します。
-
サーバープランは、`node-role.kubernetes.io/control-plane`ラベルを持つノードを選択するラベルセレクターを指定することによってサーバーノードをターゲットにします。エージェントプランは、ラベルを指定するセレクターを使用して、ラベルのないノードを選択することによってエージェントノードをターゲットにします。
-
エージェントプランの`prepare`ステップは、そのプランのアップグレードジョブがサーバープランの完了を待つようにします。このロジックは、準備ステップで使用されるイメージに組み込まれており、システムアップグレードコントローラー自体の一部ではありません。
-
両方のプランは、`channel`フィールドが安定版リリースチャネルのURLに設定されています。これにより、コントローラーはそのURLを監視し、新しいリリースに解決されるたびにクラスターをアップグレードします。これは、リリースチャネルとよく機能します。したがって、次のチャネルでプランを構成することで、クラスターが常に最新の安定版K3sに自動的にアップグレードされることを保証できます。または、`channel`フィールドを省略し、`version`フィールドを特定のK3sリリースに設定することもできます：
apiVersion: upgrade.cattle.io/v1 kind: Plan # ... spec: # ... version: v1.33.4+k3s1
アップグレードは、コントローラーがプランのターゲットバージョンが解決されたことを検出するとすぐに開始されます。これは、バージョンフィールドから、またはチャネルサーバーをポーリングすることによって行われます。プランを変更すると、コントローラーはプランを再評価し、別のアップグレードが必要かどうかを判断します。チャネルが構成されている場合、URLも定期的にポーリングされて新しいバージョンをチェックします。
アップグレードの進行状況は、kubectlを介してプランとジョブを表示することで監視できます：
kubectl -n system-upgrade get plans -o wide
kubectl -n system-upgrade get jobsアップグレードのスケジューリング
プラン仕様内の`window`フィールドを設定することにより、プランが特定の時間ウィンドウ内で発生するように制限できます。時間ウィンドウフィールドは、https://kured.dev/docs/configuration/#setting-a-schedule[kuredスケジュールオプション]と互換性があり、同じ形式を取ります。次に例を示します。
apiVersion: upgrade.cattle.io/v1
kind: Plan
# ...
spec:
# ...
window:
days:
- monday
- tuesday
- wednesday
- thursday
- friday
startTime: 19:00
endTime: 21:00
timeZone: UTCプランのアップグレードを実行するためのジョブは、時間ウィンドウの外では作成されません。ジョブが作成された後、プランはウィンドウが閉じた後も実行を続けることがあります。
ダウングレード防止
|
バージョンゲート
2023-07リリースから開始します（https://github.com/k3s-io/k3s-upgrade/releases/tag/v1.27.4%2Bk3s1[v1.27.4+k3s1], v1.26.7+k3s1, v1.25.12+k3s1, v1.24.16+k3s1) |
Kubernetesはコントロールプレーンコンポーネントのダウングレードをサポートしていません。アップグレードプランで使用されるk3s-upgradeイメージは、K3sのダウングレードを拒否し、プランが失敗します。プランに`cordon: true`が設定されているノードは、エラー後もコーデンされたままになります。
ここに、失敗したアップグレードポッドとコーデンされたノードを示す例のクラスターがあります：
$ kubectl get pods -n system-upgrade
NAME READY STATUS RESTARTS AGE
apply-k3s-server-on-ip-172-31-0-16-with-7af95590a5af8e8c3-2cdc6 0/1 Error 0 9m25s
apply-k3s-server-on-ip-172-31-10-23-with-7af95590a5af8e8c-9xvwg 0/1 Error 0 14m
apply-k3s-server-on-ip-172-31-13-213-with-7af95590a5af8e8-8j72v 0/1 Error 0 18m
system-upgrade-controller-7c4b84d5d9-kkzr6 1/1 Running 0 20m
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-31-0-16 Ready,SchedulingDisabled control-plane,etcd,master 19h v1.27.4+k3s1
ip-172-31-10-23 Ready,SchedulingDisabled control-plane,etcd,master 19h v1.27.4+k3s1
ip-172-31-13-213 Ready,SchedulingDisabled control-plane,etcd,master 19h v1.27.4+k3s1
ip-172-31-2-13 Ready <none> 19h v1.27.4+k3s1コーデンされたノードをサービスに戻すには、次のいずれかの方法を使用できます：
-
プランのバージョンまたはチャネルを変更して、クラスターで現在実行中のものと同じか新しいリリースをターゲットにすることで、プランが成功するようにします。
-
プランを削除し、ノードのコーデンを手動で解除します。 `kubectl get plan -n system-upgrade`を使用してプラン名を見つけ、その後`kubectl delete plan -n system-upgrade PLAN_NAME`を使用して削除します。プランが削除されたら、`kubectl uncordon NODE_NAME`を使用して各ノードのアンコーデンを行います。