Google Cloud

GCP / Nutanix と Kubernetes でコンテナ化アプリをハイブリッド対応に

2017年7月25日

Google Cloud Japan Team

私たちは先ごろ、Nutanix との戦略的提携を発表しました。大企業のハイブリッドクラウドデプロイにおける課題の解決を支援するためです。発表に関する投稿記事はこちらにあります。

ハイブリッドクラウドを導入した企業は、オンプレミスもしくはパブリッククラウドでさまざまなアプリケーションを実行できます。このアプローチには次のような利点があります。

製品、機能のリリースのスピードアップ
顧客の需要に合わせたアプリケーションのスケーリング
自社のペースに合わせたアプリケーションのパブリッククラウドへの移行
インフラストラクチャに費やす時間を減らし、コード開発の時間を増やす
リソースの活用と効率的なコンピューティングによるコスト削減

大多数の企業はニーズが異なるさまざまなアプリケーションを抱えています。アプリケーションによっては、データ主権とコンプライアンスの関係から、アプリケーションとそのデータをオンプレミス環境か国境線の内側に置かなければならないという管轄権上の制約を受ける場合があります。それに対してモバイルや IoT のアプリケーションは予測不能な消費モデルを特徴としており、最良のデプロイターゲットはオンデマンドの pay-as-you-go クラウドモデルになります。

ハイブリッドクラウドデプロイは、要求されるセキュリティ、コンプライアンス、コンピューティングパワーと、必要とする機敏性、柔軟性、スケーリングを両立させるうえで大きな力となります。

ここで例として取り上げるハイブリッドクラウドは、次の 3 つの主要コンポーネントから構成されます。

オンプレミス : Nutanix のインフラストラクチャ
パブリッククラウド : Google Cloud Platform（GCP）
オープンソース : Kubernetes とコンテナ

不変でポータビリティの高いインフラストラクチャを提供するコンテナにより、コンテナランタイムエンジンを実行できるあらゆる環境に予測可能な形でアプリケーションをデプロイできます。ベアメタルでもプライベート / パブリッククラウドでも、同じコンテナ化アプリケーションを実行できるわけです。しかし、開発のトレンドはマイクロサービスアーキテクチャの方向に向かっており、デベロッパーはスケーリングやローリングアップデート、ディスカバリ、ロギング、モニタリング、ネットワーク接続といった新しい課題を解決しなければなりません。

Googleは、コンテナベースの社内システムを独自に開発してきた経験からヒントを得て、さまざまなコンピューティングリソースのもとでコンテナ化アプリケーションを実行できる、オープンソースと Google Cloud 管理下のプラットフォームとして Kubernetes と Google Container Engine を作りました。Kubernetes は、基盤となるインフラストラクチャを抽象化し、統一的な形でコンテナ化アプリケーションを実行できるようにします。

Kubernetes は宣言的なデプロイモデルという概念を導入しています。このモデルのもとでは、アプリケーションをどのように実行すべきかを記述したテンプレートに従って、Kubernetes がアプリケーションの状態を制御します。Kubernetes は、コンテナのスケジューリング、スケーリング、健全性、ライフサイクル、ロードバランシング、データ永続性、ロギング、モニタリングも管理します。

Google Cloud と Nutanix による共同作業の第 1 段階では、オンプレミスの Nutanix と Google Cloud の両方の環境において、ワークロード管理の単一のコントロールプレーンとして Nutanix Calm を使用し、コンテナ管理レイヤとして Kubernetes を使用するハイブリッド運用に力を注ぎます。

Nutanix Calm は、先ごろ開催された Nutanix .NEXT カンファレンスで発表された製品で、ハイブリッドクラウドデプロイを通じてプロビジョニングとライフサイクル管理を自動化します。また Nutanix Enterprise Cloud OS は、クラウドの Google Compute Engine で実行されるハイブリッド Kubernetes 環境と、オンプレミス Nutanix 上の Kubernetes クラスタをサポートします。これにより、オンプレミスの Nutanix 環境と Google Cloud の両方で動作するポータブルなアプリケーションのブループリントをデプロイできるようになるわけです。

それでは、Nutanix と Google Cloud を使用したハイブリッド環境のセットアップ例を見ていきましょう。

