「Istio」カテゴリーアーカイブ

Istio使ってURLパス単位でリクエスト処理を分けてみる

Istioを使ってURLパス単位で、コンテナアプリケーションを割り振ってみます。

  • コンテナアプリケーションを作成する
    • ソースコードを作成する
    • helloaコンテナイメージを作成する
    • hellobコンテナイメージを作成する
  • コンテナアプリケーションを実行する
  • Istioの設定をする
    • Gatewayを作成する
    • VirtualServiceを作成する
  • 設定を確認する

コンテナアプリケーションを作成する


Istioの割り振り先コンテナアプリケーションを作成します。

今回作成するのは、httpリクエストをポート8080で受け付けると以下の振る舞いを行うアプリケーションです。

    • / ・・・”Hello A” or “Hello B”を表示する
    • /hello ・・・”Hello A” or “Hello B”を表示する

ソースコードを作成する


コンテナアプリケーションで使うソースコードをgolangで作成します。

main.goを以下に示します。マックスハンドラを使って、URL毎に使うhtmlファイルを分けています。

package main

import (
    "log"
    "net/http"
    "html/template"
    "fmt"
)

func main() {
    //index関数をルートディレクトリに指定
    http.HandleFunc("/", index)
    //hello関数をルートディレクトリに指定
    http.HandleFunc("/hello", hello)
    //サーバー起動
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal("ListenAndServe:", nil)
    }
}

func index(writer http.ResponseWriter, r *http.Request) {
  generateHTML(writer, "index")
}

func hello(writer http.ResponseWriter, r *http.Request) {
  generateHTML(writer, "hello")
}

func generateHTML(writer http.ResponseWriter, filenames ...string) {
    var files []string
    for _, file := range filenames {
        files = append(files, fmt.Sprintf("templates/%s.html", file))
    }

    templates := template.Must(template.ParseFiles(files...))
  templates.Execute(writer, nil)
}

main.goを実行するコンテナをビルドするためのDockerfileを以下に示します。

FROM golang:latest

# コンテナ作業ディレクトリの変更
WORKDIR /go/src/web
# ホストOSの ./src の中身を作業ディレクトリにコピー
COPY ./src .
RUN go build -o web
# ウェブアプリケーション実行コマンドの実行
CMD ["./web"]

ディレクトリ構造は以下の通りです。index.htmlとhello.htmlはhelloa, hellobアプリケーション毎に作成します。

$ tree .
.
├── Dockerfile
└── src
    ├── main.go
    └── templates
        ├── hello.html
        └── index.html

helloaコンテナイメージを作成する


httpリクエストを受け付けると”Hello A”を表示するhelloaコンテナイメージを作成します。

以下のコマンドを使って、”Hello A”を表示するindex.htmlとhello.htmlを作成します。

$ echo "Hello A" > index.html
$ echo "Hello A" > hello.html

以下のコマンドでコンテナイメージをビルドして、docker registryに登録します。このdocker registryはMicroK8s上にコンテナとして動いています。docker registryの起動方法は、MicroK8sでアプリケーションを動かすを参考にしてください。

$ docker build -t helloa:latest .
$ docker tag helloa 192.168.64.2:32147/helloa
$ docker push 192.168.64.2:32147/helloa

hellobコンテナイメージを作成する


httpリクエストを受け付けると”Hello B”を表示するhelloaコンテナイメージを作成します。

以下のコマンドを使って、”Hello B”を表示するindex.htmlとhello.htmlを作成します。

$ echo "Hello B" > templates/index.html 
$ echo "Hello B" > templates/hello.html

以下のコマンドでコンテナイメージをビルドして、docker registryに登録します。

$ docker build -t hellob:latest .
$ docker tag hellob 192.168.64.2:32147/hellob
$ docker push 192.168.64.2:32147/hellob

コンテナアプリケーションを実行する


作成したコンテナイメージからコンテナアプリケーションを実行します。

