Managed Service Column <システム運用コラム>

Kubernetes

Category: 実践編

2020.05.15

なぜ今 Kubernetes なのか?

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

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

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

※ なお、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 によってロードバランサーサービスに設定が反映されます。)

Config & Storage

初期データ、もしくは、永続データを管理するオブジェクトたちです。

  • configmap
    暗号化されていない key, value の組です。データベースへの接続情報などを記述します。
  • secrets
    暗号化されている key, value の組です。パスワードなどを記述します。
  • Persistent Volumes
    永続化ボリュームの情報です。クラウドプロバイダが提供するストレージサービスなどを指定します。

spec にどんな値を指定できるか、及び、他にどんなオブジェクトがあるかは、公式のリファレンスを見てください。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/

まとめ

ここまでざっと説明しましたが、実際に触ってみないとイメージがわかないかと思います。
(現時点ではなんとなく理解できていれば大丈夫です。)

次は、Azure が提供する Kubernetes のマネージドサービス AKS を使って、実際に WordPress サイトを作ってみます。
「Kubernetes で WordPress サイトを公開してみる (Azure 環境構築編)」を読む

Tag: Kubernetes

Contactお問い合わせ

お見積もり・ご相談など、お気軽にお問い合わせください。

single.php