Ubuntu Weekly Recipe

第469回AWS上に魔獣「Kubernetes」10分で召喚する魔法

皆さんはGWを楽しんでいますか。せっかくの長期休暇をぐったりウィークとして無為に過ごしたりしていませんか。もちろん体を休めることは重要ですが、あまり休めすぎると後悔という名のリバウンドが待っていますよ。

そこで今回のRecipeでは、GWが終わったあとに「がんばった私」とエクスキューズできるよう、Kubernetesを簡単に構築できる方法を紹介します。これで連休明けには「いやぁ連休中はKubernetesを触っていてさぁ」と言えますよ!

コンテナを「いい感じ」に調整してくれるKubernetes

Kubernetesはコンテナのオーケストレーションツールです。具体的にはDockerコンテナに対して、次のような機能を提供します。

  • 複数のホストに複数のコンテナをデプロイするためのインフラストラクチャー
  • コンテナが提供するサービスのスケーリング・ロードバランシング
  • インスタンスのレプリケーション
  • コンテナ間のネットワーク管理
  • ロギング・モニタリング
  • 上記の機能を利用するためのAPIや鍵の管理

Dockerは単にコンテナ内部でソフトウェアを実行するツールです。Dockerそのものには上記のような「複数のコンテナを連携させる機能」はありません。もちろんDockerfileやソフトウェアをうまく作りこむことで同じようなことを実現できますが、それらはあくまでDockerの外の仕事です[1]⁠。

Dockerコンテナを純粋なアプリコンテナとして使った場合、どうしても複数のアプリ(インスタンス・サービス)を連携させたくなることがよくあります。シンプルなサービスであっても、たとえばフロントエンドとデータベースを別々のインスタンスにしたいこともあるでしょう。サービスの構成が複雑になればなるほど、インスタンスの起動手順やDockerfile、Dockerイメージの管理も複雑になっていきます。インスタンス間を連携させるとなると、IPアドレスやホスト名の管理を行わなくてはならないかもしれません。さらにはサービスの可用性をあげるために、同じサービスを複数のホストにレプリケーションしたい場合もあります。

複数のコンテナを管理するツールにDocker Composeがあります。Docker Composeは複数のコンテナの設定や関係をひとつのファイルにまとめて記述できるため、コンテナ同士が連携することでひとつのサービスを提供するようなソフトウェアにとっては非常に便利なツールです。さらに従来はdockerコマンドにオプションとして渡していたような情報も設定ファイルとして記述できるため、マルチコンテナではない環境でも有用です。ただし複数のホストにデプロイするとなると、ひと手間必要になります。

とどのつまりKubernetesは、複数のコンテナを複数のマシンに「いい感じ」に配置・管理できるツールなのです[2]⁠。

Kubernetes環境を「召喚」する

Kubernetes環境を用意すれば、マルチホストでDockerコンテナを管理できるようになります。

つまり管理対象の複数のホストに、Kubernetes環境を「デプロイ」する必要があります。Kubernetes本体だけではなく、Dockerなどのコンテナ管理システムも必要です。用途によってはコンテナ間のネットワーク管理としてFlannelやホスト間の情報を保存する分散型キーバリューストアとしてetcdなどを用意しなくてはならないかもしれません。つまり「めんどくさい」のです。

単にKubernetesの仕組みを勉強したいだけであればMinikubeを使うという手があります。Minikubeは単一ホスト上にKVMやVirtualBoxなどを用いて複数の仮想ホストを作成し、それらの仮想ホストを用いてKubernetes環境を構築します。よってMinikubeを動かすためにはそこそこのスペックのマシンが必要です。当然のことながらプロダクションの用途に使うことは想定していません。

そこで今回はより簡単に複数のホストにKubernetesを構築する方法としてconjure-upを使うことにしましょう。⁠conjure-up」呪文spellを唱えることで、人智の及ばない魔獣複雑怪奇なソフトウェアスタック現し世サーバー喚び出すconjure up術式です。召喚には代償・贄が必要になることもあります。conjure-upだと大抵は「インスタンス料金」とか「電気代」という形で、召喚者の財布の中身が消失するようです。

