そもそもコンテナとは？
アプリケーションを独立で実行するための入れ物です。
特徴
コンテナの実態はプロセスです。
chrootが始まり
rootディレクトリを変更して、上位ディレクトリへのアクセスを制限する。あたかも別マシンを使ってるかのような錯覚をさせる仕組み。
Kernel Namespaceを使用してプロセスID、ネットワークインターフェース、リソースなどを分離
コンテナ間で干渉しない。
ホストマシンへの依存度を最小化している。
アプリケーションがどこでも実行可能。つまり、アプリケーションが依存しているライブラリがコンテナ側にしかインストールされておらず、コンテナを動かすホスト側にはインストールされない。
コンテナはCI/CDと相性が良い
ポータビリティと再現性に優れる。
コンテナはアプリケーションに必要な依存関係をパッケージ化してビルドします。一度ビルドしたコンテナイメージは実行環境となるホストマシン上で同じように振る舞います。CI/CDと組み合わせることで依存関係が解決されたアプリケーションの自動ビルド〜デプロイが実現できる。
軽量
また、VMなどの従来の仮想化技術と比較してアプリが動作するために必要な最低限のコンピュータリソースのみ消費するためアプリの起動速度が早いです。
コンテナオーケストレーションとは？
複数サーバーでコンテナを動かしたい場合
複数サーバーの複数コンテナを効率よく管理する仕組みで、本番環境でコンテナを使って動作させようと思った際に使える技術です。
ローカル環境では「docker-compose」を使って開発したりすると思いますが、docker-composeは単一サーバーの複数コンテナしか管理することができないので複数サーバーが前提の本番環境やマイクロサービスアーキテクチャでは使えません。そういう意味でこの技術が最近は需要が上がっています。
耐障害性をあげたい。
1つのマシンが落ちたら終わりにならないようにしたい。
アプリケーションごとに求められるマシンスペックが異なる。
メモリを増強したいなど。
コンテナ
Docker
デファクトスタンダード
containerd
Docker社がCNCFへ寄与したコンテナランタイム
cri-o
純粋なCRI実装。軽量でセキュア。
rkt
Dockerランタイムの代替として開発。デーモンが存在しない。
コンテナオーケストレーションサービスの例
Docker-Swarm
Docker用のクラスタ管理ツール
Kubenetes
高機能
ECS
EKS
AWS上で利用可能なKubenetes
AKS
Azure上で利用可能なKubenetes
GKS
GCP上で利用可能なKubenetes
Rancher
複数環境のKubenetesを統合管理する。
コンテナオーケストレーションサービスの機能
使うサービスによって異なる部分はありますが、概ね以下のような機能はどのサービスにも提供されています。これらの機能はコンテナオーケストレーションがない時代は運用者がそれぞれそれができる専用のツールを入れて運用していたりしていたのでシステムに一任できるメリットがあります。
クラスター管理機能
あるコンテナがダウンした際に、別のコンテナを動作させる。
コンテナの自動デプロイ
コンテナを配備する際に、サーバーの負荷状況から配備に適したサーバーを自動判断します。また、アプリをアップデートする場合でも停止しないようにアップデートすることができます。（ローリングアップデートや、blue/greenアップデート戦略など）
コンテナの死活監視
コンテナが停止してないか監視する。
障害時の自動復旧
障害によりコンテナが停止した場合に、コンテナを破棄して新たなコンテナを起動する。
スケーリング機能（オートスケーリング）
アプリケーションへ高負荷がかかった際に、コンテナ数を増減させたり、サーバーを増減させたりできる。
ネットワーク機能（サービスディスカバリー）
他サーバーで動いているコンテナを自動検出して、コンテナ間の通信を簡単にします。
スケジューリング機能
どのマシン上で動かすのか（地理的分散、マシン要件）
リソースマネジメント機能
使用可能なリソースを環境ごとにリミットやデフォルト値を設定できます。
セキュリティ機能
ネットワークポリシー、リソースへの権限設定などができる。
この記事へのコメントはありません。