まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2019/04

この記事の続きです:
"Play with Docker" で遊ぶ(1)

前回は Play with Docker(以下 "PwD")というサービスを使うことで Docker をインストールすることなく、ブラウザだけで docker コマンドを体験できることを紹介しました。今回はこのサービスの標準機能として提供されている Docker Swarm を使ったクラスタリング環境構築の手順を確認してみます。

Docker Swarm は Docker に対応したネイティブ&軽量なクラスタリング用のツールです。Docker の標準機能の一部として提供されているので、Kubernetes のように Docker 導入の後から追加でインストールする必要なく(Swarm モードに切り替えるだけで)利用できます。

では早速 PwD で Docker Swarm を使ってみましょう。まずは前回同様、Docker Hub のアカウントで PwD にログインします:
2019041901


PwD のダッシュボード画面が表示されます。まずは前回同様に "+ ADD NEW INSTANCE" をクリックして Docker インスタンスを追加します:
2019042101


"node1" という名称の Docker ノードインスタンスが追加され、操作するためのコンソールも表示されました。ここまでは前回と同じです:
2019042102


今回はクラスタリング環境を構築したいので、更に2つの Docker ノードインスタンスを追加します(合計3つにします)。あともう2回 "+ ADD NEW INSTANCE" をクリックして、"node2" と "node3" を追加します。こんな感じで Docker ノードを気軽に増やせるのは本当に便利です。。
2019042103


この時点で3つの Docker が(独立した状態で)準備できました。ではこの3つの Docker ノードを使ってクラスタリング環境を構築します。今回は node1 を管理ノード、node2 と node3 をワーカーノードとするクラスタリング環境とします。

まずは管理ノードを準備します。node1 を選択して、node1 のコンソールに以下のコマンドを入力します:
$ docker swarm init --advertise-addr eth0

2019042104


成功すると出力結果に
$ docker swarm join --token XXXXXX...
という内容が表示されます。これはワーカーノードとなるノードで入力すべきコマンドです。これで管理ノードの準備はできました。


では次にワーカーノードをこの管理ノードに接続します。先程の管理ノードでのコマンド出力結果の "docker swarm join --token XXXXXX..." 部分をそのまま node2 のコンソールにコピー&ペーストして実行します:
2019042105


"This node joined a swarm as a worker." というメッセージが表示されれば正しくワーカーノードとしてクラスタリングに追加し、初期化できたことになります。

同様に node3 でも同じコマンドを実行して、ワーカーノードとしてクラスタリングに追加します:
2019042106


これで3つの Docker インスタンスノードによるクラスタリング環境が構築できているはずです。念の為、node1 ノードで以下のコマンドを実行します:
$ docker node ls

実行結果を見ると、node1, node2, node3 の3つのノードがクラスタリングを構成している様子が表示され、かつ node1 が "Leader" (管理ノード)と表示されているはずです:2019042107



では、このクラスタリング環境でアプリケーションを実行してみます。なお原則的には以下のコマンドはすべて管理ノードである node1 ノードのコンソールを使います。

改めて node1 ノードで nginx のイメージを使って 80 番ポートで、1インスタンスで、"web" という名前でサービスを作成します:
$ docker service create --replicas 1 --name web -p 80:80 nginx

初回はイメージのダウンロードもあるので少し時間がかかりますが、以下のようなメッセージが表示され、正しくサービスが作成されます:
2019042108


動作確認する前に、この時点でサービスの様子を確認します。node1 ノードで以下のコマンドを実行します:
$ docker service ls

"web" というサービスがレプリカ1つで定義され、そのうちの1つが動いている形で 80 番ポートで作成されている様子が確認できます:
2019042109


実際に動作確認してみます。80 番ポートで公開されているので、curl コマンドを使って以下のコマンドを実行します(このコマンドは node2 や node3 で実行しても確認できます):
$ curl http://localhost/

Nginx 標準のトップページの HTML が表示されます。正しくサービスが動いている様子が確認できました:
2019042110