conjure-upはホストを管理するバックエンドとしてJujuを使います。つまりホストの準備や個々のソフトウェアのデプロイそのものはJujuやその設定スクリプト群であるCharmが担います。conjure-upのSpellには、Juju環境を構築したあと、Charmを呼び出す前、デプロイが完了したあとのそれぞれについて行うべき作業を記述するのです。あとはconjure-upを呼び出すときにホストの数やホストを構築する対象(AWSやAzureを使うのか、ローカルのLXDを使うのか、MAASを使うのか)などを設定することで、フレキシブルに複雑なソフトウェアスタックをコマンド一発で構築できます。

簡単に言ってしまえば第341回で紹介したOpenStack Installerを、OpenStack以外の構築にも利用できるようにしたツールです。

conjure-upのインストールと実行

conjure-upを利用するためには、あらかじめ次のような環境を用意しておく必要があります。

  • snapが動く環境(この記事ではUbuntu 16.04 LTSを使用しています)
  • Kubernetesを構築する環境

後者については、AWSやAzure、GCPといったパブリッククラウドに加えて、LXDやMAASといったローカル環境をサポートしています。この記事ではAWSを使う前提で説明しますが、他のサービスを使う場合はサービスごとのアクセスキーを、ローカルに構築する場合はLXDやMAASをインストールした環境を用意しておいてください[3]⁠。ローカルにKubernetesを構築する場合は、16GBのRAMや250GB程度のストレージが必要なようです。AWSの場合、m3.mediumインスタンスを10個ほど作ります。

conjure-upそのものはsnapパッケージとして提供されています。よってUbuntuでも、その他のディストリビューションでも同じ手順でインストールできます。Ubuntu 16.04 LTSなら最初からsnapシステムがインストールされているので、次のコマンドを実行するだけです。

$ sudo snap install conjure-up --classic
conjure-up 2.1.5 from 'canonical' installed

conjure-upにはJujuのコマンドも同梱されています。このためJujuを別途インストールする必要なく、Juju環境を構築可能です。conjure-upを用いた召喚は、次のコマンドを呼び出すだけです。

$ conjure-up

以降はCUIから呪文を唱えることになります[4]⁠。

図1 conjure-upは独自のCUIツールキットを使用している
画像

conjure-upは独自のCUIツールキットを使っています。このため画面上の文字列のコピーアンドペースト操作が若干特殊です。まず文字列をコピーする場合は、Shiftキーを押しながらマウスで選択してください。選択することでクリップボードにその文字列がコピーされます。クリップボード上の文字列をペーストするには「Shift + Insert」キーを押します。

また、端末のサイズは「132x43」以上を推奨しています。GNOME端末を使っている場合は、メニューの「端末」から端末サイズを変更しておきましょう。ノートPCなどは縦43が足りない場合もあるかもしれませんが、多少は132x43を下回っても問題なく動きますので安心してください。

なおプロキシ環境の場合はconjure-upコマンドに--http-proxyオプションなどを渡すことで対応できます。詳細は--helpオプションで確認してください。ちなみにプロキシ環境内部からAWSなどプロキシの外に構築する場合は、コマンドオプションなどだけではケアできないようです。そのような場合は、sshuttleなどで外への経路を確保した上でconjure-upを実行したほうがいいでしょう。

Kubernetes構築の流れ

Kubernetes環境を構築する場合は、最初の選択画面で「The Canonical Distribution of Kubernetes」を選択します。ここにあるリストがいわゆるSpellと呼ばれるもので、個々のSpellはYAMLファイルとスクリプトの集合体です。もちろん自作のSpellを使って、召喚魔法を唱えることも可能です。

The Canonical Distribution of KubernetesはJujuを用いてKubernetesの環境を構築するためのキットです。このキットを使うと、以下のような環境をワンタッチで構築できます。

  • Kubernetes
    • マスターノード1つに、ワーカーノード2つ
    • ノード間通信にTLSを使用
    • CNIプラグインとしてのFlannel
    • マスターノードのHAとしてロードバランサー
    • Nginx Ingress Controller
    • Kubernetes Dashboard
    • クラウドモニタリングツールとしてHeapster
  • EasyRSA
    • 自己署名証明書の認証局
  • Etcd
    • 信頼性を高めるために3ノード構築

