目次


ローカル・クラスターとリモート・クラスターを使用して Kubernetes アプリケーションを開発する

ローカルでの Kubernetes 開発チュートリアル

Comments

開発者としては、ローカルでアプリケーション・コードの反復型開発を迅速に進めながらも、リモートの本番環境をできるだけ忠実に反映させたいものです。 このチュートリアルでは、こうした願いをかなえる方法を紹介します。簡単に説明すると、まず、Minikube を使用して単一ノードの Kubernetes クラスターをローカルでセットアップし、そのクラスターにアプリケーションをデプロイします。次に、この同じ手順を IBM Cloud™ 上の IBM Cloud Kubernetes Service (IKS) で行います。 その後、ローカルでは kubeadm-dind-cluster を使用し、リモートでは IKS を利用してマルチノード・クラスターをセットアップします。

目標

このチュートリアルでは、次の作業を行う方法を説明します。

  • Minikube を使用してローカルの単一ノード・クラスターを作成する
  • kubeadm-dind-cluster を使用してローカルのマルチノード・クラスターを作成する
  • IBM Cloud Kubernetes Service (IKS) を利用してリモートの単一ノード・クラスターとマルチノード・クラスターを作成する
  • ローカル・クラスターとリモート・クラスターの両方でイメージを利用できるようにする
  • ローカル・クラスター内とリモート・クラスター内のそれぞれで実行中のアプリケーションにアクセスする
  • アプリケーションに変更を加えて再デプロイする

前提条件

手順を開始する前にインストールしておかなければならない CLI がいくつかあります。これらの CLI は、Kubernetes クラスターを作成して管理する際や、コンテナー化されたアプリをクラスターにデプロイする際に必要になるものです。 必要なすべてのツールを入手するには、IBM が提供しているインストーラーをこのリンク先からダウンロードしてください。このリンク先のページでは、必要に応じてツールを手作業で入手する場合の手順も確認できます。

このチュートリアルでは次のツールを使用します。

  • git
    • git はバージョン管理システムです。このチュートリアルでは git を使用してサンプル・アプリケーションのソースを取得します。
  • Docker
    • Docker は、開発者がアプリケーションを軽量の移植可能なコンテナーとして構築して実行するために使用するツールです。
  • kubectl CLI
    • kubectl は、Kubernetes クラスターに対してコマンドを実行するためのコマンド・ライン・インターフェースです。
  • ibmcloud CLI
    • ibmcloud は、IBM Cloud 内のリソースを管理するためのコマンド・ライン・インターフェースです。

手順

1. サンプル・アプリケーションをダウンロードする

このチュートリアルで使用するサンプル・アプリケーションは、ユーザーがメッセージを投稿するために使用できる単純なゲストブック Web サイトです。ローカルで作成できるよう、このサンプル・アプリケーションのリポジトリーを複製します。

console
$ git clone https://github.com/IBM/guestbook

このチュートリアルでは、サポート・データベースを使用せずにアプリケーションを実行します (つまり、データはメモリー内に保管されます)。

2. Minikube を使用してローカルの単一ノード・クラスターをセットアップする

Minikube を使用すると、ローカルで簡単に Kubernetes を実行できるようになります。Minikube はワークステーション上の VM 内で単一ノードの Kubernetes クラスターを実行します。

Minikube をインストールする

このリンク先の手順に従って、Minikube をワークステーション上にインストールしてください。

クラスターを作成する

minikube start コマンドを使用してクラスターを実行します。このコマンドにより、ワークステーション上に仮想マシンが作成されて、そこに Kubernetes がインストールされます。注意する点として、VirtualBox 以外のハイパーバイザーを使用している場合、このコマンドには、該当する VM ドライバーを識別する引数 --vm-driver も渡す必要があります。

console
$ minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Downloading Minikube ISO
 160.27 MB / 160.27 MB  100.00% 0ss
Getting VM IP address...
Moving files into cluster...
Downloading kubelet v1.10.0
Downloading kubeadm v1.10.0
Finished Downloading kubelet v1.10.0
Finished Downloading kubeadm v1.10.0
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.

Minikube により、このクラスターを処理するように kubectl CLI が構成されます。これを確認するために、次の kubectl コマンドを入力します。

console
$ kubectl get nodes
NAME       STATUS    ROLES     AGE       VERSION
minikube   Ready     master     1m       v1.10.0

他にも Kubernetes クラスターを操作していて、別のクラスターを使用するように kubectl CLI のコンテキストを変更した場合、コマンド kubectl config use-context minikube を使用すると minikube のコンテキストを復元できます。

アプリケーションをローカル・クラスターにデプロイする

