DevOpsのためのPython

第12章 コンテナのオーケストレーション コンテナ・オーケストレーション：Kubernetes

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

Dockerを試している場合や、1台のマシンでDockerコンテナのセットを実行するだけなら、DockerとDocker Composeで十分だろう。しかし、1 （シングルマシン）から2 （マルチマシン）に移行した時点で、ネットワーク越しのコンテナのオーケストレーションについて心配し始める必要がある。プロダクション・シナリオでは、これは当然のことだ。フォールトトレランス／高可用性を実現するには、少なくとも2台のマシンが必要だ。

クラウドコンピューティングの時代には、インフラを「アウト」（「水平スケーラビリティ」とも呼ばれる）にスケーリングすることが推奨されており、1つのインスタンスにCPUとメモリを追加して「アップ」（または「垂直スケーラビリティ」）にスケーリングする旧来の方法とは対照的に、システム全体にインスタンスを追加する方法が推奨されている。Dockerオーケストレーションプラットフォームは、これらの多数のインスタンスまたはノードを生のリソース（CPU、メモリ、ネットワーク）のソースとして使用し、プラットフォーム内で実行されている個々のコンテナに割り当てる。コンテナはVMよりもはるかにきめ細かくリソースを割り当てることができるため、自由に使える生のリソースをより有効に活用することができ、インフラをより有効に活用することができる。

また、特定の目的のためにサーバをプロビジョニングし、各インスタンスで特定のソフトウェア・パッケージ（ウェブ・サーバ・ソフトウェア、キャッシュ・ソフトウェア、データベース・ソフトウェアなど）を実行することから、リソースを割り当てる一般的な単位としてサーバをプロビジョニングし、Dockerオーケストレーション・プラットフォームによって調整されたDockerコンテナをその上で実行することへとシフトしてきている。サーバを "ペット "として見るか、"家畜 "として見るかという区別はよく知られているかもしれない。インフラ設計の初期には、各サーバには明確な関数があり（メールサーバなど）、多くの場合、特定の関数ごとに1つのサーバしか存在しなかった。そのようなサーバには名前付けのスキームがあり（グリッグはドットコム時代に惑星系の名前付けスキームを使っていたことを覚えている）、その世話と餌やりに多くの時間が費やされた。Puppet、Chef、Ansibleのような構成管理ツールがシーンに登場すると、各サーバに同一のインストール手順を使用することで、同じ種類の複数のサーバ（例えば、ウェブサーバファーム）を同時にプロビジョニングすることが容易になった。これは、クラウド・コンピューティングの台頭、前述の水平スケーラビリティの概念、そしてよく設計されたシステムインフラの重要な特性としての耐障害性と高可用性への関心の高まりと重なった。サーバやクラウドインスタンスは、その総体として価値を持つ、使い捨ての家畜のようなものだと考えられていた。

コンテナとサーバーレス・コンピューティングの時代は、"昆虫 "という別の呼称ももたらした。実際、コンテナの出入りは、儚い昆虫のように、潜在的に短い存在として見ることができる。ファンクション・アズ・ア・サービスは、Dockerコンテナよりもさらに儚く、その呼び出し期間と一致する短い、しかし強烈な寿命を持つ。 ...