containerd與安全沙箱的Kubernetes初體驗

時間 2019-11-05

原文原文鏈接

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畢業，成爲生產可用的項目。html

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

在Kubernetes場景下，containerd與完整Docker Engine相比，具備更少的資源佔用和更快的啓動速度。
nginx

來源 containerdgit

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

來源 ebay的分享api

更重要的是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等不一樣容器運行時。app

咱們建立一個Minikube虛擬機環境，詳細信息能夠參考 https://yq.aliyun.com/articles/221687 ,注意須要指明 --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=containerd
?  Darwin 10.14.6 上的 minikube v1.5.0
  Automatically 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 dashboard
?  Verifying 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: nginx
    image: 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 gvisor
  gvisor was successfully enabled

$ kubectl get pod,runtimeclass gvisor -n kube-system
NAME         READY   STATUS    RESTARTS   AGE
pod/gvisor   1/1     Running   0          60m

NAME                              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: gvisor
  containers:
  - name: nginx
    image: 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-untrusted
    io.kubernetes.pod.namespace -> default
    io.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.675588392Z
    kubernetes.io/config.source -> api

ID: 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 -> nginx
    io.kubernetes.pod.namespace -> default
    io.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.206096389Z
    kubernetes.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做爲容器運行時也是一個不錯的選擇。