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

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

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

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

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

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

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

體驗

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

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

我們創(chuàng)建一個Minikube虛擬機環(huán)境，注意需要指明?--container-runtime=containerd?參數(shù)設(shè)置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 用作后備存儲庫。正在創(chuàng)建 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 已經(jīng)配置至 "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...

部署測試應(yīng)用

我們通過Pod部署一個nginx應(yīng)用

$ 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?狀態(tài)的時候，可以部署gvisor測試應(yīng)用。

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

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

$ 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

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

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

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

使用ctl和crictl工具

我們現(xiàn)在可以進入進入Minikube虛擬機

$ minikube ssh

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

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

在Kubernetes環(huán)境更加簡單的方式是利用?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的關(guān)系

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

但是Docker Engine包含了更多的開發(fā)者工具鏈，比如鏡像構(gòu)建。也包含了Docker自己的日志、存儲、網(wǎng)絡(luò)、Swarm編排等能力。此外，絕大多數(shù)容器生態(tài)廠商，如安全、監(jiān)控、開發(fā)等對Docker Engine的支持比較完善，對containerd的支持也在逐漸補齊。

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

阿里云容器服務(wù)對containerd的支持

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

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

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。