翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

このガイドでは、クラスター管理者が Amazon EKSアップグレード戦略を計画および実行する方法について説明します。また、セルフマネージド型ノード、マネージド型ノードグループ、Karpenter ノード、Fargate ノードをアップグレードする方法について説明します。AnywhereEKS、セルフマネージド型 Kubernetes、AWSOutposts、またはAWSローカルゾーンに関するガイダンスは含まれません。

概要

Kubernetes バージョンには、コントロールプレーンとデータプレーンの両方が含まれます。円滑なオペレーションを実現するには、コントロールプレーンとデータプレーンの両方が 1.24 などの同じ Kubernetes マイナーバージョンを実行する必要があります。はコントロールプレーンAWSを管理およびアップグレードしますが、データプレーンのワーカーノードの更新はお客様の責任となります。

アップグレード前

Amazon で Kubernetes バージョンをアップグレードする場合はEKS、アップグレードを開始する前にいくつかの重要なポリシー、ツール、手順を実施する必要があります。

クラスターを保持する up-to-date

Kubernetes の更新を最新の状態に保つことは、Amazon の 責任共有モデルを反映した、安全で効率的なEKS環境にとって最も重要ですEKS。これらの戦略を運用ワークフローに統合することで、最新の機能と改善を最大限に活用する up-to-dateの安全なクラスターを維持する体制を整えることができます。戦術：

EKS リリースカレンダーを確認する

EKS Kubernetes リリースカレンダーを確認して、新しいバージョンがいつリリースされるか、特定のバージョンのサポートが終了するかを確認してください。一般的に、 は Kubernetes のマイナーバージョンを毎年 3 つEKSリリースし、各マイナーバージョンは約 14 か月間サポートされています。

さらに、アップストリーム Kubernetes リリース情報 を確認します。

責任共有モデルがクラスターのアップグレードにどのように適用されるかを理解する

クラスターコントロールプレーンとデータプレーンの両方のアップグレードを開始する責任があります。アップグレードを開始する方法について説明します。クラスターのアップグレードを開始すると、 はクラスターコントロールプレーンのアップグレードAWSを管理します。Fargate ポッドやアドオン など、データプレーンのアップグレードはお客様の責任となります。クラスターで実行されているワークロードのアップグレードを検証して計画し、クラスターのアップグレード後に可用性とオペレーションに影響がないことを確認する必要があります。

クラスターをインプレースでアップグレードする

