なぜ今 Kubernetes なのか？使い方、オブジェクトの種類を解説 | クラウド導入・システム運用ならアールワークスへ

2020.05.15

なぜ今 Kubernetes なのか？
Kubernetes って何?
Kubernetes のオブジェクト
まとめ

なぜ今 Kubernetes なのか？

コンテナ技術、特に Docker の普及により、アプリケーションの開発からリリースまでのサイクルが短縮されているのは、皆様実感されているものと思われます。
しかし、いざ本番展開しようと考えたとき、サービスの運用についてはいかがでしょうか。
例えば、リリースタイミングが増えたことで、コンテナの入れ替えオペレーションが増え、リリース対応の負荷が増えていたら元も子もありません。
また、サービスをコンテナ化すると、「どのコンテナがどういった状態であることが正しいのか」という状態の管理に負担が掛かることは、想像に難くないかとおもいます。

こういったコンテナ運用の悩みをサポートしてくれるツールの一つとして Kubernetes があります。
Kubernetes はコンテナ運用システムとして高い支持を得ており、事実上のデファクトスタンダードとなっています。
(Sysdig, Inc によると 2019 年時点でシェア 77% を超えているとのこと。)
大手クラウドの AWS、Azure、GCP も Kubernetes のマネージドサービスを提供しています。

この記事では、「WordPress サイトを構築する」というハンズオンを通して、kubernetes のコンセプト、使い方について、皆様のイメージの手助けができればと考えています。

なぜ今 Kubernetes なのか？ : この記事
Kubernetes で WordPress サイトを公開してみる (Azure 環境構築編)
Kubernetes で WordPress サイトを公開してみる (Kubernetes 設定編)
Kubernetes で WordPress サイトを公開してみる (運用編)

※ なお、Docker についての基本的なことは知っている前提とします。

Kubernetes って何?

「Kubernetes (クーバネティス)」とは、 Docker のオーケストレーションシステムのことです。
https://kubernetes.io/ja/

では、「オーケストレーションシステム」とは何か？という話になりますが、もともとはシステムやアプリケーションを運用するにあたって必要となる、設定・調整など一連の管理を自動化するシステムのことを言います。
Kubernetes は Docker のオーケストレーションシステムとして、コンテナの管理、もっと言えば、システム全体の管理を自動で行います。例えば、ダウンタイムが発生しないようにアプリをデプロイしたり、障害が発生したコンテナを作り直したり、スケールアウトしたり、などです。
これらのことを実現するために、Kubernetes には重要なコンセプトがあります。それは、

ユーザは、望ましい状態 (desired state) をセットする。
kubernetes は現在の状態を常に監視し、望ましい状態 (desired state) に一致させる。

ということです。

ユーザは、「使用するコンテナイメージ」「コンテナの数」「ネットワーク構成」「ディスク構成」などのシステム全体の情報を、全てマニュフェストと呼ばれる yaml ファイルで記述します。そして、この yaml ファイルを設計図に、オブジェクトと呼ばれるリソースを作成します。このあたりは、ansible や CloudFormation などの構成管理ツールに似ています。
大きく違う部分は、Kubernetes は常にオブジェクトを監視しており、現在の状態が望ましい状態からズレるとリアルタイムで一致するように修正するという点です。これにより、ユーザは「望ましい状態」を書いておけば、あとは Kubernetes が「ダウンタイムが発生しないようにアプリをデプロイしたり、障害が発生したコンテナを作り直したり、スケールアウトしたり」をよしなにやってくれます。

Kubernetes のオブジェクト

Kubernetes の使い方は、

マニュフェストからオブジェクトを作成する。

これだけです。

オブジェクトについて、もう少し詳しく説明します。
オブジェクトとは「望ましい状態 (spec) と、現在の状態 (status) を持つもの」です。
ですので、コンテナのような実体のあるものだけではなく、設定情報を持つもの (もしくは、設定情報そのもの) は全てオブジェクトです。

オブジェクトを作成するときに必須となるものは、以下の4つです。

apiVersion : Kubenetes API のバージョン
kind : オブジェクトの種類
metadata : 名前など、オブジェクトをユニークに指定するもの
spec : 望ましい状態

次に、オブジェクトの種類について説明します。
たくさんあるので、このあと必要になるものに絞って説明します。

Workloads

コンテナを管理するためのオブジェクトたちです。

Pod
Kubenetes の最小単位で、1つの IP アドレスを持っています。1コンテナ = 1 Pod と思っていても問題ありません。(ただし、複数のコンテナをまとめて 1 Pod にすることも可能です)
ReplicaSet
Pod のグループです。Pod をいくつ用意するかを指定します。
Deployments
ReplicaSet を管理するオブジェクトです。新しい ReplicaSet を作成することでアプリケーションをアップデートしたり、問題があるときは元の ReplicaSet に戻すことでロールバックしたりと、ユーザは Deployments を通してアプリケーションのデプロイを行います。Deployments/ReplicaSet/Pod の3層構造になっていることからわかるとおり、Deployment を作成することが、Kubernetes 上でコンテナを動かすための最初のゴールとなります。

Discovery & LB

エンドユーザがアクセスする場所、つまりサービスのエンドポイントを提供するオブジェクトたちです。

Service
L4 ロードバランサーに相当します。幾つかのタイプがありますが、クラウドプロバイダが提供するロードバランサーサービスと連携させることが多いです。
Ingress
L7 ロードバランサーに相当します。クラウドプロバイダが提供するロードバランサーサービスと連携させることもできますし、クラスタ内に自前で nginx などのプロキシを用意することもできます。 Ingress にて定義したルーティングルールなどは、Ingress コントローラーと呼ばれるコントローラーにより、ロードバランサーに反映されます。(AWS であれば ALB Ingress Controller、AKS であれば Application Gateway Ingress Controller が提供されており、API によってロードバランサーサービスに設定が反映されます。)