Oisix ra daichi Creator's Blog(オイシックス・ラ・大地クリエイターズブログ)

オイシックス・ラ・大地株式会社のエンジニア・デザイナーが執筆している公式ブログです。

コンテナを知らないインターン生がKubernetesの監視をしてみた!

はじめに

はじめまして! SREセクションでインターンに参加している東田成輝と申します。
約1か月間、KubernetesでのWebサイト構築とKubernetesの監視に挑戦しました!
コンテナやAWSも触ったことがなく分からないことだらけでしたが、分からないなりに試行錯誤しましたのでそこで学んだことをまとめていきます!
​ ​

インターンでの目標

プロジェクトのミッション

​ オイシックス・ラ・大地ではコーポレートサイトをAmazon Elastic Kubernetes Service(EKS)上に構築しています。
今回はコーポレートサイトの監視の強化を目的として、監視ツールの一つであるDatadogを用いて監視を行ってみます! ​

自分のミッション

検証用のEKS上に、コーポレートサイトと同じ構成でKubernetesのリソースを構築した環境を用意し、その環境に対してDatadogの設定を1つ以上行うことです。 ​

インターンでやったこと

全体の流れ

  1. 環境構築
  2. 開発の基本であるGitやLinuxについて学ぶ
  3. AWSやEKSについて学ぶ
  4. Datadogでモニターを設定する

​ 全体の流れの各工程で行ったことを詳しく記載していきます! ​

環境構築

​ SREセクションではMacを使うのが主流なのですが、私のPCはWindowsだったのでLinuxコマンドを実行できるようにWindows Subsystem for Linux(WSL)を用いてUbuntuで環境構築を行いました。
今までLinuxやAWSやKubernetesを使ったことが無く、何もわからないまま環境構築をはじめました。
Ubuntuでインストールしたものは以下の通りです。 ​

  • aws cli
  • direnv
  • tfenv
  • terraform
  • kubectl
  • kubernetes-cli (kubectx, kubens)
  • helm
  • stern
  • krew
  • ghq, peco

インストールではHomebrewを用いました。
brew install terraform
このようにbrew installの後にツール名を入れることで簡単にインストールできました!
​ また、AWS上のEC2インスタンスにsshするための秘密鍵・公開鍵を作成しました! ​ この手順でインストールしたものは何がなんだか分からないまま使っていたものもあるので、今後も勉強していきますm( )m ​

チーム開発の基本であるGitついて学ぶ

​ 次に、オイシックス・ラ・大地のGitHubリポジトリをgit cloneし、自分が作業するためのブランチの作成を行いました。
Git未経験の状態から、ローカルで編集したファイルをcommit, pushしてpull requestを送ることができましたが、Gitに関してまだ分からないことだらけなのでこちらもまた勉強していきますm( )m

AWSやEKSについて学ぶ

​ Kubernetesを触る前に、AWSで操作をする感覚をつかむためにEC2単体でWebページを立てて公開しました!
まず、検証用のEC2のインスタンスを作成しました。
インスタンスタイプはt3.mediumで作成し、セキュリティグループでインバウンドルールに自宅のグローバルIPアドレスのsshを許可するセキュリティ設定を行いました。
このインスタンスにsshで接続し、WordPressをインストールしていきました!
また、より実務に近い形にするためElastic Load Balancerの設置や、Route53を用いた独自ドメイン設定などを行いました!

EC2で構築したWebサイト

​ ここまででAWS上で操作する感覚をつかんだところで、いよいよEKSを触っていきます!
KubernetesではManifestと呼ばれるファイルをapplyすることでリソースを構築します。
ManifestはYAML形式で書いていきます。コーポレートサイトと同じようなリソース構成にしてWebサイトを公開します!
Manifestについては事前に用意されたものを使用し、ゼロからの記述は行いませんでした。まだ分からないことが多いため今後も勉強していきます。

コーポレートサイトの全体構成

実はこのリソース構築の段階でトラブルが発生し、苦労しました...
結論からすると、Manifestの設定ミスによってPodやPVCがpendingから変わらないというエラーが起こっていたのですが、それに気付くことができず...
解決を試みるために行った操作に誤りがあり、それがまた新たなエラーを呼び... という形になってしまいました。
このことから私はエラーのトラブルシューティングの考えかたを勉強したので、後の「学んだこと」に記載しておきます!

EKSで構築したWebサイト

Datadogでモニターを設定する

​ ここから本番です!いよいよ今回のインターンの目的である監視を行っていきます! 監視にはDatadogのモニターと呼ばれる機能を使用していきます!モニターとは、メトリクスがしきい値を超えた、あるいは下回ったときにアラートを出すというもので、これを用いることで異常をいち早く検知することができます!
他社事例などを自分で調べながら、4つモニターを設定しました!

①EKSが管理しているNodeのEC2の使用CPUが大きければアラート

​ 監視において、CPUの使用率を参照するのは一般的だそうなので設定しました。作成したモニターは以下です。
min(last_10m):100 * sum:kubernetes_state.container.cpu_requested{host:ホスト名} /avg:kubernetes_state.node.cpu_allocatable{host:ホスト名} > 90

CPUの使用率を参照するモニター
90%以上でアラートを鳴らすようにしたのは、90%以上が続くとヤバそう...という直感からです。閾値は今後管理していくうえで調整がありそうですね。

