containerd是一個開源的行業標準容器運行時，關注于簡單、穩定和可移植，同時支持Linux和Windows。2016年12月14日，Docker公司宣布將Docker Engine的核心組件 containerd 捐贈到一個新的開源社區獨立發展和運營。阿里云，AWS， Google，IBM和Microsoft作為初始成員，共同建設 containerd 社區。2017年3月，Docker 將 containerd 捐獻給CNCF（云原生計算基金會）。containerd得到了快速的發展和廣泛的支持。Docker引擎已經將containerd作為容器生命周期管理的基礎，Kubernetes也在2018年5月，正式支持containerd作為容器運行時管理器。2019年2月，CNCF宣布containerd畢業，成為生產可用的項目。

containerd 從1.1版本開始就已經內置了Container Runtime Interface (CRI) 支持，進一步簡化了對Kubernetes的支持。其架構圖如下：

在Kubernetes場景下，containerd與完整Docker Engine相比，具有更少的資源占用和更快的啟動速度。

紅帽主導的cri-o是與containerd競爭的容器運行時管理項目。containerd與cri-o項目相比，在性能上具備優勢，在社區支持上也更加廣泛。

更重要的是containerd提供了靈活的擴展機制，支持各種符合OCI（Open Container Initiative）的容器運行時實現，比如runc容器（也是熟知的Docker容器），KataContainer, gVisor和Firecraker等安全沙箱容器。

在Kubernetes環境中，可以用不同的API和命令行工具來管理容器/Pod，鏡像等概念。為了便于大家理解，我們可以用下圖說明如何利用不同層次的API和CLI管理容器生命周期管理。

• Kubectl：是集群層面的命令行工具，支持Kubernetes的基本概念
• crictl：是針對節點上CRI的命令行工具，文檔
• ctr：是針對containerd的命令行工具，文檔

體驗

Minikube是體驗containerd作為Kubernetes容器運行時的最簡單方式，我們下面將將其作為Kubernetes容器運行時，并支持runc和gvisor兩種不同的實現。

早期由于網絡訪問原因，很多朋友無法直接使用官方Minikube進行實驗。在最新的Minikube 1.5版本中，已經提供了完善的配置化的方式，可以幫助大家利用阿里云的鏡像地址來獲取所需Docker鏡像和配置，同時支持Docker/Containerd等不同容器運行時。

我們創建一個Minikube虛擬機環境，注意需要指明?--container-runtime=containerd?參數設置containerd作為容器運行時。同時registry-mirror也要替換成自己的阿里云鏡像加速地址。

$ minikube start --image-mirror-country cn \--iso-url=https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.5.0.iso \--registry-mirror=https://XXX.mirror.aliyuncs.com \--container-runtime=containerdDarwin 10.14.6 上的 minikube v1.5.0Automatically selected the 'hyperkit' driver (alternates: [virtualbox]) ? 您所在位置的已知存儲庫都無法訪問。正在將 registry.cn-hangzhou.aliyuncs.com/google_containers 用作后備存儲庫。正在創建 hyperkit 虛擬機（CPUs=2，Memory=2000MB, Disk=20000MB）... ? VM is unable to connect to the selected image repository: command failed: curl -sS https://k8s.gcr.io/ stdout: stderr: curl: (7) Failed to connect to k8s.gcr.io port 443: Connection timed out : Process exited with status 7正在 containerd 1.2.8 中準備 Kubernetes v1.16.2…拉取鏡像 ...正在啟動 Kubernetes ... ? Waiting for: apiserver etcd scheduler controller完成！kubectl 已經配置至 "minikube"$ minikube dashboardVerifying dashboard health ...Launching proxy ...Verifying proxy health ...Opening http://127.0.0.1:54438/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...

部署測試應用

我們通過Pod部署一個nginx應用

$ cat nginx.yaml apiVersion: v1 kind: Pod metadata:name: nginx spec:containers:- name: nginximage: nginx$ kubectl apply -f nginx.yaml pod/nginx created$ kubectl exec nginx -- uname -a Linux nginx 4.19.76 #1 SMP Fri Oct 25 16:07:41 PDT 2019 x86_64 GNU/Linux

然后，我們開啟 minikube 對 gvisor 支持

$ minikube addons enable gvisorgvisor was successfully enabled$ kubectl get pod,runtimeclass gvisor -n kube-system NAME READY STATUS RESTARTS AGE pod/gvisor 1/1 Running 0 60mNAME CREATED AT runtimeclass.node.k8s.io/gvisor 2019-10-27T01:40:45Z$ kubectl get runtimeClass NAME CREATED AT gvisor 2019-10-27T01:40:45Z

當?gvisor?pod進入?Running?狀態的時候，可以部署gvisor測試應用。

我們可以看到K8s集群中已經注冊了一個gvisor的“runtimeClassName“。

之后，開發者可以通過在Pod聲明中的 ”runtimeClassName“來選擇不同類型的容器運行時實現。比如，如下我們創建一個運行在 gvisor 沙箱容器中的 nginx 應用。