EKS は、インプレースクラスターアップグレード戦略をサポートします。これにより、クラスターリソースが維持され、クラスター設定が一貫して維持されます (APIエンドポイント、、OIDCENIs、ロードバランサーなど）。これはクラスターユーザーにとってそれほど破壊的ではなく、ワークロードを再デプロイしたり、外部リソース ( 、ストレージなど) を移行したりすることなくDNS、クラスター内の既存のワークロードとリソースを使用します。

インプレースクラスターアップグレードを実行する場合、一度に実行できるマイナーバージョンアップグレードは 1 つだけであることに注意してください (例: 1.24 から 1.25)。

つまり、複数のバージョンを更新する必要がある場合は、一連のシーケンシャルアップグレードが必要になります。シーケンシャルアップグレードの計画はより複雑であり、ダウンタイムのリスクが高くなります。この場合は、「」を参照してくださいインプレースクラスターアップグレードの代替としてブルー/グリーンクラスターを評価する。

コントロールプレーンとデータプレーンを順番にアップグレードする

クラスターをアップグレードするには、次のアクションを実行する必要があります。

EKS ドキュメントを使用してアップグレードチェックリストを作成する

EKS Kubernetes バージョンドキュメントには、バージョンごとの変更の詳細なリストが含まれています。アップグレードごとにチェックリストを作成します。

特定のEKSバージョンアップグレードのガイダンスについては、ドキュメントで各バージョンに特筆すべき変更点と考慮事項を確認してください。

Kubernetes を使用してアドオンとコンポーネントをアップグレードする API

クラスターをアップグレードする前に、使用している Kubernetes コンポーネントのバージョンを理解しておく必要があります。クラスターコンポーネントをインベントリし、Kubernetes APIを直接使用するコンポーネントを特定します。これには、モニタリングおよびログ記録エージェント、クラスターオートスケーラー、コンテナストレージドライバー (、 などEBSCSIEFSCSI）、イングレスコントローラー、Kubernetes APIに直接依存するその他のワークロードやアドオンなどの重要なクラスターコンポーネントが含まれます。

kubectl get ns | grep '-system'

Kubernetes に依存するコンポーネントを特定したらAPI、そのドキュメントでバージョンの互換性とアップグレード要件を確認してください。例えば、バージョンの互換性については、AWSLoad Balancerコントローラーのドキュメントを参照してください。一部のコンポーネントは、クラスターのアップグレードに進む前にアップグレードまたは設定の変更が必要になる場合があります。チェックすべき重要なコンポーネントには、 Core DNS、kube-proxy 、VPCCNI、ストレージドライバーなどがあります。

クラスターには、Kubernetes を使用する多くのワークロードが含まれていることが多く、進入コントローラー、継続的デリバリーシステム、モニタリングツールなどのワークロード機能にAPI必要です。EKS クラスターをアップグレードするときは、アドオンとサードパーティーのツールもアップグレードして、互換性があることを確認する必要があります。

一般的なアドオンの例と、関連するアップグレードドキュメントを参照してください。

アップグレード前に基本EKS要件を確認する

AWS では、アップグレードプロセスを完了するために、アカウント内の特定のリソースが必要です。これらのリソースが存在しない場合、クラスターをアップグレードすることはできません。コントロールプレーンのアップグレードには、次のリソースが必要です。

使用可能な IP アドレスを確認する

クラスターを更新するには、Amazon では、クラスターの作成時に指定したサブネットから最大 5 つの使用可能な IP アドレスEKSが必要です。

サブネットにクラスターをアップグレードするのに十分な IP アドレスがあることを確認するには、次のコマンドを実行します。

CLUSTER=<cluster name>
aws ec2 describe-subnets --subnet-ids \
  $(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.resourcesVpcConfig.subnetIds' \
  --output text) \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \
  --output table

----------------------------------------------------
|                  DescribeSubnets                 |
+---------------------------+--------------+-------+
|  subnet-067fa8ee8476abbd6 |  us-east-1a  |  8184 |
|  subnet-0056f7403b17d2b43 |  us-east-1b  |  8153 |
|  subnet-09586f8fb3addbc8c |  us-east-1a  |  8120 |
|  subnet-047f3d276a22c6bce |  us-east-1b  |  8184 |
+---------------------------+--------------+-------+

VPC CNI Metrics Helper を使用して、VPCメトリクスの CloudWatch ダッシュボードを作成できます。クラスターの作成時に最初に指定されたサブネットの IP アドレスが不足している場合は、Kubernetes バージョンアップグレードAPIを開始する前にUpdateClusterConfiguration「」を使用してクラスターサブネットを更新EKSすることをお勧めします。新しいサブネットが提供されることを確認してください。

既存のCIDRブロックの IP アドレスがなくなった場合は、追加のVPCCIDRブロックの関連付けを検討してください。AWS では、追加のCIDRブロックを既存のクラスター に関連付けることができVPC、IP アドレスプールを効果的に拡張できます。この拡張は、追加のプライベート IP 範囲 (RFC 1918) を導入するか、必要に応じてパブリック IP 範囲 ( 1918 年以外RFC) を導入することで実現できます。Amazon が新しい を使用する前にEKS、新しいVPCCIDRブロックを追加し、VPC更新の完了を許可する必要がありますCIDR。その後、新しく設定されたCIDRブロックに基づいてサブネットを に更新できますVPC。

EKS IAM ロールを検証する

IAM ロールが使用可能で、アカウントで正しいロールの引き受けポリシーがあることを確認するには、次のコマンドを実行します。

CLUSTER=<cluster name>
ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.roleArn' --output text)
aws iam get-role --role-name ${ROLE_ARN##*/} \
  --query 'Role.AssumeRolePolicyDocument'

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

EKS アドオンに移行する

Amazon は、Kubernetes、、kube-proxyおよび CoreDNS 用の Amazon VPCCNIプラグインなどのアドオンをクラスターごとにEKS自動的にインストールします。アドオンは、セルフマネージド型でも、Amazon EKS アドオンとしてインストールすることもできます。Amazon EKS アドオンは、 EKS を使用してアドオンを管理する代替方法ですAPI。

Amazon EKS アドオンを使用して、1 つのコマンドでバージョンを更新できます。例:

aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \
--service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE

以下を含むEKSアドオンがあるかどうかを確認します。

aws eks list-addons --cluster-name <cluster name>

EKSアドオンとして利用可能なコンポーネントと、使用を開始する方法について説明します。

EKSアドオンにカスタム設定を提供する方法について説明します。

コントロールプレーンをアップグレードする前に、削除されたAPI使用状況を特定して修正する

EKS コントロールプレーンをアップグレードAPIsする前に、削除された APIの使用を特定する必要があります。そのためには、実行中のクラスターまたは静的にレンダリングされた Kubernetes マニフェストファイルをチェックできるツールを使用することをお勧めします。

静的マニフェストファイルに対してチェックを実行する方が一般的に正確です。ライブクラスターに対して実行した場合、これらのツールは誤検出を返す可能性があります。

非推奨の Kubernetes APIは、 API が削除されたことを意味するものではありません。Kubernetes 非推奨ポリシーを確認して、API削除がワークロードにどのように影響するかを理解する必要があります。

クラスターインサイト

Cluster Insights は、EKSクラスターを新しいバージョンの Kubernetes にアップグレードする機能に影響を与える可能性のある問題に関する検出結果を提供する機能です。これらの検出結果は Amazon によってキュレーションおよび管理EKSされ、修正方法に関する推奨事項を提供します。Cluster Insights を活用することで、新しい Kubernetes バージョンへのアップグレードにかかる労力を最小限に抑えることができます。

EKS クラスターのインサイトを表示するには、 コマンドを実行します。

aws eks list-insights --region <region-code> --cluster-name <my-cluster>

{
    "insights": [
        {
            "category": "UPGRADE_READINESS",
            "name": "Deprecated APIs removed in Kubernetes v1.29",
            "insightStatus": {
                "status": "PASSING",
                "reason": "No deprecated API usage detected within the last 30 days."
            },
            "kubernetesVersion": "1.29",
            "lastTransitionTime": 1698774710.0,
            "lastRefreshTime": 1700157422.0,
            "id": "123e4567-e89b-42d3-a456-579642341238",
            "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact."
        }
    ]
}

受信したインサイトに関するよりわかりやすい出力については、 コマンドを実行できます。

aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>

Amazon EKSコンソール でインサイトを表示するオプションもあります。クラスターリストからクラスターを選択すると、インサイトの検出結果は Upgrade Insightsタブの下に表示されます。

でクラスターインサイトが見つかった場合は"status": ERROR、クラスターのアップグレードを実行する前に問題に対処する必要があります。aws eks describe-insight コマンドを実行して、次の修復アドバイスを共有します。

影響を受けるリソース：

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

APIs 非推奨：

"deprecationDetails": [
      {
        "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas",
        "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas",
        "stopServingVersion": "1.29",
        "clientStats": [],
        "startServingReplacementVersion": "1.26"
      }
]

推奨されるアクション：

"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."

EKS コンソールを通じてクラスターインサイトを活用するか、EKSクラスターバージョンを正常にアップグレードするプロセスを高速化CLIします。詳細については、次のリソースを参照してください。* 公式EKSドキュメント * クラスターインサイト起動ブログ 。

Kube-no-trouble

Kube-no-trouble は、 コマンド を持つオープンソースのコマンドラインユーティリティですkubent。引数kubentなしで を実行すると、現在の KubeConfigコンテキストを使用し、クラスターをスキャンして、廃止および削除される内容を含むレポートを印刷APIsします。

kubent

4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d
4:l INF Retrieved 93 resources from collector name=Cluster
4:17PM INF Retrieved 16 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
4:17PM INF Loaded ruleset name=deprecated-1-25.rego
4:17PM INF Loaded ruleset name=deprecated-1-26.rego
4:17PM INF Loaded ruleset name=deprecated-future.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME             API_VERSION      REPLACE_WITH (SINCE)
PodSecurityPolicy   <undefined>   eks.privileged   policy/v1beta1   <removed> (1.21.0)

また、静的マニフェストファイルや helm パッケージのスキャンにも使用できます。マニフェストがデプロイされる前に問題を特定するために、継続的統合 (CI) プロセスkubentの一部として を実行することをお勧めします。マニフェストのスキャンは、ライブクラスターのスキャンよりも正確です。

Kube-no-trouble は、サンプルサービスアカウントとロールに、クラスターをスキャンするための適切なアクセス許可を提供します。

冥王星

もう kubent 1 つのオプションは https://pluto.docs.fairwinds.com/冥王星です。これは、ライブクラスター、マニフェストファイル、ヘルムチャートのスキャンをサポートし、CI プロセスに含めることができる GitHub アクションがあるため、 に似ています。

pluto detect-all-in-cluster

NAME             KIND                VERSION          REPLACEMENT   REMOVED   DEPRECATED   REPL AVAIL
eks.privileged   PodSecurityPolicy   policy/v1beta1                 false     true         true

リソース

アップグレードAPIs前にクラスターが廃止されていないことを確認するには、以下をモニタリングする必要があります。

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1

CLUSTER="<cluster_name>"
QUERY_ID=$(aws logs start-query \
 --log-group-name /aws/eks/${CLUSTER}/cluster \
 --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \
 --end-time $(date "+%s") \
 --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \
 --query queryId --output text)

echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query

aws logs get-query-results --query-id $QUERY_ID

非推奨の場合に行APIsを出力します。

{
    "results": [
        [
            {
                "field": "@message",
                "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}"
            },
[...]

Kubernetes ワークロードを更新します。kubectl-convert を使用してマニフェストを更新する

更新する必要があるワークロードとマニフェストを特定したら、マニフェストファイル内のリソースタイプ ( など PodSecurityStandards) PodSecurityPolicies を変更する必要があります。そのためには、置き換えるリソースに応じて、リソース仕様を更新し、追加の調査を行う必要があります。

リソースタイプが同じままでAPIバージョンを更新する必要がある場合は、 kubectl-convert コマンドを使用してマニフェストファイルを自動的に変換できます。例えば、古いデプロイを に変換しますapps/v1。詳細については、Kubernetes ウェブサイトの「kubectl 変換プラグインのインストール」を参照してください。

kubectl-convert -f <file> --output-version <group>/<version>

データプレーンのアップグレード中にワークロードの可用性 topologySpreadConstraints を確保するために PodDisruptionBudgets と を設定する

データプレーンのアップグレード中にワークロードが確実に利用可能topologySpreadConstraintsになるように、ワークロードに適切な PodDisruptionBudgetsと があることを確認します。すべてのワークロードが同じレベルの可用性を必要とするわけではないため、ワークロードのスケールと要件を検証する必要があります。

ワークロードが複数のアベイラビリティーゾーンに分散され、トポロジースプレッドを持つ複数のホストに分散されていることを確認すると、ワークロードがインシデントなしで新しいデータプレーンに自動的に移行されるという信頼度が高まります。

これは、レプリカの 80% が常に利用可能で、レプリカをゾーンとホストに分散するワークロードの例です。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: "80%"
  selector:
    matchLabels:
      app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: myapp
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

AWS Resilience Hub では、サポートされているリソースとして Amazon Elastic Kubernetes Service (Amazon EKS) が追加されました。レジリエンスハブは、アプリケーションのレジリエンスを定義、検証、追跡するための単一の場所を提供するため、ソフトウェア、インフラストラクチャ、または運用の中断による不要なダウンタイムを回避できます。

Managed Node Groups または Karpenter を使用してデータプレーンのアップグレードを簡素化する

Managed Node Groups と Karpenter はどちらもノードのアップグレードを簡素化しますが、アプローチは異なります。

マネージド型ノードグループは、ノードのプロビジョニングとライフサイクル管理を自動化します。つまり、1 回のオペレーションでノードを作成、自動更新、終了できます。

デフォルト設定では、Karpenter は最新の互換性のある EKS Optimized を使用して新しいノードを自動的に作成しますAMI。EKS リリースがEKS最適化AMIsまたはクラスターがアップグレードされると、Karpenter は自動的にこれらのイメージの使用を開始します。Karpenter は、ノードを更新するために Node Expiry も実装します。

Karpenter は、カスタム を使用するように設定できますAMIs。Karpenter AMIsでカスタムを使用する場合は、kubelet のバージョンを担当します。

既存のノードとコントロールプレーンとのバージョン互換性を確認する

Amazon で Kubernetes アップグレードを進める前にEKS、マネージドノードグループ、セルフマネージドノード、コントロールプレーン間の互換性を確保することが重要です。互換性は使用している Kubernetes バージョンによって決まり、シナリオによって異なります。戦術：

Karpenter マネージドノードのノードの有効期限を有効にする

Karpenter がノードアップグレードを実装する 1 つの方法は、ノードの有効期限という概念を使用することです。これにより、ノードのアップグレードに必要な計画が削減されます。プロビジョナーでttlSecondsUntil期限切れの値を設定すると、ノードの有効期限が有効になります。ノードが定義された経過時間を数秒で経過すると、ノードは安全にドレインおよび削除されます。これは、ノードが使用中であっても当てはまります。ノードを新しくプロビジョニングされたアップグレードされたインスタンスに置き換えることができます。ノードが置き換えられると、Karpenter は最新の EKSに最適化された を使用しますAMIs。詳細については、Karpenter ウェブサイトの「プロビジョニングの解除」を参照してください。

Karpenter は、この値にジッターを自動的に追加しません。ワークロードの過剰な中断を防ぐには、Kubernetes ドキュメントに示すように、ポッドの中断予算 を定義します。

プロビジョナーでttlSecondsUntil期限切れを設定する場合、これはプロビジョナーに関連付けられた既存のノードに適用されます。

Karpenter マネージドノードにドリフト機能を使用する

Karpenter の Drift 機能を使用すると、Karpenter でプロビジョニングされたノードを自動的にアップグレードして、EKSコントロールプレーンと同期させることができます。Karpenter Drift は現在、機能ゲート を使用して有効にする必要があります。Karpenter のデフォルト設定では、EKSクラスターのコントロールプレーンと同じメジャーバージョンとマイナーバージョンAMIに対して最新の EKS-Optimized を使用します。

EKS クラスターのアップグレードが完了すると、Karpenter の Drift 機能は、Karpenter がプロビジョニングしたノードが以前のクラスターバージョンAMIsに EKS-Optimized を使用していることを検出し、それらのノードを自動的にコード、ドレイン、および置き換えます。新しいノードへのポッドの移動をサポートするには、適切なポッドリソースクォータ を設定し、ポッド中断予算 () を使用して、Kubernetes のベストプラクティスに従いますPDB。Karpenter のプロビジョニング解除は、ポッドリソースリクエストに基づいて交換ノードを事前にスピンアップし、ノードのプロビジョニング解除PDBs時に を尊重します。

eksctl を使用してセルフマネージド型ノードグループのアップグレードを自動化する

セルフマネージド型ノードグループは、アカウントにデプロイされ、EKSサービス外のクラスターにアタッチされたEC2インスタンスです。これらは通常、何らかのオートメーションツールによってデプロイおよび管理されます。セルフマネージド型ノードグループをアップグレードするには、ツールのドキュメントを参照してください。

例えば、eksctl はセルフマネージド型ノードの削除とドレインをサポートしています。

一般的なツールには、次のようなものがあります。

アップグレード前にクラスターをバックアップする

新しいバージョンの Kubernetes では、Amazon EKSクラスターに大きな変更が加えられます。クラスターをアップグレードした後は、ダウングレードできません。

Velero は、コミュニティがサポートするオープンソースツールで、既存のクラスターのバックアップを取得し、新しいクラスターにバックアップを適用するために使用できます。

現在 でサポートされている Kubernetes バージョンの新しいクラスターのみを作成できることに注意してくださいEKS。クラスターが現在実行しているバージョンが引き続きサポートされており、アップグレードが失敗した場合、元のバージョンで新しいクラスターを作成し、データプレーンを復元できます。を含むAWSリソースはIAM、Velero によるバックアップに含まれていないことに注意してください。これらのリソースは再作成する必要があります。

コントロールプレーンのアップグレード後に Fargate デプロイを再起動する

Fargate データプレーンノードをアップグレードするには、ワークロードを再デプロイする必要があります。-o wide オプションですべてのポッドを一覧表示することで、ファーゲートノードで実行されているワークロードを特定できます。で始まるノード名fargate-は、クラスターに再デプロイする必要があります。

インプレースクラスターアップグレードの代替としてブルー/グリーンクラスターを評価する

一部のお客様は、ブルー/グリーンアップグレード戦略の実行を好みます。これには利点がありますが、考慮すべき欠点も含まれます。

利点は次のとおりです。

欠点には、次のようなものがあります。

この戦略は可能ですが、インプレースアップグレードよりもコストがかかり、調整やワークロードの移行により多くの時間が必要です。状況によっては必要になる場合があり、慎重に計画する必要があります。

のような高度な自動化と宣言システムを使用すると GitOps、これが容易になる場合があります。データをバックアップして新しいクラスターに移行するには、ステートフルワークロードに対して追加の予防措置を講じる必要があります。

詳細については、以下のブログ記事を参照してください。

Kubernetes プロジェクトで計画された大きな変更を追跡する — 先を考える

次のバージョンだけを見ないでください。リリースされた Kubernetes の新しいバージョンを確認し、大きな変更を特定します。例えば、一部のアプリケーションは docker を直接使用しておりAPI、Docker (Dockershim とも呼ばれますCRI) の Container Runtime Interface () のサポートが Kubernetes で削除されました1.24。このような変更には、準備により多くの時間が必要です。

アップグレード先のバージョンの文書化されたすべての変更を確認し、必要なアップグレードステップをメモします。また、Amazon EKSマネージドクラスターに固有の要件や手順についても注意してください。

機能の削除に関する具体的なガイダンス

1.25 での Dockershim の削除 - Detector for Docker Socket の使用 (DDS）

EKS Optimized AMI for 1.25 には Dockershim のサポートが含まれなくなりました。Dockershim に依存関係がある場合、例えば Docker ソケットをマウントする場合、ワーカーノードを 1.25 にアップグレードする前に、これらの依存関係を削除する必要があります。

1.25 にアップグレードする前に、Docker ソケットに依存しているインスタンスを見つけます。Detector for Docker Socket (DDS）、kubectl プラグインを使用することをお勧めします。

1.25 PodSecurityPolicy の の削除 - Pod セキュリティ標準または policy-as-codeソリューションへの移行

PodSecurityPolicy は Kubernetes 1.21 では廃止され、Kubernetes 1.25 では削除されました。クラスター PodSecurityPolicy で を使用している場合は、ワークロードの中断を避けるため、 policy-as-codeクラスターをバージョン 1.25 にアップグレードする前に、組み込みの Kubernetes Pod セキュリティ標準 (PSS) または ソリューションに移行する必要があります。

AWS は、 EKSドキュメントFAQで詳細な を発行しました。

Pod Security Standards (PSS) と Pod Security Admission (PSA） のベストプラクティスを確認します。

Kubernetes ウェブサイトのPodSecurityPolicy非推奨ブログ記事を確認してください。

1.23 でのツリー内ストレージドライバーの廃止 - コンテナストレージインターフェイス (CSI) ドライバーへの移行

Container Storage Interface (CSI) は、Kubernetes が既存のツリー内ストレージドライバーメカニズムを置き換えるのに役立つように設計されています。Amazon EBSコンテナストレージインターフェイス (CSI) の移行機能は、Amazon EKS1.23以降のクラスターでデフォルトで有効になっています。バージョン 1.22以前のクラスターでポッドを実行している場合は、サービスの中断を避けるため1.23、クラスターをバージョン に更新する前に Amazon EBSCSIドライバーをインストールする必要があります。

Amazon EBSCSI移行に関するよくある質問 を確認します。

その他のリソース

ClowdHaus EKS アップグレードガイダンス

ClowdHaus EKS Upgrade Guidance はCLI、Amazon EKSクラスターのアップグレードに役立つ です。クラスターを分析して、アップグレード前に修正すべき潜在的な問題がないか調べることができます。

GoNoGo

GoNoGo は、クラスターアドオンのアップグレードの信頼性を判断するためのアルファステージツールです。

📝 このページを で編集する GitHub