Bottlerocket Update Operatorを利用したワーカーノードのOS自動アップデートの利用

enterpriseCloud+ > ブログ > 技術レポート > Bottlerocket Update Operatorを利用したワーカーノードのOS自動アップデートの利用

技術レポート

Bottlerocket Update Operatorを利用したワーカーノードのOS自動アップデートの利用

Bottlerocket Update Operatorを利用した
ワーカーノードのOS自動アップデートの利用

1．はじめに

2. マネージドノードグループでのAMIの指定方法とワーカーノードのAMI更新方法

3. Bottlerocketの特徴

4. Bottlerocketを利用した場合の定期的なOSのアップデート方法

5. Bottlerocket Update Operatorを利用したOSの自動アップデート

6．おわりに

1．はじめに

Amazon EKS(以降EKS)のコンテナ実行環境(以降ワーカーノード)として、マネージドノードグループを利用する場合、マネージドノードグループでワーカーノードのOSとして利用可能なEKSに最適化されたLinux系OSは、以下の2種類が選択可能である。

Amazon Linux2
Bottlerocket

Bottlerocketとは、AWSによってスポンサーおよびサポートされているオープンソースのLinux ディストリビューションで、コンテナワークロードのホスティング専用のOSである。他のLinuxディストリビューションよりもリソースフットプリントが小さく、セキュリティの脅威に対する脆弱性が低い。また、Bottlerocketは、「Bottlerocket Update Operator」というツールを導入すれば、OSの自動アップデートを行うことが可能である。
上記のBottlerocketの特徴から、Amazon Linux2ではなくBottlerocketの利用を検討したほうがよいケースとしては、以下が挙げられる。

ワーカーノードに、より高いセキュリティ要件が求められる場合
ワーカーノードの運用負荷低減のため、OSアップデートを手動ではなく自動で行いたい場合

本稿では、マネージドノードグループでワーカーノードのOSとしてBottlerocketを利用した場合において、定期的にOSのアップデートを行っていく方法について、「Bottlerocket Update Operator」を導入した際のOSの自動アップデート方法を中心に説明を行う。
なお、本稿の対象読者としては以下を想定している。

EKSについて基本的な知識がある。
マネージドノードグループのワーカーノードのOSとしてBottlerocketの利用に興味がある、または利用を検討している。

2. マネージドノードグループでのAMIの指定方法とワーカーノードのAMI更新方法

主題の説明に入る前に、マネージドノードグループを利用していて、ワーカーノードに障害が発生した場合の挙動について、はじめに説明をしておきたい。
ワーカーノードに障害が発生した場合は、ワーカーノードは自動的に削除され、マネージドノードグループで指定しているAMIから再作成されるため、各ワーカーノードのOSにログインしてコマンドでOSのアップデートを行っていた場合は、障害発生時にOSのアップデートが適用されていない状態に戻ってしまう。
そのため、OSのアップデートを定期的に行うためには、マネージドノードグループで指定しているAMIを新しいバージョンのAMIに変更し、現行のワーカーノードを、新しいバージョンのAMIから作成されたワーカーノードに入れ替えることを定期的に行うことが必要になる。

各ワーカーノードのOSにログインしてコマンドでOSのアップデートを行っていた場合の障害発生時の挙動

マネージドノードグループで指定しているAMIを新しいバージョンのAMIに変更を行うことで、
ワーカーノードの入れ替えを行い、OSのアップデートを行う際のイメージ

マネージドノードグループで使用するAMIを指定する方法によって、ワーカーノードのAMIの更新方法が異なる。マネージドノードグループで使用するAMIを指定する方法には、以下の2つの方法がある。

パターン1：マネージドノードグループの設定の中でAMIタイプ(Amazon Linux 2、BottlerocketなどAMIの種別)を指定する。
パターン2：マネージドノードグループが使用する起動テンプレートの設定の中でAMI IDを指定する。

それぞれ以下の特徴がある。

	AMI IDの指定可否	ワーカーノードのAMI更新方法
