目录

1 容器原理架构

1.1 容器与虚拟化

1.2 容器应用架构

1.3 容器引擎架构

1.4 Namespace与Cgroups

1.5 容器镜像原理

2 K8S原理架构

2.1 K8S主要功能

2.2 K8S 系统架构

2.3 Pod原理与调度

3 K8S存储方案

3.1 容器存储类型

3.2 PVC与PV

3.3 PV创建与挂载

4 K8S网络方案

4.1 CNI与网络方案

4.2 网络配置与通信

5 应用编排管理

5.1 工作负载workload

5.2 服务与负载均衡

5.3 应用监控管理

6 容器安全方案

6.1 API  访问控制

6.2 Pod安全策略PSP

6.3 安全容器Kata

---

1.   容器原理架构

1.1  容器与虚拟化

如图1，虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。而容器(container)技术是一种更加轻量级的操作系统虚拟化技术，将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中，通过容器引擎提供进程隔离、资源可限制的运行环境，实现应用与OS平台及底层硬件的解耦，一次打包，随处运行。容器基于镜像运行，可部署在物理机或虚拟机上，通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理。

图1：虚拟化与容器架构

VM中包含GuestOS，调度与资源占用都比较重。而容器仅包含应用运行所需的文件，管理容器就是管理应用本身。如表1，容器具有极其轻量、秒级部署、易于移植、敏捷弹性伸缩等优势；但VM是OS系统级隔离，而容器是进程级隔离，容器的安全性相对更弱一些，需要一些额外的安全技术或安全容器方案来弥补。作为云原生的核心技术，容器、微服务与DevOps/ CICD)等技术已成为应用架构转型或实现技术中台不可或缺组件。

对比项	虚拟化VM	容器Container
镜像大小	包含GuestOS，几十G以上；	仅包含应用运行的Bin/Lib，几十M；
资源要求	CPU与内存按核、按G分配	CPU与内存按0.x核、0.0x G分配
启动时间	分钟级	毫秒/秒级
可移植性	跨物理机器迁移	跨OS平台迁移。
弹性伸缩	VM自动伸缩，CPU/内存手动伸缩	实例自动伸缩、CPU/内存自动在线伸缩
隔离策略	OS、系统级	Cgroups、进程级别

表1：容器与虚拟化对比

1.2   容器应用架构

容器概念始于1979年提出的UNIX chroot，而2008年推出功能比较完善的Linux容器LXC，但标准化与可移植性面临较大挑战。2013 推出的Docker突破性的解决了容器标准化与可移植性问题，成为当前最流行的开源容器容器引擎。2016年OCI组织推出了开放容器标准，包括容器运行时标准(runtime spec)和容器镜像标准(image spec)，推动了容器技术的广泛应用。如图2，docker应用是一种C/S架构，包括3个部分：

1)  Docker Client：Docker的应用/管理员，通过相应的docker 命令通过HTTP或REST API等方式与dockerdaemon实现docker服务使用与管理。

2)  Docker Host：运行各种组件docker组件提供容器服务。其中Docker Daemon负责监听client的请求并管理docker对象(容器、镜像、网络、磁盘等)；Docker Image提供容器运行所需的所有文件；Linux 内核中的namespace负责容器的资源隔离，而Cgroup负责容器资源使用限制。

3)  Docker Registry：容器镜像仓库，负责docker镜像存储管理。 可以用镜像仓库如DockerHub或者自建私有镜像仓库。可以通过docker push/pull 往镜像仓库上传/下载镜像。

所以，Docker运行过程就是Client发送Dockerrun命令到Dockerd，Dockerd从本地或镜像仓库获取Docker镜像，然后通过镜像启动运行容器实例。

图2：Docker容器应用架构

1.3   容器引擎架构

容器引擎负责容器的生命周期管理与资源管理，2017年4月docker公司将docker项目改名为Moby。Moby容器引擎的内部架构如图3：

1)  Moby daemon：通过HTTP/S或Restful API对外提供容器、镜像、网络与存储管理。

