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

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デプロイをする方法について書きます。

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

以下の記事でMicroK8sをインストールしてみたので、MicroK8s上でアプリケーションを動かしてみたいと思います。

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

  • docker.ioのコンテナイメージを実行する
  • オリジナルコンテナイメージを実行する
    • docker registryを構築する
    • docker registryにオリジナルコンテナイメージを登録する
    • オリジナルコンテナイメージを実行する

docker.ioのコンテナイメージを実行する


最初にdocker.ioのコンテナイメージからアプリケーションを実行します。

以下のコマンドで、ベースイメージbusyboxを使って”Hello World”を出力するPodを作成します。

root@microk8s-vm:~# microk8s kubectl run hello --restart=Never --image=busybox -- echo "Hello World"

確認してみると、以下のように”Hello World”を出力していることがわかります。

root@microk8s-vm:~# microk8s kubectl get pods
NAME    READY   STATUS      RESTARTS   AGE
hello   0/1     Completed   0          65s
root@microk8s-vm:~# microk8s kubectl logs hello
Hello World

ということで、kubernetesと全く同じようにアプリケーションを実行できることが確認できました。

オリジナルコンテナイメージを実行する


次に自身で作成したオリジナルコンテナイメージを以下の構成でMicroK8sで動かします。

docker registryを構築する


以下のコマンドでdocker registryコンテナを作成します。今回は永続ボリュームは付与しません。

root@microk8s-vm:~# microk8s.kubectl run registry --image=registry --port=5000
pod/registry created
root@microk8s-vm:~# microk8s.kubectl get pods
NAME       READY   STATUS      RESTARTS   AGE
hello      0/1     Completed   0          6h56m
registry   1/1     Running     0          93s

作成したら、MacPCからアクセスできるようにNodePortで公開します。

root@microk8s-vm:~# microk8s.kubectl expose pod registry --type=NodePort --name=registry-service
service/registry-service exposed
root@microk8s-vm:~# microk8s.kubectl get svc
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes         ClusterIP   10.152.183.1    <none>        443/TCP          20h
registry-service   NodePort    10.152.183.23   <none>        5000:32147/TCP   8s

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


構築したdocker registryにオリジナルコンテナイメージを登録します。オリジナルコンテナイメージは、golangでcssファイルを読み込むで作成したwebコンテナイメージを利用します。

ifconfigコマンドでmultipassのVM IPアドレスを調べて、~/.docker/daemon.jsonに以下の内容を追記します。ポート番号はNodePortで公開したポートです。

"insecure-registries":["192.168.64.2:32147"]

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

$ docker push 192.168.64.2:32147/web
The push refers to repository [192.168.64.2:32147/web]
aa26d6c54ca2: Pushed 
51b5da98010b: Pushed 
6510ca638cc9: Pushed 
6e69dbdef94b: Pushed 
f0c38edb3fff: Pushed 
ef234633eec2: Pushed 
8967306e673e: Pushed 
9794a3b3ed45: Pushed 
5f77a51ade6a: Pushed 
e40d297cf5f8: Pushed 
latest: digest: sha256:860250e45f5851832e2c7632b3e6e1b2c7b89319fdd521bc99262baad6b992cc size: 2421

オリジナルコンテナイメージを実行する


以下のコマンドで登録したオリジナルコンテナイメージを実行します。

root@microk8s-vm:~# microk8s.kubectl run web --image=localhost:32147/web --port=8080 --insecure-skip-tls-verify
pod/web created
root@microk8s-vm:~# microk8s.kubectl get pods
NAME       READY   STATUS      RESTARTS   AGE
hello      0/1     Completed   0          7h28m
registry   1/1     Running     0          33m
web        1/1     Running     0          6s

NodePortで公開し、Mac PCからアクセスできるようにします。

root@microk8s-vm:~# microk8s.kubectl expose pod web --type=NodePort --name=web
service/web exposed
root@microk8s-vm:~# microk8s.kubectl get svc
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes         ClusterIP   10.152.183.1    <none>        443/TCP          20h
registry-service   NodePort    10.152.183.23   <none>        5000:32147/TCP   26m
web                NodePort    10.152.183.60   <none>        8080:30162/TCP   29s

192.168.64.2:30162でアクセスしたところ、以下の画面になりました。