ノードの数などは構築時や構築後に調整可能です。では、実際にKubernetesを構築していきましょう。

図2 Jujuコントローラーの選択
画像

ホストマシンの構築にはJujuを使います。Jujuを使用するためにはどこかにJujuコントローラーが必要です。これまではjuju bootstrapを用いてAWSだったりローカルのコンテナ内部にコントローラーを構築することが一般的でした。しかしながら、最近CanonicalはこのコントローラーのみをCanonicalのサーバーでホストするサービスJaaS(Juju as a Service)立ち上げました。パブリックベータというステータスではあるものの、このサービスを使えばコントローラー部分はCanonicalのサービスを利用できるため構築時間を短縮できます。ただし当然のことながら、Jujuコントローラー以外は別のホストが必要です。

今回は従来通り、独自のJujuコントローラーを立てることにしますので「Deploy New Self-Hosted Controller」を選択します。

図3 クラウドサービスの選択
画像

Spellを展開する先のクラウドサービスを選択します。⁠localhost」だとLXDを使ってすべてのインスタンスをローカルのコンテナに構築しますし、⁠MAAS」だとMAASとして構築済みの環境を使います。そこそこの性能があるホストマシンであれば、インスタンス代がかからないlocalhostも選択肢になるでしょう。ただしMinikubeとどこまで違うのかという点は一考の余地があります。

今回は「aws」を選択しますが、⁠azure」「google」と比べて手順にそれほど違いはありません。

図4 アクセスキーの入力
画像

Jujuがクラウドサービス上にインスタンスを立ち上げられるよう、アクセスキーを指定してください。AWSだったらIAMでJuju用のアカウントを作ってしまうのが良いでしょう。

前述したとおりクリップボードの文字列をペーストするには「Shift + Insert」を押します。

図5 インスタンスの設定
画像

この画面で「Deploy」もしくは「Dploy all 6 Remaining Applications」にフォーカスを合わせてエンターを押すと、それぞれのインスタンスを作成します。必要であれば「Configure」からインスタンスの数を調整してください。⁠Configure」では他にも個々のアプリケーション(Juju Charm)の設定が行えます。ちなみにAWSのインスタンスサイズの変更やアベイラビリティゾーンの指定はできません。自動的にm3.medium/us-east-1が選択されます。どうしても変更したい場合は、ヘッドレスモードを使いましょう。

図6 Jujuコントローラーの準備中
画像
図7 Jujuのデプロイステータス
画像
図8 kubectlパッケージのダウンロード
画像

最終的にデプロイが完了すると、Kubernetesを操作するkubectlコマンドがインストールされます。ちなみにkubectlコマンドはsnapパッケージとして提供されるので、conjure-upを実行していない環境でもインストール可能です。

$ which kubectl
/snap/bin/kubectl

$ snap list
Name             Version  Rev   Developer  Notes
conjure-up       2.1.5    197   canonical  classic
core             16-2     1577  canonical  -
kubectl          1.6.1    7     canonical  classic
図9 インストールステータスの表示
画像

構築した環境の確認

まずは構築した環境を確認してみましょう。まずはJujuを使って、各インスタンスの状況を表示してみます。

$ juju status
Model                         Controller          Cloud/Region   Version
conjure-canonical-kubern-56a  conjure-up-aws-59b  aws/us-east-1  2.1.2

App                    Version  Status  Scale  Charm                  Store       Rev  OS      Notes
easyrsa                3.0.1    active      1  easyrsa                jujucharms    8  ubuntu
etcd                   2.3.8    active      3  etcd                   jujucharms   29  ubuntu
flannel                0.7.0    active      4  flannel                jujucharms   13  ubuntu
kubeapi-load-balancer  1.10.0   active      1  kubeapi-load-balancer  jujucharms   10  ubuntu  exposed
kubernetes-master      1.6.1    active      1  kubernetes-master      jujucharms   17  ubuntu
kubernetes-worker      1.6.1    active      3  kubernetes-worker      jujucharms   22  ubuntu