Kubernetes デプロイメントはコンテナー・レジストリーからイメージをプルするように設計されています。ただし、ローカルで開発を行っているときは、 イメージをレジストリーにプッシュするのは無用のステップです。このステップを省略すべく、Docker CLI が Minikube 内部で実行されている Docker デーモンを指すように環境変数を設定します。

console
$ eval $(minikube docker-env)

上記のコマンドを実行した後、docker ps コマンドを入力すると、すべてのコンテナーが minikube 内部で実行されていることを確認できます。

注:eval コマンドが作用するのは、現在のコマンド・ウィンドウだけに限られます。したがって、ウィンドウを閉じた場合は、次にウィンドウを開いたときに上記の コマンドを再度実行する必要があります。

次は、Guestbook アプリケーションをビルドします。

console
$ cd guestbook/v1/guestbook
$ docker build -t guestbook:v1 .
Sending build context to Docker daemon   16.9kB
Step 1/13 : FROM golang as builder
latest: Pulling from library/golang
05d1a5232b46: Pull complete
5cee356eda6b: Pull complete
89d3385f0fd3: Pull complete
80ae6b477848: Pull complete
94ebfeaaddf3: Pull complete
dd697213ec59: Pull complete
715d1281dfe7: Pull complete
Digest: sha256:e8e4c4406217b415c506815d38e3f8ac6e05d0121b19f686c5af7eaadf96f081
Status: Downloaded newer image for golang:latest
 ---> fb7a47d8605b
Step 2/13 : RUN go get github.com/codegangsta/negroni
 ---> Running in 6867267a6832
Removing intermediate container 6867267a6832
 ---> 41cdd0ea4dee
Step 3/13 : RUN go get github.com/gorilla/mux github.com/xyproto/simpleredis
 ---> Running in 6f928ff5ec97
Removing intermediate container 6f928ff5ec97
 ---> 2c51f4a80903
Step 4/13 : COPY main.go .
 ---> 919077d83e2b
Step 5/13 : RUN go build main.go
 ---> Running in 5959c30f5c10
Removing intermediate container 5959c30f5c10
 ---> cbe90ddb11ed
Step 6/13 : FROM busybox:ubuntu-14.04
ubuntu-14.04: Pulling from library/busybox
a3ed95caeb02: Pull complete
300273678d06: Pull complete
Digest: sha256:7d3ce4e482101f0c484602dd6687c826bb8bef6295739088c58e84245845912e
Status: Downloaded newer image for busybox:ubuntu-14.04
 ---> d16744963217
Step 7/13 : COPY --from=builder /go//main /app/guestbook
 ---> 67c829eb8d1b
Step 8/13 : ADD public/index.html /app/public/index.html
 ---> e71b4653ca17
Step 9/13 : ADD public/script.js /app/public/script.js
 ---> 1e3e52db271f
Step 10/13 : ADD public/style.css /app/public/style.css
 ---> b5b7fcfa50ca
Step 11/13 : WORKDIR /app
Removing intermediate container b982fa510f1c
 ---> 15947fedd20a
Step 12/13 : CMD ["./guestbook"]
 ---> Running in 156afadc0459
Removing intermediate container 156afadc0459
 ---> 0205392b8cbf
Step 13/13 : EXPOSE 3000
 ---> Running in 448df38be767
Removing intermediate container 448df38be767
 ---> 9708eb5366ec
Successfully built 9708eb5366ec
Successfully tagged guestbook:v1

上記のコマンドで、イメージに v1 というタグを付けていることに注目してください。 これは、latest タグを使用すると Kubernetes がパブリック・レジストリーからイメージをプルしようとするためです。 ローカルで開発するときは、Kubernetes にローカルに保管されているイメージを使用させる必要があります。

Guestbook イメージが Minikube クラスターに取り込まれたら、Guestbook アプリケーションの実行を開始できます。

console
$ kubectl run guestbook --image=guestbook:v1
deployment.apps/guestbook created

kubectl を使用して、Kubernetes によってコンテナーを収容するポッドが作成されたこと、そしてそのポッドが実行中であることを確認できます。

console
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
guestbook-6cd549c68f-d6qvw   1/1       Running   0          1m

実行中のアプリケーションにアクセスする

Guestbook アプリケーションはポッド内のポート 3000 上で listen します。このアプリケーションに外部からアクセスできるようにするには、 アプリケーション用にタイプを NodePort に設定した Kubernetes サービスを作成する必要があります。作成されたサービスに、Kubernetes は 30000-32767 の範囲内にある任意のポートを割り当て、 ノードがプロキシーとしてそのポートをポッドのターゲット・ポートに中継します。