以下のコマンドを使って、Injection済みのnamespaceにhelloaとhellobを実行し、サービスを公開します。Injectionの方法は、Microk8sでIstioによるABテストを試してみる(1/2)を参照してください。

ubuntu@microk8s-vm:~$ microk8s.kubectl run helloa --image=localhost:32147/helloa:latest --port=8080 -n istio-app
pod/helloa created
ubuntu@microk8s-vm:~$ microk8s.kubectl run hellob --image=localhost:32147/hellob:latest --port=8080 -n istio-app
pod/hellob created
ubuntu@microk8s-vm:~$ microk8s.kubectl expose pod helloa --port=8080 -n istio-app
service/helloa exposed
ubuntu@microk8s-vm:~$ microk8s.kubectl expose pod hellob --port=8080 -n istio-app
service/hellob exposed

Istioの設定をする


Gatewayを作成する


全てのホスト名をポート80で受け付けるIstioのGatewayを作成します。

yamlファイルを以下に示します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hello-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

以下のコマンドでgatewayリソースを作成します。

ubuntu@microk8s-vm:~$ microk8s.kubectl apply -f gateway.yaml -n istio-app

VirtualServiceを作成する


/helloのリクエストはhellobに、それ以外はhelloaに割り振るVirtualServiceを作成します。

VirtualService全体のyamlファイルを以下に示します。match.uri.prefixを使うことでURL毎に割り振り先を変更できます。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-switch-url-route
spec:
  hosts:
  - "*"
  gateways:
  - hello-gateway
  http:
  - match:
    - uri:
        prefix: /hello
    route:
    - destination:
        host: hellob
        port:
          number: 8080
  - route:
    - destination:
        host: helloa
        port:
          number: 8080

設定を確認する


以下のcurlコマンドを利用して確認すると、正しくルーティングされていることがわかります。192.168.64.2:31380はIstio Ingressgatewayの公開Serviceで、[multipass-vmのIP]:[NodePort]です。IngressgatewayをNodePortにする方法は、MicroK8sでIstioによるABテストを試してみる(2/2)を参照してください。

$ curl -s http://192.168.64.2:31380/
Hello A
$ curl -s http://192.168.64.2:31380/hello
Hello B

 

以上です。ページなどモジュール単位で分けるようなシステムには使えそうですね!

IstioのSubsetでバージョン毎に流量制御を行う

以下の記事でIstioによる流量制御を行いました。しかし、本来ABテストというのはバージョン毎に流量制御を行うことが多いので、Subsetを使って異なるバージョンのコンテナアプリケーションに対して行います。

MicroK8sでistioによるABテストを試してみる(1/2)
MicroK8sでistioによるABテストを試してみる(2/2)

  • コンテナイメージを用意する
    • v1コンテナイメージの作成
    • v2コンテナイメージの作成
  • コンテナアプリケーションをデプロイする
    • v1 Deploymentを作成する
    • v2 Deploymentを作成する
    • Serviceを作成する
  • Istioの設定を行う
    • VirtualServiceを作成する
    • DestinationRuleを作成する
  • 設定を確認する

コンテナイメージを用意する


以下の記事で作成したhelloaを使ってコンテナイメージを作成します。

MicroK8sでistioによるABテストを試してみる(1/2)

v1コンテナイメージの作成


以下のコマンドで、v1タグのhelloaイメージを作成し、レジストリに登録します。

$ docker build -t helloa:v1 helloA/
$ docker tag helloa:v1 192.168.64.2:32147/helloa:v1
$ docker push 192.168.64.2:32147/helloa:v1

v2コンテナイメージの作成


httpリクエストを受け付けたら”Hello A v2″を表示されるように、以下のコマンドでhtmlファイルを編集します。

$ echo "Hello A v2" > helloA/src/templates/index.html 

以下のコマンドで、v2タグのhelloaをイメージを作成してレジストリに登録します。

$ docker build -t helloa:v2 helloA/
$ docker tag helloa:v2 192.168.64.2:32147/helloa:v2
$ docker push 192.168.64.2:32147/helloa:v2