Unit                      Workload  Agent  Machine  Public address  Ports           Message
easyrsa/0*                active    idle   0        AAA.BBB.CCC.DD                  Certificate Authority connected.
etcd/0*                   active    idle   1        AAA.BBB.CCC.DD  2379/tcp        Healthy with 3 known peers
etcd/1                    active    idle   2        AAA.BBB.CCC.DD  2379/tcp        Healthy with 3 known peers
etcd/2                    active    idle   3        AAA.BBB.CCC.DD  2379/tcp        Healthy with 3 known peers
kubeapi-load-balancer/0*  active    idle   4        AAA.BBB.CCC.DD  443/tcp         Loadbalancer ready.
kubernetes-master/0*      active    idle   5        AAA.BBB.CCC.DD  6443/tcp        Kubernetes master running.
  flannel/2               active    idle            AAA.BBB.CCC.DD                  Flannel subnet 10.1.103.1/24
kubernetes-worker/0       active    idle   6        AAA.BBB.CCC.DD  80/tcp,443/tcp  Kubernetes worker running.
  flannel/3               active    idle            AAA.BBB.CCC.DD                  Flannel subnet 10.1.2.1/24
kubernetes-worker/1*      active    idle   7        AAA.BBB.CCC.DD  80/tcp,443/tcp  Kubernetes worker running.
  flannel/1               active    idle            AAA.BBB.CCC.DD                  Flannel subnet 10.1.20.1/24
kubernetes-worker/2       active    idle   8        AAA.BBB.CCC.DD  80/tcp,443/tcp  Kubernetes worker running.
  flannel/0*              active    idle            AAA.BBB.CCC.DD                  Flannel subnet 10.1.62.1/24

Machine  State    DNS             Inst id              Series  AZ
0        started  AAA.BBB.CCC.DD  i-0e621a5d06fcf0f6d  xenial  us-east-1a
1        started  AAA.BBB.CCC.DD  i-030519d511782fa14  xenial  us-east-1a
2        started  AAA.BBB.CCC.DD  i-039478ca3d761b32f  xenial  us-east-1c
3        started  AAA.BBB.CCC.DD  i-04dff5a25d1bcc4a3  xenial  us-east-1d
4        started  AAA.BBB.CCC.DD  i-0445ab5ce74c72197  xenial  us-east-1e
5        started  AAA.BBB.CCC.DD  i-0cab289259c45b691  xenial  us-east-1c
6        started  AAA.BBB.CCC.DD  i-083d7c7d8bea6a1c0  xenial  us-east-1d
7        started  AAA.BBB.CCC.DD  i-0b28daa810f52c8a7  xenial  us-east-1a
8        started  AAA.BBB.CCC.DD  i-06c25f726cfb48a37  xenial  us-east-1c

Relation           Provides               Consumes               Type
certificates       easyrsa                etcd                   regular
certificates       easyrsa                kubeapi-load-balancer  regular
certificates       easyrsa                kubernetes-master      regular
certificates       easyrsa                kubernetes-worker      regular
cluster            etcd                   etcd                   peer
etcd               etcd                   flannel                regular
etcd               etcd                   kubernetes-master      regular
cni                flannel                kubernetes-master      regular
cni                flannel                kubernetes-worker      regular
loadbalancer       kubeapi-load-balancer  kubernetes-master      regular
kube-api-endpoint  kubeapi-load-balancer  kubernetes-worker      regular
cni                kubernetes-master      flannel                subordinate
kube-control       kubernetes-master      kubernetes-worker      regular
cni                kubernetes-worker      flannel                subordinate

「Machine」がインスタンスに該当します。9個のインスタンスが立ち上がっていますが、これとは別にcontrollerモデルのほうにJujuコントローラーのインスタンスがいるため、全部で10個のインスタンスがいます。⁠DNS」「Public address」の部分は、ここではマスクしていますが実際にはインスタンスのアドレスが表示されています。また「Unit」を見ると、Kubernetesのワーカーノードやetcdは3つ存在することがわかります。

