APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

【AWS】Amazon EKS Node Monitoring AgentによるNode自動復旧を試してみる

こんにちは、クラウド事業部の山路です。今回は昨年末ごろにリリースされたAmazon EKSのNode自動復旧機能 (本記事ではAuto repairと呼んでいます) について紹介します。

aws.amazon.com

EKS Auto repairとは

EKS Auto repairはWorker node上に問題が発生した際に、自動的にNodeを復旧する機能です。具体的にはNodeをモニタリングするエージェントとして Node Monitoring Agent (NMA) をクラスターにインストールし、エージェントが障害を検知したら新規Nodeの作成と再配置または再起動を実行します。

aws.amazon.com

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 や空き領域が使用可能であってもファイルの作成が妨げられる可能性があります。

docs.aws.amazon.com

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

docs.aws.amazon.com

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が再起動する様子を確認できました。

dev.classmethod.jp

さいごに

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp