Amazon EKS が Kubernetes 1.21 のサポートを開始

この記事は Amazon EKS now supports Kubernetes 1.21 を翻訳したものです。

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Kubernetes 1.21 のサポートを発表できることを嬉しく思います。私は 2021 年の 1 月から 4 月まで、このリリースのアップストリームのリリースチームに参加することができました。Amazon EKS のお客様が “Power to the Community” リリースを体験できることに興奮しています。

Kubernetes のランタイム変更と EKS

バージョン 1.20 では、Kubernetes がコンテナランタイムとして Docker を使用できるようにする Dockershim が非推奨となりました。Docker は引き続き完全に機能しますが、将来の Kubernetes のリリースでサポートが削除される前に、ユーザーは別のコンテナランタイムに移行する必要があります。

Amazon EKS チームは、お客様がランタイムを containerd に移行するための明確な道筋を確保することに懸命に取り組んできました。1.21 のリリースでは、Amazon Linux 2 EKS optimized AMI イメージに containerd のサポートが組み込まれています。1.21 のデフォルトランタイムは Docker のままですが、ユーザーデータに --container-runtime containerd オプションを追加することで、containerd ランタイムに切り替えることができます。

EKS 1.16、1.17、1.18、1.19、1.20 用の Amazon Linux 2 EKS optimized AMI の新しいバージョンにも containerd のサポートが組み込まれています。そのため、containerd コンテナランタイムをテストするために、1.21 へのアップグレードを待つ必要はありません。既存のクラスターにノードグループを追加したり、最新の AMI で新しいクラスターを作成したりしてテストすることができます。

/etc/eks/bootstrap.sh $CLUSTER_NAME \
  --b64-cluster-ca $B64_CLUSTER_CA \
  --apiserver-endpoint $API_SERVER_URL \
  --container-runtime containerd

また、以下の eksctl 設定ファイルを使用して、eksctl で containerd ランタイムを使用する EKS クラスターを作成することもできます。

EKS_VERSION=1.21

AMI_ID=$(aws ssm get-parameter \
    --name /aws/service/eks/optimized-ami/${EKS_VERSION}/amazon-linux-2/recommended/image_id \
    --query "Parameter.Value" --output text)

AWS_REGION=${AWS_DEFAULT_REGION:-us-west-2}

CLUSTER_NAME=containerd-eks

cat > eksctl-containerd.yaml <<EOF
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_REGION}
  version: "${EKS_VERSION}"
managedNodeGroups:
  - name: containerd
    ami: ${AMI_ID}
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh ${CLUSTER_NAME} --container-runtime containerd
EOF

eksctl create cluster -f eksctl-containerd.yaml

Kubernetes 1.23 では、デフォルトのランタイムを Docker から containerd に変更します。これは、EKS 1.22 が Docker コンテナランタイムをサポートする最後のリリースになることを意味します。1.21 のライフサイクルにおいて、containerd を使用してワークロードをテストすることをお勧めします。そうすることで、Docker ソケットのマウントやコンテナビルドのための docker-in-docker の使用など、Docker 特有の機能に依存していないことを確認することができます。

containerd は Kubernetes コミュニティで広く採用されており、CNCF の “Graduated” なプロジェクトです。EKS で完全にサポートされており、Docker の代替として優れています。コンテナネイティブな OS を使いたい場合は、デフォルトのコンテナランタイムとして containerd が搭載されている Bottlerocket OS を使うこともできます。

Kubernetes 1.21 のハイライト

注目すべき機能のすべてに興味がある場合は、Kubernetes ブログのリリースに関する投稿とリリースノートの全文を確認してください。ここでは、いくつかの注目すべきアップデートを紹介します。

CronJob の改善

CronJob は、Kubernetes のこのリリースで安定版の機能に移行しました。また、TTLAfterFinished オプションは EKS 1.20 で有効化されていますが、この機能はアップストリームの 1.21 でベータ版に移行します。この機能により、Pod を作成する CronJob がある場合、ttlSecondsAfterFinished を指定して Pod を削除し、完了した Pod が etcd に残らないようにすることができます。これは特に AWS Fargate のユーザーにとって便利な機能です。AWS Fargate で Pod を作成すると Kubernetes ノードも作成されますが、この設定によって、 Job が完了した後に Pod が自動的に削除され、Kubernetes ノードも削除されます。

Graceful Node Shutdown

この機能はベータ版に移行し、すべての Pod が正常にシャットダウンする機会が与えられるまで、kubelet がノードのシャットダウンをブロックできるようになりました。これは、Kubernetes の外部で発生し (誰かが sudo poweroff を実行するなど) 、ライフサイクルフックを介した cordon と drain のライフサイクルを、完全には通過しない可能性があるノード終了要求に対して役に立ちます。なお、マネージド型ノードグループには、すでに Cluster Autoscaler のスケールダウンイベントのような Kubernetes API を通じて要求されるノード終了のためのライフサイクルフックがあります。