冷静に考えると、バックエンドのsearcherとdbを動かしてなかったので、エラーになってました。。。もっと早く気づくべきだった。。

# microk8s.kubectl logs web
2020/06/07 13:19:35 http: panic serving 10.1.2.1:51940: runtime error: invalid memory address or nil pointer dereference
goroutine 18 [running]:
net/http.(*conn).serve.func1(0xc000096000)
    /usr/local/go/src/net/http/server.go:1772 +0x139
panic(0x7993a0, 0xb09820)
    /usr/local/go/src/runtime/panic.go:975 +0x3e3
main.glob..func1(0x890ac0, 0xc0000c0000, 0xc0000a0300)
    /go/src/web/main.go:36 +0xc6
net/http.HandlerFunc.ServeHTTP(0x81cc60, 0x890ac0, 0xc0000c0000, 0xc0000a0300)
    /usr/local/go/src/net/http/server.go:2012 +0x44
net/http.(*ServeMux).ServeHTTP(0xb19820, 0x890ac0, 0xc0000c0000, 0xc0000a0300)
    /usr/local/go/src/net/http/server.go:2387 +0x1a5
net/http.serverHandler.ServeHTTP(0xc000136000, 0x890ac0, 0xc0000c0000, 0xc0000a0300)
    /usr/local/go/src/net/http/server.go:2807 +0xa3
net/http.(*conn).serve(0xc000096000, 0x891440, 0xc00009c000)
    /usr/local/go/src/net/http/server.go:1895 +0x86c
created by net/http.(*Server).Serve
    /usr/local/go/src/net/http/server.go:2933 +0x35c

まぁ、今回はKubernetesと同じように動かせることが分かっただけで良しとします。

中途半端になってしまいましたが、以上です!

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

最近MicroK8sがMacに対応されたので、インストールしてみたいと思います。

Canonicalの軽量Kubernetes「MicroK8s」がWindowsとMacに対応。インストーラーで簡単に導入可能に

  • MicroK8sとは
  • MicroK8sをMacにインストールする

MicroK8sとは


MicroK8sとは、ワークステーションやエッジデバイスで実行できる軽量Kubernetesです。必要なパッケージやライブラリが一つのスナップとして提供されているため、インストールが簡単です。ただし、シングルノードでのみ稼働するなど制約はあります。

Linuxで稼働しますが、WindosとMacでは仮想ソフトウェアで専用のLinux仮想マシンを起動して稼働します。

MicroK8sをMacにインストールする


以下のリンク先を参考に、インストールします。

https://ubuntu.com/tutorials/install-microk8s-on-mac-os#1-overview

Homebrewをインストールする


以下のコマンドでhomebrewをインストールします。私は既にインストール済みなので、スキップします。

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

MicroK8sの前提パッケージをインストールする


まずは以下のコマンドで前提パッケージをインストールします。

$ brew install ubuntu/microk8s/microk8s

インストールしたところ、以下のエラーが発生しました。Xcodeのバージョンが古いみたいです。

Error: Your Xcode (10.0) is too outdated.
Please update to Xcode 11.3.1 (or delete it).
Xcode can be updated from the App Store.

Error: Xcode alone is not sufficient on Mojave.
Install the Command Line Tools:
  xcode-select --install

私のMacOSはバージョンがMojaveで、Xcodeのバージョンアップができなかったため、一度MacOSのバージョンをCatalina(10.15.5)にしてXcodeのバージョンを11.5にしました。

再度実行すると、以下のエラーが表示されます。

Error: You have not agreed to the Xcode license. Please resolve this by running:
  sudo xcodebuild -license accept

促されているコマンドをそのまま実行して解消しました。

$ sudo xcodebuild -license accept

改めて以下のコマンドを実行します。今度はエラーなしに完了しました。

$ brew install ubuntu/microk8s/microk8s

MicroK8sをインストールする


以下のコマンドでmicrok8sをインストールします。