コンテナアプリケーションをデプロイする


v1 Deploymentを作成する


以下のファイルを使って$ microk8s.kubectl create -f [ファイル名]を実行し、helloa-v1 Deploymentを作成します。hello-v1は、タグv1のhelloaから実行されるPodを管理します。

重要なのは、version: v1 ラベルが付与されていることです。このラベルをSubsetとして使い、流量制御を行うことになります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloa-v1
  labels:
    app: helloa
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloa
      version: v1
  template:
    metadata:
      labels:
        app: helloa
        version: v1
    spec:
      containers:
      - name: helloa 
        image: localhost:32147/helloa:v1 
        ports:
        - containerPort: 8080

v2 Deploymentを作成する


同じように、以下のファイルを使って$ microk8s.kubectl create -f [ファイル名]を実行し、helloa-v2 Deploymentを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloa-v2
  labels:
    app: helloa
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloa
      version: v2
  template:
    metadata:
      labels:
        app: helloa
        version: v2
    spec:
      containers:
      - name: helloa 
        image: localhost:32147/helloa:v2 
        ports:
        - containerPort: 8080

Serviceを作成する


以下のファイルを使って$ microk8s.kubectl create -f [ファイル名]を実行し、helloa-v1/v2 DeploymentのPodをエンドポイントとするServiceを作成します。

apiVersion: v1
kind: Service
metadata:
  name: helloa
  labels:
    app: helloa
    service: helloa
spec:
  ports:
  - port: 8080
    name: http
  selector:
    app: helloa

Istioの設定を行う


Istioの設定を行い、流量制御をします。Ingressgatewayについては、以下の記事で作成したものがあるのを前提に行います。

MicroK8sでistioによるABテストを試してみる(1/2)

VirtualServiceを作成する


バージョン毎に流量制御を行うVirtualServiceを作成します。

Subset v2に25%、Subset v1に75%の通信を割り振るhello-ab-route VirtualServiceを作成します。

以下のファイルを使って$ microk8s.kubectl create -f [ファイル名]を実行します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-ab-route
spec:
  hosts:
  - hello.example.com
  gateways:
  - hello-gateway
  http:
  - route:
    - destination:
        host: helloa
        subset: v2
        port: 
          number: 8080
      weight: 25
    - destination:
        host: helloa
        subset: v1
        port: 
          number: 8080
      weight: 75

DestinationRuleを作成する


Subsetを使う場合に必要となるDestinationRuleを作成します。

以下はhelloaのSubsetをversionラベルで区別しています。この定義によってラベルによる通信制御が行えます。

以下のファイルを使って$ microk8s.kubectl create -f [ファイル名]を実行します。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: helloa-destination-rule
spec:
  host: helloa
subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

設定を確認する


以下のコマンドで、helloaに対して10回httpリクエストを行って設定を確認します。

$ for i in {0..9};do curl -s -HHost:hello.example.com "http://192.168.64.2:31380"; done

しかし、以下のエラーが出てしまいました。

upstream connect error or disconnect/reset before headers. reset reason: connection termination

mutual TLSを有効にしている場合は、DestinationRuleにおけるtlsのモードをISTIO_MUTUALにする必要があるそうです。従って、DestinationRuleのyamlを以下に編集し、$ microk8s.kubectl apply -f [ファイル名]を実行する必要がありました。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: helloa-destination-role
spec:
  host: helloa
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

改めて実行したところ、うまく流量制御が行えていました。

[walker:~/Desktop/hello]$ for i in {0..9};do curl -s -HHost:hello.example.com "http://192.168.64.2:31380"; done
Hello A
Hello A
Hello A
Hello A
Hello A v2
Hello A
Hello A
Hello A v2
Hello A
Hello A v2

せっかくなのでKialiで見てみたところ、実際にリクエストがきた通信をパーセント表示しているので定義した値と多少異なりますが、近い値が出ています。