console
$ kubectl expose deployment guestbook --type=NodePort --port=3000
service/guestbook exposed

サービスにアクセスするためには、Minikube の仮想マシンの IP アドレスとノード・ポート番号が必要です。 Minikube には、この情報を取得するための便利な手段が用意されています。

console
$ minikube service guestbook --url
http://192.168.99.104:30571

当然、ご使用のワークステーション上の IP アドレスとポート番号は上記とは異なるはずです。 取得した URL をコピーしてブラウザー内に貼り付けると、Guestbook アプリケーションが表示されます。 --url オプションは省略することもできます。その場合、Minikube はデフォルトのブラウザーを開いて指定されたサービスの URL に自動的にアクセスします。

アプリケーションに変更を加える

アプリケーションに単純な変更を加えてから、アプリケーションを再デプロイしましょう。 vi または任意のエディターでファイル public/script.js を開きます。 handleSubmission 関数を次のように変更して、入力値の末尾に日付を付加するステートメントを追加します。

javascript
  var handleSubmission = function(e) {
    e.preventDefault();
    var entryValue = entryContentElement.val()
    if (entryValue.length > 0) {
      entryValue += " " + new Date();     // ADD THIS LINE
      entriesElement.append("<p>...</p>");
      $.getJSON("rpush/guestbook/" + entryValue, appendGuestbookEntries);
    entryContentElement.val("")
    }
    return false;
  }

Docker イメージを再ビルドして新しいタグを割り当てます。

console
$ docker build -t guestbook:v1.1 .

イメージのビルドが完了したら、新しいイメージを使用するよう Kubernetes に指示する必要があります。

console
$ kubectl set image deployment/guestbook guestbook=guestbook:v1.1
deployment.extensions/guestbook image updated

ブラウザー内の Guestbook アプリケーションを更新してください (更新後の javascript ファイルを適用するには、ページの再ロードが必要な場合もあります)。 フォームに何らかの値を入力して、「Submit (送信)」ボタンをクリックします。 ページ上に表示されるテキストで、入力した値の後に現在時刻が続いていることを確認できるはずです。

3. IBM Cloud Kubernetes Service を使用してリモートの単一ノード・クラスターをセットアップする

次は、IBM Cloud_上での継続的アプリケーション開発に目を向けましょう。 まだ IBM Cloud アカウントの登録が済んでいない場合は、このリンク先のページでアカウントを登録してください。 このセクションで説明する手順は、無料のライト・アカウントを使用して行うことができます (この場合、作成するクラスターは 1 か月後に有効期限が切れます)。

IBM Cloud CLI にログインします。資格情報の入力を求められたら IBM Cloud の資格情報を入力します。

console
ibmcloud login

注: フェデレーテッド ID を使用している場合は、IBM Cloud CLI にログインする際に ibmcloud login --sso を使用してください。

クラスターを作成する

Kubernetes クラスターを作成しましょう。

console
$ ibmcloud ks cluster-create --name mycluster
The 'machine-type' flag was not specified.So a free cluster will be created.
Creating cluster...
OK

クラスターの作成処理はバックグラウンドで続行されます。ステータスを確認するには、次のコマンドを使用します。

console
$ ibmcloud ks clusters
OK
Name        ID                                 State     Created         Workers   Location   Version
mycluster   ae7148d3c8e74d69b3ed94b6c5f02262   normal    4 minutes ago   1         hou02      1.10.7_1520

クラスターの状態が pending として示された場合は、しばらく待ってから上記のコマンドを再試行してください。 クラスターのプロビジョニングが完了したら (状態が normal に変わります)、プロビジョニングされたクラスターとやり取りするように Kubernetes クライアント CLI kubectl を構成する必要があります。 それには、ibmcloud ks cluster-config mycluster を実行します。このコマンドにより、ワークステーション上に構成ファイルが作成されます。

console
$ ibmcloud ks cluster-config mycluster
OK
The configuration for mycluster was downloaded successfully.Export environment
variables to start using Kubernetes.

export KUBECONFIG=/home/gregd/.bluemix/plugins/container-service/clusters/mycluster/kube-config-hou02-mycluster.yml

export ステートメントをコピーして実行します。このステートメントにより、KUBECONFIG 環境変数が kubectl 構成ファイルを指すように設定されます。 これで、kubectl クライアントと新しく作成した Kubernetes クラスターが連動するようになります。次の kubectl コマンドを入力して確認してください。

console
$ kubectl get nodes
NAME            STATUS    ROLES     AGE       VERSION
10.76.202.250   Ready     <none>    4m        v1.10.7+IKS

アプリケーションをリモート・クラスターにデプロイする

