gVisor和KataContainers怎么使用

本篇內容介紹了“gVisor和KataContainers怎么使用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

目前的容器技術仍然有許多廣為人知的安全挑戰，其中一個主要的問題是，從單一共享內核獲得效率和性能意味著容器逃逸可能成為一個漏洞。

所以在 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"
    }
  }
}
EOF

systemctl daemon-reload
systemctl restart docker

運行一個容器，可以看到顯示的內核版本和宿主機是不一樣的：

root@cr7-ubuntu:~# docker run busybox uname -a

Kubernetes使用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"]
EOF

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"
EOF

systemctl daemon-reload 
systemctl restart kubelet

kubernetes創建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: 80

gVisor

相比之下，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"
        }
    }
}
EOF

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"]
EOF

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"
EOF

systemctl daemon-reload 
systemctl restart kubelet

kubeadm 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怎么使用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！