CRI-O + Kata containers + Weavenetでkubernetesをインストールする


普段はCRIはDocker、OCIはrunc、CNIはcalicoで構成することが多いのだけど、たまには違う構成でもとってみようと思いインストールしてみる。 特にこれまでKata containersはさわったことなかったので。 OSはUbuntuを適当に入れた

Kataのインストール

https://github.com/kata-containers/documentation/blob/master/install/ubuntu-installation-guide.md

ARCH=$(arch)
BRANCH="${BRANCH:-master}"
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/home:/katacontainers:/releases:/${ARCH}:/${BRANCH}/xUbuntu_$(lsb_release -rs)/ /' > /etc/apt/sources.list.d/kata-containers.list"
curl -sL  http://download.opensuse.org/repositories/home:/katacontainers:/releases:/${ARCH}:/${BRANCH}/xUbuntu_$(lsb_release -rs)/Release.key | sudo apt-key add -
sudo -E apt-get update
sudo -E apt-get -y install kata-runtime kata-proxy kata-shim

CRI-Oのインストール

https://github.com/cri-o/cri-o#installing-cri-o

. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -

sudo apt-get update -qq
apt-get install -y cri-o-1.17
sudo systemctl enable crio

Ubuntuのパッケージは、1.18がまだ無いようなので1.17を利用した。

CRI-Oのランタイムの設定

https://github.com/kata-containers/documentation/blob/master/how-to/run-kata-with-k8s.md#cri-o

/etc/crio/crio.conf に書かれている設定を入れた。 デフォルトはruncのままにしてある。

[crio.runtime.runtimes.kata-runtime]
  runtime_path = "/usr/bin/kata-runtime"
  runtime_type = "oci"

kubernetesのインストール

kubeadmでインストール。

全ノードで

sudo modprobe overlay
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet=1.17.0-00 kubeadm=1.17.0-00 kubectl=1.17.0-00
sudo apt-mark hold kubelet kubeadm kubectl

cat <<EOF | sudo tee /etc/systemd/system/kubelet.service.d/0-crio.conf
[Service]
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --cgroup-driver=systemd --runtime-request-timeout=15m --container-runtime-endpoint=unix:///var/run/crio/crio.sock"
EOF
sudo systemctl daemon-reload
sudo systemctl restart kubelet

コントロールプレーンで以下を実行。

sudo kubeadm init --skip-preflight-checks --cri-socket /var/run/crio/crio.sock --pod-network-cidr=10.244.0.0/16

実行後には、joinコマンドが表示されるので、今度はそれを各ノードで実行する。もし、見逃してしまった場合は、以下のコマンドで再表示できる。

kubeadm token create --print-join-command

前に入れたときは、CNIプラグイン入れないとNodeの状態がREADYにならなかったはずなのに、 今回試したらNodeが参加した時点でREADYになってた。ランタイムが違うから?そんなことある?

とりあえず、WeaveNetをいれておく。

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

クラスタのテスト

OCIとして、runcを使うPodとkataを使うPodをデプロイしてみる

kubectl run hello-runc --image=gcr.io/google-samples/hello-app:1.0 --restart Never
cat <<EOF | kubectl apply -f -
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: kata
handler: kata-runtime
EOF
kubectl get pod hello-runc -o yaml > hello-kata.yaml

hello-kata.yamlを以下の通り編集

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: hello-kata
  name: hello-kata
spec:
  containers:
  - image: gcr.io/google-samples/hello-app:1.0
    imagePullPolicy: IfNotPresent
    name: hello-kata
  dnsPolicy: ClusterFirst
  restartPolicy: Never
  runtimeClassName: kata

これを流したんたけどPodが起動しない。eventを見てみると以下のようなログが。

Failed to create pod sandbox: rpc error: code = Unknown desc = container create failed: failed to launch qemu: exit status 1, error messages from qemu log: Could not access KVM kernel module: No such file or directory
qemu-vanilla-system-x86_64: failed to initialize kvm: No such file or directory

今回ESXi上の仮想マシンでやったのだけど、CPUの仮想化を有効にするの忘れてた。仮想マシンの設定変更から、 「CPU仮想化 ハードウェア アシストによる仮想化をゲストOSに公開」を有効にしたところ解決。

kubectl get pod -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP          NODE    NOMINATED NODE   READINESS GATES
hello-kata   1/1     Running   0          9h    10.32.0.2   node1   <none>           <none>
hello-runc   1/1     Running   0          9h    10.38.0.3   node2   <none>           <none>

無事に起動したっぽい。

動作を見比べる

うまいことnode1とnode2に分散してPodを動かしたので、通常のruncで動くパターンとkataで動くパターンのプロセス構成などを見てみる。

kata-runtime list

kataで動いているコンテナのリストは、 kata-runtime list で確認することができる。

  • Node1 (kata利用)