Kubernetes がクラスター内で実行するイメージをプルできるよう、Kubernetes からアクセス可能なレジストリーにイメージを保管する必要があります。 独自のプライベート・レジストリーに Docker イメージをプッシュするには、IBM Cloud Kubernetes Service (IKS) を利用できます。

まず、名前空間を追加して、独自のイメージ・レジストリーを作成します (名前空間とは、プライベート・イメージ・レジトリーを一意に識別する名前のことです)。

以下のコマンドの <my_namespace> の部分を、実際に追加する名前空間で置き換えてください。

console
$ ibmcloud cr namespace-add <my_namespace>

作成されるレジストリーには、registry.<region>.bluemix.net/<your_namespace> 形式の名前が設定されます。 <region> は、ご使用の IBM Cloud アカウントが作成されている領域に応じて異なります。 該当する領域を確認するには、ibmcloud cr region コマンドを実行します。

$ ibmcloud cr region
You are targeting region 'us-south', the registry is 'registry.ng.bluemix.net'.

OK

このレジストリーにイメージをプッシュするには、その前に、ibmcloud cr login コマンドを実行して ローカル Docker デーモンを IBM Cloud Container Registry にログインさせる必要があります。

ibmcloud cr login

 

これで、現行のローカル・イメージ (Minikube のデプロイ時にビルドしたイメージ) にタグを付けてプライベート・レジストリーを関連付ければ、このイメージをプライベート・レジストリーにプッシュできます。必ず、<region><my_namespace> を該当する値で置き換えてください。

console
$ docker tag guestbook:v1.1 registry.<region>.bluemix.net/<my_namespace>/guestbook:v1.1
$ docker push registry.<region>.bluemix.net/<my_namespace>/guestbook:v1.1

アプリケーションを実行するには、前と同じ kubectl run コマンドを使用しますが、今回はプライベート・リポジトリー内のイメージを参照します。

console
$ kubectl run guestbook --image=registry.<region>.bluemix.net/<my_namespace>/guestbook:v1.1
deployment.apps/guestbook created

kubectl を使用して、Kubernetes によってコンテナーを収容するポッドが作成されたこと、そしてそのポッドが実行中であることを確認できます。

console
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
guestbook-5986549d9-2f49g    1/1       Running   0          1m

実行中のアプリケーションにアクセスする

Guestbook アプリケーションはポッド内のポート 3000 上で listen します。このアプリケーションに外部からアクセスできるようにするには、 アプリケーション用にタイプを NodePort に設定した Kubernetes サービスを作成する必要があります。作成されたサービスに、Kubernetes は 30000-32767 の範囲内にある任意のポートを割り当て、 ノードがプロキシーとしてそのポートをポッドのターゲット・ポートに中継します。

console
$ kubectl expose deployment guestbook --type=NodePort --port=3000
service/guestbook exposed

サービスにアクセスする際は、アプリケーションが実行されているノードのパブリック IP アドレスと、 Kubernetes によってサービスに割り当てられたノード・ポート番号が必要です。

該当する IP アドレスを取得するには、次のコマンドを実行します。

console
$ ibmcloud ks workers mycluster
OK
ID                                                 Public IP       Private IP    Machine Type   State    Status   Zone    Version
kube-hou02-paae7148d3c8e74d69b3ed94b6c5f02262-w1   173.193.75.82   10.76.202.250 free           normal   Ready    hou02   1.10.7_1520

この例でのパブリック IP は 173.193.75.82 です。

次は、以下のコマンドを実行してノードのポート番号を取得します。

console
$ kubectl describe services/guestbook
Name:                     guestbook
Namespace:                default
Labels:                   run=guestbook
Annotations:              <none>
Selector:                 run=guestbook
Type:                     NodePort
IP:                       172.21.192.189
Port:                     <unset>  3000/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  32146/TCP
Endpoints:                172.30.151.71:3000
Session Affinity:         None
External Traffic Policy: Cluster
Events:                   <none>

この例での NodePort は 32146 です。

以上の結果から、URL http://173.193.75.82:32146/ を使用して、ブラウザーからアプリケーションにアクセスできることがわかります。

4. kubeadm-dind-cluster を使用してローカルのマルチノード・クラスターをセットアップする

高度なアプリケーション開発になってくると、マルチノード・クラスターが必要になります。 ここではマルチノードの Kubernetes クラスターを作成するために、kubernetes-sigs/kubeadm-dind-cluster というプロジェクトを使用します。 このプロジェクトは「Docker 内の Docker」を使用して、単一マシンの環境内で複数の Kubernetes ノードをシミュレーションします。

kubeadm-dind-cluster をインストールする