パターン1	AMIタイプの指定しかできず、AMI IDを指定することはできない。AMIタイプの設定時点での最新のバージョンのAMIでワーカーノードが作成される。	利用可能なAMIの最新バージョンがある場合、AWSコンソールでノードグループの設定画面に「今すぐ更新」ボタンが表示されるので、そのボタンから更新を行う。
パターン2	AMI IDを指定することができる。	最新のAMI IDを指定した新しいバージョンの起動テンプレートを作成し、ノードグループで使用する起動テンプレートのバージョンを新しいバージョンに変更する。

パターン1の方法では、設定時点での最新のバージョンのAMIでワーカーノードが作成されるため、例えば、開発環境と本番環境でAMI更新を行う時期のずれによっては、ワーカーノードで利用するAMIのバージョンが環境ごとに異なる状況が発生しうる。そのような状況を許容できない場合は、パターン2の方法を採用し、ワーカーノードで利用するAMIのAMI IDを明示的に指定する必要がある。

パターン1の方法においてワーカーノードのAMIを更新した場合に開発環境と本番環境のAMIのバージョンが異なる状態になるときの挙動

3. Bottlerocketの特徴

「1.はじめに」で軽く説明をしたが、Bottlerocketの特徴について説明する。

Bottlerocketには以下の特徴がある。

他のLinuxディストリビューションよりもリソースフットプリントが小さく、起動時間が短く、セキュリティの脅威に対する脆弱性が低い。
Bottlerocketはパッケージ更新システムがなく、代わりにイメージベースのモデルを使用している。Bottlerocketには「アクティブなパーティション」と「非アクティブなパーティション」があり、updateコマンドを実行することにより、最新のOSイメージが非アクティブなパーティションにダウンロードされ、その後rebootコマンドでOSを再起動すると、非アクティブだったパーティションから最新のOSイメージが起動される。
AMIの更新を行う以外の方法で、OSのアップデートを行う方法は以下の2つがある。

OSにログインし、コマンドでOSアップデート、OS再起動を行う。
「Bottlerocket Update Operator」というツールをkubernetes上にPodとして導入し、自動でOSアップデート、OS再起動を行う。

4. Bottlerocketを利用した場合の定期的なOSのアップデート方法

「2. マネージドノードグループでのAMIの指定方法とワーカーノードのAMI更新方法」で述べたが、ワーカーノードに障害が発生した場合は、ワーカーノードは自動的に削除され、マネージドノードグループで指定しているAMIから再作成されるため、各ワーカーノードのOSにログインしてコマンドでOSのアップデートを行っていた場合は、障害発生時にOSのアップデートが適用されていない状態に戻ってしまう。
そのため、「3.Bottlerocketの特徴」で述べたOSにログインし、コマンドを手動実行してOSアップデート、OS再起動を行う方法を採用することはできない。

上記を踏まえ、Bottlerocketを利用した場合の定期的にOSをアップデートする方法は以下の3パターンになる。

パターン1：マネージドノードグループの設定の中でAMIタイプを指定する構成をとり、AWSコンソールでノードグループの設定画面の「今すぐ更新」ボタンからワーカーノードのAMIの更新を行う。
パターン2：マネージドノードグループが使用する起動テンプレートの設定の中でAMI IDを指定する構成をとり、最新のAMIのAMI IDを指定した新しいバージョンの起動テンプレートを作成し、マネージドノードグループで使用する起動テンプレートのバージョンを変更する。
パターン3：Bottlerocket Update Operatorをkubernetesに実装し、自動でOSの更新、サーバ再起動を行う。

パターン1、2の方法については、Bottlerocket固有の方法ではなく、Amazon Linux2を利用する場合でも同様の方法である。
そのため、パターン1、2についての説明は割愛し、パターン3の方法について、次の章で詳しく説明をしていく。

5. Bottlerocket Update Operatorを利用したOSの自動アップデート

5.1.　Bottlerocket Update Operatorの概要