IPv4/IPv6 デュアルスタックのサポート

Kubernetes は、Pod が IPv4 と IPv6 のアドレスを同時に持つことができる機能を追加しました。この機能は、クラスターのニーズや使用している Container Network Interface (CNI) に依存します。Amazon VPC CNI Plugin は、1.21 リリースではデュアルスタックをサポートしません。現時点では、Pod が IPv6 アドレスを利用しつつ、IPv4 エンドポイントにルーティングできるように、単一インターフェイス構成で IPv6 サポートを有効にすることに焦点を当てています。IPv6 サポートに関する最新情報を入手したい場合は、この GitHub issue をサブスクライブしてください。

Immutable Secret と Immutable ConfigMap

Kubernetes API で ConfigMap と Secret をイミュータブルとしてマークすることができるようになりました。これは、ConfigMap の変更が必要な新しいアプリケーションに移行しようとするときに非常に役立ちます。イミュータブルな ConfigMap と Secret を使用することで、それらが変更されず、各デプロイメントバージョンが正しい構成を持つことを保証することができます。これにより障害やエラーを防ぐことができますが、現在のところ、どのアプリケーションがどのバージョンのイミュータブルな ConfigMap や Secret を使用するかについては手動で追跡する必要があります。

マネージド型ノードグループのための Cluster Autoscaler priority expander

EKS 1.21 のマネージド型ノードグループは、Auto Scaling Group に eks-<managed-node-group-name>-<uuid> の形式で名前を付けます。これにより、マネージド型ノードグループで Cluster Autoscaler の priority expander を利用できるようになりました。

オンデマンドインスタンスとスポットインスタンス用の 2 つのマネージド型ノードグループがあり、名前が spot と on-demand である場合、以下の ConfigMap でスポットインスタンスのスケーリングの優先度を高く設定することができます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    20:
      - eks-spot.*
    10:
      - eks-on-demand.*

機能の非推奨化

Kubernetes API は時間の経過とともに進化し、新機能はアルファ版からベータ版、そして最終的には安定版に移行します。Amazon EKS では、デフォルトで有効になっているベータ版と安定版の Kubernetes 機能を有効にします。

また、機能はバージョンごとに非推奨化され、削除されます。機能の削除は時間のかかる慎重なプロセスであり、機能は最初に非推奨になり、いくつかのリリースの間はそのように維持され、最終的には削除されます。Kubernetes Deprecation Policy の詳細については、アップストリームのドキュメントを確認してください。

1.21 での 2 つの新しい非推奨事項について以下に説明します。最終的な削除に備えて、これらからの移行の計画を開始する必要があります。次のリリースを知るために、この Kubernetes 1.22 での削除に関する最近のブログを確認してください。

PodSecurityPolicy の非推奨化

PodSecurityPolicy は非推奨になりました。この機能は引き続き使用できますが、この機能を使用している場合は、将来のリリースで別のものを使用する計画を立てる必要があります。Kubernetes プロジェクトの現在の計画では、Kubernetes 1.25 で PodSecurityPolicy の機能を削除します。この機能は将来的に新しいものに置き換えられる予定です。詳細についてはこちらをご覧ください。

すでに PodSecurityPolicy を使用していて、すぐに置き換えたい場合は、オープンソースの Gatekeeper を代替のポリシーエンフォースメントソリューションとして使用することができます。このブログ記事で Gatekeeper の使い方を紹介しています。

TopologyKeys の非推奨化

TopologyKeys は Kubernetes のアルファ機能で、EKS では利用できませんでした。1.21 では Topology Aware Hints という新しいアルファ機能に置き換えられています。この機能がアルファ版を卒業したら、将来のリリースで EKS で利用できるようになります。TopologyKeys は、EKS が API サーバーでアルファ機能を有効にしない理由を示す良い例です。アルファ機能は、長期的に API の一部となることが保証されておらず、安定版やベータ版のような長い非推奨サイクルもありません。

EKS のアップグレード

1.21 にはいくつかの非推奨事項がありますが、1.21 で EKS の機能が削除されることはないため、ワークロードをテストして中断することなくアップグレードできるはずです。EKS のバージョンをアップグレードする方法については、EKS のドキュメントを参照してください。

もしまだ EKS 1.16 を使用している場合は、今すぐアップグレードしてください。EKS 1.16 は 2021 年 7 月 25 日にサポートが終了するため、できるだけ早く新しいリリースに移行する必要があります (訳注: EKS 1.16 のサポート終了日は 2021 年 9 月 27 日に変更されています) 。詳細は、EKS リリースカレンダーを参照してください。

翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。

Amazon Web Services ブログ