kubeadm-dind-cluster は Linux® 内で実行するように作成されています。Windows または Mac のワークステーションを使用している場合、Linux を稼働する仮想マシンをセットアップする必要があります。その場合に推奨される手法は、VirtualBox を使用して Ubuntu ゲスト仮想マシンを実行することです。

ゲスト仮想マシンにも Docker をインストールする必要があります。

kubeadm-dind-cluster に用意されている構成済みのスクリプトを使用すれば、さまざまなバージョン・レベルで Kubernetes クラスターをセットアップできます。 チュートリアルでは dind-cluster-v1.10.sh スクリプトを使用します。このスクリプトは、次の方法で取得できます。

console
wget https://cdn.rawgit.com/kubernetes-sigs/kubeadm-dind-cluster/master/fixed/dind-cluster-v1.10.sh

クラスターを作成する

up オプションを指定した dind-cluster-v1.10.sh スクリプトを実行してクラスターを起動します。

console
./dind-cluster-v1.10.sh up

このスクリプトがデフォルトで作成するのは、1 つの Kubernetes マスター・ノードと 2 つのワーカー・ノードです。 それぞれのノードは個別の Docker コンテナー内で稼働します。

このスクリプトはクラスターを起動した後、そのクラスターを処理するように kubectl CLI を構成します。まずは、kubectl CLI を PATH 環境変数に追加する必要があります。 その上で kubectl get nodes コマンドを入力すると、クラスターの各ノードを確認できます。

console
$ export PATH="$HOME/.kubeadm-dind-cluster:$PATH"
$ kubectl get nodes
NAME          STATUS    ROLES     AGE       VERSION
kube-master   Ready     master    5m        v1.10.5
kube-node-1   Ready     <none>    3m        v1.10.5
kube-node-2   Ready     <none>    4m        v1.10.5

アプリケーションをクラスターにデプロイする

Kubernetes クラスターは、その内部で実行するイメージを何らかの場所からプルできなければなりません。 Minikube では、Docker CLI が Minikube の Docker デーモンを指すようにすることで、レジストリーを使用しなくても済むようにできましたが、Docker コンテナー内で複数の Docker デーモンがネストされて実行されている場合、これらのデーモンの間でイメージを同期するのは難しく、エラーの原因になりがちです。それよりも、Kubernetes モデルの内部で処理し、レジストリーを使用するほうが賢明です。

前の手順で、IBM Cloud Kubernetes Service を利用してプライベート・レジストリーを作成しました。このレジストリーを使用するようにクラスターをセットアップする方法を見ていきましょう。 ibmcloud CLI を使用して独自のイメージ・リポジトリーを作成する方法はすでに説明しましたが、 今度は同じく ibmcloud CLI を使用して、IBM Cloud Container Registry の名前空間に対するアクセス権を付与するためのトークンを作成する必要があります。

console
$ ibmcloud cr token-add --description "token for kubeadm dind cluster access" --non-expiring --readwrite
Requesting a registry token...

Token identifier   58669dd6-3ddd-5c78-99f9-ad0a5aabd9ad
Token              <token_value>

上記のコマンドにより、すべての名前空間に対する読み取り/書き込みアクセス権を持つ、無期限のトークンが作成されます。<token_value> の部分に、実際のトークンが示されます。このトークンを所有している限り、どのユーザーでも名前空間に対してイメージのプッシュ、プルを行うことができます。

次に、トークン値を格納する Kubernetes シークレットを作成します。シークレットは、機密情報を格納するよう意図されています。このコマンドには次の値を代入する必要があります。

  • <region>
    • 該当する値を確認するには、ibmcloud cr region コマンドを実行します。
    $ ibmcloud cr region
    You are targeting region 'us-south', the registry is 'registry.ng.bluemix.net'.
    OK

    In this case you would substitute ng into the registry address.

  • <token_value>
    • This is the <token_value> that was output when you created the registry token above.
  • <email>
    • You can provide any email address.This argument is required by this kubectl command but is not used for anything.
console
$ kubectl --namespace default create secret docker-registry registrysecret --docker-server=registry.<region>.bluemix.net --docker-username=token --docker-password=<token_value> --docker-email=<email>
secret "registrysecret" created

最後に、Kubernetes がイメージをプルするときに、このシークレットを使用させる必要があります。それには最も簡単な方法として、このシークレットをデフォルトの Kubernetes サービス・アカウントに追加します。サービス・アカウントは、ポッド内で実行されるプロセスの ID を表すものです。ポッドにサービス・アカウントが割り当てられていなければ、ポッドはデフォルトのサービス・アカウントを使用します。

kubectl patch -n default serviceaccount/default -p '{"imagePullSecrets":[{"name": "registrysecret"}]}'