2)  Containerd：容器运行时管理引擎，向上提供gRPC调用，镜像与容器的基本管理。通过containerd shim插件模块实现对不同容器运行时模块的动态接管，保障Moby daemon或containerd动态升级时对业务不产生影响。

3)  容器运行时RunC：基于OCI标准实现，负责容器的配置文件、运行环境与生命周期管理。另外应对Docker容器安全性不足，新推出Kata、gVisor等安全容器技术。

图3：Moby容器引擎架构

1.4   Namespace与Cgroups

Linux namespace

Linux namespace负责容器的工作空间与资源隔离。容器中namespace通过unshare系统调用来创建，Linux内核提供了7中namespace：

1)PIDnamespace：保障进程隔离，每个容器都以PID=1的init进程来启动。

2)MNTnamespace: 保障每个容器都有独立的目录挂载路径。

3)UTSnamespace：保障每个容器都有独立的主机名或域名。

4)NETnamespace：保障每个容器有独立的网络栈、socket和网卡设备。

5)IPCnamespace：只有在相同IPC命名空间的容器才可以利用共享内存、信号量和消息队列通信。

6)Usernamespace：用于隔离容器中UID、GID以及根目录等。可配置映射宿主机和容器中的UID、GID。

7)Cgroupnamespace：保障容器容器中看到的 cgroup 视图像宿主机一样以根形式来呈现，同时让容器内使用 cgroup 会变得更安全。

Linux Cgroups

Cgroups对容器进程进行层次化分组，并按组实现资源限制和策略控制。

1)Cgroupfs驱动：需要限制CPU或内存使用时，直接把容器进程的PID写入相应的CPU或内存的cgroup。

2)systemdcgroup驱动：提供cgroup管理，所有的cgroup写操作需要通过systemd的接口来完成，不能手动修改。

Linux内核提供了很多Cgroup控制器，容器中常用的是

1)cpu/cpuset/cpuacct group：设置CPU share、cpuacct控制CPU使用率2)memory group：控制内存使用量；

3)device group：控制在容器中看到的device设备，保障安全。

4)freezer group：容器停止时Freezer当前容器进程都写入cgroup、进程冻结。

5)blkio group：限制容器到磁盘的IOS、BPS；

6)pid group：限制容器里面可用到的最大进程数量。

1.5   容器镜像原理

容器镜像就是容器运行时所需要的二进制文件与依赖包的集合，存储在只读的Dockerfile中。镜像基于分层的联合文件系统UnionFS来实现，Ubuntu里基于AUFS实现，新推出OverlayFS比AUFS性能更好，部署更简单，两者核心原理是类似的。图5为容器镜像基于OverlayFS(推荐更高效稳定的Overlay2)的分层架构，其文件处理如表2。

1)lowerdir：镜像层，保存只读的容器镜像文件，多个容器共享；

2)upperdir：容器层，可读可写，采用写时复制COW，每个容器独有。

3)merged：统一视图层，整合各层内容，挂载的容器rootfs下，统一呈现。

图5：基于OverlayFS容器镜像分层

类别	处理情况
读文件	文件不在容器层，直接从镜像层读取； 文件只在容器层，直接从容器厂读取； 文件在两层都有，读取容器层的文件，并隐藏镜像层同名文件。
写文件	首次写已有文件，文件不在容器层，需要镜像层复制到容器层，再在容器层修改。 非首次修改已有文件，文件已经在容器层，直接修改。 写新文件，直接在容器层写入。
删除文件	当一个文件或目录被删除，容器层会创建一个whiteout文件或apaque目录，防止该文件或目录被容器看到；而镜像层的文件或目录是只读的，不会被删除。

表2：基于overlay2的容器文件的读写处理

2.   K8S原理架构

2.1   K8S主要功能

Kubernetes简称K8S 是 Google于2014年开源容器编排调度管理平台。相比与Swarm、Mesos，K8S引入Pod、Replica、Label、Service等机制简化了容器调度与管理，提供可靠性，增加了功能特性，目前成为最流行的容器编排平台，K8S主要功能如下：

1)容器调度管理：基于调度算法与策略将容器调度到对应的节点上运行。