では、現在1インスタンスで稼働しているこのサービスを複数インスタンスとなるように node1 でスケールアウトさせてみます:
$ docker service scale web=3

3インスタンスで稼働するように指定しました。少し待ちますが、3つのインスタンスが "running" となることを確認します:
2019042101


改めてnode1 でレプリカ数を確認します:
$ docker service ls

結果、以下のように3つのレプリカが定義されており、そのうちの3つが動いている様子が確認できます:
2019042102


最後に作成したサービス(web)を削除する方法を紹介しておきます。node1 で以下のコマンドを実行します:
$ docker service rm web

これで web サービスはクラスタリング環境から削除されました:
2019042103



PwD 環境を使ったクラスタリング環境構築と、簡単なサービス作成&スケールアウト&削除といった手順を紹介しました。 通常、同じことを行うには3台のマシンを用意した上で、それぞれに Docker をインストールしておかないとこのような動作確認はできないのですが、PwD を使うと Docker 導入の手順を省略することができる上、全ての操作を1つのブラウザ画面上で行うことができるという点が勉強しやすいと感じました。




"Play with Docker" (以下、"PwD")というサービスを使ってみました:
https://labs.play-with-docker.com/


2019041901


一言でいうと「ブラウザだけで docker コマンドを体験できるサービス」です。普通、Docker を使うには(当然ですが)Docker 環境が必要です。自分でインストールすることもできますし、各種クラウドサービスで提供されているものを使ってもいいです。自分でインストールせずにクラウドサービスの Docker サービスを利用する場合は別途手元のマシンに docker クライアントを導入&セットアップして使うことになります。一度セットアップしてしまえばいい話ではありますが、慣れてなかったり「そもそも Docker って何?」という人がこれから勉強するために用意することを考えると「ちと面倒」です。

この PwD は、そんな Docker のセットアップ手順をすっ飛ばして Docker を使うことができるサービスです。具体的には Docker Hub のアカウントを取得し、そのアカウントでログインするとブラウザ上で docker 他の各種コマンドが使えるターミナルが提供され、裏で動いている Docker エンジンや、オーケストレーション環境である Docker Swarm エンジンを利用することができる、というものです。

利用するにはブラウザで PwD サイトへアクセスし、"Login" と書かれたボタンをクリックして Docker Hub のアカウントでログインします(所有していない場合はここで作成してログイン):
2019041901


ログイン後に改めて同ページを参照し、今度は "Start" ボタンをクリックしてサービス開始です:
2019041902


PwD サービス画面に切り替わります。画面左上にこのセッションで使える残り時間が表示されています。カウントダウンも始まっていますが、約4時間使える、ということみたいです。この時点ではまだdocker インスタンスが1つも起動していません。まずは1つ使ってみましょう。"+ ADD NEW INSTANCE" と書かれた箇所をクリックします:
2019041903


"node1" という名称のインスタンスが追加されました。同時に画面右にコンソールが現れて、プロンプト状態になります。すでに docker エンジンは起動している状態になっていて、ここから docker コマンドなどを実行することができる状態になってます。簡単すぎる・・・:
2019041904


試しに "$ docker version" を実行してみました。サーバー側もちゃんと動いてそうです:
2019041905


では深く考えずに nginx のイメージからコンテナを1つ起動してみます:
$ docker pull nginx

$ docker run -d -p 80:80 nginx


そして起動中であろう nginx にアクセスしてみます:
$ curl http://localhost/

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

  :

</html>

普通に使えてますね、これはすごい!

ほぼ準備することなく Docker コマンドが使えて、コンテナの実行もできて、勉強目的であればとてもいい環境だと思いました。

次回はこの PwD で(使えることになっている)オーケストレーション環境である Docker Swarm を使ってみる予定です。




2019年4月1日午前11時40分ごろ、新しい元号の発表がありました:
gengou_happyou_reiwa_kakageru


30年ちょっと続いた「平成」は4月30日の「退位の日」を持って終わり、5月からは「令和」となります。自分自身は昭和から平成と変わる時も物心がついていたのですが、昭和天皇崩御の直後だったこともあってお祝いというよりは静粛な雰囲気で行われた記憶があります。改元自体はおめでたいことだと思うので、本来はこうあるべきなんじゃないかな、、と思っています。

