Google Cloud Platform

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

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

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

  • 製品、機能のリリースのスピードアップ
  • 顧客の需要に合わせたアプリケーションのスケーリング
  • 自社のペースに合わせたアプリケーションのパブリック クラウドへの移行
  • インフラストラクチャに費やす時間を減らし、コード開発の時間を増やす
  • リソースの活用と効率的なコンピューティングによるコスト削減
大多数の企業はニーズが異なるさまざまなアプリケーションを抱えています。アプリケーションによっては、データ主権とコンプライアンスの関係から、アプリケーションとそのデータをオンプレミス環境か国境線の内側に置かなければならないという管轄権上の制約を受ける場合があります。それに対してモバイルや IoT のアプリケーションは予測不能な消費モデルを特徴としており、最良のデプロイ ターゲットはオンデマンドの pay-as-you-go クラウド モデルになります。

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

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

  1. オンプレミス : Nutanix のインフラストラクチャ
  2. パブリック クラウド : Google Cloud Platform(GCP)
  3. オープンソース : 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 つのステップから構成されています。

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

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

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

iEdEvQ9viAhtuKp_uBhw3Dp0lLE6tX1ClJULo_ZgzE-E4v5hd_ssd4MzOBMpDxZd98CdNC6mzRKNmB7yV9p3_V0XB3Jps-dGmtY-ZoIdK0eYwUubSLwRoymiiza7I7ABc0YuXrsNxdsx.PNG
Nutanix / Google のハイブリッド クラウド スタックのデプロイに使われるツール

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

kEBmAVSZxIY3c9hDpsbAWT70ZS8rCy6au7HbPu6xX8ag-8YFF1MS-q_9HQUMG1P1yh2Bu7nZ49VSJPIYURsMrr0wymz0Ax96LCuvg-NWFGl5lNWACX7oE02aqtBX__xsV6zKuvOEichj.PNG

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

TVJVuQ8q6w-E_lDqLbJpwQIGYnv8qBWa0pBA1SpBPoGvzQ348-G9CpDl2-LoMlXxrtD2KZnYqkdrqxLrEpMF_zPbYNEbsQlMTlGki7OL-4TLU78jeBH9jQHZ_w5WyAbfOmu4zIPec0cd.PNG

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

FX55n6EN2RlkSzcKrL3_wVLwe4SXPwPZRvmcPPk2UOxWEAd8ABMotYCBIOLMxkXFYJO16eFPUujcRvV8AYyiqHZA7AV7IQcl5RDj_IoKiqWGE6_40eMEdKrLJ89Ox51vZktvxd4zc6z5.PNG

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

1MK_C_cCmYx0fJLUZ1v5e41Nqf--2DQtta0Ba3Zzj5wTktq_sTRS-rvMEAslCUEofBNdH8NLKYP65cv4CjmlRgGNea0P8fHctpvTOXX8dbkY8pl9V7K29haWLW-VM5JdI7U6DCo11gft.PNG

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

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

sMpBE2252Ms-Wx7S0fY_2D67kgVPmm7lU4PFMuhtooE6x8XCqaAps0jZBiNmK5a3tuzcN_gY946vn3IhxCjzSjkQYShnbFZg6oVTQ8_Pjrx5lnlzQW1X-m5N93K7TevjcGjN7RH05g4m.PNG
LUyAOta8fcmK6hbd1TbWGKFc9G819lG2f1lFE_22LO6CRCs5Yl4e2W86xWzYKZC_pTvka9LG7xmEuXUlBortXXqzXES9VMTpcWrwRmjUgVJ6soesLzrrxtQT-8XaGBWjput1ioIt57mo.PNG

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

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

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

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

  # List out the nodes in the cluster
$ kubectl get nodes
NAME          STATUS    AGE
10.21.80.54   Ready     16m
10.21.80.59   Ready     16m
10.21.80.65   Ready     16m
10.21.80.67   Ready     16m
# View the cluster config
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    server: http://10.21.80.66:8080
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    user: default-admin
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users: []
# Describe the storageclass configured. This is the Nutanix storage volume plugin for Kubernetes
$ kubectl get storageclass
NAME      KIND
silver    StorageClass.v1.storage.k8s.io
$ kubectl describe storageclass silver
Name:  silver
IsDefaultClass: No
Annotations: storageclass.kubernetes.io/is-default-class=true
Provisioner: kubernetes.io/nutanix-volume

オンプレミスと 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 サービスに自動的に割り当てられました。

nutanix-kubernetes-64n1o.PNG

まとめ

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

次のステップ


ご意見、ご質問はこちらまでお寄せください。

* この投稿は米国時間 7 月 10 日、Kubernetes and Container Engine の Product GTM Lead である Allan Naim によって投稿されたもの(投稿はこちら)の抄訳です。

- By Allan Naim, Product GTM Lead, Kubernetes and Container Engine