🎯 レッスンの目的
ReplicaSet が Pod レプリカの数を確保する方法、デプロイメントが純粋な ReplicaSet よりも優れている理由、ローリング アップデートとロールバックを安全に実行する方法、および一般的なデプロイメント戦略を理解します。
1.レプリカセット
ReplicaSet は、指定された数のポッド レプリカが常に実行されるようにします。 Pod が削除されたりクラッシュした場合、ReplicaSet は新しい Pod を作成して補います。
___コードブロック_0___ReplicaSet は、__HTMLTAG_10___ラベル セレクター を使用して、管理するポッドを認識します。ただし、ReplicaSet を直接作成することはほとんどなく、代わりに Deployment を使用します。
2.導入 — ReplicaSet より優れているのはなぜですか?
Deployment は ReplicaSet よりも高レベルの抽象化であり、次のことが可能です。
- 宣言的な更新: 望ましい状態を宣言するだけで、残りはデプロイメントが処理します
- ローリングアップデート: ダウンタイムゼロの導入
- 改訂履歴: 更新履歴を保存し、ロールバックを許可
- 一時停止/再開: ロールアウトは一時停止できます
3.ローリングアップデート
ローリング アップデートでは、古いポッドが新しいポッドに徐々に置き換えられ、ダウンタイムが発生しません。
___コードブロック_2___maxSurge あり: 2 および max 利用不可: 5 つのレプリカで 1:
- 最大 7 つのポッドが同時に存在します (5 + 2 サージ)
- 最低 4 つのポッドが利用可能 (5 ～ 1 つは利用不可)
- Kubernetes は古いポッドの終了と並行して新しいポッドを作成します__HTMLTAG_51___
4.戦略を再作成
新しいポッドを作成する前に、古いポッドをすべて削除してください。 ダウンタイムはあります が、シンプルでバージョン管理の競合はありません。
___コードブロック_3___次の場合に使用します: データベースの移行には単一のインスタンスが必要で、2 つのバージョンの並行実行は受け入れられません。
5.改訂履歴とロールバック
___コードブロック_4___保存されるリビジョンの数は、__HTMLTAG_64___spec.revisionHistoryLimit (デフォルトは 10) によって制御されます。
6.ロールアウトの一時停止と再開
___コードブロック_5___7.ブルー/グリーン展開
新しいバージョンを古いバージョンと並行して展開し、すべてのトラフィックを新しいバージョンに転送します。
___コードブロック_6___ ___コードブロック_7___8.カナリア デプロイメント
テストのためにトラフィックの一部を新しいバージョンに送信します。
___コードブロック_8___9。スケーリング
___コードブロック_9___10.導入のアンチパターンは回避する必要があります
- ❌ リソースのリクエスト/制限を設定しない → ノードに圧力がかかるとポッドが削除される
- ❌ readinessProbe がありません → ポッドへのトラフィックの準備ができていません
- ❌
maxUnavailable: 0およびmaxSurge: 0同時に → 無効 - ❌
最新画像タグを使用 → 再現できません - ❌
revisionHistoryLimit: 0→ ロールバックできません
概要
- Deployment は ReplicaSet を管理します。ReplicaSet を直接作成しないでください
- ローリング アップデート: ダウンタイムゼロ、maxSurge と maxUnavailable を調整
kubectl ロールアウトを元に戻す によるロールバック
- 青/緑: 即時切り替え、2 倍のリソースが必要__HTMLTAG_113___
- _Canary: 段階的なロールアウト、レプリカ数によるトラフィック % の制御__HTMLTAG_115___