Amazon EKS 1.20 がリリースされました

この記事は Amazon EKS 1.20 Released を翻訳したものです。

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Kubernetes 1.20 のサポートを発表できることを嬉しく思います。私は 2020 年の 9 月から 12 月まで、このリリースのアップストリームのリリースチームを務めるという特権に恵まれました。Amazon EKS のお客様が “The Raddest Release” (訳注: 最高のリリース) のその素晴らしさを体験できることを楽しみにしています。

Kubernetes 1.20 Official Release Logo. © The Kubernetes Authors CC BY 4.0

EKS チームにとって、新しいリリースをより迅速に提供することは優先事項であり、今回のリリースをもって、次のリリースに向けての作業に取り掛かります。アップストリームの Kubernetes プロジェクトは、最近、年に 4 回のリリースから年に 3 回のリリースへと移行しました。この変更はプロジェクトの継続的な成熟と相まって、より大きな機能を含んだリリースにつながるでしょう。EKS チームは、EKS ですべての新機能が簡単に使えるように、引き続き取り組んでいきます。

また、今回のリリースは EKS 1.15 のサポート終了を意味します。Kubernetes 1.16 では、多くの非推奨 API が削除されているため、アップグレードが特に難しいバージョンとなっています。1.16 へのアップグレードの準備に関するブログ記事と、将来の予定について Amazon EKS リリースカレンダーを確認してください。

Kubernetes 1.20 のハイライト

詳細については、アップストリームのブログ記事とリリースノートをご覧ください。この記事では、いくつかのハイライトを紹介します。

Kubernetes の機能は、リリースフェーズによって制限されています。アルファ機能は最先端の機能であり、短期間のテストにのみ推奨されます。これらは通常、デフォルトでは無効になっており、任意の時点で変更または削除される可能性があります。ベータ機能は、デフォルトで有効になっていることが多く、安全に使用できると考えられています。リソースの構造は変更される可能性がありますが、フィードバックを提供し、機能改善を支援するのに最適な時期です。安定版の機能は一般提供されており、安心して利用できます。安定版の機能について、現在のメジャーバージョンでは、破壊的な変更はないはずです。EKS はリリース以来、安定版の機能とベータ機能をデフォルトで有効としてサポートしています。

TTL コントローラー

Kubernetes の Job は、長時間稼働するサービスやアプリケーションのための Deployment とは対照的に、処理が完了すると終了する短命のタスクを実行するためのワークロードです。Job は、レポートの作成やデータの抽出・変換・ロード (ETL) などのタスクによく使われます。デフォルトでは、Job が作成した Pod は完了後もクラスター内に残ります。これには、結果やログを確認できるようにするという意図がありますが、Pod のクリーンアップまたはそのためのツールを構築するのは、利用者の責任です。

TTL コントローラーは、Kubernetes 1.12 で初めて導入され、この問題を解決するのに役立ちます。これは、完了した Job をクリーンアップするための TTL (time-to-live) メカニズムを提供します。ジョブが Completed または Failed とマークされると、.spec.ttlSecondsAfterFinished の時間経過後に、その Job は (作成された Pod と一緒に) 削除されます。

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 # <-- TTL controller

TTL コントローラーは 1.21 でベータ版に移行しましたが、過去数回のリリースでは大きな変更はありませんでした。最も要望の多かった機能の 1 つであることから、徹底したテストが行われ、その結果 EKS 1.20 ではこのアルファ機能を有効にすることにしました。Amazon EKS on AWS Fargate では完了したタスクがクリーンアップされるまでコストが発生するため、この機能は特に便利です。

PID Limits が GA に移行

プロセス ID (PID) は、サーバー上で実行されているプロセスを表します。Linux のインストール環境によって PID Limits は異なり、利用可能なコンピューティングリソースの量に直接依存します。PID Limits 機能では、ノードごとおよび Pod ごとの制限を提供し、kubelet のフラグとして設定することができます (ノードに関して前述の注意が必要です) 。これらの制限により、オペレーティングシステム用に一定数の PID を予約することができ、Kubernetes ワークロードがシステムオペレーションを枯渇させるのを防ぐことができます。

Volume Snapshot が GA に移行

Container Storage Interface (CSI) は、クラスターに永続的なストレージをプロビジョニングする方法です。Amazon Elastic Block Store (Amazon EBS) CSI ドライバーをデプロイし、PersistentVolume を作成すると、コントローラーがユーザーに代わって EBS ボリュームをプロビジョニングします。EBS CSI ドライバーも最近 GA に移行しました。

EBS スナップショットは、EBS ボリューム上のデータの特定時点のバックアップです。クローンを作成したり、ディスクをロールバックしたりする方法として、スナップショットから新しい EBS ボリュームを作成できます。Kubernetes Volume Snapshot は、クラスターでネイティブの Kubernetes リソースを使用してこの機能を可能にします。EBS スナップショットの作成と使用の詳細については、このブログ記事を確認してください。

API Priority and Fairness がベータに移行

