containerd与安全沙箱的Kubernetes初体验

时间  2019-11-05
标签 containerd 安全 kubernetes 体验 栏目 系统安全 繁體版
原文   原文链接

15721732905416.jpg
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

15624000803382.jpg
在Kubernetes场景下，containerd与完整Docker Engine相比，具备更少的资源占用和更快的启动速度。
15721645366477.jpgnginx

15721645452809.jpg
来源 containerdgit

红帽主导的cri-o是与containerd竞争的容器运行时管理项目。containerd与cri-o项目相比，在性能上具有优点，在社区支持上也更加普遍。
15721651915384.jpggithub

来源 ebay的分享api

更重要的是containerd提供了灵活的扩展机制，支持各类符合OCI（Open Container Initiative）的容器运行时实现，好比runc容器（也是熟知的Docker容器），KataContainer, gVisor和Firecraker等安全沙箱容器。安全

15624007123770.jpg

在Kubernetes环境中，能够用不一样的API和命令行工具来管理容器/Pod，镜像等概念。为了便于你们理解，咱们能够用下图说明如何利用不一样层次的API和CLI管理容器生命周期管理。网络

15624008216276.jpg

  • 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

更多信息能够参考

https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/

containerd与Docker的关系

不少同窗都关心containerd与Docker的关系，以及是否containerd能够取代Docker？
containerd已经成为容器运行时的主流实现，也获得了Docker社区和Kubernetes社区的大力支持。Docker Engine底层的容器生命周期管理也是基于containerd实现。

test.png
可是Docker Engine包含了更多的开发者工具链，好比镜像构建。也包含了Docker本身的日志、存储、网络、Swarm编排等能力。此外，绝大多数容器生态厂商，如安全、监控、开发等对Docker Engine的支持比较完善，对containerd的支持也在逐渐补齐。

因此在Kubernetes运行时环境，对安全和效率和定制化更加关注的用户能够选择containerd做为容器运行时环境。对于大多数开发者，继续使用Docker Engine做为容器运行时也是一个不错的选择。

阿里云容器服务对containerd的支持

在阿里云Kubernetes服务ACK，咱们已经采用containerd做为容器运行时管理，来支撑安全沙箱容器和runc容器的混合部署。在现有产品中，咱们和阿里云操做系统团队、蚂蚁金服一块儿支持了基于轻量虚拟化的runV沙箱容器，4Q也将发布基于Intel SGX的可信加密沙箱容器。

15721673120627.jpg

具体信息能够参考 https://help.aliyun.com/document_detail/140541.html

和Serverless Kubernetes（ASK）中，咱们也利用containerd灵活的插件机制定制和剪裁了面向nodeless环境的容器运行时实现。

 

》》阿里云双11亿元补贴提早领，进入抽取iPhone 11 Pro

 

阅读原文

本文为云栖社区原创内容，未经容许不得转载。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程