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

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

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

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

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

4.作成をクリック

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

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

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

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

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

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

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のアクセスが利用できる様になります。

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をアクセスすると次の様になります。

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

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

pingの応答時間

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

東京データセンター(TOK02)のウェブサーバーへのping

ダラス データセンター(DAL10)の同一コンテナへping

キャッシュ無しの時からのブラウザでの描画時間

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

東京データセンター(TOK02)のウェブページの描画速度

スクリーン・ショットの下部に、サマリーの情報があり、そこに描画までの時間があります。 また、中段で４つのそれぞれの要求が、Status 200 となっていることから、ブラウザのキャッシュではなく、ダウンロードされた事が判ります。

ダラスデータセンター(DAL10)のウェブページの描画速度

TCPのハンドシェイクの時間や転送時間が、pingの応答速度として把握できる距離遅延によって、全体的に時間がかかってるのが理解できます。

まとめ

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へデプロイする方法 を書きましたので、参照頂けると幸いです。

参考資料

[1] IBM Cloud Docs IBM Cloud Container Service, Regions and locations
[2] IBM Cloud Blog IBM Cloud Container Service – Simplified Region Switching