他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術。１つのプロセスとして稼働しているにも関わらず、コンテナ内のソフトウェアから見ると独立したOS環境を占有しているように見える。OSとカーネルは共有し、プロセスを分離する仕組み。コンテナのプロセスごとにCPUやメモリなどのコンピューティングリソースが割り当てられ、アプリケーション稼働に必要なライブラリやミドルウェア等の依存関係が全て含まれる。

動作中のプログラム。あるプログラムがメインメモリ上に展開され、CPUで実行されている状態を指す。あるプログラムの実行中に同じプログラムをもう一度起動すると、それらは別のプロセスとして管理される。

コンピュータに命令を出すためのプログラム。種類としては、OS（オペレーション・システム）と、アプリケーション・ソフトの2つに大きく分けられる。

ハイパーバイザーを用いてCPUやメモリ、ストレージ等のハードウェアリソースをエミュレートすることで、複数のOSを同一のハードウェア上で実行する仕組み。ゲストOSごとにカーネルを占有するしくみ。

物理マシン上に仮想的なコンピュータ（仮想マシン）を作成し、その実行制御を担うソフトウェア

ある装置やソフトウェア、システムの挙動を別のソフトウェアなどによって模倣し、代替として動作させること

CPU（MPU/マイクロプロセッサ）や主記憶装置（メインメモリ）、外部記憶装置（ストレージ）、入出力装置などコンピュータのハードウェア資源の管理、外部の別の装置やネットワークとのデータ通信の制御などが主な役割で、コンピュータに電源が投入されると最初に起動し、電源が落とされるまで動作し続ける。

仮想的に作られたハードウェアリソース

仮想マシン上で動作するOS。１つのサーバーとして扱われ、ミドルウェアや各種ライブラリをインストールした状態で複数のアプリケーションを稼働することが一般的。

データベースへのアクセスやネットワークとの通信など、アプリケーションがよく利用するリクエストが数多くあります。これらのリクエストをサービスごとにまとめたものがミドルウェアと呼ばれるソフトウェア。webサーバやアプリケーションサーバー、データベースサーバーなど。

ある特定の機能を持ったコンピュータプログラムを他のプログラムから呼び出して利用できるように部品化し、そのようなプログラム部品を複数集めて一つのファイルに収納したもの。いくつかのパッケージをまとめて一つのライブラリとしてインストールできるようにしたもの

コンテナには、アプリケーションの稼働に必要となるランタイムやライブラリを１つのパッケージとして全て含めることができるため、アプリケーションの依存関係を全てコンテナ内で完結できる。依存関係を含めたパッケージがリリース単位となる。リリース時は環境ごとにどのパッケージを対象とするか意識する必要がなくなる。

プログラムの実行時に必要なライブラリやパッケージのこと。ランタイムモジュール、ランタイムライブラリなどとも呼ぶ。

動作に必要な各種プログラムやファイルをまとめたものである。モジュールをいくつか集めてまとめたもの。

pythonでいうと、pythonファイルのこと。他のpythonのプログラムからimportなどで呼び出して使える。（fromにライブラリ指定）モジュールの中にはいくつかのクラスや関数が含まれる。

言語の開発環境に標準で付属していないライブラリ。利用するにはpipなどのパッケージ管理ツールを使って、外部からインストールする必要がある。

言語の開発環境に元から付属しているもの。インストールなど必要なく利用できる。importが必要なものと必要ないものがある。

外部ライブラリをインストール、管理する際に使われる pythonならpip,javaならMavenなど

コンパイルされたコードを実行可能なソフトウェアに組み立てるプロセス。 これには、コンパイルだけでなくリンクやパッケージングなどの追加のステップが含まれる。ビルドは、ソフトウェアの完成形を作り出すための一連の作業のことを指す。 コンパイル+リンクのこと。

コンパイルすることで作られるオブジェクトコードにライブラリを付け加える作業

人間がプログラミング言語を用いて作成したソフトウェアの設計図(ソースコード)を、コンピュータ上で実行可能な形式(オブジェクトコード)に変換すること

人間の書いたソースコードを、コンピュータが実行するのに適した形式に変換したコードのこと。変換は主にコンパイラによって行われ、人間には容易に読み取れないバイナリ形式のオブジェクトファイル(object file)として生成される。それ自体が直ちに実行可能なわけではなく、リンカなどを用いていくつかのオブジェクトファイルを特定の形式で連結することにより、最終的な実行可能ファイルやライブラリが生成される。