API Priority and Fairness (APF) は、ビジー状態のコントローラーや、オブザーバビリティツールのような Kubernetes API サーバーにリクエストを行うその他のアプリケーションからのトラフィックを分類し、重み付けする方法を提供します。これまでのソリューションでは、Kubernetes API サーバーにフラグを設定する必要がありましたが、EKS ではお客様定義のフラグをサポートしていませんでした。この機能は、API サーバーに殺到してリクエスト失敗の原因となるバースト的なトラフィックのような様々な問題に対処するために使用できる、より高度な機能です。

クラスター運用者は、リクエストのドロップや遅延が発生した場合、APF のきめ細かな制御を調整することができます。また、特定のエンドポイントまたはヘルスチェックやレディネスチェックなどのサービスに対して API のレート制限を無効にしたい場合には、そのメカニズムもあります。詳しくはドキュメントをご覧ください。

RootCAConfigMap がベータに移行

1.20 以降、すべての Namespace にデフォルトで新しい ConfigMap があることに気付くかもしれません。

$ kubectl create namespace dontpageme
namespace/dontpageme created

$ kubectl -n dontpageme get configmaps
NAME               DATA   AGE
kube-root-ca.crt   1      7s

$ kubectl -n dontpageme get configmaps kube-root-ca.crt -o yaml
apiVersion: v1
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
    notarealcertiamgoingtowalkmydogintheparbecauseheisagoodboyLUJefD
    [snip]
    IXK0CtsLWTuafWK9YU7NYyfMD6DHVEV3dwMeLnlMoK28YTwdKVrF20qUDUSmsEO0
    Xvd/tqXWqNMqDXkyCUbnqXYe3A/N6iaGHJjK
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  creationTimestamp: "2021-04-30T22:01:08Z"
  name: kube-root-ca.crt
  namespace: dontpageme
  resourceVersion: "775"
  uid: f672079e-cd60-4a02-86ba-426a295b2393

この ConfigMap には、Kubernetes API サーバーの認証局バンドルが含まれており、コントローラーやサービスが API リクエストを行うときに接続を検証できるようにします。これは、Service Account Token のセキュリティを向上させるための進行中の取り組みの一部です。

Dockershim の非推奨

数ヶ月前、これが初めてリリースノートに登場したときの Kubernetes ユーザーの議論を覚えているかもしれません。AWS の Developer Advocate の Justin Garrison による共著である Kubernetes Blog の Don’t Panic: Kubernetes and Docker では、この件について非常に詳しく説明しています。要するに、心配する必要はありません。クラスターで使われているコンテナランタイムは将来的に変わるかもしれませんが、Docker コンテナは引き続き動作しますので、コンテナランタイムが変わっても気にする必要はありません。kubelet の起動ログに表示される dockershim 非推奨の警告メッセージは無視しても問題ありません。EKS は、EKS optimized Amazon Linux 2 AMI のランタイムとして、最終的に containerd に移行する予定です。詳細については、Containers Roadmap の Issue をフォローしてください。

Amazon EKS 1.20 固有の変更点

Kubernetes バージョンのリリースごとに、いくつかの EKS 固有の変更点がある場合があります。これらは通常、他の AWS サービスとの相互運用性に焦点を当てています。EKS 1.20 からは、さまざまな Kubernetes コンポーネントに RBAC アクセス許可を提供するために、いくつかの新しいデフォルトの ServiceAccount と Role が作成されます。

Bottlerocket (AWS が構築したコンテナを実行するための Linux ベースのオープンソース OS) は、EKS 1.20 でカーネルバージョン 5.10 に更新されました。EKS optimized Bottlerocket AMI を使用して、クラスターでセルフマネージド型ノードを起動できます。そして AWS は、EKS のマネージド型ノードグループで Bottlerocket をネイティブサポートすることに懸命に取り組んでいます。

詳しくは、1.19 からの変更履歴と、EKS 1.20 のドキュメントをご覧ください。

ネクストステップ

1.19 からのアップグレード

1.19 から 1.20 へのアップグレードは、破壊的な変更がほとんどないため、非常に簡単なはずです。いつものように、まずアップグレードノートを確認してください。クラスターを最新の状態に保つことは、Kubernetes を使用する上で重要です。EKS は自動化されたアップグレードを提供しますが、チームは事前に計画を立てる必要があります。クラスターのアップグレードを開始するには、このブログ記事と Amazon EKS のドキュメントを参照してください。

アップグレードの計画

まだ Kubernetes 1.15 をお使いの場合は、アップグレードする時が来ました。サポートサイクルは 2021 年 5 月 3 日に終了し、コントロールプレーンは最終的に自動的にアップグレードされます。Amazon EKS の自動更新プロセスに依存せずに、事前にアクションを実行してコントロールプレーンを更新することをお勧めします。詳細については、バージョン廃止に関する FAQ を参照してください。Kubernetes 1.16 のサポートは 2021 年 7 月 25 日に終了します。サポート終了を待たずに今すぐアップグレードするのがベストです。詳細については、EKS リリースカレンダーを参照してください。

翻訳はプロフェッショナルサービスの杉田が担当しました。

Amazon Web Services ブログ