共計 5511 個字符，預計需要花費 14 分鐘才能閱讀完成。
本篇內容介紹了“gVisor 和 KataContainers 怎么使用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
目前的容器技術仍然有許多廣為人知的安全挑戰，其中一個主要的問題是，從單一共享內核獲得效率和性能意味著容器逃逸可能成為一個漏洞。
所以在 2015 年，幾乎在同一個星期，Intel OTC（Open Source Technology Center）和國內的 HyperHQ 團隊同時開源了兩個基于虛擬化技術的容器實現，分別叫做 Intel Clear Container 和 runV 項目。而在 2017 年，借著 Kubernetes 的東風，這兩個相似的容器運行時項目在中立基金會的撮合下最終合并，就成了現在大家耳熟能詳的 Kata Containers 項目。由于 Kata Containers 的本質就是一個精簡后的輕量級虛擬機，所以它的特點，就是“像虛擬機一樣安全，像容器一樣敏捷”。
2018 年，Google 公司則發布了一個名叫 gVisor 的項目。gVisor 項目給容器進程配置一個用 Go 語言實現的、運行在用戶態的、極小的“獨立內核”。這個內核對容器進程暴露 Linux 內核 ABI，扮演著“Guest Kernel”的角色，從而達到了將容器和宿主機隔離開的目的。
KataContainers
首先，我們來看 KataContainers。它的工作原理可以用如下所示的示意圖來描述。
Kata Containers 的本質，就是一個輕量化虛擬機。所以當你啟動一個 Kata Containers 之后，你其實就會看到一個正常的虛擬機在運行。這也就意味著，一個標準的虛擬機管理程序（Virtual Machine Manager, VMM）是運行 Kata Containers 必備的一個組件。在我們上面圖中，使用的 VMM 就是 Qemu。
Docker 使用 KataContainers
首先節點需要支持以下四種任意一種 cpu 虛擬化技術：
Intel VT-x technology
ARM Hyp mode
IBM Power Systems
IBM Z manframes 如果部署在 VMware 虛擬機中，需要在宿主機開啟嵌套虛擬化的功能，開啟步驟見鏈接：https://blog.51cto.com/11434894/2389180?source=dra
安裝 kataContainer:
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設置 docker 配置文件：
cat /etc/docker/daemon.json EOF
default-runtime : kata-runtime ,
runtimes : {
kata-runtime : {
path : /usr/bin/kata-runtime
}
}
systemctl daemon-reload
systemctl restart docker運行一個容器，可以看到顯示的內核版本和宿主機是不一樣的：
root@cr7-ubuntu:~# docker run busybox uname -aKubernetes 使用 kataContainer
配置 containerd 使用 kataContainer：
cat /etc/containerd/config.toml EOF
disabled_plugins = [restart]
[plugins.linux]
shim_debug = true
[plugins.cri.containerd.runtimes.kata] #kata 這個名字可以自己定義，和 runtimeClass 指定的名字要一樣
runtime_type = io.containerd.kata.v2
[plugins.cri.registry.mirrors. docker.io]
endpoint = [https://frz7i079.mirror.aliyuncs.com]
systemctl daemon-reload
systemctl restart containerd配置 kubelet 使用 containerd 作為容器運行時：
cat /etc/systemd/system/kubelet.service.d/0-cri-containerd.conf EOF
[Service]
Environment= KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m -- container-runtime-endpoint=unix:///run/containerd/containerd.sock
systemctl daemon-reload
systemctl restart kubeletkubernetes 創建 runtimeClass:
apiVersion: node.k8s.io/v1beta1 # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
name: kata
handler: kata # 這里與 containerd 配置文件中的 [plugins.cri.containerd.runtimes.{handler}] 匹配 創建 pod：
apiVersion: v1
kind: Pod
metadata:
name: kata-nginx
spec:
runtimeClassName: kata
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80gVisor
相比之下，gVisor 的設計其實要更加“激進”一些。它的原理，可以用如下所示的示意圖來表示清楚。
gVisor 工作的核心，在于它為應用進程、也就是用戶容器，啟動了一個名叫 Sentry 的進程。而 Sentry 進程的主要職責，就是提供一個傳統的操作系統內核的能力，即：運行用戶程序，執行系統調用。所以說，Sentry 并不是使用 Go 語言重新實現了一個完整的 Linux 內核，而只是一個對應用進程“冒充”內核的系統組件。
Docker 使用 gVisor
查看原本的 runtime:
root@cr7-ubuntu:~# docker info
Runtimes: runc
Default Runtime: runc
...安裝 gVisor:
(
set -e
ARCH=$(uname -m)
URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
wget ${URL}/runsc ${URL}/runsc.sha512 \
${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
sha512sum -c runsc.sha512 \
-c containerd-shim-runsc-v1.sha512
rm -f *.sha512
chmod a+rx runsc containerd-shim-runsc-v1
sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin
)設置 docker 配置文件：
cat /etc/docker/daemon.json EOF
registry-mirrors : [https://frz7i079.mirror.aliyuncs.com],
runtimes : {
gvisor : { # 這個名字可以自己制定，docker run 的時候 --runtime 使用
path : /usr/local/bin/runsc
}
}
systemctl daemon-reload
systemctl restart docker查看此時的 runtime:
root@cr7-ubuntu:~# docker info
Runtimes: runc gvisor
Default Runtime: runc
...運行 gvisor 為 runtime 的容器：
docker run -itd --name web1 --runtime=gvisor nginx在宿主機上是看不到這個進程的，如果是 runc 的容器是能看到進程的：
root@cr7-ubuntu:~/gvisor# ps -ef | grep nginx | grep -v grep
#沒有輸出 Kubernetes 使用 gVisor
配置 containerd 使用 gvisor：
cat /etc/containerd/config.toml EOF
disabled_plugins = [restart]
[plugins.linux]
shim_debug = true
[plugins.cri.containerd.runtimes.gvisor] #gvisor 這個名字可以自己定義，和 runtimeClass 指定的名字要一樣
runtime_type = io.containerd.runsc.v1
[plugins.cri.registry.mirrors. docker.io]
endpoint = [https://frz7i079.mirror.aliyuncs.com]
systemctl restart containerd配置 crictl 使用 containerd 作為作為容器運行時:
runtime-endpoint: unix:///var/run/containerd/containerd.sock
image-endpoint:
timeout: 0
debug: false配置 kubelet 使用 containerd 作為容器運行時：
cat /var/lib/kubelet/kubeadm-flags.env EOF
KUBELET_KUBEADM_ARGS= --network-plugin=cni --pod-infra-container- image=registry.aliyuncs.com/google_containers/pause:3.2 --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock
systemctl daemon-reload
systemctl restart kubeletkubeadm join 將 node 加入 kubernetes 集群，master 使用 docker 作為容器運行時，node 使用 containerd 作為容器運行時。
創建 runtimeClass:
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: gvisor
handler: gvisor # 對應 CRI 配置的名稱 創建 pod 使用 gvisor 作為 runtime：
apiVersion: v1
kind: Pod
metadata:
name: nginx-gvisor
spec:
runtimeClassName: gvisor
containers:
- name: nginx
image: nginx
nodeName: cks3對比
在性能上，KataContainers 和 KVM 實現的 gVisor 基本不分伯仲，在啟動速度和占用資源上，基于用戶態內核的 gVisor 還略勝一籌。但是，對于系統調用密集的應用，比如重 I/O 或者重網絡的應用，gVisor 就會因為需要頻繁攔截系統調用而出現性能急劇下降的情況。此外，gVisor 由于要自己使用 Sentry 去模擬一個 Linux 內核，所以它能支持的系統調用是有限的，只是 Linux 系統調用的一個子集。
“gVisor 和 KataContainers 怎么使用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！
