EKSを本番環境で使う上で知っておいた方が良いこと（2019/12/12時点）

はじめに

この記事はAmazon EKS Advent Calendar 2019 12日目の記事です。

この記事では実際に本番環境でEKSを使うために検証し、個人的にこれを先に知ってればよかったなと思うことを紹介していきます。これからEKS使う人や、検証中の方に参考になれば幸いです。

目次

• IPいっぱい使う問題
• Podごとにセキュリティグループ効かせられない問題
• タグを使ってVPCとかサブネットを認識しようとする問題
• Node "Not Ready"問題

IPいっぱい使う問題

aws-vpc-cni-k8s

まず一つ目にIPをいっぱい使う問題を紹介します。そのために前提となるaws-vpc-cni-k8sのことを少し説明します。

eksではデフォルトのcniでaws-vpc-cni-k8sと言うaws謹製のcniを利用します。このcniの特徴としてPodに振るIPを実際のサブネットで利用するIPを振ることにあります。なのでPodのIPに対して同一ネットワーク内であればIPを参照してPodにアクセスできます。

セカンダリIPをPodに付与する

Podには実際にサブネットからIPが振られることを説明しました。ではどうやってその機能を行なっているのでしょうか？

AWSではセカンダリIPと言う機能が存在しEC2に複数個のIPを振ることができます。これを使ってセカンダリIPを用意してPodに実IPを振っています。

事前にセカンダリIPを取得する

セカンダリIPはPodが起動する際にサブネットから取得されるわけではありません。インスタンスの起動時にインスタンスタイプによって決められている量のIPを取得します。

参考までにm5.largeは29個のセカンダリIPを取得すると書いてあります。なのでm5.largeの起動時にプライマリIPで一個、セカンダリIPで29個IPがサブネットから振られることになり、合計30個のIPがサブネットから振られることになります。

改善策

改善するにはcniの環境変数を修正する必要があります。

Podごとにセキュリティグループ効かせられない問題

次にPodごとにセキュリティグループ効かせられない問題を紹介します。

セキュリティグループ

AWSではセキュリティグループと言うリソースが存在し、それをec2などのリソースに効かせることでRDSへのアクセスを制限したりすることができます。

AWSを使っていると大抵はRDSとインスタンス間のアクセスをセキュリティグループを用いて制限しているケースが多いです。（個人の観測）

Podにセキュリティグループがつけれない？

PodはEC2の上で動いています（Fargateを除く）。なのでセキュリティグループは載っているEC2に依存することになります。EKSように管理されたEC2インスタンスにRDSへのアクセスを許可したり、Elasticcacheへのアクセスを許可したりでPodに対して制限をかけることが工夫しない限りできません。

改善策

改善策はこれと言うものはまだ見つかっていません。なのでcniのアップデートを待つ、セキュリティグループごとにNodeグループを作る、セキュリティグループに頼らない認証を用いるなどしなければなりません。

（個人的にはコンテナはどこでも動いて欲しいのでセキュリティグループに頼らない方法ができるとエレガントだと思っています。）

めも

一応issueは立っているので解決されるんじゃないかなと思います。

タグを使ってVPCとかサブネットを認識しようとする問題

次にAWSのリソースにつけられるタグを使ってEKSはVPCやサブネットの状態を認識しようとする問題を紹介します。

"kubernetes.io/cluster/": "shared"

EKSではVPCとサブネットを認識するために"kubernetes.io/cluster/<cluster-name>": "shared"と言うタグをEKSマスター作成時に指定したVPCとサブネットに自動的につけます。

terraformを使っていると勝手にリソースが変更されるのでdiffが出てしまいあまりうれしくありません。

elbやalbを立てるために

VPCやサブネットの認識の他にもELBを建てて良いサブネットかどうかを判断するためにもタグを必要とします。

詳しくは上記のリンクをみてください。

改善策

ないです。

タグなのでEKSのことをよくわからない人が勝手に消したりしないように注意することが大事だと思います。（急にELB建てれなくなったとかありそうですね）

Node "Not Ready"問題

次に紹介するのはNodeがNotReadyになってしまう問題です。以前にEKS production ready! part1と言う記事をかきそちらで詳しく説明しているのでぜひそちらをみてください、

あらすじだけ説明すると、eviction policyがデフォルトだと設定されてないのでいつの間にかNodeがスケジュール不能な状態に陥ってしまう。と言うものです。

設定しないと割と深刻な状態になるのでぜひ記事をみてください。

まとめ

今回EKSを実践的に使う上で知っておいた方が良いことを書きました。他にも色々な問題はあると思いますのでぜひコメントなどで書いていただけると幸いです。

最後に、今回はEKSのあまり良くない点をピックアップしました。ただこのような問題をクリアすればあとは問題なく稼働します。今後ともEKSが発展していくことを楽しみにしています。

Twitter(https://twitter.com/Sueken51)