以上です!

Jeagerって何?

Jeagerの概要を調査したので、記事を描いてみました。

  • 分散トレーシング
    • 分散トレーシングとは
    • SpanとTraceの関係
    • Propagation
  •  Jeager
    • Jeagerとは 
    • Jeagerを操作してみる 

分散トレーシング


分散トレーシングとは


分散トレーシングとは、マイクロサービスのような分散されたシステムにおいて、障害の検知や原因特定を迅速化するために考えられた、サービス間通信の監視を行う概念です。

SpanとTraceの関係


分散トレーシングの基本概念であるSpanとTraceの関係について以下に示します。

  • Span・・・サービス単位の処理
  • Trace・・・任意のリクエストにおけるSpanの集合体

Propagation


分散トレーシングでは、Span同士でメタデータを伝播(Propagation)させています。以下のように、HttpヘッダーにSpanのメタデータを埋め込み、Spanの関係を把握しています。

参照元)https://github.com/openzipkin/b3-propagation#overall-process

Jeager


Jeagerとは


分散トレーシングを体現したツールは、Zipkin、Hawkularなど様々あります。Jeagerはその中の一つで、Uber社がGo言語で開発した分散トレーシングシステムです。

CNCFにホストされたのがきっかけで、分散トレーシングシステムの代表例でもあります。IstioをOperatorでインストールする場合は、Jeagerも一緒にインストールすることができ、Operatorによって構成されます。

アーキテクチャは以下の通りです。jeager-clientが取得したログをjeager-agentを経由してjeager-collectorが受け取り、DBにログを保管します。ユーザーはGUIを通して、このDBを参照することができます。

参照元)https://www.jaegertracing.io/docs/1.8/architecture/

Jeagerを操作してみる 


以下の記事で、MicroK8sにIstioをインストールした時に、一緒にインストールされていたJeagerを使って簡単に確認したいと思います。

MicroK8sでistioによるABテストを試してみる(1/2)
MicroK8sでistioによるABテストを試してみる(2/2)

アクセスするとこんな画面でした。キャラクターが可愛い件について。

適当に検索してみると、トレースログ毎に発生日時とレスポンスタイムのグラフに表示されていました。また、それぞれのトレースログの詳細が確認できますし、トレースログ同士を比較する機能までついていました。

トレースログをクリックすると、上で説明したようなTraceとSpanが確認できました。

Httpリクエストヘッダーも確認することができました。

右上の「Trace Timeline」を「Trace Graph」に変更すると、以下のように依存関係が確認できました。

以上です。本当に概要だけですが、参考になれば幸いです。

MicroK8sでKialiを使ってみる

以下の記事でMicroK8sにIstioを使ってABテストを実施しました。Kialiを使って発生した通信をGUIで確認してみましたので投稿します。

MicroK8sでistioによるABテストを試してみる(1/2)
MicroK8sでistioによるABテストを試してみる(2/2)

  • Kialiにログインする
    • Kiali Serviceの設定を変更する
    • Kialiのログインユーザーとパスワードを確認する
    • Kialiにログインする
  • KialiでGraphを確認する
    • 正常な状態でGraphを確認する
    • helloaを通信不可な状態にして確認する

Kialiにログインする


MicroK8sでIstioをデプロイすると、Kialiも一緒にデプロイされます。ここではそのKialiにログインします。

Kiali Serviceの設定を変更する


KialiはGUIで表示されるので、ローカルPCからブラウザでアクセスする必要があります。従って、KialiのServiceを公開する必要があります。(通常$ microk8s istioctl dashboard kialiでブラウザが開くはずなのですが、私はエラーで開ませんでした。)

以下のコマンドでKialiのServiceのタイプをNodePortにします。spec.typeをClusterIPからNodePortにするだけで変更できます。

