東京DCで IBM Cloud Kubernetes サービス開始、早速、使ってみた！


IBM Cloud (旧SoftLayer) 東京データセンターで、Kubernetesのサービスが開始されたので、検証も兼ねてレポートします。


## 東京データセンターでのKubernetesクラスタの起動

https://console.bluemix.net/ からログインします。 東京データセンターにk8sのクラスタ環境を作るには、クレジットカードを登録したアカウントが必要になります。 無料のライトプランの場合は、クラスタを起動する場所を選択できず、ドイツにインスタンスが起動します。

![スクリーンショット 2017-12-05 17.32.09.png](https://qiita-image-store.s3.amazonaws.com/0/42829/7feb7927-2d66-a466-b09f-803558ea0f6e.png "スクリーンショット 2017-12-05 17.32.09.png")

矢印の番号順にクリックして、メニューを進んでいきます。
1.カタログをクリック
2.コンテナをクリック
3.Kubernetes Clusterをクリック

![スクリーンショット 2017-12-05 17.32.15.png](https://qiita-image-store.s3.amazonaws.com/0/42829/d810e5df-f3e0-529e-5d98-450aa81079e4.png "スクリーンショット 2017-12-05 17.32.15.png")

4.作成をクリック

![スクリーンショット 2017-12-05 17.32.23.png](https://qiita-image-store.s3.amazonaws.com/0/42829/f22467bf-ee40-338e-1b95-36f324e519f5.png "スクリーンショット 2017-12-05 17.32.23.png")

5.従量制プランをクリック
6.自分のクラスタの名前を設定
7.場所で TOK02(東京データセンター)を選択  必要に応じてバージョンも選択
8.マシンタイプを選択します。


![スクリーンショット 2017-12-05 17.32.32.png](https://qiita-image-store.s3.amazonaws.com/0/42829/6ec8304e-a4df-fbf9-4407-87bc7c16abf1.png "スクリーンショット 2017-12-05 17.32.32.png")

8.マシンタイプの中から、自分の利用用途に適したものをクリックします。
9.ノード数 (IBMの呼称ではワーカーノード）を設定　（デフォルトは３なのでそのまま利用しました。）
10.その他はデフォルトを利用して、クラスタの作成ボタンをクリック、これでクラスタの作成が自動的に進行していきます。

![スクリーンショット 2017-12-05 17.32.45.png](https://qiita-image-store.s3.amazonaws.com/0/42829/7226dd4d-aadd-e610-7621-5bb0f26545e3.png "スクリーンショット 2017-12-05 17.32.45.png")

11.作成中のワーカーノードのリストを参照するには、左橋のメニューを展開して、コンテナの行をクリックします。REGIONをクリックするとKubernetesの拠点のリストが表示されます。
12.この中に東京データセンターもあります。


![スクリーンショット 2017-12-05 17.32.53.png](https://qiita-image-store.s3.amazonaws.com/0/42829/af2ffb45-4627-65c2-0b02-d6d29a5f348b.png "スクリーンショット 2017-12-05 17.32.53.png")

13.東京データセンターのk8sクラスタがリストされますから、NAMEをクリックして進みます。
14.アクセスをクリックすると、kubectlで接続するまでの手順が表示されますが、2017年12月5日現在、東京データセンターを利用に対して、この内容には誤りがあります。

![スクリーンショット 2017-12-05 17.33.03.png](https://qiita-image-store.s3.amazonaws.com/0/42829/2b924640-b1ee-a112-967e-1b7cb22f877d.png "スクリーンショット 2017-12-05 17.33.03.png")

2017年12月5日現在、下記の表示の通りに操作しても、東京データセンターのk8sクラスタのマスターノードへはアクセスできません。問題対応を要請中ですが、対策を次に書いていきます。

![スクリーンショット 2017-12-05 17.33.11.png](https://qiita-image-store.s3.amazonaws.com/0/42829/605b79b3-93f3-3b00-8e34-b6aaec96546f.png "スクリーンショット 2017-12-05 17.33.11.png")



## kubectlコマンドを東京データセンターのk8sマスターノードに繫げるには

IBM Cloud シドニーのエンドポイントへログインします。 

~~~
$ bx login -a api.au-syd.bluemix.net
~~~

コンテナサービスのエンドポイントは ap-north へ接続します。 [1]（2017-12-5現在、英語ページのみ情報あり)

~~~
$ bx cs init --host https://ap-north.containers.bluemix.net
~~~

これで、TOK02に出来た k8sクラスタにアクセスできる様になります。

~~~
$ bx cs clusters
OK
Name         ID                                 State    Created      Workers   Datacenter   Version   
mycluster3   20bee482ba9d4a9687dea557b8b13271   normal   4 days ago   3         tok02        1.8.2_1501   
~~~

次にkubectlがマスターノードへアクセスとために必要な情報を取得して、環境変数としてセットします。

~~~
$ bx cs cluster-config mycluster3
OK
The configuration for mycluster3 was downloaded successfully. Export environment variables to start using Kubernetes.

export KUBECONFIG=/home/vagrant/.bluemix/plugins/container-service/clusters/mycluster3/kube-config-tok02-mycluster3.yml
~~~

コピペして、実行してシェルの環境変数にします。

~~~
$ export KUBECONFIG=/home/vagrant/.bluemix/plugins/container-service/clusters/mycluster3/kube-config-tok02-mycluster3.yml
~~~

これで、kubectl から 東京DCのk8s クラスタへアクセスできる様になりました。

~~~
$ kubectl get node
NAME            STATUS    ROLES     AGE       VERSION
10.132.253.17   Ready     <none>    4d        v1.8.2-2+d68ca389c3219c
10.132.253.30   Ready     <none>    4d        v1.8.2-2+d68ca389c3219c
10.132.253.38   Ready     <none>    4d        v1.8.2-2+d68ca389c3219c
~~~


## 東京(TOK02)へウェブサーバーを立ててみる
せっかくIBM Cloud 東京データセンターに Kubernetes の基盤が出来たので、コンテナをデプロイして、速さを体感してみましょう。

### ウェブサーバーのコンテナの準備

下記の様に、ディレクトリ htmlの下に HTMLのコンテンツを置きます。そして、Dockerfileを作成します。

~~~
container-web-nginx/
├── Dockerfile
└── html
    ├── images
    │   ├── ibm_cloud_logo.png
    │   ├── ibm_cloud.png
    │   └── kubernetes-logo.png
    └── index.html
~~~

~~~file:Dockefile
FROM nginx:latest
ADD ./html /usr/share/nginx/html
~~~

このウェブページや必要なYAMLファイルは、GitHubに登録しておきましたので、参考にしてください。 https://github.com/takara9/k8s_webpage



### コンテナのビルドとレジストリへの登録

事前にコンテナ・レジストリ・サービスへログインします。 bx login が成功していれば、ユーザーやパスワードをインプットする必要はありません。

#### コンテナ・レジストリサービスの初期化

~~~
bx cr login
~~~

もし初めての利用であれば、自分のネームスペースを作っておきます。 [your space name] は適当に決めてください。自分の場合は、takaraを設定しました。

~~~
bx cr namespace-add [your space name]
~~~


#### コンテナのビルド
Dockerfile を指定して、コンテナをビルドします。　このコマンドを実行するためには、自分のPCやMacに、DockerCE環境がインストールされている必要があります。

~~~
docker build container-web-nginx -f container-web-nginx/Dockerfile -t web:v3
~~~

出来上がったコンテナ・イメージとレジストリを関連づけます。

~~~
docker tag web:v3 registry.au-syd.bluemix.net/takara/web:v3
~~~

#### コンテナのレジストリ登録

次のコマンドで、レジストリにアップロードします。

~~~
docker push registry.au-syd.bluemix.net/takara/web:v3
~~~

登録したコンテナ・イメージの一覧を表示するには、次のコマンドで実行します。

~~~
bx cr images
~~~

ここまでで、k8sクラスタへ、コンテナへデプロイするセットアップが完了しました。



### コンテナをk8sクラスタへデプロイ

最初にコンテナをk8sクラスタへデプロイするために、k8sのYAMLファイルを作成します。このファイルを適用することで、３個のコンテナにHTTPSのアクセス、及び、ロードバランスを提供します。 
これで、別途、ロードバランサを利用する必要がなく、ドメイン名は与えられたものとなりますが、デジタル証明書を購入する事なく、HTTPSのアクセスが利用できる様になります。

~~~file:nginx_ingress.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.au-syd.bluemix.net/takara/web:v3
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  tls:
  - hosts:
    - mycluster3.jp-tok.containers.mybluemix.net
    secretName: mycluster3
  rules:
  - host: mycluster3.jp-tok.containers.mybluemix.net
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc
          servicePort: 80
~~~


次のコマンドで、k8sクラスタへのデプロイを実行します。

~~~
kebectl create -f nginx_ingress.yaml
deployment "nginx-deployment" created
service "nginx-svc" created
ingress "nginx-ingress" created
~~~

createの部分をdeleteに置き換えると、削除できます。また、YAMLファイルを修正して実体へ反映したい場合は、applyとすることで、YAMLの定義に合わせて実体が変更されます。


### 動作確認
HTTPSでアクセスできるURLを確認するには、次のコマンドで取得できます。 Ingress subdomainとして表示されている部分です。

~~~
$ bx cs cluster-get mycluster3
Retrieving cluster mycluster3...
OK

Name:			mycluster3
ID:			    20bee482ba9d4a9687dea557b8b13271
State:			normal
Created:		2017-12-01T02:04:01+0000
Datacenter:		tok02
Master URL:		https://***.***.***.***:*****
Ingress subdomain:	mycluster3.jp-tok.containers.mybluemix.net
Ingress secret:		mycluster3
Workers:		3
Version:		1.8.2_1501

Addons
Name                   Enabled   
basic-ingress-v2       true   
customer-storage-pod   true   
storage-watcher-pod    true   
~~~

ブラウザでURLをアクセスすると次の様になります。

![スクリーンショット 2017-12-05 17.02.55.png](https://qiita-image-store.s3.amazonaws.com/0/42829/211b7a9b-56d2-670d-f9ed-d3d647e63e54.png "スクリーンショット 2017-12-05 17.02.55.png")



## 東京DCのk8sを利用すると、どれくらい差が出るの？

東京データセンターにデプロイしたコンテナを同じものをダラスデータセンターへもデプロイして比較してみました。

### pingの応答時間

都内の自宅からのpingの応答時間で、東京データセンター(TOK02)では7.6ミリ秒、ダラスデータセンター(DAL10)では154.9ミリ秒なので、劇的に応答時間が短くなった事が解ります。


#### 東京データセンター(TOK02)のウェブサーバーへのping
![スクリーンショット 2017-12-05 17.08.03.png](https://qiita-image-store.s3.amazonaws.com/0/42829/806cfcb2-f100-164e-a6ea-8df23a489c8c.png "スクリーンショット 2017-12-05 17.08.03.png")


#### ダラス データセンター(DAL10)の同一コンテナへping
![スクリーンショット 2017-12-05 17.10.42.png](https://qiita-image-store.s3.amazonaws.com/0/42829/cb3601d4-4792-8b4e-7ad9-081248254c14.png "スクリーンショット 2017-12-05 17.10.42.png")


### キャッシュ無しの時からのブラウザでの描画時間
キャッシュ無しの状態から、同じウェブページを描画するための時間の比較を実施してみました。このサンプルのウェブページでは画像ファイルを含んでいるので、距離に応じてダウンロード完了の時間、及び、ブラウザで描画完了する時間が、変わってきます。 東京データセンター(TOK02)では48ミリ秒、ダラスデータセンター(DAL10)では1004ミリ秒、こちらも劇的にスピードアップされた事がわかります。

#### 東京データセンター(TOK02)のウェブページの描画速度
スクリーン・ショットの下部に、サマリーの情報があり、そこに描画までの時間があります。 また、中段で４つのそれぞれの要求が、Status 200 となっていることから、ブラウザのキャッシュではなく、ダウンロードされた事が判ります。
![スクリーンショット 2017-12-05 17.15.35.png](https://qiita-image-store.s3.amazonaws.com/0/42829/be9eee13-6b1d-14c0-9883-7023302af62f.png "スクリーンショット 2017-12-05 17.15.35.png")


#### ダラスデータセンター(DAL10)のウェブページの描画速度
TCPのハンドシェイクの時間や転送時間が、pingの応答速度として把握できる距離遅延によって、全体的に時間がかかってるのが理解できます。
![スクリーンショット 2017-12-05 17.17.08.png](https://qiita-image-store.s3.amazonaws.com/0/42829/afad8e1d-cad1-9fe0-8ca9-24abf7578135.png "スクリーンショット 2017-12-05 17.17.08.png")


## まとめ

IBM Cloud 東京データセンタでも、Kubernetesが使える様になりました。 Kubernetesの環境を展開するに際して、BluemixのAPIエンドポイントに加えて、Kubernetesのエンドポイントが増設されました。 東京データセンターには、Bluemixの本体が無いので、シドニーへ bx login した後に、bx cs init --host https://ap-north.containers.bluemix.net を実行する必要がある点が、これまでと違う点になります。

それから、やはり東京データセンターにk8sクラスタが存在することで、応答速度、ブラウザの描画が快適になる事が解ります。 これで IBM Cloud の利用が増える事を期待したいと思います。


US南部のレジストリ・サービスからコンテナ・イメージをプルして、東京DCのk8sのクラスタへデプロイするケースの記事として、[IBM Cloud 他リージョンやDocker Hubのプライベートのレジストリからk8sへデプロイする方法](https://qiita.com/MahoTakara/items/711f63f80b8bf783f2b7) を書きましたので、参照頂けると幸いです。


# 参考資料

[1] [IBM Cloud Docs IBM Cloud Container Service, Regions and locations](https://console.bluemix.net/docs/containers/cs_regions.html#regions-and-locations)
[2] [IBM Cloud Blog IBM Cloud Container Service – Simplified Region Switching](https://www.ibm.com/blogs/bluemix/2017/12/ibm-cloud-container-service-simplified-region-switching/)