Kubernetes完全ガイド第2版を読んでみた（輪読会用のメモ）1-2章

Last updated at 2024-01-11Posted at 2024-01-11

第1章

主に気をつける点

1コンテナにつき1プロセス
- 1つのイメージの中に複数のプロセスを立てる方法は非推奨
Immutable Infrastructureなイメージにする
- 不変のインフラを意味し、「環境を変更する際は古い環境は廃棄して新たに作る」「一度作られた環境は変更されないことを徹底する
軽量なDockerイメージにする
- コンテナ実行時、ノード上に使用するDockerイメージが存在しない場合は、外部からイメージをダウンロードして取得するため軽量に保つことが大事
実行ユーザをroot以外にする
- コンテナ内でプロセスを起動する実行ユーザの権限を最小化にして、リスクを減らす

（省略）

コンテナオーケストレーションエンジンであるKubernetesを利用することで、これらの課題は自動化可能かつシンプルなオペレーションによって解決できる

Kubernetesは、YAML形式やJSON形式で記述した宣言的なコード（マニフェスト）によって、デプロイするコンテナや周辺リソースを管理できる
- Infrastructure as Code

コンテナをKubernetes Nodeにデプロイする際には、どのKubernetes Nodeに配置するかを決定することを「スケジューリング」という。
- AffinityとAnti-Affinity機能を使用することで、コンテナ化されたアプリケーションのワークロードの特徴や、Kubernetes Nodeの性能差を意識してスケジューリングを行うことがでる。
  - 例えば、「ディスクI/Oが多い」コンテナを「ディスクがSSD」のKubernetes Nodeに配置する、といった制御が可能

コンテナ配置のための特別な指定がない場合には、Kubernetes NodeのCPUやメモリの空きリソースの状況に従ってスケジューリングが行われるため、ユーザはどのKubernetes Nodeにコンテナを配置するのかを管理する必要はありません

耐障害性という観点では、Kubernetesにとって重要なコンセプトの一つでもある、セルフヒーリング
- Kubernetesは標準でコンテナのプロセス監視を行っており、プロセスの停止を検知すると、再度コンテナのスケジューリングを実行することで自動的にコンテナを再デプロイされる
- クラスタのノード障害が起きたり、ノード退避を行ったりして、そのノード上のコンテナが失われた場合であっても、サービスに影響なくアプリケーションを自動復旧できるように作られている

あらかじめ指定した条件に合致するコンテナ群に対してルーティングを行うエンドポイントを払い出すことができる
- コンテナのスケール時にエンドポイントとなるServiceへのコンテナの自動追加や削除はもちろん、コンテナの障害時における切り離しや、コンテナのローリングアップデート時における事前の切り離しなども自動的に実行してくれます

※一部のサービスを順次更新していく手法

Serviceにサービスディスカバリの機能があることにより、それぞれのマイクロサービスが定義された複数のマニフェストを元に、システム全体を簡単に連携させることが可能

Kubernetesは、バックエンドのデータストアにetcdを採用している
- etcdはクラスタを組むことで冗長化ができるため、コンテナやServiceに関するマニフェストも冗長化されて保存されている
コンテナが利用する設定ファイルや認証情報などのデータを保存する仕組みも用意されており、コンテナで共通の設定やアプリケーションから利用されるデータベースのパスワードなどの情報を、安全かつ冗長化された状態でKubernetes上に集中管理できる

※etcdはオープンソースとして配布されているキーバリュー・ストアであり、配布されたシステムが実行し続けるために必要不可欠な情報を保持、管理するために使用される

引用元：Kubernetes完全ガイド第2版