作業は次の 4 つのステップから構成されています。

Nutanix Calm のブループリントを使用して、4 ノードの Kubernetes クラスタをオンプレミスにプロビジョニングします。
Google Cloud 用に構成された同じ Nutanix Calm のブループリントを使用して、4 ノードの Kubernetes クラスタを Compute Engine にプロビジョニングします。
オンプレミスと Google Cloud の両方の Kubernetes クラスタを、kubectl を使って管理します。
オンプレミスと Google Cloud の両方の Kubernetes クラスタに、同じ WordPress チャートを Helm を使ってデプロイします。

Nutanix Calm ブループリントを使って、オンプレミス Kubernetes クラスタをプロビジョニング

Nutanix Calm を使えばオンプレミスに Kubernetes クラスタをプロビジョニングでき、Nutanix Prism（仮想データセンター用インフラストラクチャ管理ソリューション）を使えば仮想化されたコンピュートとストレージのクラスタをブートストラップできます。その結果、Nutanix Calm によってオーケストレートされる準備が整った、Nutanix が管理するコンピュートおよびストレージのプールが、人気のある市販 / オープンソースパッケージのワンクリックデプロイに使用できるようになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/iEdEvQ9viAhtuKp_uBhw3Dp0lLE6tX1ClJULo_ZgzE-E.max-700x700.PNG

Nutanix / Google のハイブリッドクラウドスタックのデプロイに使われるツール

次に、Nutanix オンプレミス環境をターゲットとして Kubernetes ブループリントを選択します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/kEBmAVSZxIY3c9hDpsbAWT70ZS8rCy6au7HbPu6xX8.max-1300x1300.PNG

以下に示す Calm Kubernetes ブループリントは、すべてのノードとマスターにすべてのベースソフトウェアを組み込んで 4 ノードの Kubernetes クラスタを構成します。この Kubernetes ブループリントは、Helm を使った WordPress チャートのデプロイを可能にするために、クラスタに Helm Tiller を構成するようにカスタマイズしてあります。また Calm ブループリントでは、下の画面の “create” アクションが示すように、指定した順序で構成のタスクが行われるようにワークフローを作ることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/TVJVuQ8q6w-E_lDqLbJpwQIGYnv8qBWa0pBA1SpBPo.max-1600x1600.PNG

それでは、Kubernetes ブループリントをローンチします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/FX55n6EN2RlkSzcKrL3_wVLwe4SXPwPZRvmcPPk2UO.max-1300x1300.PNG

数分後には、5 台の VM（1 台がマスターノード、4 台がワーカーノード）で構成された Kubernetes クラスタが起動します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1MK_C_cCmYx0fJLUZ1v5e41Nqf--2DQtta0Ba3Zzj5.max-1200x1200.PNG

同じ Nutanix Calm Kubernetes ブループリントを使って、Compute Engine 上の Kubernetes クラスタをプロビジョニング

Nutanix Calm を使用すれば、Google Cloud にも Kubernetes ブループリントをデプロイできます。この場合も数分以内に、5 台の VM（1 台がマスターノード、4 台がワーカーノード）で構成された Compute Engine 上の Kubernetes クラスタが起動します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/sMpBE2252Ms-Wx7S0fY_2D67kgVPmm7lU4PFMuhtoo.max-1100x1100.PNG

https://storage.googleapis.com/gweb-cloudblog-publish/images/LUyAOta8fcmK6hbd1TbWGKFc9G819lG2f1lFE_22LO.max-1200x1200.PNG

以上で、ハイブリッド環境にワークロードをデプロイする準備が整いました。次に、コンテナ化された WordPress スタックをデプロイします。

オンプレミスと Google Cloud の両方の Kubernetes クラスタを kubectl で管理

kubectl は、Kubernetes クラスタへのコマンド実行に使用する、Kubernetes 付属のコマンドラインインターフェースツールです。

ハイブリッド環境の個々の Kubernetes クラスタに対しても、kubectl の基本コマンドを実行できるようになりました。まず、オンプレミス環境に ssh で接続し、いくつかのコマンドを実行します。

読み込んでいます...