上記のコマンドにより、Kubernetes はイメージをプルするために、作成済みの registrysecret を使用してプライベート・レジストリーに対する認証を行うはずです。早速、試してみましょう。

console
$ kubectl run guestbook --image=registry.<region>.bluemix.net/<my_namespace>/guestbook:v1.1
deployment.apps/guestbook created

kubectl を使用して、コンテナーを収容するポッドが Kubernetes によって作成されたこと、そしてそのポッドが実行中であることを確認します。

console
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
guestbook-5986549d9-h5n74    1/1       Running   0          1m

実行中のアプリケーションにアクセスする

Guestbook アプリケーションはポッド内のポート 3000 上で listen します。外部からアクセス可能なアプリケーションにするには、このアプリケーション用に、タイプを NodePort に設定した Kubernetes サービスを作成する必要があります。作成されたサービスに、Kubernetes は 30000-32767 の範囲内にある任意のポートを割り当て、ノードがプロキシーとしてそのポートをポッドのターゲット・ポートに中継します。

console
$ kubectl expose deployment guestbook --type=NodePort --port=3000
service/guestbook exposed

サービスにアクセスするには、いずれかのワーカー・ノードの IP アドレスと、Kubernetes によってサービスに割り当てられたノード・ポート番号が必要です。

該当する IP アドレスを取得するには、次のコマンドを実行します。

console
$ docker exec -it kube-node-1 ip addr show eth0
15: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.3/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever

このコマンドにより、kube-node-1 コンテナー内の eth0 インターフェースが表示されます。 コンテナーの IP アドレスは inet に続く部分です。この例の場合、172.18.0.3 となっています。

次は、以下のコマンドを実行してノードのポート番号を取得します。

console
$ kubectl describe services/guestbook
Name:                     guestbook
Namespace:                default
Labels:                   run=guestbook
Annotations:              <none>
Selector:                 run=guestbook
Type:                     NodePort
IP:                       10.100.222.15
Port:                     <unset>  3000/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  32345/TCP
Endpoints:                10.244.2.3:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

この例での NodePort は 32345 です。

したがって、Linux ホスト上でブラウザーを実行してアプリケーションにアクセスするには、URL として http://172.18.0.3:32345/ を使用します。ここでは kube-node-1 の IP アドレスを使用しますが、どちらのノード上でアプリケーションを実行するのでも、 この URL は有効です。いずれのノードもプロキシーとして NodePort をサービスに中継します。

ポッドの数を増やしてスケーリングする

クラスターを使用する理由は当然のことながら、アプリケーションのコピーを複数のノードに配置することで、容量を増やし、可用性を向上させることにあります。Kubernetes では、こうしたコピーを「レプリカ」と呼んでいます。一例として、Kubernetes にアプリケーションの 2 つのレプリカを要求しましょう。

console
$ kubectl scale --replicas=2 deployment guestbook
deployment.extensions "guestbook" scaled

バックグラウンドで動作する Kubernetes が、ポッドの合計数を 2 つにするように追加のポッドを起動します。 これは、kubectl get deployments コマンドを実行すると確認できます。

console
$ kubectl get deployments
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
guestbook   2         2         2            2           10m

次のコマンドを使用して、各ポッドのステータスと、それぞれのポッドが実行されているノードを確認することもできます。

console
$ kubectl get pods -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP           NODE
guestbook-5986549d9-8dnhb   1/1       Running   0          7s        10.244.3.5   kube-node-2
guestbook-5986549d9-qtnmg   1/1       Running   0          7s        10.244.2.5   kube-node-1

 

両方のポッドが実行中になったら、試しに、ブラウザー内でアプリケーションを開いてメッセージをいくつか入力し、ブラウザーを閉じるという操作を何回か繰り返してください。Guestbook に表示されるメッセージが毎回変わっていくはずです。これはつまり、ブラウザーがどちらのノードに接続するかに関わらず、入力したメッセージがメモリー内に保持されることを意味します (接続先ノードを変えるには、ブラウザーをいったん閉じて、もう一度開く必要があります。こうしなければ、ブラウザーが同じノードに接続されたままになります)。

当然のことですが、本物のゲストブック・アプリケーションではメッセージをサポート・ストア内に保持することになります。IBM Cloud Kubernetes Service ラボでは、このサンプル Guestbook アプリケーションと Redis を例に、アプリケーションにデータベースを追加する方法を説明しています。

5. IBM Cloud Kubernetes Service を使用してリモートのマルチノード・クラスターをセットアップする

続いて、IBM Cloud 内のマルチノード・クラスター上で継続的アプリケーション開発を行う方法を説明します。

