コンテナオーケストレーションツール "kubernetes" でできること
https://gyazo.com/29bf53682f8b5eda8b18f23b6f8f341b
こんにちは、石﨑です。
みなさん、"Kubernetes"って聞いたことありますでしょうか？
名前は聞いたことあるけど、どんな技術なのかよくわかっていないという方もいらっしゃるかもしれません。
今回は、Kubernetesについて基本的な概念からお伝えしていこうと思いますので、初めの一歩として概要を掴んでいただけたら幸いです。
では、よろしくお願いいたします。
この記事で伝えたいこと
ソフトウェア仮想化ってなに？
ハイパーバイザー型、コンテナ型とは？
コンテナオーケストレーションってなに？
Kubernetesでなにができるの？
ソフトウェア仮想化技術について
まず、kubernetesを理解する上での大前提として、ソフトウェアの仮想化技術について理解しておく必要があります。
ソフトウェア仮想化とは、PCやサーバーなどのハードウエアリソース（CPU、メモリ、ディスクなど）を抽象化し、物理的な制限にとらわれず、ソフトウェア的に分割できるようにする技術です。
この技術を使用することで、アプリケーションの実行環境や開発環境に応じて、独立した環境を簡単かつ効率的に用意することができます。
ハイパーバイザー型とコンテナ型
ソフトウェア仮想化技術にはいくつか種類がありますが、現在主流となるのがハイパーバイザ型、コンテナ型と呼ばれる二つです。
ハイパーバイザー型では、一つのハードウェアに「ハイパーバイザー」と呼ばれる仮想化ソフトウェアをインストールし、仮想環境を構築します。ハイパーバイザーの代表的なソフトは、VMwareやHyper-Vなどが挙げられます。
一方、コンテナ型では、ホストOSに「コンテナエンジン」とよばれる仮想化ソフトウェアをインストールし、その中でコンテナと呼ばれる環境を作り、アプリケーションを実行させます。
コンテナのイメージとしては、「webサーバーを起動するCentOS」とか「Javaアプリケーションを実行するUbuntu」とか様々なパターンを簡単に用意することができます。
それらは、コンテナエンジン上で容易に生成、実行でき、それぞれが独立した環境で動作します。
コンテナエンジンとして最も有名なソフトウェアがDockerです。
https://gyazo.com/11763516bc31dd847f6afde10788145b
一般的に、コンテナ型はハイパーバイザ型に対して以下のような優位性を持ちます。
高速に起動、終了できる
ベースOSの機能を共有するため、オーバーヘッドが小さい
必要最小限のCPUやメモリーしか使用しない
アプリケーションの動作に必要な環境が、1つのコンテナで完結し、独立
環境構築、環境のコピー、配布、再利用が容易
コンテナ技術が持つこれらの特長を最大限に活かし、ユースケースに応じて様々な拡張機能をもたらすツールとして、本記事の主役であるKubernetesが登場します。
コンテナオーケストレーションツール "Kubernetes"
コンテナはとても便利なアプリケーションの実行環境です。
しかし、コンテナの利用が増えるのに応じて、大量のコンテナを管理するのも一苦労になってきます。
実際のサーバーの上では、さまざまな機能を提供するコンテナが無数に配置されますが、Docker等のコンテナエンジンはそれらを効率よく配置したり、自動で管理する機能は持ちあわせていません。
そこで、コンテナオーケストレーションツールKubernetesの出番となるわけです。
KubernetesはGoogle主導で開発された、コンテナの運用を自動化するためのコンテナオーケストレーションツールです。 読み方はクバネティス(私はこれです)やクーベルネティス等と呼ばれることが多く、K8s(ケーエイツ)と表記されることもあります。
現状、コンテナオーケストレーションツールとしてはKubernetesがほとんどデファクトとしての位置を築いており、様々なサービスで利用されています。
さっそく、Kubernetesでできることを以下にまとめます！（ここが本記事の全てかもしれません、、）
Kubernetesでできること
アプリケーションに必要な複数のコンテナを予定通りに自動デプロイ(スケジューリング)
ロードバランシングによる負荷分散の実現
サービスの負荷に応じてコンテナを自動的に増減（スケーリング）
コンテナイメージのバージョン管理とロールバック（問題が発生したらすぐ前のバージョンに戻せる）
障害発生時にコンテナを自動で再デプロイ
コンテナイメージの自動ビルドを実行
リソース利用率の監視と制限 などなど、、
ここに挙げたことだけでも、便利なことがいろいろできそうな気がしてきます。
それでは、どのような仕組みでこのような機能を実現しているのか、次で具体的に見ていきます。
Kubernetesの仕組み
Kubernetesで実行されるアプリケーションは、様々なリソースと強調して動作することで成立します。
ここでいうリソースとは、アプリケーションのデプロイ環境を構成する部品のようなもので、これから紹介するNodeやPodといったKubernetes独自で定義された構成要素のことを指します。
Kubernetesの各種リソースについて
以下がKubernetesの最も基本的な概念図となります。
Kubernetesでは、用途に応じて多種多様なリソースがあらかじめ定義されているため、ここで全てを取り上げることはできません。
ここでは、Kubernetesの概要を掴むために重要な、基本的なリソースをピックアップして、それらの概念についてざっくりと理解していきたいと思います。
https://gyazo.com/3ad0d7fb22c742a15d4b846a271f8959
◇クラスタ、Node、Namespace
Kunbernetesで登場する各種リソースの管理をする大きな集合体がKubernetesクラスタと呼ばれます。
このクラスタが持つリソースで最も大きな概念がNodeになります。
Nodeはアプリケーションを実際に実行するための物理/仮想サーバのことを指しており、一般的に1つのクラスタ内には複数のNodeが含まれます。クラスタには全体を管理するサーバとなるMaster Nodeと、コンテナの実行環境となる複数台のWorkerNodeが存在します。
KubernetesはNamespceという概念によって、クラスタの中に入れ子となる仮想的なクラスタを作成することができます。
このNamespaceを利用すると、チーム開発をする際にも開発者それぞれのクラスタを用意することができ、開発リソースの共有ができます。
◇コンテナの実行環境Pod、Podへの経路情報を司るService
Kubernetesにおいて、コンテナを実行する最小単位がPodと呼ばれます。
Pod内には少なくとも一つのコンテナが含まれますが、アプリケーションとDBのように、密結合な関係であることのほうが都合が良い場合は、それらのコンテナを一つのPodに一括りにしてデプロイします。
Podがノード上にデプロイされると、そのPodに含まれるコンテナがそのノード上で次々と起動されていきます。
Podは複数のノードに散らばって配置されますが、障害発生時などには別ノードへ再配置されることもあるので、Podへのアクセス先が急に変わってしまうということがあります。
このような問題を解決するために、KubernetesではServiceと呼ばれるリソースが各Podの単一エンドポイントとなることで、複数のPodやNodeの所在を意識せずに通信を行うことができます。
また、Serviceのtypeを変更することによって、ロードバランシングやサービスディスカバリ、スケジューリング等を行うこともできます。下記はServiceのtypeをロードバランサーにした場合の外部との通信を模式化したものです。
https://gyazo.com/f8566612e1bf5b6825ce24ddbcd3e3d1
Kubernetesリソースの種類と用途 まとめ
Node：Kubernetesクラスタで実行するコンテナを配置するためのサーバ
Namespace：Kubernetesクラスタ内で作る仮想的なクラスタ
Pod：コンテナ集合体の単位で、コンテナを実行する方法を定義する
Service：Podにアクセスするための経路を定義する
まとめ
Kuberntesについてなんとなく概要を掴んでいただくことはできましたでしょうか？
本来であればGKE(Google Kubernetes Engine)等を使って、Kubernetsクラスタ上へのデプロイ等を実際に行ってみたかったのですが、時間がとれず申し訳ありません、、 Kubernetesに関しては公式ドキュメントや各種記事も豊富なので、今回興味を持たれた方は実際にクラスタを組んで色々試してみると面白いと思います。
ここまで読んでくださった方、ありがとうございました。
参考文献
Docker/Kubernetes 実践コンテナ開発入門 山田明憲