ubuntu@microk8s-vm:~$ microk8s.kubectl get svc -n istio-system
NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
kiali                    ClusterIP   10.152.183.201   <none>        20001/TCP       2d1h
ubuntu@microk8s-vm:~$ microk8s.kubectl edit svc kiali -n istio-system
service/kiali edited
ubuntu@microk8s-vm:~$ microk8s.kubectl get svc kiali -n istio-system
NAME    TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
kiali   NodePort   10.152.183.201   <none>        20001:31793/TCP   2d1h

Kialiのログインユーザーとパスワードを確認する


Kialiの初期ユーザーと初期パスワードがわからなかったので、以下のコマンドで確認しました。結果、admin/adminでした。

$ microk8s kubectl get secret kiali -n istio-system -o json | jq -r '.data.username' | base64 --decode
$ microk8s kubectl get secret kiali -n istio-system -o json | jq -r '.data.passphrase' | base64 --decode

Kialiにログインする


http://[multipass-vmのIPアドレス]:[NodePortの公開ポート]/kiali/にアクセスすると、以下の画面が表示されるので、admin/adminを入力して「Log in」ボタンをクリックします。

KialiでGraphを確認する


正常な状態でGraphを確認する


左の「Graph」タブをクリックし、まずは正常な状態でGraphを確認します。

以下のように、ServiceとPodがバラバラな状態になっていました。

以下のコマンドで100回httpリクエストを行うと、正しく通信経路が表示されました。

$ for i in {0..99}; do curl -s -HHost:hello.example.com "http://192.168.64.2:31380"; done

左上のプルダウンメニューより、「No edge labels」を「Requests percentage」に変更すると、以下のように流動制御を行う割合が表示されました。

左上のプルダウンメニューより、「Requests percentage」を「Response time」に変更すると、以下のように通信経路ごとのレスポンスタイムが表示されました。

helloaを通信不可な状態にして確認する


コンテナが異常だった場合の表示も見てみたいと思います。

以下のコマンドでhelloa Podを削除します。

ubuntu@microk8s-vm:~$ microk8s.kubectl delete pod helloa -n istio-app

以下のyamlファイルから$ microk8s.kubectl create -f [ファイル名]でPodを作成します。readinessProbeを定義していて、/tmp/healthyが存在しない間は閉局します。

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: helloa
  name: helloa
spec:
  containers:
  - image: localhost:32147/helloa
    name: helloa
    ports:
    - containerPort: 8080
    resources: {}
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

閉局するといってもPodは存在しますので、envoyコンテナが起動していて、helloaコンテナが起動していない状態になります。

ubuntu@microk8s-vm:~$ microk8s.kubectl get pods -n istio-app
NAME     READY   STATUS    RESTARTS   AGE
helloa   1/2     Running   0          47m
hellob   2/2     Running   0          83m

この状態で再度以下のコマンドを実行します。

$ for i in {0..99}; do curl -s -HHost:hello.example.com "http://192.168.64.2:31380"; done

100回は大分時間かかるので、途中でキャンセルしても大丈夫です。完了後にGUIを確認すると以下の画面になりました。helloaコンテナへのhttpリクエストが失敗した割合が分かりやすく表示されていました。右側には失敗したステータスコードも確認できるようになっていました。

以上です。2つ程度では価値が伝わりにくいですが、マイクロサービスなどコンテナの数が膨大になればなるほど貴重になるツールなので、皆様も是非お試しあれ。

MicroK8sでIstioによるABテストを試してみる(2/2)

本記事は以下の続きです。Istioを使って流量制御を行います。

MicroK8sでistioによるABテストを試してみる(1/2)

  • アプリケーションのServiceを作成する
  • Istioの設定をする
    • Istio Ingressgatewayの設定を変更する
    • Gatewayを作成する
    • Virtual Serviceを作成する
  • 設定を確認する

アプリケーションのServiceを作成する


MicroK8sでistioによるABテストを試してみる(1/2)で作成したアプリケーションに、helloa, hellobで名前解決できるServiceを付与します。