次にkubectlコマンドを使ってみましょう[5]⁠。

$ kubectl cluster-info
Kubernetes master is running at https://(Kubernetes APIのIPアドレス):443
Heapster is running at https://(Kubernetes APIのIPアドレス):443/api/v1/proxy/namespaces/kube-system/services/heapster
KubeDNS is running at https://(Kubernetes APIのIPアドレス):443/api/v1/proxy/namespaces/kube-system/services/kube-dns
kubernetes-dashboard is running at https://(Kubernetes APIのIPアドレス):443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard
Grafana is running at https://(Kubernetes APIのIPアドレス):443/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
InfluxDB is running at https://(Kubernetes APIのIPアドレス):443/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

「The Canonical Distribution of Kubernetes」ではKubernetes Dashboardが有効化されています。よって、上記の「kubernetes-dashboard」にアクセスするとDashboardが表示されます。

図10 Kubernetes Dashboard
画像

本来このDashboardはkubectl proxyでトンネルを構築して初めてアクセスできるはずなのですが、なぜか特に認証の必要なくアクセスできるようです。不安な場合は、次のコマンドでDashboard機能を無効化してしまいましょう。

$ juju config kubernetes-master enable-dashboard-addons=false

Kubernetesではコンテナを動かすためのホストを「Node⁠⁠、関連性の強いコンテナの集合を「Pod⁠⁠、Podによって提供されるサービスを「Service」と呼んでいます。現在のステートはそれぞれkubectl getコマンドで確認できます。

$ kubectl get nodes
NAME                STATUS    AGE       VERSION
ip-10-146-206-186   Ready     22h       v1.6.1
ip-10-180-49-180    Ready     22h       v1.6.1
ip-10-183-107-114   Ready     22h       v1.6.1
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
default-http-backend-x6f4f       1/1       Running   0          22h
nginx-ingress-controller-100lz   1/1       Running   0          22h
nginx-ingress-controller-8prr9   1/1       Running   0          22h
nginx-ingress-controller-vcmz7   1/1       Running   0          22h
$ kubectl get services
NAME                   CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
default-http-backend   10.152.183.176   <none>        80/TCP    22h
kubernetes             10.152.183.1     <none>        443/TCP   22h

前述したとおり、ワーカーノードが3つに、Nginx Ingress Controllerが3つ動いていますね。

Kubernetesでコンテナを立ち上げる

Kubernetes上にコンテナを立ち上げる場合も、kubectlコマンドを使います。コンテナを立ち上げる方法はいくつか存在しますが、ここでは既存のYAMLファイル(Pod)を利用することにしましょう。

KubernetesのソースコードexamplesディレクトリにはPodのサンプルがいくつも存在します。ここではシンプルなGuestbookをデプロイしましょう。Guestbookはその名の通り、サイトを訪れた人がコメントを残すサービスです。コメントのデータベースとしてRedisを、フロントエンドにはPHPを使用しています。Redisのマスターに1つとスレーブに2つ、フロントエンドに1つの計4つのコンテナが立ち上がります。

$ git clone https://github.com/kubernetes/kubernetes.git
$ cd kuernetes

コンテナの作成はkubectl createコマンドに、Podを渡すだけです。Guestbookには個々のサービスごとのPodとは別に、4つのコンテナをひとつにまとめたYAMLファイルもあります。今回はこちらを指定しましょう。

$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
service "redis-master" created
deployment "redis-master" created
service "redis-slave" created
deployment "redis-slave" created
service "frontend" created
deployment "frontend" created

ステータスを確認すると、PodやServiceがそれぞれ作られていることがわかります。

$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
default-http-backend-x6f4f       1/1       Running   0          3d
frontend-3823415956-0wvqq        1/1       Running   0          10s
frontend-3823415956-w2m23        1/1       Running   0          10s
frontend-3823415956-z9kb7        1/1       Running   0          10s
nginx-ingress-controller-100lz   1/1       Running   0          1d
nginx-ingress-controller-8prr9   1/1       Running   0          1d
nginx-ingress-controller-vcmz7   1/1       Running   0          1d
redis-master-1068406935-bhgdn    1/1       Running   0          13s
redis-slave-2005841000-37qtz     1/1       Running   0          12s
redis-slave-2005841000-jtvjx     1/1       Running   0          12s