$ microk8s install
VM disk size requested exceeds free space on host.
Support for 'multipass' needs to be set up. Would you like to do that it now? [y/N]: y
Updating Homebrew...
==> Tapping homebrew/cask
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 443429 (delta 16), reused 0 (delta 0), pack-reused 443394
Receiving objects: 100% (443429/443429), 200.17 MiB | 1.50 MiB/s, done.
Resolving deltas: 100% (314065/314065), done.
Tapped 1 command and 3570 casks (3,687 files, 214.8MB).
==> Downloading https://github.com/CanonicalLtd/multipass/releases/download/v1.2.1/multipass-1.2.1+mac-Darwin.pkg
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/114128199/fcb43c80-861f-11ea-90e8-08d13101e315?X-Am
######################################################################## 100.0%
==> Verifying SHA-256 checksum for Cask 'multipass'.
==> Installing Cask multipass
==> Creating Caskroom at /usr/local/Caskroom
==> We'll set permissions properly so we won't need sudo in the future.
Password:
==> Running installer for multipass; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
installer: Package name is multipass
installer: Installing at base path /
installer: The install was successful.
🍺  multipass was successfully installed!
Waiting for multipass...
Launched: microk8s-vm                                                           
2020-06-07T01:23:36+09:00 INFO Waiting for restart...
microk8s (latest/stable) v1.18.2 from Canonical✓ installed
MicroK8s is up and running. See the available commands with `microk8s --help`.

これでインストールが完了しました。kubectlコマンドを実行したら動きました。

$ microk8s kubectl get nodes
NAME          STATUS   ROLES    AGE    VERSION
microk8s-vm   Ready    <none>   4m9s   v1.18.2-41+b5cdb79a4060a3

ちなみにmicrok8sを止めるときは以下のコマンドを実行します。

$ microk8s stop
Stopped.

 

以上です。なんて簡単なんでしょうか。。。

KubeVirtとは?従来仮想基盤の代わりになるのか??

先日OpenShift4.4が発表され、OpenShift Virtualizationの機能がテックプレビューで追加されました。OpenShift Virtualizationは、Virtual Machine(VM)をOpenShift上で操作する機能です。こちらの動画ではOpenShift上にWindows VMを起動しています。

「OpenShift Virtualizationによって従来の仮想基盤は不要になるのか?」という疑問を抱いたため、ベースの技術であるKubeVirtについて調査しました。KubeVirtを紐解くことで、OpenShift Virtualizationを知る近道になるはず。

  • KubeVirtとは?
    • KubeVirtの概要
      • 従来仮想基盤との違い
      • コンテナとの違い
    • KubeVirtの構成
  • KubeVirtのメリット/デメリットは?
    • コンテナと比較したメリット
    • コンテナと比較したデメリット
    • 従来の仮想基盤と比較したメリット
    • 従来の仮想基盤と比較したデメリット
  • KubeVirtは従来の仮想基盤の代わりになるのか?

KubeVirtとは?


KubeVirtの概要


KubeVirtは、Kubernetes上でVMをコンテナとして操作するインタフェースです。Kubernetes上でVMを従来通り動かすのが目的ではなく、コンテナ化が難しい従来のVMをKubernete上のワークロードに適用しやすくすることが目的で作られました。

従来仮想基盤との違い


図の通りKubernetes上でVMがコンテナとして動きます。

従来の仮想基盤と大きく異なる点は、VMがKubernetesのワークロードとして稼働する点です。従って、スケジューリングやHWリソースの割り当ての方法が大きく変わります。レプリカセットやサービスなどのリソースと組み合わせて使うことができるようになる一方で、これまでのHWリソース割り当てができなくなる可能性があります。改修が必要なVMアプリケーションも今後出てくることが考えられます。

コンテナとの違い


コンテナと大きく異なる点は、イメージです。通常コンテナイメージでコンテナアプリケーションを実行しますが、KubeVirtではVMイメージから実行します。

ちなみにKubeVirtがサポートするイメージは現状以下のみになります。コンテナが再起動する度にデータが削除されてしまうので、通常はPVCにイメージを書き込んでディスクから起動します。

  • .img
  • .iso
  • .qcow2
  • 上記イメージの圧縮ファイル( .tar, .gz,  .xz )

引用元)https://kubevirt.io/user-guide/#/installation/image-upload

KubeVirtは、コンテナの中でlibvirtdがVMのライフサイクルを管理しています。だからこそVMのイメージでアプリケーションが起動しますし、コンテナなのに起動・停止・再起動ができるのです。

KubeVirtの構成


KubeVirtの構成についても調査しました。KubeVirtをデプロイすると以下のコンポーネントが配置されます。

  •  
    • virt-controller