2)服务发现与负载均衡：通过域名、VIP对外提供容器服务，提供访问流量负载均衡。

3)弹性扩展：定义期待的容器状态与资源，K8S自动检测、创建、删除实例和配置以满足要求。

4)自动恢复与回滚：提供健康检查，自动重启、迁移、替换或回滚运行失败或没响应的容器，保障服务可用性。

5)K8S对象管理：涉及应用编排与管理、配置、秘钥等、监控与日志等。

6)资源管理：对容器使用的网络、存储、GPU等资源进行管理。

2.2   K8S系统架构

如图5，K8S是二层C/S架构Master作为管控节点，负责集群调度，监控管控与元数据存储；Node是业务节点，负责容器运行、资源分配与管理。用户通过UI或API与Master通信交付，然后把相关请求转发到Node上进行处理。

图5：K8S系统架构

Master的主要组件功能如下：

1)API Server：K8S资源对象的唯一操作入口，接收、校验并处理API 请求；Master中所有组件互不相连，都通过APIServer 进行消息传送与任务处理；

2)Controller Manager：集群管理控制中心，负责集群状态检测与故障恢复等工作。管理多个控制器：Node Controller、Endpoint Controller、Service Account & Token Controller等。

3)Scheduler：集群调度器，负责容器调度操作，基于资源与策略等将Pod调度到合适的Node上运行。

4)ETCD：负责集群元数据与状态保存。是一个基于RAFT协议的高可用的分布式Key-Value存储系统。

5)Cloud Controller Manager：新增特性，负责与云厂商组件相关的控制器交互，如 NodeController、Route Controller、ServiceController、Volume Controller。K8S控制器由“声明式”的API驱动，提前定义K8S资源对象的期待状态，控制器自主运行，异步地控制系统向最终状态趋近。

Node的主要组件功能如下：

1)Kube-let：与API Server交互获取容器Pod创建请求，转到对应的Container Runtime处理。监控并上报Pod运行情况、镜像与资源状态等。

2)kube-proxy：Node上的网络代理，维护集群的网络规则与网络通信。

3)Container Runtime：接收kube-let请求在OS创建容器的运行时环境。

4)Storage Plugin/Network Plugin, 负责与外部组件通信，容器存储或网络的配置使用。

2.3   Pod原理与调度

Pod 是K8S的最小调度以及资源分配单元，包含容器运行环境与资源。Pod之间相互隔离。通常一个Pod运行一个容器。当某些容器间关系非常紧密Tightly coupled(如文件交换、频繁的RPC调用、共享网络或存储等)，需要在一个Pod运行多个容器方便调度管理。

Pod中可以通过Infra Container共享网络。Infra container，大小100-200KB，最先启动，并绑定了Pod的唯一IP地址与各种网络资源，Pod内其他容器通过加入infra container的Network namespace来实现网络共享。Pod中的多个容器也可以通过挂载相同的共享路径实现存储共享。

Pod 中可定义Init Container在应用启动前先启动来执行一次性的辅助任务，比如执行脚本、拷贝文件到共享目录、日志收集、应用监控等。将辅助功能与主业务容器解耦，实现独立发布和能力重用。

一个Pod就是一个应用运行实例，可以运行多个Pod实现应用横向扩展。当调度失败或运行失败时，Pod本身没有自恢复能力，需要借助上层的controller来通过采用提前定义好的Pod模板创建Pod，提供Pod重启、重建或迁移能力。

K8S调度主要涉及资源调度和关系的调度，采用两种机制过滤(Filtering)和打分(Scoring)。通过过滤机制选择备用节点，过滤因素包括CPU/内存/存储、Pod与Nod匹配、Pod与Pod匹配等；然后将Pod调度到分数最高的节点，打分依据包含亲和性/反亲和性、资源水位等等。完整的调度流程如下：

1)   用户通过UI或CLI提交Pod部署请求时，会首先提交给API Server，然后信息存储到ETCD；

2)   Scheduler通过Watch或通知机制获得Pod需要调度的请求，通过过滤和打分机制做出调度决策，并通知API Server调度结果；