$ cat nginx-untrusted.yaml apiVersion: v1 kind: Pod metadata:name: nginx-untrusted spec:runtimeClassName: gvisorcontainers:- name: nginximage: nginx$ kubectl delete -f nginx-untrusted.yaml pod/nginx-untrusted created$ kubectl exec nginx-untrusted -- uname -a Linux nginx-untrusted 4.4 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux

我們可以清楚地發現：由于基于runc的容器與宿主機共享操作系統內核，runc容器中查看到的OS內核版本與Minikube宿主機OS內核版本相同。而gvisor的runsc容器采用了獨立內核，它和Minikube宿主機OS內核版本不同。

正是因為每個沙箱容器擁有獨立的內核，減小了安全攻擊面，具備更好的安全隔離特性。適合隔離不可信的應用，或者多租戶場景。

注意：gvisor在minikube中，通過ptrace對內核調用進行攔截，其性能損耗較大。此外gvisor的兼容性還有待增強。

使用ctl和crictl工具

我們現在可以進入進入Minikube虛擬機

$ minikube ssh

containerd支持通過名空間對容器資源進行隔離，查看現有 containerd 名空間

$ sudo ctr namespaces ls NAME LABELS k8s.io # 列出所有容器鏡像 $ sudo ctr --namespace=k8s.io images ls ...# 列出所有容器列表 $ sudo ctr --namespace=k8s.io containers ls

在Kubernetes環境更加簡單的方式是利用?crictl?對pods進行操作

# 查看pod列表 $ sudo crictl pods POD ID CREATED STATE NAME NAMESPACE ATTEMPT 78bd560a70327 3 hours ago Ready nginx-untrusted default 0 94817393744fd 3 hours ago Ready nginx default 0 ...# 查看名稱包含nginx的pod的詳細信息 $ sudo crictl pods --name nginx -v ID: 78bd560a70327f14077c441aa40da7e7ad52835100795a0fa9e5668f41760288 Name: nginx-untrusted UID: dda218b1-d72e-4028-909d-55674fd99ea0 Namespace: default Status: Ready Created: 2019-10-27 02:40:02.660884453 +0000 UTC Labels:io.kubernetes.pod.name -> nginx-untrustedio.kubernetes.pod.namespace -> defaultio.kubernetes.pod.uid -> dda218b1-d72e-4028-909d-55674fd99ea0 Annotations:kubectl.kubernetes.io/last-applied-configuration -> {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx-untrusted","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx"}],"runtimeClassName":"gvisor"}}kubernetes.io/config.seen -> 2019-10-27T02:40:00.675588392Zkubernetes.io/config.source -> apiID: 94817393744fd18b72212a00132a61c6cc08e031afe7b5295edafd3518032f9f Name: nginx UID: bfcf51de-c921-4a9a-a60a-09faab1906c4 Namespace: default Status: Ready Created: 2019-10-27 02:38:19.724289298 +0000 UTC Labels:io.kubernetes.pod.name -> nginxio.kubernetes.pod.namespace -> defaultio.kubernetes.pod.uid -> bfcf51de-c921-4a9a-a60a-09faab1906c4 Annotations:kubectl.kubernetes.io/last-applied-configuration -> {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"containers":[{"image":"nginx","name":"nginx"}]}}kubernetes.io/config.seen -> 2019-10-27T02:38:18.206096389Zkubernetes.io/config.source -> api

containerd與Docker的關系

很多同學都關心containerd與Docker的關系，以及是否containerd可以取代Docker？
containerd已經成為容器運行時的主流實現，也得到了Docker社區和Kubernetes社區的大力支持。Docker Engine底層的容器生命周期管理也是基于containerd實現。

但是Docker Engine包含了更多的開發者工具鏈，比如鏡像構建。也包含了Docker自己的日志、存儲、網絡、Swarm編排等能力。此外，絕大多數容器生態廠商，如安全、監控、開發等對Docker Engine的支持比較完善，對containerd的支持也在逐漸補齊。

所以在Kubernetes運行時環境，對安全和效率和定制化更加關注的用戶可以選擇containerd作為容器運行時環境。對于大多數開發者，繼續使用Docker Engine作為容器運行時也是一個不錯的選擇。

阿里云容器服務對containerd的支持

在阿里云Kubernetes服務ACK，我們已經采用containerd作為容器運行時管理，來支撐安全沙箱容器和runc容器的混合部署。在現有產品中，我們和阿里云操作系統團隊、螞蟻金服一起支持了基于輕量虛擬化的runV沙箱容器，4Q也將和操作系統團隊、安全團隊合作發布基于Intel SGX的可信加密沙箱容器。

和Serverless Kubernetes（ASK）中，我們也利用containerd靈活的插件機制定制和剪裁了面向nodeless環境的容器運行時實現。

阿里云雙11億元補貼提前領，進入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的containerd与安全沙箱的Kubernetes初体验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。