ubuntu@microk8s-vm:~$ microk8s.kubectl expose pod helloa --name=helloa --port=8080 -n istio-app
service/helloa exposed
ubuntu@microk8s-vm:~$ microk8s.kubectl expose pod hellob --name=hellob --port=8080 -n istio-app
service/hellob exposed
ubuntu@microk8s-vm:~$ microk8s.kubectl get svc -n istio-app
NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
helloa   ClusterIP   10.152.183.63    <none>        8080/TCP         7m23s
hellob   ClusterIP   10.152.183.36    <none>        8080/TCP         7m11s

Istioの設定をする


Istio Ingressgatewayの設定を変更する


Istio Ingressgatewayの設定を変更します。

Istio IngressgatewayはIstioで構成されたアプリケーションの入り口となるServiceです。istio-system namespaceで稼働していて、Service TypeがLoadBalancerです。IngressIPを設定できる場合はLoadBalancerIPとして設定すれば問題ありませんが、MicroK8sはデフォルトでは使えないのでNodePortに変更しておきます。

この設定は、Istioのドキュメントにも記載があります。

以下のコマンドでspec.typeをLoadBalancerからNodePortに変更します。

ubuntu@microk8s-vm:~$ microk8s.kubectl edit svc istio-ingressgateway -n istio-system

Gatewayを作成する


IstioでGatewayを作成します。

Gatewayは、サービスメッシュのエッジで動作するロードバランサーで、http/tcp接続を受信します。Istioで構成されたアプリケーションを外部に公開するには、Ingressgatewayに加えてGatewayが必要になります。

https://istio.io/docs/reference/config/networking/gateway/

ホスト名”hello.example.comyaml”に対して、httpプロトコルを受け付けるhello-gatewayのyamlを以下に示します。このyamlをoc create -f [ファイル名]で作成します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hello-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "hello.example.com"

Virtual Serviceを作成する


IstioでVirtual Serviceを作成します。

Virtual Serviceはトラフィックルーティングを制御して、Istioで構成されたアプリケーションの振る舞いを変えられます。

https://istio.io/docs/reference/config/networking/virtual-service/

hello.example.comへのhttpリクエストに対して、helloa Serviceに25%、hellob Serviceに75%のトラフィックをルーティングするhello-ab-route Virtual Serviceのyamlを以下に示します。こちらもoc create -f [ファイル名]で作成します。

spec.http.route.destination.hostでServiceを指定し、weightでルーティングするトラフィックの割合を定義しています。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-ab-route
spec:
  hosts:
  - hello.example.com
  gateways:
  - hello-gateway
  http:
  - route:
    - destination:
        host: helloa
        port: 
          number: 8080
      weight: 25
    - destination:
        host: hellob
        port: 
          number: 8080
      weight: 75

設定を確認する


最後に設定した流動制御を確認します。

設定したホスト名hello.exapmle.comに対して、Istio Ingressgatewayを経由するcurlコマンドを10回実行してみます。補足すると、Gatewayとして指定している192.168.64.2:31380は、[multipass-vmのIPアドレス]:[NodePortで80番を公開しているポート]です。

$ for i in {0..9}; do curl -s -HHost:hello.example.com "http://192.168.64.2:31380"; done
Hello B
Hello A
Hello B
Hello A
Hello B
Hello B
Hello B
Hello A
Hello B
Hello B

これは綺麗に7:3ぐらいの割合で出力されていますが、何度も繰り返すと、10:0の時もありました。但し、Hello AがHello Bの回数を越すということはなかったので、正しくルーティングされていることが伺えました。

以上です!全体を通して考えると、MicroK8s特有の部分はインストールのところだけでしたね。Istioの勉強をしてみたいと思っていたので、いい機会になりました。

MicroK8sでIstioによるABテストを試してみる(1/2)

以下の記事でMicroK8sをインストールしてみたので、IstioをインストールしてABテストを試します。今回は長くなってしまったので、インストール編とABテスト編に分けてお送りします。

