Management and operations for Amazon EKS

朝はDr. Werner VogelsのKeynoteを開始から1時間位みてきました。Firecrackerはcontainerdをベアメタルサーバごとに共通化させていて、それもオープンソースとして開発しているなど、非常に面白かったです。FargateとEC2の比較なんかも動画だとかなりわかりやすくてよかったです（本当に？とも思いましたが…）。ほんの少しだけ、Getting Started on Kubernetesをかぶる内容もありましたが、EKSでスポットインスタンスを使う方法やロギングでEFK構成を取る方法などをWorkshopで学んでいきました。
実はCON203/CON205/CON206は続けて取ると丁度よくEKSのWorkshop全てを網羅出来るみたいです。
ちなみにこのセッション、Walk-Upで行こうと思って並んで腰をおろしてPC開いたら予約できるようになっていました。予約して部屋戻って休憩できたので良かったです。

導入

他のWorkshopと同じようにチームハッシュの書かれたシールを貰って、https://dashboard.eventengine.run/にアクセスしてハッシュ打ち込むのかなと思っていたんですが、シールが用意されていませんでした。こういったケースもあるんですね。チームハッシュの書かれた紙をスタッフの方が持っていて、その方が「これだよー」と提示して頂いて確認します。自分は写真を撮りました。

Workshopの流れ

他のKubernetesのセッションは3回目になるので、セットアップはかなりすんなり行きました。ここで結構詰まってしまう方が多いのと、eksctlでクラスターを作成するまでに時間がかかるので、CON203と同じく質問コーナーが設けられました。
EKS on Fargate発表後というのもあり、そのへんの質問が多かったように感じます。Twitterでも議論になっていましたが、「Daemonsetは使えなくなるので、FluentdコンテナとかはSideCarコンテナで」など、EKS on EC2でのマニフェストをそのまま適用できるかというとそうでは無いようです。
資料は下記

eksworkshop.com

Health Checks

正直に言いますとここはEKSの話というより、純粋なKubernetesでの話なのでMustではないのかなと感じました。内容としてもベーシックな内容でした。

Using Spot Instances with EKS

EKSでSpotInstanceを上手く使う方法ですね。この辺を知りたくて来ました。このセッションでは、スポットインスタンスのNodeGroupを別で作成しています。作成の際にlifecycle=Ec2SpotというlabelとspotInstance: true:PreferNoScheduleというtaintsをつけています。これを上手く利用します。
taintsはtolerationsという概念とともにKubernetesで扱われる機能の一つです。Node側からSchedulingされるpodを制限できるのが強みです。pod側のnodeSelectorだと何も指定しなければ、どこのNodeでもスケジューリングされてしまいます。今回のケースでは、pod側でspotInstance: trueというtolerationsを持っていないものは、スポットインスタンスのnodeGroupには、スケジューリング出来ないことになります。taintsについているPreferNoScheduleはeffectと呼ばれるもので、Taintsを許容できないpodはSchedulingするのをなるべく避けるというものなっています。

SpotInstanceはTerminateの2分前にEc2メタデータを通して通知を行います。それをキャッチしてハンドリングしないと、いきなりpodが死ぬことになります。そこで下記のものを使います。11月くらいからCommitが始まっているのでかなり最近のプロダクトになると思います。
Terminateの通知を受けとったら、ノードにTaintをつけて他のpodがSchedulingされないようにします。その後に、Drainを行うことでpod内の各コンテナにSIGTERMを発行し、Graceful Shutdownを促します。

t.co

このDaemonSetはデフォルトで全てのNodeにSchedulingされますが、lifecycle=Ec2SpotというlabelのついたものだけにSchedulingされるように変更したほうがいい。

そしてサンプルアプリケーションfrontendのマニフェストで、Spotinstanceのtaintsを受容するようなtolerationsを設定し、nodeAffinityでlifecycle=Ec2Spotのラベルが付いたノードに優先的にスケジュールするように変更する。frontendのアプリケーションのみスポットインスタンスで運用されるようになった。

Logging with Elasticsearch, Fluentd, and Kibana (EFK)

まずElastic Search Service(ESS)を構築します。自分は業務でESSに触ったことがなかったので新鮮でした。
それとは並行して、fluentdのdaemonsetを作成していきます、一つ驚きだったのは、fluentdのdeploymentです。fluent/fluentd-kubernetes-daemonsetのimageかつ、fluentdの設定をConfigMapで持つ場合には、多少工夫をしなくてはいけないようです。initContainersでConfigMapをマウントして、/fluent/etc配下にコピーする必要性があるようです。 (コンテナを扱うものとして恥ずかしくて仕方なかったものとしては/var/log/containers/*.logにコンテナのログが吐かれることを知らなかったことです)
このDaemonSetが稼働するようになると、CloudWatchにデータが流れるようになります。
CloudWatchの画面の「Action」ボタンからStream to Amazon ElasticSearch Serviceを選択するとESSに流せるようになります。簡単！ただそのデータ投入はLambdaを使ってやるようで、Roleの準備とコストの考慮が必要になります。

いざKibanaにログが入るとどうでしょう！？バージョン6.3のKibanaの画面きれい…！ f:id:jrywm121:20191209185335p:plain