3)   APIServer收到调度结果写入ETCD，并通知响应Node上的Kube-let。

4)   Kube-let调用Container Runtime配置其他运行环境，并调用对应的插件去分片存储和网络资源。

3  K8S存储方案

3.1 容器存储类型

容器数据存储与共享需要提供存储卷，有几种方式：

1)  本地存储：将容器所在宿主机的目录挂载到容器中，可以是指定路径的Hostpath或系统分配的零时路径Emptydir。

2)  网络存储：通过in-tree 方式实现(代码包含在K8S中)维护和扩展相对麻烦，目前推荐采用 out-of-tree方式实现，通过CSI插件将网络存储diver实现与K8S解耦。

3)  Projected Volume：将配置数据(如Secret、ConfigMap等)以卷形式挂载到容器中，让应用可以通过POSIX接口来访问。

4)  PVC与PV：通过PV(Persistent Volume)将Pod与Volume生命周期解耦，同时通过PVC(Persistent Volume Claim)实现职责分离，简化K8S用户对存储的使用与调度分配。

3.2 PVC与PV

PVC定义业务侧的存储需求，如存储容量、访问模式(独占还是共享、只读还是读写)等；PV是存储的具体实现，分配存储空间。如图7，PV支持静态分配与动态分配。

图6：PV存储分配方式

1)  静态分配：管理员预先创建分配一些PV，用户端提交Pod与PVC存储需求时，管控组件将PVC与合适的PV绑定到一起，然后提供给Pod使用。这里预先分配的PV很难精确匹配存储需求，可能造成资源浪费。

2)  动态分配：管理员不预先分配PV，只是定义了PV模板StorageClass，说明存储类型，存储插件，回收策略及相关参数，用户端提交Pod与PVC存储需求时，管控组件会根据StorageClass动态创建符合需求的PV，然后绑定到PVC，提供给Pod使用。这里实现了存储按需分配，管理运维也更加简单。

3.3 PV 创建与挂载

如图8，K8S中引入了存储插件CSI(Container Storage Interface)，其一部分是K8S驱动中实现的通用部分如图中的CSI-Provisioner-Controller和CSI-Attacher-Controller，实现存储控制功能；另一部分是云存储厂商实现的CSI-Controller-Server与CSI-Node-Server，实现Vol创建/删除、挂载/卸载等存储操作。PV和PVC的处理有3个阶段：

1)  PV创建与绑定(1-5)：Kube-API-Server接收到用户提交Pod和PVC请求。CSI-Provisioner-Controller监听到PVC对象生成，结合PVC中声明StorageClass，通过gRPC调用CSI-Controller-Server，然后调用云存储组件创建PV资源。PV-Controller将PVC与PV绑定，PV使用就绪。

2)  Pod调度与PV Attach(6-8)：用户提交Pod后，调度器选择合适的Node。AD-Controller监听到被选Node并生成VolumeAttachment对象，触发CSI-Attacher-Controller调用CSI-Controller-Server去将存储关联(Attach)到被选Node上(路径/dev)。

3)  Pod创建与PV Mouth(9-10)：Kube-let创建Pod时先通过CSI-Node-Server将PVC绑定的PV挂载(Mount)到Pod可以使用的路径，然后启动Pod中的所有容器。

图7：Pod与PV创建与挂载流程

4 K8S网络方案

4.1 CNI与网络方案

K8S网络通过CNI(Container Network Interface)网络插件实现。如图6，基于不同的实现模式(Overlay、Underlay或路由)，对底层网络依赖程度也不同。主流网络实现方案如表3所示，可以基于网络环境限制、功能需求与性能要求进行对比选择。

图9：K8S网络插件实现模式

网络方案	情况描述
Flannel	应用广泛，提供多种backend实现，覆盖overlay、Underlay多种场景，可选用户态UDP或内核态VxLAN封装(性能好)或host-gw方式。
Calico	采用策略路由，BGP网络直连、功能丰富、要求MAC地址直通不能跨二层
Canal	组合方案：Flannel for Network + Calico for  Firewall。
Cilium	基于EBPF和XDP的高性能Overlay方案。
Kube-router	采用BGP提供网络直连，集成LVS负载均衡能力
Romana	采用BGP或OSPF提供网络直连方案
WeaveNet	采用UDP封装L2 Overlay  ，用户态(慢，可加密)/内核态(快、不加密)