MicroK8sをMacOSにインストールしてみる

  • Istioをインストールする
  • Istio Injection用のnamespaceを作成する
  • テスト用アプリケーションを実行する
    • アプリケーションソースコードを作成する
    • コンテナイメージを作成する
    • コンテナイメージをdocker registryに登録する
    • コンテナアプリケーションを実行する

Istioをインストールする


以下のコマンドでMicroK8sにIstioをインストールします。Istioを有効化するだけで必要なyamlをダウンロードしてリソースを作成します。

ubuntu@microk8s-vm:~$ microk8s.status | grep istio
istio: disabled
ubuntu@microk8s-vm:~$ microk8s enable istio
Enabling Istio
Fetching istioctl version v1.3.4.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   635  100   635    0     0    444      0  0:00:01  0:00:01 --:--:--   444
100 36.3M  100 36.3M    0     0  2553k      0  0:00:14  0:00:14 --:--:-- 5118k
・
・
省略
・
・
Istio is starting
ubuntu@microk8s-vm:~$ microk8s.status | grep istio
istio: enabled

インストール完了後、istio-systemというnamespaceに色んなpodがデプロイされていました。

ubuntu@microk8s-vm:~$ microk8s.kubectl get ns
NAME              STATUS   AGE
default           Active   43h
istio-system      Active   119s
kube-node-lease   Active   43h
kube-public       Active   43h
kube-system       Active   43h
ubuntu@microk8s-vm:~$ microk8s.kubectl get pods -n istio-system 
NAME                                      READY   STATUS      RESTARTS   AGE
grafana-78758665bb-tbdn8                  1/1     Running     0          7m4s
istio-citadel-799bf7ddb9-hlzjw            1/1     Running     0          7m3s
istio-egressgateway-76d7cf9c58-dlwnx      1/1     Running     0          7m4s
istio-galley-54cb4b4bcd-ptcmx             1/1     Running     0          7m5s
istio-grafana-post-install-1.3.4-hcbgl    0/1     Completed   0          7m6s
istio-ingressgateway-785cd6c5cc-lj7md     1/1     Running     0          7m4s
istio-pilot-5fdd79bcb5-rzfmn              2/2     Running     0          7m3s
istio-policy-7dc9dbf6bc-jrvht             2/2     Running     5          7m4s
istio-security-post-install-1.3.4-bhctr   0/1     Completed   0          7m6s
istio-sidecar-injector-66bc6cf76b-rc868   1/1     Running     0          7m2s
istio-telemetry-66786bfd8f-km8jh          2/2     Running     5          7m3s
istio-tracing-6cb4f885d4-275sq            1/1     Running     0          7m2s
kiali-68d8fc4d54-66s7r                    1/1     Running     0          7m4s
prometheus-5c8fb8f746-m8kc8               1/1     Running     0          7m3s

Istio Injection用のnamespaceを作成する


以下のコマンドでIstio Injection用のnamespaceを作成します。

このnamespace上にデプロイされたpodは、Envoyがサイドカーとして一緒にデプロイされるようになります。

ubuntu@microk8s-vm:~$ microk8s.kubectl create ns istio-app
namespace/istio-app created
ubuntu@microk8s-vm:~$ microk8s.kubectl label ns istio-app istio-injection=enabled
namespace/istio-app labeled
ubuntu@microk8s-vm:~$ microk8s.kubectl get ns -L istio-injection
NAME              STATUS   AGE   ISTIO-INJECTION
default           Active   43h   
istio-app         Active   53s   enabled
istio-system      Active   10m   disabled
kube-node-lease   Active   43h   
kube-public       Active   43h   
kube-system       Active   43h   
ubuntu@microk8s-vm:~$

テスト用アプリケーションを実行する


アプリケーションソースコードを作成する


明日はABテストを試してみる予定なので、二つのGoアプリケーションを作成します。httpリクエストをするとそれぞれ”Hello A”, “Hello B”と表示する簡単なサンプルアプリケーションです。

階層構造は以下の通りです。