VMのPodを作成します。kubeletによってPodがスケジュールされると、virt-handlerにCRDであるVM情報を連携します。

    • virt-handler

CRDであるVM情報が更新されたことを検知すると、そのVM情報をvirt-launcherに指示します。

    • virt-launcher

virt-handlerからCRDであるVM情報を受け取ると、それを基にlibvirtdを介してVMを起動します。

    • libvirtd

VMライフサイクルを管理します。

KubeVirtのメリット/デメリットとは?


思いつくメリット/デメリットを書き出してみました。もちろんこれ以外にもあると思いますので、参考程度に読んでいただければ幸いです。

コンテナと比較したメリット


サーバー型アプリケーションのコンテナ化が容易

サーバー型アプリケーションのコンテナ化が容易であることが挙げられます。これは1番の強みと言っても過言ではないと思います。
サーバー型アプリケーションをコンテナ化するには、必要なファイルを洗い出してベースイメージの仕様に合わせる必要があります。更には、アプリケーションやジョブクライアントなど、仕様を大きく変更しなければならない箇所も多く出てきます。一方、KubeVirtはサーバーイメージからOSごとコンテナ化できますので、そういった作業を比較的少なくすることができます。

アプリケーションがカーネルを共有しない

カーネルを共有しないという点もメリットとして挙げられます。厳密に言えば共有していますが、アプリケーションが直接利用するカーネルを他のアプリケーションが利用することがありません。
カーネルを独占することによってセキュリティをコンテナよりも担保し易くなるというメリットがあります。

VMの起動・停止・ライブマーグレーションが可能

メリットになるか賛否両論あると思いますが、コンテナなのに起動・停止・再起動・ライブマイグレーションが可能であることで、アプリケーションによってはメリットになると思います。

コンテナと比較したデメリット


資源効率が悪い

資源効率が悪いということがデメリットとして挙げられます。コンテナは必要最低限のモジュールのみインストールすればアプリケーションが実行できます。それと比較すると、KubeVirtはOSのイメージを利用するため、容量を多く使います。更にVMの数が増えるほど、VM間におけるOSモジュールの重複や不要なOSモジュールが増えてしまいます。このような観点でコンテナと比較すると資源効率は悪いです。

従来の仮想基盤と比較したメリット


複製・自動化が容易

複製・自動化が容易であることがメリットとして挙げられます。Kubernetes上でコンテナとして動くので、HPAやReplicaSetのようなリソースを使って運用の自動化ができます。

開発スピードの向上

開発スピードの向上が期待できます。これまで開発者はシステム管理者にサーバー作成を依頼していました。VMアプリケーションを開発者が自律的に作成できるようになるため、そのリードタイムを短縮できます。

VMとコンテナの連携が容易

Kubernetes上のコンテナとVMの連携が容易であることも挙げられます。通常のVMだと当然ながらKubernetesの外にいます。従って、コンテナと通信するにはコンテナを外部に公開する設定が必要でした。更にはKubernetes内で定義した名前をVMで扱うことができませんでした。Kubernetes内にVMを構築できることで、これらの考慮が不要になり、コンテナとの連携が比較的容易になります。

従来の仮想基盤と比較したデメリット


OSの設定変更が煩雑

KubeVirtでVMデプロイ後にOSの設定を変更しても、障害などで再作成された時に設定が消えてしまいます。設定変更にはイメージを編集し、VMを再度起動する必要があります。Immutableな性質によるメリットの裏返しです。但し、これは永続ボリュームを使うことで回避できますのでデメリットにはならないことが多いです。

KubeVirtは従来の仮想基盤の代わりになるのか?


結論から言うと、単純なマイグレーションつまり従来と同じ用途では代替ツールにはならないと思います。VMのライフサイクルがKubernetesで管理されるので、今までと作成方法や管理方法が異なります。様々な管理が自動化できる一方で、従来仮想基盤でできたことができなくなることも今後見つかってくると思います。だからこそ、今までと同じと考えるのは非常に危険です。

繰り返しになりますが、KubeVirtは従来の仮想基盤の代わりを目指している訳ではありません。従来のワークロードにImmutableな性質を持たせ、よりスケーラブルで柔軟なシステムにすることを目的としています。従来の仮想基盤から移行する場合は、運用の発想も大きく変える必要があるということがわかりました。