コンテナに格納されるアプリケーションやアプリケーションの実行に必要な設定ファイル、実行環境、ミドルウェア、ライブラリなどをひとまとめにした、ファイル、設定情報のかたまりのこと

コンテナエンジン上にプロセスとしてコンテナは存在する。そのエンジンが管理するシステムリソースの範囲内で、複数のコンテナを同時に動作させることができる。ホストOSの「カーソル」をコンテナ間で共有することでCPUやメモリなどのリソースを共有隔離し、仮想的な空間を作り出す。

ハイパーバイザー型仮想化では、物理サーバにインストールされているOSとは別に、仮想マシン上にも個別にOSをインストールする必要があるため、仮想マシンの起動には物理サーバと同様にOSを起動する。しかし、コンテナでは起動しているホストOSの「カーネル」を共有することでアプリケーションの実行土台を備えることから、コンテナの起動には従来のOSの起動といった工程が必要ない（仮想サーバを立ち上げるオーバーヘッドが不要）。ハイパーバイザー型仮想化における物理サーバと仮想サーバは、それぞれ1つのサーバ環境として位置付けられる。しかし、コンテナ型仮想化におけるコンテナは、ホストOS上からは１つのプロセスとして扱われる。例えるならパソコン（ホストOS）と、この記事を表示しているブラウザ（プロセス）と同じような関係性。

ユーザが動作させたい「アプリケーション」と、そのアプリケーションの実行に必要な「ミドルウェア」、そして「ライブラリ」などが含まれる。このライブラリの中にはOSの基本的なコマンドセットやファイルシステムのライブラリなど、OSが提供する機能の一部が含まれている。Linuxコンテナを指すことが多い。OSとミドルウェアの一部までも同梱することにより、どこでも実行できるという高いポータビリティが得られる

Linuxにおけるアプリケーション（とその実行環境）を仮想のコンテナとして分離する方式

アプリケーションは、内部でOSの中核であるカーネルの機能を呼び出して動作している。その代表的な例としてファイルの読み書き（I/O）があげられる。このようなカーネルに対する呼び出しをシステムコールといい、ホストOS内のカーネルがコンテナ内のアプリからのシステムコールを処理することでコンテナ内のアプリケーションを動作させている。Linuxと呼ばれるOS群にRedHatEnterpriseLinux（RHEL）やCentOS、Ubuntuなど様々なディストリビーション（各社の配布パッケージ）が存在するが、基本的に共通のカーネルを使用している。そのため、アプリケーションの実行に必要なライブラリさえ（コンテナ内に）あれば、どのディストリビーションでもアプリケーションを動作できる仕様になっている

Linuxカーネル機能のNamespace、Cgroup、Capabilityを組み合わせる

各プロセスに対してシステムリソースそれぞれをその他のプロセスと分離する役割を担っている。例えば、ユーザIDやホスト名、ネットワークインターフェースの分離などがある。この機能によりコンテナAのプロセスとコンテナBのプロセスは隔離されるので、互いに干渉せずにプロセスを稼働できる。例えば隣り合うコンテナの中に同じ種類の物が入っていても、それぞれがコンテナAの〇〇、コンテナBの〇〇として管理される

プロセスをグループ化し、CPUやメモリなどホストOSの物理的なリソースを分離する役割を担う。例えば、プロセスが用いるCPUの使用率やメモリの割り当て、デバイスへのアクセスを制御する。１つの特定のプロセスがCPUやメモリリソースを大量に消費することで、ホストOSや他のプロセスに影響が出るといったリスクをコントロールする

Capabilityを用いてプロセスなどに与える権限を最小限に制御することで、仮に実行しているプロセスに脆弱性があったとしてもホストOSやほかのプロセスへの影響範囲をコントロールできる

ハイパーバイザー型仮想化では物理サーバ内に仮想サーバを作り、その上にゲストOSやアプリケーションを構築していく。この仮想サーバには仮想NICがあり、IPアドレスやMACアドレスが割り当てられている。仮想サーバから外のネットワークと通信するときは、普通の物理サーバと同様に通信を束ねて管理するハイパーバイザー上の仮想スイッチを経由する