マルチノード・クラスター (標準クラスターと呼ばれます) を作成するには、従量課金アカウントまたはサブスクリプション・アカウントのいずれかが必要です。 アカウントのタイプについて詳しくは、https://cloud.ibm.com/docs/account/index.html#accounts を参照してください。

IBM Cloud CLI にログインします。資格情報の入力を求められたら IBM Cloud の資格情報を入力します。

console
ibmcloud login

注: フェデレーテッド ID を使用している場合は、IBM Cloud CLI にログインする際に ibmcloud login --sso を使用してください。

クラスターを作成する

標準クラスターを作成する際は、IBM Cloud ダッシュボードを使用することをお勧めします。このダッシュボードでは案内に従って構成作業を進めることができるだけでなく、見積りコストも確認できます。

  • 右上隅にある「Login (ログイン)」ボタンをクリックし、必要な情報を入力してアカウントにログインします。
  • ウィンドウの左側にある「Containers (コンテナー)」タブをクリックし、「Kubernetes Service」タイルを選択します。
  • Create (作成)」ボタンをクリックします。
  • 表示されるフォームに値を入力します。まず、クラスターのロケーションを選択します。選択したロケーションによって、使用できる他の選択肢が決まります。次に、選択したロケーション内で使用できるゾーンとマシン・タイプを選択します。ワーカー・ノードの数を 2 に設定し、クラスターに名前を付けます。このチュートリアルでは「myStandardCluster」という名前を使用します。
  • ウィンドウの右側に表示される見積りコストを確認します。
  • Create Cluster (クラスターを作成)」ボタンをクリックします。

クラスターの作成処理はバックグラウンドで続行されます。ステータスを確認するには、次のコマンドを使用します。

console
$ ibmcloud ks clusters
OK
Name                ID                                 State     Created          Workers   Location    Version
myStandardCluster   fc5514ef25ac44da9924ff2309020bb3   normal    12 minutes ago   2         Dallas     1.10.7_1520

クラスターの状態が pending として示された場合は、しばらく待ってから上記のコマンドを再試行してください。 クラスターのプロビジョニングが完了したら (状態が normal に変わります)、プロビジョニングされたクラスターとやり取りするように Kubernetes クライアント CLI kubectl を構成する必要があります。 それには、ibmcloud ks cluster-config myStandardCluster を実行します。このコマンドにより、ワークステーション上に構成ファイルが作成されます。

console
$ ibmcloud ks cluster-config myStandardCluster
OK
The configuration for mycluster was downloaded successfully.Export environment
variables to start using Kubernetes.

export KUBECONFIG=/home/gregd/.bluemix/plugins/container-service/clusters/myStandardCluster/kube-config-hou02-myStandardCluster.yml

export ステートメントをコピーして実行します。このステートメントにより、KUBECONFIG 環境変数が kubectl 構成ファイルを指すように設定されます。 これで、kubectl クライアントと新しく作成した Kubernetes クラスターが連動するようになります。

次の kubectl コマンドを入力して確認してください。

$ kubectl get nodes
NAME            STATUS    ROLES     AGE       VERSION
10.177.184.185   Ready     <none>    2m        v1.10.7+IKS
10.177.184.220   Ready     <none>    2m        v1.10.7+IKS

アプリケーションをリモート・クラスターにデプロイする

レジストリーをトライアルまたはライト・プランで作成した場合、レジストリーには引き続きそのプランのクォータが適用されます。 レジストリーのクォータおよびレジストリーに適用されるサービス・プランのアップグレード方法について詳しくは、https://cloud.ibm.com/docs/services/Registry/registry_overview.html を参照してください。

前の手順でプライベート・レジストリーにプッシュした Guestbook アプリケーションを引き続き使用しましょう。 新しく作成されるクラスターには、このレジストリーへのアクセス権が自動的に割り当てられます。

console
$ kubectl run guestbook --image=registry.<region>.bluemix.net/<my_namespace>/guestbook:v1.1
deployment.apps/guestbook created

kubectl を使用して、Kubernetes によってコンテナーを収容するポッドが作成されたこと、そしてそのポッドが実行中であることを確認できます。

console
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
guestbook-7b9f8cf696-fg8v8   1/1       Running   0          1m

実行中のアプリケーションにアクセスする

Guestbook アプリケーションはポッド内のポート 3000 上で listen します。このアプリケーションに外部からアクセスできるようにするには、 アプリケーション用にタイプを NodePort に設定した Kubernetes サービスを作成する必要があります。作成されたサービスに、Kubernetes は 30000-32767 の範囲内にある任意のポートを割り当て、 ノードがプロキシーとしてそのポートをポッドのターゲット・ポートに中継します。