さて、この新元号発表の瞬間、僕は Abema TV にへばりついて生中継を見ていました。一刻も早く新元号を知りたかった理由、それは「新元号のドメインをとりたかった」に他なりません(笑)。

ドメインというのはインターネットのネームスペースのドメインのことです。メールアドレス xxx@abc.co.jp でいう "abc.co.jp" の部分です。ドメインは原則早いもの勝ちで取得ができるもので、おそらく同じことを考えていた人は少なくないと思います。そんな中で新しい元号が発表されたら、その元号にちなんだドメイン ○○○.jp を後で高く転売してやろうとか考えて取りたかったのでした。

ちなみに、自分はいくつかのドメインを所有しています。ドメインの申請や登録業者には GoDaddy.com を使っています。特別な理由はなく「ずっと昔からここを使っていたから」です。今回の新元号ドメイン取得は多くのライバルがいることを想定していたので、事前にシミュレーションを行って購入のリハーサルを行ったり、最短スピードで購入できるような手順を確認した上で臨みました。

(1)購入まで
そして当日、Abema TV を聴きながら(視てません。画面は GoDaddy.com にして、音声だけ聞いて、発表直後にドメイン検索できるように待ち構えてました)その瞬間を待ちます。そして発表!

・・「レイワ? レイワって言ったな?」 直後に reiwa.jp を検索(体感的にはこの間 0.1 秒)! 結果は・・・がーん、まさかの取得済み! 


後で調べてわかったのですが、千葉県柏市の「株式会社 冷和」様が 2007 年に登録済みのドメインでした:
2019041801


が、reiwa.jp が取得済みなのは(まさか一般企業が取得しているとは思ってなかったけど)想定済み、プランB発動! .jp 以外でどこか空いてないかな・・・ と探していたら reiwa.world が空いていました。

「ワールド!? うーん、ワールドか・・・ でもまあ『世界にアピールするには悪くない』よな。あと .world なら値段もそんなに高くないはず」と体感的には1秒ほど考えた後、脊髄反射的に購入プロセスへ(というわけでスクリーンショット撮ってません、ごめんなさい)。もしかしたら同じ処理をしている人が他にいるかもしれない、その場合は早いもの勝ち! でもこのあたりは直前に何度もリハーサルしてるので(苦笑)迷うことなくサクサク進めることができました。そして、、、
2019041802


取ったー!!