表3：K8S网络实现方案

4.2 网络配置与通信

K8S中每个Pod有独立网络空间，通过独立的IP对外通信。Pod之间、Pod与Node之间可直接通信，无需地址转换，可通过Network Policy设置访问策略。通过CNI网络插件实现网络配置步骤如下：

1)   配置CNI配置文(/etc/cni/net.d/xxnet.conf)；

2)   安装二进制CNI插件(/opt/cni/bin/xxnet)；

3)   在节点上创建Pod时，Kube-let根据CNI配置文件执行CNI插件来配置Pod网络。

如图7在云厂商容器服务中，容器服务可以部署在VM上。容器网络采用基于VPC私有网络实现，其中涉及底层主机的物理网络，Node集群的虚拟网络，以及上层容器网络。容器与外部网络通信基于Overlay隧道、虚拟网关、VPC路由表、物理网络路由等技术实现。

图10：基于Overlay隧道的容器网络

5 应用编排管理

5.1 工作负载Workload

K8S中通过工作负载Workload来管理应用部署与发布。需要基于不同的工作负载类型(Deployment、StatefulSet、DaemonSet、Job、CronJob)，配置存储卷，配置容器实例与镜像，实例的数量与弹性伸缩，服务访问方式等。不同负载类型与说明如表4。另外容器中还可以通过ConfigMap、Secret来保持容器中的可变配置与敏感信息。

Workload	关键特征
Deployment	管理部署无状态应用。Deployment管理不同版本的ReplicaSet，ReplicaSet管理相同版本的Pod。Deployment调整ReplicaSet的终态副本数，控制器会维持实际运行的Pod数量与期望的数量一致，Pod出故障时可以自动重启或恢复。
StatefulSet	管理部署有状态应用。创建的 Pod 拥有根据规范创建的持久型标识符。Pod 迁移或销毁重启后，标识符仍会保留。如，每个Pod有序号，可以按按序号创建更新或删除 ；Pod有唯一的网络标志(hostname)或独享的存储PV，支持灰度发布等 。
DaemonSet	管理部署每个节点都要运行的任务，如监控、日志收集等。指定每个节点上都运行的Pod，新加入的节点也要运行，移出节点是需要删除。也可以通过标签的方式制定哪些节点运行
Job	单次任务。可创建一个或多个Pod，监控Pod是否成功运行或终止；根据Pod状态设置重复次数、并发度、重启策略；
CronJob	Cronjob定时的Job，可以指定运行时间、等待时间、是否并行运行。运行次数限制。

表4：容器工作负载类型与说明

ConfigMap	存储容器的可变配置(文件、环境变量或命令参数)， 使容器的配置与运行镜像解耦，保证容器可移植性。可以通过挂载、环境变量或运行命令方式在容器中使用。
Secret	采用 base-64 编码保存密码、令牌、密钥等敏感信息。可以通过挂载、环境变量或运行命令方式在容器中使用。

表5：容器配置ConfigMap与Secret

5.2 服务与负载均衡

K8S服务Service提供了功能相同的一组Pod统一抽象入口，定义了服务访问方式与负载均衡，实现前端Client的服务访问与后端Pod上的服务部署解耦。另外可以通过Ingress实现基于HTTP/HTTPS的7层负载均衡，配置转发规则，实现不同URL访问不同的service，支持配置SSL证书。如表6，容器服务支持基于负载均衡、ClusterIP或NodePort方式实现不同场景下的服务访问。