$ kubectl get services
NAME                   CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
default-http-backend   10.152.183.176   <none>        80/TCP     2d
frontend               10.152.183.132   <none>        80/TCP     10s
kubernetes             10.152.183.1     <none>        443/TCP    2d
redis-master           10.152.183.235   <none>        6379/TCP   13s
redis-slave            10.152.183.222   <none>        6379/TCP   12s

ただしこのままだと外部からGuestbookサービスにアクセスできません。なぜならワーカーノードが動いているインスタンスの80番ポートをAWSが塞いでいますし、GuestbookのfrontendサービスもKubernetesのローカルなIPアドレスしか持っていないからです。そこで以下の対応を行う必要があります。

  • Jujuのコマンド経由でAWSのインスタンスのポートを開ける
  • ワーカーノードへのアクセスをfrontendサービスに転送する

その前に、ワーカーノードが動いているインスタンスにログインして、curlコマンドでfrontendサービスが動いているか確認してみましょう。Jujuで立ち上げたインスタンスへは、JujuのコマンドでSSHログインできます。ホスト名の代わりにjuju statusで表示されたUnit名を指定するだけです。

$ juju ssh kubernetes-worker/0
ubuntu@ip-10-183-107-114:~$ curl http://10.152.183.132/
<html ng-app="redis">
  <head>
    <title>Guestbook</title>
    <link rel="stylesheet" href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css">
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.12/angular.min.js"></script>
    <script src="controllers.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/angular-ui-bootstrap/0.13.0/ui-bootstrap-tpls.js"></script>
  </head>
  <body ng-controller="RedisCtrl">
    <div style="width: 50%; margin-left: 20px">
      <h2>Guestbook</h2>
    <form>
    <fieldset>
    <input ng-model="msg" placeholder="Messages" class="form-control" type="text" name="input"><br>
    <button type="button" class="btn btn-primary" ng-click="controller.onRedis()">Submit</button>
    </fieldset>
    </form>
    <div>
      <div ng-repeat="msg in messages track by $index">
        
      </div>
    </div>
    </div>
  </body>
</html>
ubuntu@ip-10-183-107-114:~$

kubectl get servicesコマンドのfrontendサービスのIPアドレスへとアクセスすれば、Guestbookが動いていることがわかります。

Jujuのコマンド経由でAWSのインスタンスのポートを開ける

AWSのインスタンスのポートは、Jujuのコマンドで開けられます。

$ juju expose kubernetes-worker

もちろんGCPやAzureであっても同様です。Jujuが各種パブリッククラウドのAPIを使用してうまくやってくれます。⁠kubernetes-worker」juju statusで表示されているアプリケーション名です。複数のインスタンスにスケールしている場合は、すべてのインスタンスに対して設定を反映します。また開くポートは、Unitsの「Ports」フィールドに記載されています。

公開状態のアプリケーションはNotesフィールドに「exposed」と表示されます。

$ juju show-status kubernetes-worker
Model                         Controller          Cloud/Region   Version
conjure-canonical-kubern-56a  conjure-up-aws-59b  aws/us-east-1  2.1.2

App                Version  Status  Scale  Charm              Store       Rev  OS      Notes
flannel            0.7.0    active      3  flannel            jujucharms   13  ubuntu
kubernetes-worker  1.6.1    active      3  kubernetes-worker  jujucharms   22  ubuntu  exposed
(後略)

ワーカーノードへのアクセスをfrontendサービスに転送する

ワーカーノードのポートをあけたら今度は、ワーカーノードへのアクセスをルーティングします。Kubernetesの場合はいくつかの方法がありますが、conjure-upではNginx Ingress Controllerが構築されています。これを使うことにしましょう。

Ingress Controllerでは、ルーティング設定をYAMLとして記述した上で、kubectlコマンドに渡します。たとえばgbook.example.comにアクセスした場合にGuestbookに転送したい場合は、次のような設定ファイルguestbook-ingress.yamlを作ります。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: guestbook-ingress
spec:
  rules:
  - host: gbook.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: frontend
          servicePort: 80

