アップグレードのベスト・プラクティス

ベスト・プラクティス: 最新バージョンのKubernetesを使用

新しいKubernetesリリースには、通常、多くの更新、追加機能、および最も重要なのは、以前のバージョンのセキュリティ問題に対処するためのパッチが含まれています。Kubernetes Engineは、3つのマイナー・バージョンのKubernetesをサポートし、それらのバージョンごとに最新のパッチ・バージョンを提供します。

したがって、次の操作を行うことをお勧めします。

• 本番クラスタでは、常に最新の安定したバージョンのKubernetesが実行されます。
• Kubernetesエンジンを使用してクラスタを作成するときに、サポートされているKubernetesの最新マイナー・バージョンを指定します。
• OracleがKubernetesメジャー・バージョン、マイナー・バージョンまたはパッチ・バージョンのKubernetes Engineサポートを発表すると、既存のクラスタをアップグレードします。クラスタを定期的にアップグレードすると、クラスタが最新の機能および修正を含まない古いKubernetesバージョンを実行している状況を回避できます。

KubernetesバージョンおよびKubernetesエンジン(OKE)、新しいKubernetesバージョンへのクラスタのアップグレードを参照してください。

ベスト・プラクティス: テスト環境と本番環境の設定

アプリケーションのデプロイおよびリリースを行うワークフローの一部として、複数のKubernetesエンジン環境を使用することをお薦めします。複数の環境を使用すると、本番環境とは別の環境でソフトウェアおよびインフラストラクチャの更新をテストできるため、リスクおよび不要なダウンタイムを最小限に抑えることができます。少なくとも、本番環境と、本番前またはテスト環境をお薦めします。

また、クラスタを新しいバージョンのKubernetesにアップグレードする前に、クラスタにデプロイされているアプリケーションをテストし、アプリケーションが新しいKubernetesバージョンと互換性があることを確認することをお薦めします。コントロール・プレーン・ノードを新しいバージョンのKubernetesにアップグレードした後は、コントロール・プレーン・ノードを以前のバージョンのKubernetesにダウングレードできません。したがって、クラスタを新しいKubernetesバージョンにアップグレードする前にアプリケーションをテストすることが重要です。たとえば、クラスタをアップグレードする前に、新しいKubernetesバージョンを実行する別のクラスタを作成し、そのクラスタでアプリケーションをテストできます。

新しいKubernetesバージョンへのクラスタのアップグレードを参照してください。

ベスト・プラクティス: ブルー/グリーン・デプロイメント戦略の使用

ブルー/グリーン・デプロイメント戦略を使用して、Kubernetesクラスタをアップグレードする際のリスクを減らし、ダウンタイムを最小限に抑えることをお薦めします。青緑色のデプロイメントでは、「青」および「緑」と呼ばれる2つの本番環境を使用して、信頼性の高いテスト、継続的な停止なしのアップグレードおよび即時ロールバックを提供します。ブルー/グリーン・デプロイメント戦略を使用すると、ユーザーは1つの本番環境にアクセスでき、もう1つの本番環境が更新されます。

ベスト・プラクティス: メンテナンス・ウィンドウのスケジュール

オフピーク時間帯にメンテナンス・アクティビティをスケジュールして、クラスタ/ノードのアップグレードとメンテナンスによって発生するポッド中断を適切に処理しないアプリケーションへの影響を制限することをお薦めします。

たとえば、アップグレード中に、ノードを再作成するためにワークロードが移動されるときに一時的な中断が発生することがあります。可能な場合は、このような中断によって影響が最小限に抑えられるようにします。

• オフピーク時のアップグレードのスケジュール
• アプリケーション・デプロイメントの設計による部分的な中断のシームレスな処理

ベスト・プラクティス: ワーカー・ノードを不変として扱う

既存のワーカー・ノードを不変エンティティとして扱うことをお薦めします。

ノード・プールのワーカー・ノード・プロパティに対する変更は、その後に作成される新しいワーカー・ノードにのみ適用されます。既存のワーカー・ノードのプロパティは変更できません。

たとえば、既存のワーカー・ノードで実行されているOSイメージを更新するのではなく、OSイメージが更新されたワーカー・ノードを含む新しいノード・プールを作成することを検討してください。新しいポッドの開始を防止し、既存のポッドを削除するために、元のノード・プールのコードンおよびドレイン・オプションを指定した後、作業を元のノード・プールから新しいノード・プールにシフトできます。その後、元のノード・プールを削除できます。

「更新されたプロパティを持つワーカー・ノードの作成」を参照してください。

ベスト・プラクティス: メンテナンスに備えてワーカー・ノードをコードンおよびドレインします

ワーカー・ノードは、そのノードでのスケジュール済メンテナンスの前にコード化およびドレインすることをお薦めします。

コーディングにより、ワーカー・ノードがスケジュール不可能としてマークされ、kubeスケジューラがそのノードに新しいポッドを配置できなくなります。安全に排出すると、ワーカー・ノードからポッドが削除されます。これにより、コンテナが適切に終了し、必要なクリーンアップが実行されます。

終了前の管理対象ノードのコード化およびドレインに関するノートを参照してください。Kubernetesドキュメントの手動ノード管理およびノードの安全排出も参照してください。