もうドメインを取ることだけを考えて手を動かしていたので値段見ずに買ってました(良い子は真似しちゃいけません)。ぶっちゃけ思っていたよりも高い。(^^; しかもよくわからない "Private Domain Registration" まで付けて買ってるし(苦笑)。でもいい! reiwa.world ドメイン取ったどーー!!


(2)謎のメール
上記の購入お知らせメールを受信した直後に GoDaddy.com からもう一通のメールを受信しました:
2019041803


"reiwa.world" を登録できない!? エラー!? 登録できなかったら返金する、って、いやいやいや。どういうこと??

後でわかったのですが、どうやら GoDaddy.com の受付処理が間に合わないレベルでほんの僅かに先客がいたようで、このドメインを取ることができませんでした:
2019041804


この先客の登録は日本時間で 11:42:43 、僕の登録(正確には登録メールを受信したタイミング)は 11:43:04。20秒差もあったということは、この相手はほぼ自動的にドメインを登録する処理をしていたのだと思われます。やられた・・・

そしてその先客とは・・・グーグル様でした。 凸(▼▼
2019041805


残念ですが、「個人でグーグルと張り合った」と解釈して満足することにします。


(3)返金
後日、GoDaddy.com から返金処理が行われてきました:
aeon201905


ちょっと待って!

支払額が 23558 円で、返金額が 18063 円。なんで差があるの? しかもこの 18063 円ってドメイン登録費用のみの額で、(調べずに付けて買った)プライバシー登録費用の 5495 円ぶんが返金されてないじゃん!

というわけで GoDaddy.com のカスタマーサポートに電話。ここ、いつの間にか日本語で電話できるようになったんだよね。助かります。

で、事情を伝えると「忘れてたみたい、今から返金します」的な感じで対応していただきました。 まだ入金は確認できませんが、とりあえず手続き処理は完了した模様です。


最後までドタバタしましたが、令和の前に令和の騒動を解決できたっぽいのでまとめておきました。 令和の次まで生きてたら、次回は自分も API とか探して自動化で参戦したいです。

これらの記事の続きです:
IBM Cloud の無料版 Kubernetes サービスを使ってみた(1)
IBM Cloud の無料版 Kubernetes サービスを使ってみた(2)


IBM Cloud の Kubernetes サービスを使って、無料のワーカーノードにアプリケーションをデプロイして、(いったん)削除する所までを紹介しました。最終回である今回は実際にアプリケーションにアクセスしたり、デプロイしたアプリケーションをスケールさせてみたり、外部(インターネット)に公開してみたりします。

今回の作業も基本的にすべて Web Terminal から行います。というわけで、まず Web Terminal を起動します:
2019041109


改めてアプリケーションをデプロイします。が、今回は後述の RC(ReplicatoinController) としてデプロイするため、デプロイ用のファイル(rc.yaml)を作成します:
apiVersion: v1
kind: ReplicationController
metadata:
  name: kubernetes-bootcamp
spec:
  replicas: 1
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: myk8x
        image: gcr.io/google-samples/kubernetes-bootcamp:v1
        ports:
        - containerPort: 8080

デプロイ時にはこのファイル(rc.yaml)を指定して、以下のコマンドを実行します:
$ kubectl create -f rc.yaml
replicationcontroller/kubernetes-bootcamp created

このコマンドで前回とほぼ同様に kubernetes-bootcamp アプリケーションを1つのポッドにデプロイします。また app: web というセレクターを指定していますが、この後で使います。

この時点で kubernetes-bootcamp アプリケーションが1つのポッドにデプロイされます。一応ポッドと、そして(詳しくは後述の)サービスの状態を確認しておきます(緑字はコメント):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          41s  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h  ここはクラスタサービスなので無視、つまり起動したサービスなし

この時点で1つのポッドにアプリケーションがデプロイされたことが確認できました。しかしこのポッドはまだコンテナの外部からアクセスすることができません。コンテナの外部からでもアクセスできるように紐付けるサービスを作成します。

作成するサービスのための設定ファイル(service.json)を以下の内容で用意します:
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "web"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 8080,
                "nodePort": 30000
            }
        ],
        "type" : "NodePort"
    }
}

"spec" 内で app:web のラベルをセレクターに指定しています。これが先程作成したデプロイメント時の指定内容となっていて、kubernetes-bootcamp に紐づく形になります。また 8080 番ポートをターゲットに接続し、80 番ポートで公開する、という指定も行い、"my-service" という名前でサービスを作るよう指示しています。

ではこのファイル(service.json)を使ってサービスを作成します。同時に再びポッドとサービスの内容を照会してみます:
$ kubectl create -f service.json
service/my-service created

$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          13m  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h
my-service   NodePort    172.21.30.70 <none>        80:30000/TCP   94s 追加されたサービス

サービスの追加に成功しました。またその追加されたサービスはクラスター内の内部 IP アドレスである 172.21.30.70:80 上で稼働していることがわかりました。

ではこのサービスを使ってアプリケーションにアクセスしてします:
$ curl http://172.21.30.70/
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-jfswt | v=1

アプリケーションにコンテナ外部からアクセスでき、正しく動作していることも確認できました。ただし、この時点ではまだあくまで内部ネットワーク内からのアクセスが確認できただけで、まだインターネットからはアクセスできません(後述します)。