$ tree hello
hello
├── helloA
│   ├── Dockerfile
│   └── src
│       ├── main.go
│       └── templates
│           └── index.html
└── helloB
    ├── Dockerfile
    └── src
        ├── main.go
        └── templates
            └── index.html

ポート8080を受け付けるとindex.htmlを表示するmain.goを以下に示します。これはhelloA, helloB共に同じです。

package main

import (
    "log"
    "net/http"
)

func main() {
    //templatesフォルダ配下を読み込む
    http.Handle("/", http.FileServer(http.Dir("templates")))
    //サーバー起動
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal("ListenAndServe:", nil)
    }
}

helloAのindex.htmlは以下の通りです。

Hello A

helloBのindex.htmlは以下の通りです。

Hello B

helloA, helloB共通のDockerfileは以下の通りです。

FROM golang:latest

# コンテナ作業ディレクトリの変更
WORKDIR /go/src/web
# ホストOSの ./src の中身を作業ディレクトリにコピー
COPY ./src .
RUN go build -o web
# ウェブアプリケーション実行コマンドの実行
CMD ["./web"]

コンテナイメージを作成する


以下のコマンドでそれぞれのコンテナイメージを作成します。

$ docker build -t hellob:latest helloA/
$ docker build -t hellob:latest helloB/

コンテナイメージをdocker registryに登録する


コンテナイメージをMicroK8s上で動かすにはdocker registryに一度登録します。登録方法は以下の記事をご参照ください。

MicroK8sでアプリケーションを動かす

以下のコマンドでdocker registryに登録します。

$ docker tag helloa 192.168.64.2:32147/helloa
$ docker tag hellob 192.168.64.2:32147/hellob
$ docker push 192.168.64.2:32147/helloa
The push refers to repository [192.168.64.2:32147/helloa]
8b8cbdb9bcec: Pushed 
0b5b80fff15e: Pushed 
6510ca638cc9: Pushed 
6e69dbdef94b: Pushed 
f0c38edb3fff: Pushed 
ef234633eec2: Pushed 
8967306e673e: Pushed 
9794a3b3ed45: Pushed 
5f77a51ade6a: Pushed 
e40d297cf5f8: Pushed 
latest: digest: sha256:f55138ac329f19a2602f1059a1e62b3b3915b256f42938cb19aadd5e24b9567a size: 2421
$ docker push 192.168.64.2:32147/hellob
The push refers to repository [192.168.64.2:32147/hellob]
475d9ae2ebee: Pushed 
c4f195275b83: Pushed 
6510ca638cc9: Layer already exists 
6e69dbdef94b: Layer already exists 
f0c38edb3fff: Layer already exists 
ef234633eec2: Layer already exists 
8967306e673e: Layer already exists 
9794a3b3ed45: Layer already exists 
5f77a51ade6a: Layer already exists 
e40d297cf5f8: Layer already exists 
latest: digest: sha256:e625cd9ac7996901c3b74ff463ee58a7187fbb456f2ea136a482d0ea86c2756a size: 2421

コンテナアプリケーションを実行する


以下のコマンドで、Istio Injection用のnamespaceにサンプルアプリケーションをデプロイします。

ubuntu@microk8s-vm:~$ microk8s.kubectl run helloa --image=localhost:32147/helloa --port=8080 -n istio-app
pod/helloa created
ubuntu@microk8s-vm:~$ microk8s.kubectl run hellob --image=localhost:32147/hellob --port=8080 -n istio-app
pod/hellob created

デプロイした後にpodを確認するとコンテナの数が二つになっています。これはIstioのEnvoyがpodの中で一緒に稼働しているからです。

ubuntu@microk8s-vm:~$ microk8s.kubectl get pods -n istio-app
NAME     READY   STATUS    RESTARTS   AGE
helloa   2/2     Running   0          22s
hellob   2/2     Running   0          10s

今日は以上です!明日は実際にIstioを設定してABデプロイをする方法について書きます。