オンプレミスと Google Cloud の両方の Kubernetes クラスタに対し、Helm を使って同じ WordPress チャートをデプロイ

ここでは、Kubernetes アプリケーションのインストールと管理に使用されるパッケージマネージャ、Helm を使います。

先ほども説明したように、上述の Calm Kubernetes ブループリントには、クラスタセットアップの一部として Helm が含まれています。オンプレミスの Kubernetes クラスタはストレージプロビジョニングシステムの Nutanix Acropolis で構成され、この Nutanix Acropolis が WordPress ポッドのための Kubernetes 永続ボリュームを自動的に作成します。

それでは、オンプレミスと Google Cloud に WordPress をデプロイしましょう。

読み込んでいます...

# Deploy wordpress
$ helm install wordpress-0.6.4.tgz
NAME:   quaffing-crab
LAST DEPLOYED: Sun Jul  2 03:32:21 2017
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Secret
NAME                     TYPE    DATA  AGE
quaffing-crab-mariadb    Opaque  2     1s
quaffing-crab-wordpress  Opaque  3     1s
==> v1/ConfigMap
NAME                   DATA  AGE
quaffing-crab-mariadb  1     1s
==> v1/PersistentVolumeClaim
NAME                     STATUS   VOLUME  CAPACITY  ACCESSMODES  STORAGECLASS  AGE
quaffing-crab-wordpress  Pending  silver  1s
quaffing-crab-mariadb    Pending  silver  1s
==> v1/Service
NAME                     CLUSTER-IP     EXTERNAL-IP  PORT(S)                     AGE
quaffing-crab-mariadb    10.21.150.254         3306/TCP                    1s
quaffing-crab-wordpress  10.21.150.73       80:32376/TCP,443:30998/TCP  1s
==> v1beta1/Deployment
NAME                     DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
quaffing-crab-wordpress  1        1        1           0          1s
quaffing-crab-mariadb

kubectl コマンドをいくつか実行すると、オンプレミスのデプロイをブラウズできます。

読み込んでいます...

# Take a look at the persistent volume claims 
$ kubectl get pvc
NAME                      STATUS    VOLUME                                                                               CAPACITY   ACCESSMODES   AGE
quaffing-crab-mariadb     Bound     94d90daca29eaafa7439b33cc26187536e2fcdfc20d78deddda6606db506a646-nutanix-k8-volume   8Gi        RWO           1m
quaffing-crab-wordpress   Bound     764e5462d809a82165863af8423a3e0a52b546dd97211dfdec5e24b1e448b63c-nutanix-k8-volume   10Gi       RWO           1m
# Take a look at the running pods
$ kubectl get po
NAME                                      READY     STATUS    RESTARTS   AGE
quaffing-crab-mariadb-3339155510-428wb    1/1       Running   0          3m
quaffing-crab-wordpress-713434103-5j613   1/1       Running   0          3m
# Take a look at the services exposed
$ kubectl get svc
NAME                      CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
kubernetes                10.254.0.1              443/TCP                      16d
quaffing-crab-mariadb     10.21.150.254           3306/TCP                     4m
quaffing-crab-wordpress   10.21.150.73    #.#.#.#     80:32376/TCP,443:30998/TCP   4m

このオンプレミス環境はロードバランサをプロビジョニングしていないので、クラスタ IP を使用して WordPress サイトをブラウズしました。それに対し、Google Cloud における WordPress のデプロイでは、ロードバランサが外部 IP アドレスと共に WordPress サービスに自動的に割り当てられました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/nutanix-kubernetes-64n1o.max-400x400.PNG

まとめ

Nutanix Calm は、Nutanix Enterprise Cloud と Google Cloud の両方に Kubernetes クラスタをプロビジョニングできるワンクリックデプロイモデルを提供しています。
ハイブリッド環境で Kubernetes クラスタが稼働していれば、同じツール（Helm、kubectl）を使って、それぞれの環境を対象とするコンテナ化アプリケーションをデプロイできます。これは、「一度書けばどこでもデプロイ」のモデルを表しています。
Kubernetes は、基盤となるインフラストラクチャを抽象化し、異種のクラウド環境にコンテナ化アプリケーションを統一的にデプロイできるようにします。