物理サーバの物理NICとNamespaceで分離されたコンテナ内の仮想NICの間にコンテナエンジンで制御されている仮想ブリッジがあり、コンテナとホストOS間の橋渡しをする。さらに、ホストOSのNAT（Network AddressTraslation）機能により、コンテナのIPからホストOSが持つIPへ変換される。これでコンテナは外部と通信できるようになる

優れた再現性とポータビリティ。全ての依存関係がコンテナ内で完結するため、ローカル環境だけでなく、オンプレミスやパブリッククラウド上で同じように動作させることができる。テスト環境でテスト済みのイメージを本番環境に再利用することで、環境間のライブラリの差異を意識しなくてすみ、アプリケーションの開発やデプロイの効率を高めることができる

サーバー仮想化と比較すると、ゲストOSやハードウェアのエミュレートが不要となるため、アプリケーションを動かすために必要なコンピューティングリソースの消費を少なくできる。コンテナはOS単位ではなくプロセス単位で稼働するため、アプリケーションの起動も高速

linuxコンテナエンジン。その実現に欠かせない要素が「DockerEngine」と「DockerHub」

アプリケーション本体とそれを実行するための環境を１つのDockerイメージにまとめることができる。そして、移動先でDockerイメージに基づいてコンテナを実行させ、簡単かつ高速にアプリケーションを起動できる

Dockerイメージの移動や管理、Dockerイメージを共有する場としての役割を果たす（いわゆるリポジトリ）

Dockerイメージを生成するための手順を定義したもの。アプリケーションが動作する土台となるインフラ環境を構築するコマンドや手順などを所定の書き方でDockerfileに記載すれば、その作業はDockerが自動でやってくれる

UFS（UnionFileSystem）という、複数のファイルやディレクトリをレイヤ（層）として積み重ねて、仮想的に１つのファイルシステムとして扱う技術を用いている。土台となるベースレイヤの上にファイルやディレクトリなど複数のレイヤを積み重ねた読み取り専用のイメージレイヤがまとめられており、コンテナの起動時に読み書きが可能なコンテナレイヤが追加されてアプリケーションを実行する。同一のホスト上で動く複数のコンテナがある場合は、イメージレイヤを共有できる。これにより、ホストのストレージ容量の圧迫を抑制できるようになる。

イメージレイヤの内容が変更される場合には、変更対象のレイヤを一度コンテナレイヤにコピーしてから変更内容を反映する

Dockerfileからベースイメージを使用してDockerイメージを作成すること

既に起動されたDockrコンテナからイメージを作成すること

独自にイメージを登録するためのプライベートレジストリサーバを構築するか、DockerHubを使用する。DockerHubには誰でもDockerイメージを無料で保管や共有ができるパブリックリポジトリと、自分やプロジェクトメンバーだけが扱えるように制御できる有料のプライベートリポジトリの2種類がある

DockerイメージをプライベートレジストリやDockerHubなどへアップロードすること

DockerイメージをプライベートレジストリやDockerHubなどからダウンロードすること

DockerにはDockerイメージにタグを付与してイメージを区別できる機能があり、タグにバージョン番号を指定する

コンテナが削除され、再度起動しても、プロセスなので、削除前に実行していたデータが戻らないこと

Dockerではデータボリュームとデータボリュームコンテナの2つのボリュームにより、コンテナが削除されてもデータは残し、他のコンテナとデータを共有できる。このようにデータをコンテナの削除から退避させることをデータの永続化という。コンテナが削除されても退避していたデータに引き続きアクセスできる状態のこと。

２つの異なるプロセスを１つのコンテナに内包させたとする。もし片方のプロセスのアップロードに伴ってコンテナを入れ替える必要性が必要性が出てきた場合、関係のないもう片方のプロセスまで影響を受けてしまうから

複数のコンテナを一括で管理できるツール。アプリケーションが使用するDockerイメージやネットワーク、ボリューム、再起動ポリシーなどをそれぞれYAML形式でcomposeファイルとして定義。composeファイルを使用すると、１つのコマンドでコンテナのビルドや複数コンテナをまとめて起動できるようになる

Dockerが備えるクラスタ管理機能。Docker composeで定義した複数のコンテナをクラスタ上（複数のホスト）に起動することで、ホストへの負荷を分散できるようになる。このほかにも、コンテナ管理者の負担を軽減してくれる機能がある

複数のホストを仮想的に束ねて１つのホストとして扱う機能があり、この束ねられた複数のホストのこと

