🙆‍♀️

EKS のコンテナランタイムを containerd に移行手順

2023/06/01に公開

AWS

Kubernetes

インフラ

tech

はじめに

Amazon EKS での Dockershim サポート終了にあたり、EKS のコンテナランタイムを containerd に移行する手順をまとめる。

基本的にはEKS アップデート手順と同様の手順となる。

手順

EKS 1.22 を例として手順をまとめる。

YAML の準備

AMI バージョン確認して記録する。

EKS_VERSION=1.22

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

上記で記録した AMI バージョンを使ってYAMLを準備する。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: {クラスタ名}
  region: ap-northeast-1
  version: 1.22
managedNodeGroups:
  - name: old-nodegroup
  ...
  - name: new-nodegroup
    ami: {1つ前の手順で取得した AMI　バージョン}
    amiFamily: AmazonLinux2
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh {クラスタ名} --container-runtime containerd
...

監視外し

Kubernetes のリソース監視を行っている場合は、移行の妨げになるため一時的にミュートするなどの対応を済ませておく。

移行を速やかに完了させるため、念の為リリース作業などを控えてもらうように関係者へ情報共有しておく。

バージョンアップ前の確認

Client Version と Server Version　のマイナーバージョンが +/-1 であれば問題ない。

kubectl config use-context {コンテキスト}
kubectl version --short

執筆時のバージョンは 0.124.0。必ずしも揃える必要はない。

$ eksctl version
0.124.0

新ノードグループの作成

上記で準備した YAML ファイルを使って、Pod の移動先となるノードグループを作成していく。

実行

eksctl create nodegroup --config-file={YAMLファイル名} --include='{新ノードグループ名}'

CloudFormation 確認

AWS コンソールの CloudFormation > スタック から新しく作成したノードグループが存在し、ステータスが CREATE_COMPLETE であることを確認する。

ノードグループ確認

作成したノードグループが存在することを確認する。

eksctl get nodegroups --cluster {クラスタ名}

この段階で、既存のノードグループのノード数と新しく作成したノードグループのノード数が一致するように、AWS コンソールから一時的に変更しておくと良い。

ノードグループ作成後、アプリケーション側に影響が出ていないかログを確認する。

起動テンプレート確認

EKS > クラスター > {クラスタ名} のコンピューティングタブから新しく作成したノードグループを選択して、起動テンプレートのリンクをクリックする。

詳細タブの高度な詳細をクリックする。

ユーザデータに以下の設定があることを確認する。

#!/bin/bash
/etc/eks/bootstrap.sh {クラスタ名} --container-runtime containerd

ノードのバージョン確認

CONTAINER-RUNTIME が containerd://x.y.z となっているノードが存在することを確認する。

kubectl get nodes --sort-by=.metadata.creationTimestamp -o wide

Pod の移動

既存のノードグループのノードに対してスケジューリングされない様に cordon する。

kubectl cordon -l alpha.eksctl.io/nodegroup-name={既存のノードグループ名}

既存のノードグループのノードの STATUS が Ready,SchedulingDisabled になっていることを確認する。

kubectl get nodes --sort-by=.metadata.creationTimestamp

次のコマンドで drain コマンドを作成し出力された分だけ実行していく流していく。

kubectl get nodes --sort-by=.metadata.creationTimestamp | grep 'SchedulingDisabled' | awk -F' ' '{print "kubectl drain --delete-emptydir-data --ignore-daemonsets "$1}'

Pod の移動後、アプリケーション側に影響が出ていないかログを確認する。

既存のノードグループのノード数と新しく作成したノードグループのノード数が一致するように変更している場合は、AWS コンソールから一時的に変更した最小キャパシティの設定を元に戻す。

旧ノードグループの削除

既存のノードグループのノードが新しく起動していないか確認する。
起動していた場合は、再度 cordon を行う。

kubectl get nodes --sort-by=.metadata.creationTimestamp -o wide

まずはドライラン。

eksctl delete nodegroup --config-file={YAMLファイル名} --include='{既存のノードグループ名}'

削除対象のノードグループが正しいことを確認し、実行する。

eksctl delete nodegroup --config-file={YAMLファイル名} --include='{既存のノードグループ名}' --update-auth-configmap=false --approve

AWS コンソールの CloudFormation > スタック から削除したノードグループが存在しないことを確認する。

削除したノードグループのノードが存在しないことを確認する。

kubectl get nodes --sort-by=.metadata.creationTimestamp -o wide

削除したノードグループが存在しないことを確認する。

eksctl get nodegroups --cluster {クラスタ名}

アプリケーション側に影響が出ていないかログを確認する。

事後作業

アプリケーション側に影響が出ていないことを確認し、監視外しなどで行った作業をもとに戻す。

アップデート前に関係者へ情報共有している場合は、アップデート作業が完了した旨を関係者へ共有する。