访问方式	说明
提供公网访问	·        使用负载均衡模式，分配公网IP，实现公网访问容器服务：集群外通过域名或IP+服务端口访问；集群内通过服务名+端口访问。适合Web类服务。
集群内访问	·        使用ClusterIP 模式，分配容器内网IP，集群内通过服务名+服务端口访问。适合数据库类服务。
VPC内网访问	·        使用负载均衡模式，分配VPC子网IP，实现VPC内访问容器服务：集群外通过域名或IP+服务端口访问；集群内通过服务名+端口访问。适合Web类服务。
NodePort访问	·        提供主机端口映射到容器的访问方式，支持 TCP、UDP。可以通过Node IP+主机端口或服务名 + 服务端口访问服务。

表6：容器服务访问方式

容器服务的配置与访问路径如图11，Master中Kube-API-Server负责监听服务状态与变化；Cloud-Controller-Manager负责配置负载均衡提供外网访问；CoreDNS负责配置服务域名到ClusterIP的DNS解析。如图，当客户端Pod4想要访问容器服务时，先通过CoreDNS解析服务名到服务的ClusterIP，然后Pod4向ClusterIP发起服务请求；请求到达Node节点后会被Kube-Proxy配置的Iptables或IPVS的规则拦截，然后内部负载均衡到后端的服务Pod1、Pod2、Pod3。如果是集群外访问，请求发送到外部LB然后转发到NodePort，然后经过Kube-Proxy配置的Iptables或IPS转换成访问ClusterIP，然后转换成访问后端Pod具体IP。

图11：K8S服务发现与访问路径

5.3 应用监控管理

就绪探针与存活探针

要保障容器应用的健康稳定运行，需要提供应用的运行状态、资源使用的可观测性与恢复能力。系统通过就绪探针Readiness Probe探测Pod是否处于就绪状态，如果不就绪就切断上层流量，Pod不对外提供服务。通过存活探针Liveness Probe探测Pod是否存活，如果不存活，根据重启策略判断是否需要重新拉起pod。两种探针支持3种探测方式：

1)  httpGet：发送 http Get 请求来判断，当返回码是 200-399 之间时，应用正常。

2)  Exec：通过执行容器中的一个命令来判断，如果返回结果 0，容器服务正常。

3)  tcpSocket：通过容器 IP 和 Port 建立TCP 连接，如果连接成功，容器正常。

监控告警与日志

K8S监控分为几种类型，如资源监控(CPU、内存、网络)、性能监控(APM应用性能指标)、安全监控(安全策略、越权管理、安全漏洞)、事件监控(正常Normal事件或异常warning事件)。目前K8S采用主流的开源监控标准Prometheus，应用侧只需要只需要实现 Prometheus Client就是可以实现数据采集，支持3种数据采集策略：

1)  Pull 模式：通过拉模式去对应的数据的任务上面去拉取数据；一旦你的数据声明周期短于数据采集周期可能漏采。

2)  Push模式：通过 pushgateway 进行数据采集，然后 Prometheus 再通过 pull 的方式去 pushgateway 去拉数据。

3)  Prometheus on Prometheus：通过一个 Prometheus同步数据到另一个Prometheus。

K8S日志也分为几种类型：主机内核日志、运行时Runtime日志、K8S组件日志、业务应用日志。日志通过宿主机文件、容器日志文件或日志标准或错误输出进行采集。目前主流的日志采集呈现方案是ELK，通过 Fluentd采集日志，将数据汇集到 Elasticsearch(或InfluxDB)分析处理，然后再通过 Kibana(或Grafana)做日志展现。

6 容器安全方案

6.1 API访问控制

容器安全4C

如图12，容器环境的安全涉及4个层级4C(Code、Container、Cluster，Cloud)，每个层级都需要有相对独立又相互关联的安全机制与方案。本文重点讲Cluster与Container层级的安全机制。

图12：容器环境的安全层级

API 访问控制

如图13，K8S API访问控制，普通用户UserAccount或集群对象Service Account发起API请求，API Server会接收请求，并进行访问控制检测，通过后才将API请求转发到对应的K8S对象进行处理。其中，可以通过证书、密码、秘钥和Token进行用户认证；通过基于节点Node，基于角色的RBAC、基于属性的ABAC或自定义HTTP回调方法Webhook的方式进行授权校验；最后再基于各种准入控制插件在对象创建/删除/更新或连接时进行准入控制检测，读操作时不做。