Dockerのコンテナに格納されているベースとなるファイルやディレクトリ

アプリケーションのソースコードとDockerfileからイメージを作成するコマンド

作成・取得したイメージ情報の一覧を表示するコマンド

不要になったイメージの削除ができるコマンド

作成したイメージに対してタグ情報を追加するコマンド

作成したイメージをレジストリに保存するコマンド

レジストリに保存したイメージを取得するコマンド

コンテナを実行するコマンド

バックグラウンドでコンテナを実行する

実行したコンテナの起動状態を確認するコマンド

コンテナ内のアプリケーションのログを確認するコマンド

実行中のコンテナに対してコマンドを発行できるコマンド

シェル「bash」を起動するコマンド

実行中のコンテナを停止するコマンド

コンテナ化されたアプリケーションのデプロイやスケーリング、管理などが自動的にできる

・コンテナの配置管理‥各ホストのコンテナ稼働状況を考慮しながらコンテナを実行せる ・コンテナの負荷分散‥コンテナへのリクエストを負荷分散 ・コンテナの状態管理と自動復旧‥コンテナの状態を監視し、異常発生を検知して切り離しや自動復旧によりコンテナ数を維持する ・コンテナのデプロイ‥アプリケーションの稼働を正常に保ちつつ、バージョンアップなどを行い、新旧のコンテナを自動的に入れ替える

・コンテナを前提としたアプリケーション開発のあり方‥分散システム構成に近づくため、コンテナ間の疎結合性や移植性を考慮した方式を検討しないといけない ・コンテナ設計・運用に取り組む際の姿勢‥従来のサーバー構成で求められてきた非機能要件の考慮は変わらず重要 ・開発チームにおける役割分担の見直し‥コンテナはアプリケーションとその依存関係を１つのパッケージとして扱うため、アプリチームがインフラの領域を担うことになる。インフラもコードを書くこともあるため、お互い寄り添うべき。

インフラリソースをコードにより管理することで、それによってインフラ環境の自動化が可能になる。IaCを実践することで、同一のインフラ環境を迅速に手配できる。また、コードの共有や再利用が容易になるだけでなく、バージョン管理やコードレビューによる品質検証のプラクティスを適用できる

コンテナオーケストレーションシステムのデファクトスタンダード。 クラスタとノードで構成される。

異なる役割を持つノードの集まりをクラスタという形で管理する。クラスタ内には少なくとも１つ以上のマスターノードと1つまたは複数のワーカーノードが存在する。

クラスタ内にあるコンテナなどのコンポーネントに障害が発生した場合、当該コンテナを自動で再起動させたり、他のノードでコンテナを起動させ、故障したコンテナが実行していた処理を引き継がせたりと、事前に定義した状態を維持する

特定のノードに処理が集中しないように、ノード間で負荷を自動で分散する

クラスタの構成要素

クラスタ内にあるワーカーノードとPodを管理する。それぞれ役割を持った複数のマスターコンポーネントで構成されている

マスターノードで実行されるコンポーネント。それぞれが密接に連携しているため同じノードでの起動が推奨。可用性確保のためには、マスターコンポーネントを1セットとして起動させたマスターノードを複数用意するといい

外部からクラスタを操作する窓口となるAPIを公開しており、管理者がAPIを通じてKubernatesをコントロールするマスターコンポーネント。クラスタ操作に対して、認証、認可（受信した操作リクエストが実行可能な権限を持つユーザによるものかを照合する）、入力制御（リクエストの中身を確認して、受け入れるかブロックするかなどを行う）を行う

kubernatesクラスタに関する全情報（ノードやPod、構成、アカウントやロールなど）を保存するマスターコンポーネント。ノード情報を取得するリクエストが実行されたとき、表示される情報はAPIServerがetcdと直接やりとりをして引っ張ってくる。分散しれた多数のノード間でデータをレプリケート（複製）して保管することに適しており、マスターノードとマスターコンポーネントのセットが複数あっても一貫してクラスタ情報を保てる

Podが新しく作成され、どのノードにも配置されなかった場合、適切なノードに配置するマスターコンポーネント。Podが各ノード間で偏りが出ないように配置する。フィルタリング、スコアリングという配置決めのルールを指定できる