Nginx Ingress Controllerの場合は、Nginxが前段に存在するため、この設定がそのままNginxのプロキシ設定として変換され保存されるわけです。

$ kubectl create -f guestbook-ingress.yaml
$ kubectl get ingress
NAME                HOSTS              ADDRESS            PORTS     AGE
guestbook-ingress gbook.example.com 10.183.107.11... 80 11s

さらにDNSなどの設定で、gbook.example.comのAレコードにワーカーノードのIPアドレスを指定しておきましょう。juju status「Public address」がそれに該当します。

この状態でウェブブラウザーでgbook.example.comにアクセスすれば、Guestbookが表示されることでしょう。

図11 シンプルなコメントフォーム「Guestbook」
画像

コンテナにログインする

juju sshを使うとコンテナが動いているホスト(ワーカーノード)にログインできます。このホスト上ではDockerが動いていますので、dockerコマンドを使ってコンテナにログインしたり、情報を表示することが可能です。

さらにkubectl execを使うと、手作業でワーカーノードにログインしなくても直接コンテナの中にログインできます

$ kubectl exec Pod名 -it /bin/bash

Podが複数のコンテナから形成される場合は-cオプションでコンテナを指定してください。省略すると最初のコンテナが使われます。もちろんbash以外のコマンドを指定すれば、それが実行されます。

単純にコンテナのログを取得したいだけであれば、kubectl logsコマンドを使いましょう。

$ kubectl logs Pod名

kubectlには、公式のドキュメントにコマンドチートシートがあります。まずはこのドキュメントで概要を掴むと良いでしょう。

コンテナの削除

不要になったコンテナはkubectl deleteで削除できます。

$ kubectl delete -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml

kubectl delete pod Pod名kubectl delete service Service名などの指定方法も可能です。

不要になったIngress設定も同様に削除しておきましょう。

$ kubectl delete -f guestbook-ingress.yaml

他のホストでJuju/Kubernetesをコントロールするには

JujuやKubernetesのAPIにアクセスするための認証情報は、conjure-upを実行したホストのローカルディレクトリに保存されます。しかしながら、conjure-upを実行した環境とは別のホストでkubectlを実行したい場合もあるかもしれません。認証情報をバックアップする手段もありますが、いちばんお手軽なのは~/.local/share/juju/をそのままコピーしてしまうことです。もちろんこのディレクトリにはAWSのアクセスキーなども保存されていますので、コピーするにしても扱いには十分注意してください。

Jujuの認証情報をコピーした先でKubernetesの認証情報を復元するには、まずjujuコマンドをインストールします。これについても素直にconjure-upパッケージをインストールする方法がいちばん簡単でしょう。ついでにkubectlもインストールしておきましょう。

$ sudo snap install conjure-up --classic
$ sudo snap install kubectl --classic

あとはKubernetesの認証情報を、マスターノードから取得するだけです。

$ mkdir ~/.kube
$ juju scp kubernetes-master/0:config ~/.kube/config
$ kubectl cluster-info

ちなみに別のホストでkubectlを実行するだけであれば、~/.kube/configをコピーすれば十分です。

Juju GUIを利用する

JujuにはJuju GUIと呼ばれるウェブブラウザーベースの管理ツールも存在します。以前は独立したプロジェクトでしたが、Juju 2.0から本体に組み込まれるようになりました。

標準では無効化されていますが、次のコマンドを実行することで有効化されます。

$ juju gui
GUI 2.5.2 for model "admin/conjure-canonical-kubern-56a" is enabled at:
  https://juju.example.com:17070/gui/u/admin/conjure-canonical-kubern-56a
Your login credential is:
  username: admin
  password: (パスワード)

アドレスや認証情報が表示されますので、それに従ってアクセスしましょう。インスタンスのスケールをマウスで行いたい場合に便利です。Juju GUIの使い方については第307回も参照してください。

図12 Juju GUIの画面
画像

おすすめ記事

記事・ニュース一覧