EKS production ready! part.1
awsにはeksというKubernetesのマネージドサービスが存在しています。このeksを本番環境で動かすまでに色々な問題が発生したので紹介したいと思います。
Node is ”NotReady”
今回紹介する問題は「NodeがNotReady状態になってしまう」です。NodeがNotReadyになってしまうとPodをスケジュールすることもできなくなる上に、ec2のステータスとしてはhealtyな状態と判断されるため、いつの間にかPodが全くスケジュールできないクラスターになってしまいます。
発生条件
このNodeが”NotReady”になってしまう現象はPodがNodeの保有するメモリーを超える量を使用しようとすると発生するようでした。
OOM Killer
Nodeが”NotReady”になっているときにkubectl describe ${NODE}すると「System OOM encountered」というメッセージを確認することができます。この状態になるとこのNodeに乗っているpodのstatusがUnKnownになり他のNodeにスケジュールされないようになってしまいます。
対応策
このエラーに対応するには二つの方法があります。一つ目にリソース制限をかける方法です。
リソース制限
KubernetesではPodに割り当てるCPUやMemoryを指定することができます。以下のような設定をマニフェストに加えます。
resources:
requests:
memory: “500Mi”
cpu: “500m”
limits:
memory: “1000Mi”
cpu: “1000m”Eviction Policy
kubernetesにはEviction Policyと言われる、NodeのリソースをPodが超えないようにする仕組みが存在します。詳しくは上記リンクから確認して欲しいのですが、ざっくり説明するとNodeの使用可能メモリーが10%を下回ったときにPodを強制的に撤退（Evict）させたりすることが可能です。
Eviction Policyを設定する
Eviction Policyの設定はkubeletの引数を用います。eksであればNodeのec2インスタンスのuserdataに設定することで、Eviction Policyを設定することが可能になります。例は以下のようになります。
--kubelet-extra-args "--kube-reserved memory=0.3Gi,ephemeral-storage=1Gi --system-reserved memory=0.2Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"この設定をすることでNodeがいつの間にか”NotReady”になっているなんてことはなくなりました。
まとめ
eksはgkeと比べまだまだマネージドサービスの質として劣るところがあります。今回はNodeが”NotReady”になるという、割と深刻な問題を紹介しました。eksの安定運用に役立てていただければ幸いです。
参考
基本的にはこの記事を参考にしました。非常にわかりやすいのでぜひ見てみてください。