コンテナの外部からアプリケーションにアクセスできることは確認できましたが、せっかくなので Kubernetes っぽい挙動もさせてみます。現在1つのポッドで動作しているこのアプリケーションをスケールアウトして複数の(今回は2つの)ポッドで起動するようにしてみます:
$ kubectl scale -f rc.yaml --replicas=2
replicationcontroller/kubernetes-bootcamp scaled

この状態で再びポッドとサービスの状態を確認します。ポッドが2つになっていることがわかります。(一方、サービスは何も変わっていません):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-kqkhp   1/1     Running   0          14s スケールアウトして新しく増えたポッド
kubernetes-bootcamp-jfswt   1/1     Running   0          109s

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   172.21.0.1      <none>        443/TCP        3d23h
my-service   NodePort    172.21.30.70    <none>        80:30000/TCP   5m16s

ではこのアプリケーションをインターネットに公開してみます。以下のコマンドを実行します:
$ kubectl expose rc kubernetes-bootcamp --type=NodePort --name=web
service/web exposed

$ kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   172.21.0.1       <none>        443/TCP          4d20h
my-service   NodePort    172.21.199.105   <none>        80:30000/TCP     4m30s
web          NodePort    172.21.64.253    <none>        8080:30703/TCP   4m9s

"web" という名称のサービスが追加され、kubernetes-bootcamp の rc が expose(外部公開)されました。公開先のポート番号が 30703 になっていることも確認できます。

また、公開先の IP アドレスはワーカーノードのパブリック IP アドレスになっています。ダッシュボードから確認するか、または以下のコマンドを実行します:
2019041601
$ ibmcloud cs workers mycluster (最後のパラメーターはクラスタ名)

ID                                                 Public IP       Private IP       Machine Type   State    Status   Zone    Version   
kube-mel01-pa351ddd2ea19441a689a49159389f9d45-w1   168.1.149.201   10.118.243.103   free           normal   Ready    mel01   1.12.7_1548*


この例だと、パブリック IP アドレスが 168.1.149.201 となっているので、この 30703 番ポートに対してウェブブラウザでアクセスし、期待通りの結果になることを確認します:
2019041602


最後に、サービスとポッドを削除する場合は以下のコマンドを実行します:
$ kubectl delete svc web
service "web" deleted

$ kubectl delete -f service.json
service "my-service" deleted

$ kubectl delete -f rc.yaml
replicationcontroller "kubernetes-bootcamp" deleted


IBM Cloud の(無料の)Kubernetes サービスを使って、アプリケーションのデプロイ、スケール、動作確認、ウェブ公開、といった一連の作業ができることが確認できました。すでに Kubernetes 環境を手元に持っているような人であればともかく、これから Kubernetes を使ってみようと思う人にとっては面倒な準備作業も不要で気軽に始められて、スケールやウェブ公開といった一通りの作業ができるところまで使える環境としてとても便利だと思いました。





この記事の続きです。

IBM Cloud の無料版 Kubernetes サービスで、Kubernetes クラスタを立ち上げる所までを紹介しました。 今回は(ベータ版の)Web Terminal 機能を使って、この Kubernetes サービスの状態を確認したり、アプリケーションをデプロイしてみます。

IBM Cloud を操作する場合、一般的には ibmcloud コマンドを使います。また Kubernetes クラスタの状態を確認する場合、一般的には kubectl コマンドを使うことが多いと思っています。普段使っているマシンに ibmcloud コマンドや kubectl コマンドがすでにセットアップされているような場合はそれらのコマンドを使えばいいのですが、まだ導入されていないようなケースでは別途セットアップしてから利用する必要があります。 今回紹介する Web Terminal はそういった導入をしなくてもウェブブラウザ内のコンソールから ibmcloud コマンドや kubectl コマンドを使って操作できる方法です。現時点(2019/04/15)でベータ版なので今後どういう形になるかわかりませんが、使ってみて便利だったので紹介させていただくことにしました。

では以下に実際の手順を紹介します。まず前回の記事の内容が正しく実行されて、"mycluster" という名称の Kubernetes クラスタが稼働している状態になっていることを確認します:
2019041107