console
$ kubectl expose deployment guestbook --type=NodePort --port=3000
service/guestbook exposed

(標準クラスターでは LoadBalancer サービスや Ingress リソースを利用することもできますが、これらの概念はこのチュートリアルの対象範囲ではありません)。

サービスにアクセスするには、いずれかのワーカー・ノードの IP アドレスと、Kubernetes によってサービスに割り当てられたノード・ポート番号が必要です。

該当する IP アドレスを取得するには、次のコマンドを実行します。

console
$ ibmcloud ks workers myStandardCluster
OK
ID                                                 Public IP        Private IP       Machine Type        State    Status   Zone    Version
kube-dal10-crfc5514ef25ac44da9924ff2309020bb3-w1   169.47.252.42    10.177.184.220   u2c.2x4.encrypted   normal   Ready    dal10   1.10.7_1520
kube-dal10-crfc5514ef25ac44da9924ff2309020bb3-w2   169.48.165.242   10.177.184.185   u2c.2x4.encrypted   normal   Ready    dal10   1.10.7_1520

どちらのノードのパブリック IP アドレスを使うのでも構いません。いずれのノードもプロキシーとして NodePort をサービスに中継します。

次は、以下のコマンドを実行してノードのポート番号を取得します。

console
$ kubectl describe services/guestbook
Name:                     guestbook
Namespace:                default
Labels:                   run=guestbook
Annotations:              <none>
Selector:                 run=guestbook
Type:                     NodePort
IP:                       172.21.210.103
Port:                     <unset>  3000/TCP
TargetPort:               3000/TCP
NodePort:                 <unset>  31096/TCP
Endpoints:                172.30.108.133:3000
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

この例での NodePort は 31096 です。したがって、URL として http://169.47.252.42:31096/ または http://169.48.165.242:31096 のどちらかを使用すれば、ブラウザーからアプリケーションにアクセスできます。

ポッドの数を増やしてスケーリングする

ローカルのマルチノード・クラスターで行ったように、Kubernetes に対し、必要なレプリカの数を 2 つとして指定します。

console
$ kubectl scale --replicas=2 deployment guestbook
deployment.extensions "guestbook" scaled

バックグラウンドで動作する Kubernetes が、ポッドの合計数が 2 になるように追加のポッドを起動します。 これは、kubectl get deployments コマンドを実行すると確認できます。

console
$ kubectl get deployments
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
guestbook   2         2         2            2           10m

次のコマンドを使用して、各ポッドのステータスと、それぞれのポッドが実行されているノードを確認することもできます。

$ kubectl get pods -o wide
NAME                         READY     STATUS    RESTARTS   AGE       IP               NODE
guestbook-7b9f8cf696-dzgcb   1/1       Running   0          14s       172.30.58.204    10.177.184.185
guestbook-7b9f8cf696-hvrc7   1/1       Running   0          14s       172.30.108.136   10.177.184.220

前に行った演習を繰り返すことで、各ノード内で実行されているポッドに接続できます。

クリーンアップ

チュートリアルを完了した後、このチュートリアルで作成したリソースをもう使わないのであれば、リソースを削除できます。 クラスター内に作成した Kubernetes リソースをクリーンアップする方法は次のとおりです。

  • クリーンアップするクラスターに合わせて kubectl CLI のコンテキストを設定します。

    例えば Minikube の場合は、kubectl config use-context minikube と設定します。

    IBM Cloud Kubernetes Service の場合は、ibmcloud ks cluster-config mycluster または ibmcloud ks cluster-config myStandardCluster と設定して、KUBECONFIG 環境変数の設定をコピーして貼り付けます。

  • 以下のコマンドを入力して、デプロイメントとそのサービスを削除します。
$ kubectl delete deployment guestbook
$ kubectl delete service guestbook

Minikube クラスターを削除するには、以下のコマンドを入力します。

console
$ minikube stop
$ minikube delete

kubeadm-dind-cluster クラスターを削除するには、以下のコマンドを入力します。

console
./dind-cluster-v1.10.sh down
./dind-cluster-v1.10.sh clean

IBM Cloud Kubernetes Service クラスターを削除するには、以下のコマンドを入力します。

ibmcloud ks cluster-rm myCluster
ibmcloud ks cluster-rm myStandardCluster

お疲れさまでした!Minikube を使用して、アプリケーションのソース・コードをローカルで継続的に開発するための手順をマスターし、その手順をクラウド内で再現しました。次のステップとしては、Service Catalog ラボに取り組むことをお勧めします。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1066267
ArticleTitle=ローカル・クラスターとリモート・クラスターを使用して Kubernetes アプリケーションを開発する
publish-date=07122019