[レポート] コンテナおよびKubernetesのベストプラクティストップ5 #reinvent #CON307

はじめに

本記事は「Top 5 container and Kubernetes best practices」のレポートです。

セッション概要

Yes, technologies like containers and Kubernetes can help make your software delivery processes easier and faster. However, these new deployment tools and orchestration methods are very different from a traditional environment in terms of management and monitoring. How should you architect your container so that it works the way that you want—and need—it to? Through the live examples provided in this session, you learn best practices for ensuring the efficiency and quality of the next application that you migrate to AWS. This presentation is brought to you by New Relic, an APN Partner.

セッション概要（日本語訳）

はい。コンテナやKubernetesなどのテクノロジーは、ソフトウェア配信プロセスをより簡単かつ迅速にするのに役立ちます。ただし、これらの新しい展開ツールとオーケストレーション方法は、管理と監視の点で従来の環境とは大きく異なります。コンテナをどのように設計して、希望どおりに（そして必要に応じて）動作するようにしますか？このセッションで提供される実例を通して、AWSに移行する次のアプリケーションの効率と品質を確保するためのベストプラクティスを学びます。このプレゼンテーションは、APNパートナーであるNew Relicによって提供されます。

レポート

アジェンダ

• ベストプラクティストップ5
  • コンテナのイメージのサイズを小さくする
  • k8sの名前空間を活用する
  • コンテナのヘルスチェックを有効にする
  • コンテナリソース（cpu、memory）に対するrequestsとlimitsを設定する
  • ログを活用する（インフラリソースの問題に対するコンテキストを理解する）

コンテナのイメージのサイズを小さくする

なぜコンテナのイメージのサイズを小さくするのか

• ビルド時間を短縮する
• コンテナイメージをPullする時間を短縮する
• アプリケーションとして利用しないライブラリを減らすことでセキュリティリスクを低減する（脆弱性のあるライブラリが入る可能性を減らす）

どうやるのか

• アプリのニーズを特定する
• 適切なベースイメージを選択する
  • alpineのイメージを用いる
• 不要なリソースを避ける
  • alpineのイメージを用いる
• Dockerビルドキャッシュを活用する
  • 頻繁に更新するファイルはDockerファイルの後ろで実行するなど
• マルチステージビルドを活用する

k8sの名前空間を活用する

なぜk8sの名前空間を活用するのか

• 管理性、セキュリティを改善する
  • 異なるチームのk8sリソースを分離することで改善される

どうやるのか

• k8sの定義ファイル（yaml）を変更する
• kubectl applyを実行し変更を開始する

コンテナのヘルスチェックを有効にする

• Readiness probes
  • コンテナがRedyの状態であるか
  • アプリケーションがトラフィックを受け入れる準備ができているかどうか
• Liveness probes
  • コンテナが生きているのか死んでいるのか

なぜコンテナのヘルスチェックを有効にするのか

• 迅速なトラブルシューティングと問題解決
• クラスターで発生するすべてのイベントを監視する
• スケーリングイベントなどの特定のイベントを追跡する

どうやるのか

• k8sの定義ファイル（yaml）のprobeを指定する
• initialDelaySecondsを忘れずに設定する
  • ヘルスチェックの実行間隔などを定義
• kubectl applyを実行し変更を開始する

コンテナリソース（cpu、memory）に対するrequestsとlimitsを設定する

• Recuests
  • コンテナが取得することが保証されているもの
• Limits
  • コンテナが指定のサイズを超えないようにするもの

なぜコンテナリソース（cpu、memory）に対するrequestsとlimitsを設定するのか

• リソースの制限がないとポッドが不安定になり、終了する可能性がある
• 不適切なサイズのリクエストは、スケジューリングの問題を引き起こす可能性がある

どうやるのか

• k8sの定義ファイル（yaml）のRecuests、Limitsを指定する
• kubectl applyを実行し変更を開始する
• deescribeコマンドを利用しRecuestsとlmitsのリストを表示し内容を確認する

ログを活用する

ログを活用することで

• 可視性を得る（コンテナに何が起きたのか）
• 理解を得る（ポッドは適切に動作しているのか）
• 安定性を得る（ホストは危険な状態になっていないか）

なぜk8sのログを見るのか

• 環境に関するより多くのコンテキストを確認することができる
• 問題が発生した場合の迅速なトラブルシューティングが可能
• ノード、ポッド、およびクラスターレベルで状況を確認することができる

どうやるのか

• k8sのログ出力プラグインをインストールする（New Relic）
• 適切なライセンス情報で更新する
• kubectl applyを使用して取り込みを開始する

本日の学び

• イメージは小さくビルドすること
• k8sの名前空間は適切に定義すること
• コンテナを監視し正しい状態でいること
• RecuestsとLimitsを指定すること
• k8sクラスタの状態、コンテキストを理解すること

まとめ

New Relicのコンソールを確認しながら、5つのプラクティスを確認していく有益なセッションでした。ベストプラクティス沿って開発し、かつ、New Relicを導入することができれば、難しいクラスタの運用もある程度楽になるような気がしました。
※私がクラスタの面倒をみる立場であれば、New Relicを導入したい！！と思えるようなセッションでした。