様々なコントローラをまとめて実行するマスターコンポーネント。コントローラは個別のプロセスだが、ほれらが一つの実行ファイルにまとめられてcontroller-managerとして単一のプロセスで実行される

kubernatesのコンポーネントなどの状態を監視し、必要な対応を実行するプロセスのこと

kubernatesで使用したいリソースと実際にクラウドで使用しているリソースを連携する。kubernatesがやりたいことをパブリッククラウドとの間に入り操作の指示を中継することで、kubernates上の情報とパブリッククラウド上のリソースとの整合性を保つ

実際にPodを動作させるためのノード。Podとノードコンポーネントで構成されており、マスターノードにより管理される。ノードコンポーネントは全てワーカーノードで実行される

各ノードで動作するkubernatesのエージェントで、Podの起動や管理を担う。schedulerからのPod配置指示をAPIServer経由で受け取り、コンテナランタイムを操作してワーカーノード上にPodを作成する。Podやノードの状態を監視してAPIServerにレポートを送信する

iptablesを利用して、通信をPodへ転送するためのノード内のネットワークルールをメンテナンスする。

linuxカーネルのファイアウォール機能。主に通信の許可や遮断の機能と、受信した通信の送信先アドレスを変換し転送する機能などを持つ

ワーカーノードでコンテナを実行するコンポーネント。kubeletから受けた指示を元にコンテナのイメージ取得から実行まで行う。高レベルランタイムと低レベルランタイムの2層に分かれる。

主にコンテナのイメージを取得し、実行するコンテナ環境の設定ファイルなどを作成する。kubeletからCRI(Container Runtime Interface)というインターフェイスで呼び出される

高レベルランタイムで行うイメージ取得やコンテナ環境の設定などの定義情報が含まれている。

設定ファイルを元に環境の作成やコンテナの実行を行う。低レベルランタイムはOCI(Open Container Initiative)に準拠した仕様で高レベルランタイムから呼び出され、高レベルランタイムから受け取った情報を元にコンテナ環境を作成する。 OCIは低レベルランタイムの標準仕様で、設定ファイルを元に作られるNamespaceやcgroupなどの仕様が定められている。

クラスタ外部からクラスタ内に通信するためのURLを提供し、Serviceにロードバランシングするオブジェクト。外部のクライアントはこのURLを通じてServiceやPodへアクセスできるようになる。Ingressには、クラウドやオンプレミスなどのクラスタ外部のロードバランサーを使用する形式と、クラスタ内部にIngress用のPodを起動する形式とがある。負荷分散やSSL/TLS終端の機能や、Serviceに名前ベースの仮想ホスティングを構成する機能などがある。

各パブリッククラウドのロードバランサーサービスと連携するものやIngress-nginxなどがある。これらのIngressControllerを用いることで通信をServiceへルーティングできるようになる

各種リソース構成や実行するコンテナイメージなどをYAML形式で記述する。ManifestにKubernetesクラスタの「望ましい状態」を事前に定義し、マスターノードに登録して管理することで、インフラのコード化とも言われる「Infrastructure as Code」を実現する。

Kubernetesの中にコンテナを作り、アプリケーションを動かすための部品。コンテナの配置や動かし方により異なる「コンピュート」、データの永続的化に欠かせないデータを保管する「ストレージ」、外部からのアクセスに欠かせないIngressをはじめとする「ネットワーク」がある。他にも、Kubernetesクラスタ上のリソースへのアクセスを制御し、セキュリティの堅牢性を担保する「アクセス制御」、Podの中で用いる情報の一部を外部へ出力する「Pod設定」、Kubernetesクラスタを安全に扱うための「クラスタ設定」、上記に分類されない特殊な「その他」など、数多くのリソースを活用できる

Podなどのリソースをグループ化

グループ化された特定のリソースを使用する際に指定

様々なコンピュータリソースを分離・独立し、お互いの干渉を防ぐためのLinuxカーネルの機能。同様に、KubernetesのNamespaceも複数のワーカーノードを横断して「kubernetesリソース」の分離と独立を制御できる。Kubernetesには環境を作成した時点で3つのNamespaceが用意されている。 default：特にどのNamespaceに配置するかを決めていないリソースのためのデフォルト用 kube-system：Kubernetesが作成したコンポーネント(前回で紹介)や管理用のリソース用 kube-public：Kubernetesにアクセスする全ユーザーが利用できるように意図的に配置したリソース用