"Worker Nodes" タブでワーカーノード(今回は1つ)が正しく動いている点も確認します(この画面では IP アドレスをモザイクにしていますが、実際にはモザイクなしに表示されます):
2019041108


ではまずはこのワーカーノードの状態を Web Terminal からも確認してみます。画面内の "Web Terminal" と書かれたボタンをクリックします:
2019041109


最初にクリックした時だけ、「Kubernetes Terminal をインストールする」という確認のダイアログが表示されます。「Install」ボタンをクリックすると Kubernetes Terminal がインストールされます(少し時間がかかります、十数秒くらい?):
2019041110


(Kubernetes Terminal をインストールした場合は十数秒程度待って)改めて "Web Terminal" ボタンをクリックします。するとブラウザ画面下部からターミナルが現れます:
2019041111


このターミナルのプロンプトで、画面内に書かれたセットアップ手順を順に実行していきます。ibmcloud コマンドは特にインストールしていませんが、この Web Terminal 内では導入済みなので普通にそのまま使うことができます(赤字はコメント):
2019041112
$ ibmcloud login -a https://cloud.ibm.com ログイン

$ ibmcloud ks region-set ap-south サービスのリージョンを(作成したリージョンに)指定

$ ibmcloud ks cluster-config mycluster Kubernetes の環境設定用ファイルを生成してダウンロード

最後のコマンドを実行すると KUBECONFIG 環境変数を設定するためのコマンドが表示されます。そこに書かれた内容をそのままコピー&ペーストして、Web Terminal 上で KUBECONFIG 環境変数を設定します:
$ export KUBECONFIG=/home/IBMid-31000086FP/.bluemix/plugins/container-service/clusters/mycluster/kube-config-mel01-mycluster.yml

 

ここまでの作業が完了すると Web Terminal から kubectl コマンドを実行できるようになり、コマンドを通じてワーカーノードの状態を確認することもできるようになります。この kubectl コマンドも特にセットアップすることなく、Web Terminal 上でそのまま実行できます:
$ kubectl get nodes

1つだけ動いているワーカーノードが、名称や状態とあわせて Web Terminal 上に表示されます:

2019041113


先程ウェブ画面で確認したものと同じ内容が表示されました。これでこの Web Terminal 上から Kubernetes クラスタを操作できることが確認できました。


では続けてこのノードにアプリケーションをデプロイしてみます。Kubernetes の公式チュートリアルで紹介されている内容と全く同じ操作を Web Terminal から行ってみます。

デプロイメントの名前(以下の例では kubernetes-bootcamp)とアプリケーションイメージの Docker Hub リポジトリ URL (同 gcr.io/google-samples/kubernetes-bootcamp:v1)、実行ポート番号(同 8080)を指定して kubectl run コマンドを実行し、アプリケーションイメージを Kubernetes クラスタにデプロイします:
$ kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080

このコマンドが実行されると、アプリケーションが実行可能なノード(今回ははじめから1つしか用意してないので、その1つ)を探し、アプリケーションの実行がスケジュールされてデプロイが実行されます。

実行後に以下のコマンドでデプロイメントの状態を確認してみます。以下のような感じで、1つのアプリケーションが実行されている状態になればデプロイは成功しています:
$ kubectl get deployments
NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1         1         1            1           16s

また、この時点で Pod の状態も確認しておきます。デプロイ時に特にレプリカ数を指定していなかったので、1つの Pod が起動され、その上でアプリケーションが起動しているはずです:
$ kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-598f57b95c-w2k4b   1/1     Running   0          2m7s

次の段階に進む前に、いったん作成した Pod を削除しておきます。作成時に指定した名前(kubernetes-bootcamp)を指定してデプロイメントを削除します:
$ kubectl delete deployment kubernetes-bootcamp
deployment.extensions "kubernetes-bootcamp" deleted

$ kubectl get deployments
No resources found.

$ kubectl get pod
No resources found.

↑念の為、デプロイメントと Pod が存在しなくなっていることも確認できました。次回、最終回に改めてアプリケーションをデプロイして、スケールさせたりした上で使ってみることにします。

このページのトップヘ