图13：K8SAPI请求访问控制

6.2 Pod 安全策略PSP

K8S中可以设置Security Context，限制容器行为，保证系统和其他容器的安全。用户配置Security Context后，传到系统内核，然后通过内核机制让SecurityContext生效。SecurityContext分为三个级别：容器级别仅对容器生效；Pod 级别对 Pod 里所有容器生效；集群级别，就是 PSP，对集群内所有 pod 生效。可支持如下配置：

1)Users and groups：通过指定UID、GID的范围控制访问权限。

2)SELinux：对用户或进程文件配置基于Linux内核的强制访问控制；

3)Privileged：指定Pod内那些容器客户运行在特权模式；

4)Capabilities：提供与Superuser关联权限细分，可用于容器权限升级。

5)AppArmor：通过配置文件来控制可执行文件的一个访问控制权限，

6)Systemctl：对系统调用的控制；

7)Volumes and file systems：指定运行访问的存储卷类型。

PSP对象是集群级别的资源，定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行、能够控制 Pod 运行行为与访问能力。允许管理员控制如下内容：

控制面	字段名称
已授权容器的运行	privileged
为容器添加默认的一组能力	defaultAddCapabilities
为容器去掉某些能力	requiredDropCapabilities
容器能够请求添加某些能力	allowedCapabilities
控制卷类型的使用	volumes
主机网络的使用	hostNetwork
主机端口的使用	hostPorts
主机 PID namespace 的使用	hostPID
主机 IPC namespace 的使用	hostIPC
主机路径的使用	allowedHostPaths
容器的 SELinux 上下文	seLinux
用户 ID	runAsUser
配置允许的补充组	supplementalGroups
分配拥有 Pod 数据卷的 FSGroup	fsGroup
必须使用一个只读的 root 文件系统	readOnlyRootFilesystem

表7：Pod安全策略说明

K8S保障容器安全，除了以上安全机制，还可过RBAC、Namespace机制 加强隔离；使用ResourceQuota & Limit Range限制资源使用；通过加密实现敏感信息保护；通过NetworkPolicy控制网络流量，采用日志、监控与告警机制等。

6.3 安全容器Kata

应用部署在Docker容器中调度管理方便，运行性能高，但安全隔离较差； 而应用部署VM上，安全隔离更好，但调度管理与性能上又受到限制，所以，安全容器整合容器和VM的优势。如图14，传统容器中，不同Pod共享内核，通过namespace隔离。而安全容器在每个Pod外增加了保护层Pod Sandbox，容器之间达到内核级隔离，提升了安全性，调度管理与运行性能也不受影响。Pod Sandbox基于VM面向云原生的虚拟化，有kernel但没有完整OS，只读系统，仅运行容器，动态调整资源。

图14：传统容器与安全容器对比

Kata 容器可以与K8S进行集成，Kata 1.5 版本之后集成架构如图15。客户端Kube-let通过CRI接口向Containerd发起请求；Containerd为每个Pod创建一个Containerd-shim-kata-v2，然后启动Pod Sandbox，运行轻量的Guest Kernel；然后把容器的声明Spec与Rootfs提交给Pod Sandbox，启动容器运行。其他外置存储、网络等可以无缝的接入Pod sandbox使用。Kata容器通过优化现有VM隔离机制实现安全容器，Google开源的gVisor不创建Pod Sandbox，采用新的更加轻量技术实现安全容器。

图15：Kata容器与K8S集成

--------

参考资料：

1.    Docker官网：

https://docs.docker.com/

2.    K8S官网：

https://kubernetes.io/docs/home/

3.    从零开始入门 K8S系列：

https://developer.aliyun.com/article/718433

--------------------

相关阅读：

KVM 虚拟化详解

云存储详解

云网络详解

计算虚拟化详解

云计算要点简介

----------------------------------------------------------------------

智能云计算

微信：AIcloud01

介绍：云计算、人工智能、大数据、物联网、云安全、区块链等前沿技术知识与资讯分享平台。