Bottlerocket Update OperatorはkubernetesのPodとして稼働し、Bottlerocketを自動でOSアップデートするツールである。
Bottlerocket Update Operatorを導入すると、以下の3種類のPodがデプロイされる。

brupop-controller-deployment
brupop-agent（※Daemonset。各ワーカーノードに1つ配置される。）
brupop-apiserver

Bottlerocket Update Operatorは「cert-manager」というSSL証明書を管理するツールを使用して、通信時に使用される自己署名証明書を管理するため、Bottlerocket Update Operatorを導入する前に、「cert-manager」をkubernetesのPodとして導入する必要がある。

5.2.　OSアップデート・OS再起動が行われるタイミングと挙動について

OSアップデート・OS再起動が行われる際のタイミングと挙動について、Bottlerocket Update Operatorを導入し、動作確認を行った。動作確認した結果をもとに、以下の説明をしていく。
Bottlerocket Update Operatorをデフォルトの設定のまま導入すると、利用可能な最新版のOSがある場合、Bottlerocket Update Operatorを導入した直後からワーカーノードが1台ずつOSアップデート・OS再起動が行われていく。
デフォルトの設定のままだと、常に、利用可能な最新版のOSがあるかチェックが行われ、利用可能な最新版のOSがある場合は、ワーカーノードが1台ずつOSアップデート・OS再起動が行われるため、いつワーカーノードのOS再起動が行われるかわからない状態となってしまう点には注意が必要である。
OSアップデート・OS再起動を指定したタイミングで行うためには、デフォルトの設定から変更を行う必要がある。
Bottlerocket Update Operatorを導入する際に使用するyamlファイルに、以下の設定項目がある。

MAX_CONCURRENT_UPDATE：OSアップデート・OS再起動を行う際のワーカーノードの最大同時台数
SCHEDULER_CRON_EXPRESSION：OSアップデート・OS再起動を行う時間帯の指定。cron形式で時間を指定する。

以下はデフォルトの設定値である。

ワーカーノードが2台ある場合を例として、OSアップデート・OS再起動を行う時間帯を指定した際の挙動について説明する。
例えば、「SCHEDULER_CRON_EXPRESSION」に以下の設定を行った場合、

毎日UTC6:00に利用可能な最新版のOSがあるかどうか確認が行われ、利用可能な最新版のOSがある場合、OSアップデート・OS再起動が行われるが、「MAX_CONCURRENT_UPDATE」が1のため、UTC6:00に1台のワーカーノードのOSアップデート・OS再起動が行われ、翌日の6:00にもう1台のワーカーノードのOSアップデート・OS再起動が行われる。

同日に2台ともOSアップデート・OS再起動を行いたい場合は、ワーカーノードの台数の分だけ同日に複数回OSアップデート・OS再起動が行われるように設定を行えばよいので、「SCHEDULER_CRON_EXPRESSION」に以下のような設定を行う。

毎日UTC6:00と6:10に利用可能な最新版のOSがあるかどうか確認が行われ、利用可能な最新版のOSがある場合、OSアップデート・OS再起動が行われるので、UTC6:00に1台、6:10にもう1台のワーカーノードのOSアップデート・OS再起動が行われる。

上記では例として日次で実施する設定を記載したが、cron形式で時間指定を行うため、「毎週○曜日の△時」や「毎月○日の△時」など、要件に合わせて実施時間帯の指定を行うことが可能である。

5.3.　OSアップデート・OS再起動を行う時間帯を指定した際の留意点

OSアップデート・OS再起動を指定したタイミングで行うように設定を行った場合において、ワーカーノードに障害が発生した場合は、ワーカーノードは自動的に削除され、マネージドノードグループで指定しているAMIから再作成されるため、OSにログインし、コマンドを手動実行してOSアップデート、OS再起動を行った場合と同様に、障害発生時にOSのアップデートが適用されていない状態に戻ってしまう。
ワーカーノードに障害が発生した場合は、次回のOSアップデート・OS再起動が行われるまでの間は、OSのアップデートが適用されていない状態となることを留意しておく必要がある。