$ sudo kata-runtime list
ID                                                                 PID         STATUS      BU
NDLE                                                                                                                 CREATED                          OWNER
fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f   2850        running     /run/containers/storage/overlay-containers/fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f/userdata   2020-07-11T23:51:20.244499159Z   #0
4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c   3115        running     /run/containers/storage/overlay-containers/4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c/userdata   2020-07-11T23:51:26.190503017Z   #0
  • Node2 (runc利用)
$ sudo kata-runtime list
ID          PID         STATUS      BUNDLE      CREATED     OWNER

たしかに、Node1では動いているプロセスがいて、Node2にはいないことがわかる。 でも、なんで2つ? Podはひとつしか起動してないのに。

もう少しNode1側を詳しく見てみる。

$ sudo kata-runtime state fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f
{
  "ociVersion": "1.0.1-dev",
  "id": "fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f",
  "status": "running",
  "pid": 2850,
  "bundle": "/run/containers/storage/overlay-containers/fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f/userdata",
  "annotations": {
    "io.katacontainers.pkg.oci.bundle_path": "/run/containers/storage/overlay-containers/fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f/userdata",
    "io.katacontainers.pkg.oci.container_type": "pod_sandbox"
  }
}
$ sudo kata-runtime state 4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c
{
  "ociVersion": "1.0.1-dev",
  "id": "4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c",
  "status": "running",
  "pid": 3115,
  "bundle": "/run/containers/storage/overlay-containers/4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c/userdata",
  "annotations": {
    "io.katacontainers.pkg.oci.bundle_path": "/run/containers/storage/overlay-containers/4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c/userdata",
    "io.katacontainers.pkg.oci.container_type": "pod_container"
  }
}

コンテナタイプが違うのがわかる。公式のドキュメントのアーキテクチャのところを見ると、 pod_sandboxの中に、pod_containerがあるようだ。

https://github.com/kata-containers/documentation/blob/master/design/architecture.md

$ sudo kata-runtime exec 4fe1ddb9154cbfc14a7ca514e2705b91f54bfc9b89300c940ff1000b2f0bd17c ps
PID   USER     TIME   COMMAND
    1 root       0:00 ./hello-app
   28 root       0:00 ps
$ sudo kata-runtime exec fa157caa041230c1593ced717618dc2f96a80f4c0704b7d965421a8e95dc791f ps
rpc error: code = Internal desc = Could not run process: container_linux.go:349: starting container process caused "exec: \"ps\": executable file not found in $PATH"

pod_contaierの方で、期待するアプリが動いていることが確認できた。sandboxのほうは、shすら起動できなかったので、何が動いているんだろうか。

psの結果

プロセスツリーも見比べてみた。適当にプロセスは実際のものから削っている。

  • Node1 (kata利用)
systemd-+-2*[conmon-+-pause]
        |           `-{conmon}]
        |-conmon-+-kube-proxy---7*[{kube-proxy}]
        |        `-{conmon}
        |-conmon-+-kube-utils---8*[{kube-utils}]
        |        |-launch.sh---weaver---15*[{weaver}]
        |        `-{conmon}
        |-conmon-+-kata-proxy---8*[{kata-proxy}]
        |        |-kata-shim---8*[{kata-shim}]
        |        |-qemu-vanilla-sy---3*[{qemu-vanilla-sy}]
        |        `-{conmon}
        |-conmon-+-weave-npc-+-ulogd
        |        |           `-9*[{weave-npc}]
        |        `-{conmon}
        |-conmon-+-kata-shim---10*[{kata-shim}]
        |        `-{conmon}
        |-crio---14*[{crio}]
        |-kubelet---16*[{kubelet}]
        `-lxcfs---2*[{lxcfs}]
  • Node2 (runc利用)
systemd-+-3*[conmon-+-pause]
        |           `-{conmon}]
        |-conmon-+-kube-proxy---8*[{kube-proxy}]
        |        `-{conmon}
        |-conmon-+-kube-utils---8*[{kube-utils}]
        |        |-launch.sh---weaver---16*[{weaver}]
        |        `-{conmon}
        |-conmon-+-weave-npc-+-ulogd
        |        |           `-9*[{weave-npc}]
        |        `-{conmon}
        |-conmon-+-hello-app---3*[{hello-app}]
        |        `-{conmon}
        |-crio---14*[{crio}]
        |-kubelet---16*[{kubelet}]
        `-lxcfs---2*[{lxcfs}]

見比べてみると、たしかにruncだと目的のhello-appが直接動いているのに対して、 kataの場合は、hello-appは直接ホストから見えない。 kata-shimで隠蔽されていて、隔離された環境で動いていることがわかる。

まとめ

Kata Containersは、これまで安全にコンテナ実行するために使う、ぐらいしか聞いておらず どういう風に動くのかよくわかっていなかったが、今回構築してみてその動きが理解できた。 構築も、ドキュメントによって書いてあること違ったりでいくつかトラブルところもあったが、 だいたいログ見たらどこがあやしいかわかるし、それほど苦労することはなかった。 1枚噛んでるレイヤが増えるので、性能面とリソースのオーバーヘッドが気になるので、今後その辺見てみたい。


See also

comments powered by Disqus