②EKSが管理しているNodeの割り当て可能なCPUに対してコンテナが要求するCPUが大きすぎるとアラート

​ こちらもCPU関連のモニターです。Nodeのリソース管理をサポートするためにこのモニターを設定しました。
作成したモニターは以下です。
min(last_10m):100 * sum:kubernetes_state.container.cpu_requested{host:ホスト名} /avg:kubernetes_state.node.cpu_allocatable{host:ホスト名} > 90

コンテナのCPUリクエストを参照するモニター

このアラートが鳴る=Podを割り当てるためのCPUがNodeに残っていないという形になるので、以後新しくPodを起動できない可能性があります。

③EKSが管理しているNodeにデプロイ可能な最大のPodに対して現在デプロイしているPodの数が多すぎるとアラート

​ このモニターはNodeのリソース管理をサポートするモニターです。
作成したモニターは以下です。
avg(last_5m):sum:kubernetes_state.node.pods_allocatable{host:ホスト名} -sum:kubernetes.pods.running{host:ホスト名} < 1

デプロイできるPodの最大数と実行中のPodを参照するモニター
EKSのNodeはインスタンスタイプごとに最大Pod数が決められています。例えば、t3.smallの場合は11個です。 *1

これを超えると、新しいPodにIPアドレスを適用できなくなるため、新しくPodをデプロイできなくなる可能性があります。
このアラートが出れば実行中のPodを減らせば対応できると思います!

④pendingの状態に長い時間なっているPodがあればアラート

​ 最後にpendingの状態に長い時間なっているPodを検知するモニターを設定しました。Podがpendingから変わらないという問題は僕自身苦労したので、どうしても作りたかったものです。作成したモニターは以下です。 avg(last_10m):sum:kubernetes_state.pod.unschedulable{*} >= 1

Podの状態を参照するモニター
このアラートが鳴る=○○に原因があるので××する!のように明確な行動を示唆するモニターではありませんが、いち早く異常を検知することができるアラートになっているのではないかと思います!
上記のアラートをテストしてみました!

pendingが続く状態になるよう意図的にManifestを変更し、Podをapplyしてみました! MonitorがALERT状態になり、ちゃんと通知されていますね!

通知のテスト

インターンを通して学んだこと

​ インターンシップでは、AWSやKubernetesなどのコンテナに関わる知識以外にも、GitやLinuxなどの開発全般に関わることやエラー対応などの考え方など、幅広いことを勉強させていただきました。
エラー対応ではこれまではとりあえずエラーメッセージをGoogle翻訳に貼り付けていたのですが、エラーメッセージから何が起こってるのかを考えて、それが起こる原因を追い、さらにその原因を追うという考え方が重要であるということを学びました。
ここで学んだことを生かして、研究や就職活動に励んでいきたいと思います!

まとめ

​ 今回のインターンシップではEKSのモニターの設定を目的として、AWSの環境構築、GitやLinuxについての勉強、Kubernetesの使い方、EC2のインスタンスの作成など様々なことを学ばせていただきました。
習得することができれば非常に強力な武器になると感じたKubernetesは、このインターンシップに来なければ触ることはなかったと思いますし、これをきっかけに勉強していければと思っています!
また、実際のチームに入って実務的な開発環境に触れることで、SREセクションの方々のレベルの高さに圧倒されながらも楽しく勉強を進めることができました。
目標としていた、オンラインでも「明るく、話しかけやすい雰囲気」を出したいという点を達成できたかは分かりませんが、林さんやRakiさんをはじめとしたSREセクションの方々はオンラインでも話やすく面白い方ばかりで、エンジニアとしても一人の人間としても尊敬する方ばかりで良い刺激になりました! 一か月間あっという間に過ぎてしまい名残惜しいですが、またご縁があれば今度は現地でお会いしたいです🥺
一か月間本当にありがとうございました!!

メンターからのコメント

​ 東田さんのメンターを担当しました、SREセクションの高木です。 SREセクションではコーポレートサイトの信頼性向上というミッションがあります。
これまではSyntheticsによる最低限の監視を行っていました。 今後Datadogを使用して更に監視を強化して信頼性向上を目指すため、今回のインターンで他社様の事例などを調べつつモニターの設定に取り組んでもらいました。 ​ Git, Linux, AWS, Kubernetes, Datadogに触れたことがない状態からのスタートで、最初は分からないことだらけで苦労していましたが、徐々に自走できるようになりました。 モニターの設定に関しては敢えてこちらからのフォローをほとんど行わなかったにも関わらず、自力で調査やモニター設定を実施してくれました。 EKSの監視についてチーム内の知見があまり無かったため、私も学びを得ることができました。 これを機に更に監視設定を行い、信頼性向上に努めたいと思います。 ​ 今回のインターンで使用した技術は、今後エンジニアとして働くうえで必ず役に立つと思います。 インターンの時間内に学びきれなかったことは是非ご自身で学んでいただければと思います。 オイシックス・ラ・大地のインターンにご参加いただきありがとうございました。

Oisix ra daichi Creator's Blogはオイシックス・ラ・大地株式会社のエンジニア・デザイナーが執筆している公式ブログです。

オイシックス・ラ・大地株式会社では一緒に働く仲間を募集しています