こんにちは、クラウド事業部の山路です。今回は昨年末ごろにリリースされたAmazon EKSのNode自動復旧機能 (本記事ではAuto repairと呼んでいます) について紹介します。
EKS Auto repairとは
EKS Auto repairはWorker node上に問題が発生した際に、自動的にNodeを復旧する機能です。具体的にはNodeをモニタリングするエージェントとして Node Monitoring Agent (NMA)
をクラスターにインストールし、エージェントが障害を検知したら新規Nodeの作成と再配置または再起動を実行します。
EKSを運用するエンジニアにとってはありがたい機能ですが、いくつかの制限事項もあるので記載します。
検知できる障害の種類に限りがある
AWSドキュメントでは、以下の障害を検知すると記述されています。Node上で発生するすべての障害に対応しているわけではないため、ご注意下さい。またNMAが検知する障害の中にも、修復アクションのトリガーとなるものとそうでないものが含まれます。
ここでは修復アクションのトリガーとなるものだけをいくつか取り上げます。また後述しますが、ドキュメントに記載のあるイベントの中で一時的に利用できないケースもあるようなので、利用時は事前確認・検証をおすすめします。
カテゴリー | 名称 | 概要 |
---|---|---|
Kernel | ForkFailedOutOfPID | フォークまたは実行の呼び出しが失敗したのは、システムがプロセス ID またはメモリ不足であるためです。これは、ゾンビプロセスまたは物理メモリの枯渇が原因である可能性があります。 |
Networking | InterfaceNotRunning | このインターフェイスは実行されていないか、ネットワークの問題があります。 |
InterfaceNotUp | このインターフェイスは起動していないか、ネットワークの問題があります。 | |
IPAMNotReady | IPAMD が API サーバーに接続できません。 | |
IPAMNotRunning | aws-k8s-agent プロセスは実行中であることが確認されませんでした。 |
|
Runtime | PodStuckTerminating | ポッドが終了しているか、または長時間停止していました。これは、ポッドの状態の進行を妨げる CRI エラーが原因で発生する可能性があります。 |
Storage | XFSSmallAverageClusterSize | XFS Average Cluster サイズが小さいため、空き領域が過剰に断片化され、inode や空き領域が使用可能であってもファイルの作成が妨げられる可能性があります。 |
Managed NodegroupまたはKarpenter, EKS Auto Modeでのみ利用可能
NMAはKubernetes DaemonSetとして導入されます。そのためEKS on Fargateでは利用できません。またEKS Auto Modeを利用する場合はデフォルトで導入されています。
EKS Auto repairの導入手順
Auto repairの導入はとても簡単で、EKSクラスターの一部設定変更とNMAのインストールをすれば完了します。
EKSクラスターはNodegroupに対して NodeRepairConfig
というパラメータを設定します。なおこのパラメータを設定する際Nodeの再起動などは発生しません。AWS CLI / eksctlを使う場合はそれぞれの手順に従いますが、今回はCloudFormationから変更しました。
以下のような設定をファイルに追加し、デプロイします。
ManagedNodeGroup: Type: 'AWS::EKS::Nodegroup' Properties: (省略) NodeRepairConfig: Enabled: true
NMAはEKS Addonで用意されており、マネジメントコンソール画面から導入できます。Add-onの追加や更新・削除という操作は簡単ですが、いちおう過去のブログリンクも載せておきます。
Auto repairの動作確認(失敗編)
ここからAuto repairが実際に機能するかを確かめるため、Workerノード上のInterfaceをダウンさせ ( InterfaceNotUp
イベント) 、 疑似的な障害を発生させました。
# Worker NodeにログインしてInterfaceをダウンさせる [root@ip-192-168-121-108 ~]# ifconfig eth1 down [root@ip-192-168-121-108 ~]# ip addr show (省略) 5: eth1: <BROADCAST,MULTICAST> mtu 9001 qdisc mq state DOWN group default qlen 1000 link/ether 06:35:68:7c:d4:99 brd ff:ff:ff:ff:ff:ff inet 192.168.122.200/19 brd 192.168.127.255 scope global eth1 valid_lft forever preferred_lft forever [root@ip-192-168-121-108 ~]#
上記操作を行ったところ、Workerノード上の障害は検知され、AWSマネジメントコンソールでも以下のような表示がされました。
ただ、ここから30分以上待機してみたのですが、Nodeの再起動は発生しませんでした。こちらについてAWSサポートに問い合わせたところ、検証時点では InterfaceNotUp
イベントによる自動修復アクションは無効化されている、とのことでした。
※本記事公開より2か月ほど前のやり取りですので、最新の情報を確認したい場合は各自でご確認ください。
もしも本機能を試したい場合は、クラスメソッドさんのこちらの記事を参考にしてみてください。こちらで紹介された方法では問題なくNodeが再起動する様子を確認できました。
さいごに
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。