※ 本稿は Tech Inside Drecom に掲載された記事、「EKSでdocker非推奨問題に対応しました」の Qiita 出張版です。
こんにちは！enzaのインフラ周りの仕事をしているmendと申します！ 以前に k8s 1.20のDocker非推奨問題でEKSを使用しているプロジェクトが対応することとして、k8s 1.20からのdocker非推奨問題と対応案ついてまとめました。 今回の記事では先の記事でまとめた案の一つであるAWSで対応したAMIがリリースされましたので、実際にEKS 1.21にアップグレードするときに行ったことと、アップグレード時に気を付けるべきことをまとめたいと思います。
EKS 1.21の新機能
2021年 7月27日にAWSの公式からAmazon EKS が Kubernetes 1.21 のサポートを開始という発表がありました。
このEKS 1.21からコンテナランタイムにcontainerdを使用することが正式にサポートようになり、1.20からDockerのコンテナランタイムが非推奨になっていた問題に対応した形になります。
その他にもCronJob の改善やGraceful Node Shutdownなどの変更も入っていますので、詳しくは上記のリンクを確認してください。 なおこれから紹介するcontainerdをコンテナランタイムに指定する設定を行わない場合、EKS 1.21のデフォルト設定ではコンテナランタイムにDockerが設定されているのでご注意ください。
ちなみに
ちなみにではありますが、これまでリリースされていたEKS 1.16から1.20までのEKS最適化AMIの最新版でcontainerdがサポートされました。これにより、EKS 1.21まで更新してからcontainerdにした場合のアプリケーションの動作を確認するといったことは不要です。ありがたいですね！
EKS 1.21にアップグレードする
EKS 1.21にアップグレードするにあたり、ほとんどの部分は大きく変わりませんでした。
これまでと違うのはコンテナランタイムを変更する作業がある点です。
といってもEKS 1.21でコンテナランタイムをcontainerdにする方法はそこまで難しくはありません。
起動設定の中で設定しているユーザーデータを書き換えるだけになります。
ワーカーのAMIを変更する際に一緒にやってしまいましょう。 こちらがセルフマネージドノードでEKSクラスターに参加させているワーカーノード起動時のユーザーデータの例です。
#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh $CLUSTER_NAME \
--b64-cluster-ca $B64_CLUSTER_CA \
--apiserver-endpoint $API_SERVER_URL
このなかで /etc/eks/bootstrap.sh にクラスター名とその他引数を渡して起動しますが、この引数でコンテナランタイムにcontainerdを指定することで設定が可能です。 例としては以下のようになります。
#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh $CLUSTER_NAME \
--b64-cluster-ca $B64_CLUSTER_CA \
--apiserver-endpoint $API_SERVER_URL \
--container-runtime containerd # コンテナランタイムにcontainerdを指定
この他にもeksctlでマネージドノードグループでもcontainerdを使用することができます。
詳細はcontainerd ランタイムブートストラップフラグを有効にするを参照してください。 ちなみにEKS 1.21まではこのように明示的に--container-runtime containerd を指定する必要があるのですが、EKS 1.22からはデフォルトでcontainerdになるようです。 前の記事 k8s 1.20のDocker非推奨問題でEKSを使用しているプロジェクトが対応すること で記載した図の再掲になりますが、containerdに移行した場合は以下の図のようにコンテナを動かす仕組みが変更されます。
containerdにするときに気を付けること
コンテナランタイムをcontainerdに変更する際に、Podを動かすといった点でみれば大きな変更はありません。しかしdockerを使わなくなることから主にログの設定を変更する必要があります。
ワーカーのdockerのログ設定
EKSクラスターでログが欠損しないようにするために、ロギングドライバーの設定を変更していた場合は注意が必要です。
具体的には/etc/eks/bootstrap.shに--docker-config-jsonを設定している場合になります。
この場合、dockerを使えなくなることから--docker-config-jsonで行っていた設定ができなくなりますのでご注意ください。
ログの設定変更
Dockerの仕様により、ログ1行のサイズが16384バイトを超えてしまうと分割され、1件のログが複数行に分かれてしまう挙動があります。
そのためfluentbitではDocker_Mode、fluentdではfluent-plugin-concatを使うといった対策をしていたと思われます。この場合もcontainerdになることから設定の変更が必要になりますので
fluentbitではfluentbit-containerd-cri-o-json-logを、fluentdではfluent-plugin-concatを参考にそれぞれで設定の変更を忘れずに行いましょう。
まとめ
今回はEKS 1.21でdocker非推奨問題に対する対応の方法と注意点をまとめました。
dockerが非推奨だ！やばい！うおおお！と騒いでいたころが懐かしく感じます。
実際に移行してみるとそこまで大きな対応箇所はなく、対応する箇所も基本的にログ周りだけとなっており、非常に少なくて助かります。
実際にcontainerdに移行する際にはぜひ参考にしてみてください！
Tech Inside Drecom の最新の情報は Facebook や Twitter からお届けしています、フォローよろしくおねがいします！
Twitter: @DRECOM_TECH
Facebook: tech.inside.drecom
※ その他の Tech Inside Drecom の記事は、コチラからお探しいただけます！