云世

原创 谭一笑，左太冲 云世  2021-10-11 21:05

收录于话题

#云原生 210 个内容

#云计算 12 个内容

#DevOps5 个内容

#K8s 架构 46 个内容

#Docker 容器 42 个内容

续前篇：容器云平台技术解析

第三方服务目录

用户开发的应用部署到云平台后，也可以将自身注册到云平台，以一种服务的形式提供给到其  他应用。例如地理位置服务，它提供了查询 API 供第三方应用查询指定地址的经纬度。

应用市场

云平台的应用市场类似于手机的应用市场，用户可以选择心仪的应用，下载并安装在手机上。  云平台的应用市场用于管理应用模版，并将应用模版部署到云平台上。应用市场的核心功能包括应用定义、应用上下架以及应用运营报告。

应用定义以 Kubernetes 的 Helm 为例，它是 Deis (https://deis.com/) 开发的一个用于 kubernetes 的包管理器，每个包称为一个 Chart。对于应用发布者而言，可以通过 Helm 打包应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。

对于使用者而言，使用 Helm 后不需要了解 Kubernetes 的 YAML 语法并编写应用部署文件，可以通过 Helm 下载并在 kubernetes 上安装需要的应用。

 应用治理

应用治理或者说服务治理一词最早出现在 SOA 里面，称之为 SOA Governance，指企业为了确保事情顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的  因素。服务治理指管理服务的采用和实现的过程。

服务治理中一些典型的问题是： 

• 交付价值到利益相关者，这是投入与回报的问题。

• 对标准和规则的遵从（这是和审计相关的）。

• 变更管理：变更一个服务通常会引起不可预见的后果，因为服务的消费者对服务的提供者来说是不可知的。

• 服务质量的保证：弹性添加新服务需要对这些服务给予额外的关注。

  
  

服务治理的一些关键活动包括： 

• 计划开发新服务和升级现有服务。

• 管理服务的生命周期：确保升级服务不会影响目前的服务消费者。

• 制定方针来限制服务行为：制定所有服务都要遵从的规则，确保服务的一致性。

• 监控服务的性能：由于服务组合，服务停机和性能低下的后果是严重的。通过监控服务的性能和可用性，当问题出现的时候能马上采取应对措施。

• 管理由谁来调用服务、怎样调用服务。

• 从实践总结来看，服务治理包含服务管理（管控）和服务监控两大块，同时需要企业级微服务基础组件以及相关中间件的支撑。 

 DevOps

DevOps 是一种强调开发团队、运维团队以及其他团队之间增强协作与沟通，以达到软件产品快速成熟以及安全可控的文化。通过自动化软件交付和变更的流程，让构建、测试、发布软件能  够更加地快捷、频繁和可靠。它能用最小化的代价帮助企业应用开发进入高效的协作模式和快  速的迭代进程。

云平台需要提供 DevOps 能力，比如项目管理、持续集成、流水线、持续发布等。其中依托流水线和 Kubernetes 实现的持续集成、持续部署、持续发布是云平台为应用提供的最核心的 DevOps 能力。

CI（Continuous Integration）持续集成，强调开发人员提交新代码之后，立刻进行构建、（单元）测试、代码扫描等操作。根据测试结果，开发人员可以确定新代码和原有代码能否正确地  集成在一起。

Continuous Deployment（持续部署） 或者 Continuous delivery（持续交付）两者简称都为 CD，但是略有不同。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的“类生产环境”（production-like environments）中。比如完成单元测试后，可以把代码部署到连接数据库的 Staging  环境中更多的测试。注意：这里的测试重点是指测试人员进行的产品级别的测试。在测试过程中普遍都会引入测试脚本进行自动化回归测试，主要包括接口测试和 UI 测试，当然部分公司也会引入安全测试和性能（压力）测试。如果测试没有发现问题，则可以将新代码手动或  者自动部署到生产环境中。

持续部署（发布）就是定时地、手动或者自动地将过去一个稳定的发布版本部署到生产环境  里。当然持续部署的目标是自动发布，但是有时候部署比较复杂，必须人工介入。

总结来说，持续集成、持续部署与持续交付，是通过在应用开发阶段引入自动化，实现频繁向  客户交付应用的方法。需要将自动化和监控贯穿于应用的整个生命周期（从集成和测试阶段，  到交付和部署）。依托于容器化的持续集成，改变了以往应用通过 jar、war 包的部署方式，转而制作为一个镜像，通过 Kubernetes 的功能特性，对纳管的宿主机进行镜像发布、应用启动和应用验证。

平台管理 

在开发者能够在云平台上部署和管理应用之前，云平台首先应该对租户以及租户内可用资源进  行配置和管理。云平台如何对资源进行精细管理，对平台的可用性、可维护性和易用性起着至  关重要的作用，是云平台能够为用户提供丰富的管理能力的基础。

具体而言，平台的管理功能包括用户管理、用户认证与授权、租户管理、资源管理、集群管理、混合云管理等，它是云平台的大脑，用于将资源和服务以自服务的方式提供给租户内的用户。

平台运营 

对租户使用的资源进行计量和计费。除了资源之外，对于有些服务，云平台可以根据调用次  数，数据总量或者每日数据增量等不同维度进行计量和计费。

云平台可以使用数据可视化的方式，用各个维度分析展示各业务部门或项目上的费用报表。

1.1 基础层

容器技术定义了一套从构建到执行的标准化体系，包括： 

• 基础架构的标准化：当前所有的  Linux  系统以及  Windows  操作系统已经支持  Docker Engine，也就意味着可以支持容器化应用。国产操作系统也基本上都可以支持 Docker Engine。

• 应用交付的标准化：提供了一套应用快速打包为 Docker Image 的方法，开发人员在代码完成以后就可以将其打包为镜像，这样运维人员也不再需要为应用准备系统，运行环境，组件和基础软件包。

• 运维管理的标准化：容器时代都运行在一个个的 Docker Container 中，应用运维将关注在这些标准的容器中而不再是关注底层复杂的系统环境。

• 分发部署标准化：指的是容器化以后，不同版本的应用镜像都存储在镜像仓库中，运维人员可以将镜像仓库中特定版本的镜像，一键部署到开发环境、测试环境甚至是生产环境中，也  可以实现快速的版本升级或回退。

以容器技术为核心的引擎层是容器云平台的支撑部分，包括容器编排引擎、容器运行时、服务网格、无服务器计算、镜像仓库，操作系统和基础设施。

容器运行时

 Docker 则是应用最广泛的容器引擎技术之一。Docker 使用 Linux 内核和其相关功能（例如 Cgroups 和 namespaces）分隔进程，各进程相互独立运行，同时保持各个独立系统的隔离性。

继 Docker 之后也出现了多种容器运行时技术，为了更好规范容器技术，Docker，CoreOS 和容器行业中的其他领导者在 2015 年 6 月的时候启动共同发起并成立了 Open Container Initiative（ OCI ）基金会。OCI 基金会领导社区进行制定了相关规范，主要包括： 

• 镜像规范（常被称为“OCI images"）定义了容器镜像的内容。

• 运行时规范（常被称为“CRI”或者容器运行时接口）表述了容器的”配置，运行环境和生周期“。

在 OCI 项目启动后，Docker 公司将 libcontainer 的实现移动到 runC 并捐赠给了 OCI。此时，容器社区有了第一个 OCI Runtime 的参考实现。runC 是一个轻量可移植的容器运行时，包括了所有之前 Docker 所使用的容器相关的与系统特性的代码。随后在 2016 年，Docker 开源并将 Containerd 捐赠给了 CNCF，Containerd 几乎囊括了单机运行一个容器运行时所需要的一切： 执行、分发、监控、网络、构建、日志等。

最初，Kubernetes 仅支持 Docker 作为运行时，为了能够让 Kubernetes 变得更具有可扩展性， 在 1.5 版本增加了 CRI: the Container Runtime Interface，在随后的发展演进中，CRI 被抽出来做成了独立的项目。CRI 将 Kubernetes 与容器运行时解耦，将原来完全面向 Pod 级别的内部接口拆分成面向 Sandbox 和 Container 的 gRPC 接口，并将镜像管理和容器管理分离到不同的服务。

目前支持 OCI 和 CRI 的常用容器引擎有 Docker，Containerd，CRI-O 和 Kata Container。

容器编排引擎 

主流的容器编排和管理系统有 Kubernetes、Mesos 和 Swarm。进入 2017 年之后，随着 Kubernetes 逐渐建立起庞大的生态体系，容器编排之争落下帷幕，Kubernetes 成为了事实上的容器编排标准。

Kubernetes 源自于 Google 内部的 Borg 系统，最初由 Google 和 Red Hat 开源。云原生基金会（Cloud Native Computing Foundation，CNCF）成立之后，Kubernetes 被捐献给了基金会， 同时 CNCF 围绕 Kubernetes 构建生态，促使越来越多的第三方加入到 CNCF 中，丰富了 Kubernetes 大家庭。

容器本质是进程，那 Kubernetes 作为具有普遍意义的容器编排工具，就是云操作系统。Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。

Kubernetes 的核心能力包括： 

• 服务发现和负载均衡

  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排

  Kubernetes 允许自动挂载您选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚

  可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，可以自动化创建新容器，删除现有容器并将它们的所有资源用于新容器。

• 自动二进制打包

  Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复

  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， 并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理

  Kubernetes 允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。可在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

容器网络 

容器网络是容器运行时的一个关键考量技术，包括容器网络安全、如何更好地连接不同集群，  如何连接异构容器云平台等一系列问题。

容器网络的基本目标是满足云原生服务的网络端点和服务间的互通性、安全性和负载均衡要  求。Kubernetes 已经成为容器编排的事实标准，容器网络也需与 Kubernetes 的调度机制相匹配。

Container Network Interface（CNI）是 Kubernetes 现行的网络接口标准，CNI 接口只实现创建、删除容器时的调用方法，其他所有的网络能力都交由网络厂商实现增值服务，这在一定程  度上加速了网络方案的繁荣。

容器网络技术也在持续演进，从 Docker 本身的动态端口映射网络模型，到 CNCF 的 CNI 容器网络接口到 Service Mesh + CNI 层次化 SDN。

容器网络的发展与演进如下图：

1. 端口映射从全局管理容器，复杂度高，企业生产部署中很少使用。分为 Bridge 模式、Host 模式、Container 模式和 None 模式。

2. 容器网络接 CNI（Container Network Interface）是 Google 和 CoreOS 主导制定的容器网络标准，它是在 RKT 网络提议的基础上发展起来的，综合考虑了灵活性、扩展性、IP 分配、多网卡等因素。C N I 旨在为容器平台提供网络的标准化。不同的容器平台（比如目前的 Kubernetes、Mesos 和 RKT）能够通过相同的接口调用不同的网络组件。这个协议连接了两个组件：容器管理系统和网络插件，具体的事情都是插件来实现的，包括：创建容器网络空间（network namespace）、把网络接口（interface）放到对应的网络空间、给网络接口分配 IP 等。 

3. 服务网格（Service Mesh）是指用于微服务应用的可配置基础架构层。它使每个 service 实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份  鉴定、授权、支持熔断器模式（Circuit Breaker Pattern）以及其他一系列功能。但是 Service Mesh 并不会替代 CNI，他们工作在不同的 SDN（Software Defined Network，软件定义网络） 层次，CNI 更多工作在 L2-4 层，Mesh 在 5-7 层 Application SDN。Mesh 不能独立于 CNI 部署，而是将服务网格和 CNI 结合提供层次化微服务应用所需要的网络服务。

   从最初的端口映射，到容器网络接口（CNI），再到服务网络和 CNI 相结合，容器网络技术不断发展，企业可以根据不同的应用场景，选择不同的容器网络方案。

容器存储 

容器存储是云原生应用场景下的存储解决方案，存储形态可为块、对象、文件、键值存储等。  容器存储可以以“声明”的形式被云原生应用申请使用，支持容器编排层对接存储控制面，完  成对存储资源的生命周期管理。

在容器内部存储时不提供持久化数据存储解决方案，存储在容器内部的任何内容，在容器被销  毁以后，数据将自动消失，这就需要考虑采用外部存储挂载到容器上，在容器迁移、消亡、重  启等活动中保证数据的安全。

随着数据库、消息队列等中间件逐步在容器环境中得到应用，容器持久化存储的需求也逐步增  多。同时，容器云平台存储不仅仅是数据的持久化存储，也包括容器云平台自身需要的存储、镜像存储、中间件部署需要的存储。存储资源作为容器云平台的另一个核心基础设施，需要为  不同的容器服务提供可靠的存储服务。

容器存储接口（Container Storage Interface，CSI ）是一项跨行业标准倡议，旨在降低云原生存储开发工作的门槛，从而进一步确保兼容性水平。Kubernetes v1.9 开始引入了 CSI，它允许第三方存储供应商在无需接触核心 Kubernetes 代码库的前提下开发自己的解决方案。

Kubernetes 目前支持了广泛的存储插件，典型的可分为三部分。

• 首先是文件存储，例如 CephFS、GlusterFS、NFS 等。CephFS, GlusterFS 尽管有庞大的社区的支持，但成熟度上还需要进一步验证。同时在大型集群的环境下它们还无法达到企业级稳  定性、可靠性的要求，在高可靠、高性能场景也有着架构上的不足。而 NFS 在性能上存在不足。

• 其次是块存储，例如 Ceph RBD、SAN 存储等。对于这类存储，本身并不支持多读写的需求，而对复杂的容器业务系统又是强需求。

• 最后是对象存储，例如 COS、S3 等。对象存储不需要挂载可直接使用，其他两种存储方式需要挂载后使用。

镜像仓库 

通过把业务及其依赖的环境打包进容器镜像，解决了开发环境和生产环境的差异问题，提升了  业务交付的效率。如何高效地管理和分发容器镜像，是企业级镜像仓库需要解决的问题。

目前 Kubernetes 生态中主流的镜像仓库组件是 Harbor。Harbor 是 VMware 开源的一个企业级镜像仓库，包括了权限管理(RBAC)、LDAP、审计、安全漏洞扫描、镜像验真、管理界面、自我   注册、HA 镜像复制和中文支持等功能。

Service Mesh

服务网格（Service  Mesh）是一个致力于解决服务间通信的基础设施层，用于提供管理、观测、支持工作负载实例之间安全通信。服务网格通常以轻量级网络代理的形式实现，这些代理  与应用程序代码部署在一起，但是对应用程序透明。服务网格通常由控制平面和数据平面两部  分组成。数据平面运行在边车（Sidecar） 中，Sidecar 作为一个独立的容器和业务系统运行在同一个 Pod 里面，或者作为一个独立的进程和应用程序进程运行在同一个虚拟机上，其主要充当业务系统的网络流量的代理。传统 RPC 中的服务发现、限流、熔断、链路追踪等能力都会下沉到 Sidecar 中。Sidecar 为应用程序提供了一个透明的网络基础设施，让业务在低侵入或者零侵入的情况获得更健壮的网络通信能力。

具体来看，基础设施层是 Service Mesh 的定位，用于解决微服务基础设施标准化、配置化、服务化和产品化问题；服务间通信是 Service Mesh 技术面对的问题域，对微服务屏蔽通信的复杂度；请求的可靠传递是 Service Mesh 的目标；轻量级网络代理是 Service Mesh 的部署方式；对应用程序透明，对业务无侵入是 Service Mesh 的特色。

目前 Kubernetes 生态中主流的 Service Mesh 组件是 Istio。Istio 是 Google、IBM 和 Lyft 联合推出的开源微服务 Service Mesh 框架，以 Envoy 为基础，将 Envoy 作为默认的数据平面，提供强大的控制平面能力。

Envoy 内部可以分为数据平面、控制平面和管理平面 3 个部分，控制平面用于对流量路由和转发相关的策略与配置进行管理；控制平面通过标准 API 获取最新的流量配置信息；数据平面的流量转发就是基于控制平面下发的配置规则进行。

Serverless 

基础设施架构总是伴随软件架构演进。单体架构时代应用比较简单，应用的整体部署、业务的  迭代更新，物理服务器的资源利用效率足以支撑业务的部署。随着业务的复杂程度飙升，功能  模块复杂且庞大，单体架构严重阻塞了开发部署的效率，业务功能解耦，单独模块可并行开发  部署的微服务架构逐渐流行开来，业务的精细化管理不可避免地推动着基础资源利用率的提升。虚拟化技术打通了物理资源的隔阂，减轻了用户管理基础架构的负担。容器/PaaS 平台则进一步抽象，提供了应用的依赖服务、运行环境和底层所需的计算资源。这使得应用的开发、  部署和运维的整体效率再度提升。

Serverless（无服务器）是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种  服务，以 API 接口的方式供给用户按需调用。无服务器架构技术则将计算抽象得更加彻底，将应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高  价值的业务领域。

Serverless 架构由两部分构成，分别是 FaaS （Funcation as s Service） 和 BaaS（Backend as a Service）。所谓的无服务器计算，并不是不需要服务器等资源的支持，而是开发者不再需要过多顾虑关于服务器底层资源的问题，可更专注于业务逻辑的开发。

目前 Kubernetes 生态中主流的 Serverless 组件是 Knative。knative 是谷歌开源的 Serverless 架构方案，旨在提供一套简单易用的 Serverless 方案，把 Serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才刚刚对外发布，当前还处于快速发展的阶段。

Knative 是建立在 Kubernetes 和 Istio 平台之上的，使用 kubernetes 提供的容器管理能力（deployment、replicaset、和  pods  等），以及 Istio 提供的网络管理功能（ingress、LB、dynamic route 等）。

Knative 把整个系统分成了三个部分： 

· Build：构建系统，把用户定义的函数和应用 build 成容器镜像

· Serving：服务系统，用来配置应用的路由、升级策略、自动扩缩容等功能

· Eventing：事件系统，用来自动完成事件的绑定和触发

操作系统和基础设施

借开源 Linux 东风，国产操作系统从项目科研体制转向公司化运作，近些年涌现出来一大批逐步成熟的国产操作系统，包括红旗 Red Flag、深度 Deepin、中标麒麟 Neokylin、银河麒麟 Kylin、统信 UOS 等。这些操作系统目前也逐步支持 Docker 和 Kubernetes 生态。

容器云平台是新的云原生基础设施，它依赖于底层的基础设施，可以部署在裸金属（物理  机）、虚拟化（单机虚拟化）、私有云（使用 IaaS 系统，例如 OpenStack，提供的虚拟化资源）、公有云（使用公有云提供虚拟化资源）上。

运维

容器云平台的运维对象涵盖了应用层、平台层和引擎层，提供的能力主要包括巡检、排错、容量预估、日志、监控、告警、自动化等。

日志

在容器化时代，容器应用的日志管理和传统应用存在很大的区别，为了顺应容器化应用，以 Docker 和 Kubernetes 为例，均能提供较为完善的日志解决方案。

在 Docker 中日志分为两大类：Docker 引擎日志和容器日志。

其中，Docker 引擎日志就是 Docker 运行时的日志，即 dockerd 守护进程的日志，在支持 Systemd 的系统中可以通过 journal -u docker 查看日志。Docker 管理所有容器传到 stdout 和 stderr 的日志，通过 docker logs 命令查看容器日志都是读取容器传到 stdout 和 stderr 的日志。

在 Kubernetes 中日志也主要有两大类：应用 Pod 日志和 Kuberntes 集群组件日志。其中， 应用 Pod 的日志管理是基于 Docker 引擎的，Kubernetes 并不管理日志的轮转策略，日志的存储都是基于 Docker 的日志管理策略。Kuberntes 集群组件日志分为两类：运行在容器中的 Kubernetes scheduler 和 kube-proxy；未运行在容器中的 kubelet 和容器 runtime。

Kubernetes 本身并未提供集群日志收集方案，K8s 官方文档给了三种日志收集的建议方案：

• 使用运行在每个节点上的节点级的日志代理；

• 在应用程序的 pod 中包含专门记录日志 sidecar 容器；

• 应用程序直接将日志传输到日志平台。

目前在 Kubernetes 集群内部收集日志有以下几种方案

1. 常见的 ELK（ Elasticsearch、Logstash、Kibana） +  Filebeat。引入了各类  Lib Beats（Package Beat、Top Beat、File Beat 等）运行在 App 应用的 Pod 中收集日志，转发给 Logstash。此方案将手机端的 Logstash 替换为 beats，更灵活，消耗资源更少，扩展性更强。同时可配置 Logstash 和 Elasticsearch 集群用于支持大集群系统的运维日志数据监控和查询。

2. Kubernetes 官方推荐的 EFK（ELasticsearch、Fluentd、Kibana）方案，此方案通过 DaemonSet 的方式在集群内部每个节点上运行一个 Fluent Pod 统一收集上层应用层的日志并反馈到 Elasticsearch。

监控与告警方案 

Docker 是目前使用最广泛的容器之一，但它并不总是像物理硬件一样可见，因此对容器、运行系统和应用的状态的监控就显得很重要。主要对应用层，平台层和引擎层各组件/系统进行性能监控，包括的应用监控，平台监控，Kubernetes 监控，网络监控，主机监控和存储监控等。

应用层和平台层的组件，本质上都是以 Pod 的形式运行在 Kubernetes 之上，因此虽然逻辑上它们是独立的，但其背后使用的监控方案是一致的。

而对于 Pod，Kubernetes 组件，Kubernetes 网络和存储以及主机，目前 Kubernetes 生态可以使用 Prometheus，Grafana 及相关组件完成整个的监控与告警。

Prometheus 是一款面向云原生应用程序的开源监控工具，它是第一个从 CNCF 毕业的监控工具。常见的 Prometheus 监控方案的架构图如下所示：

Prometheus 组件如下所示： 

· Prometheus Server：负责监控数据采集和时序数据存储，并提供数据查询功能。

· 客户端 SDK：对接 Prometheus 的开发工具包。

· Push Gateway：推送数据的网关组件。

· 第三方 Exporter：各种外部指标收集系统，其数据可以被 Prometheus 所采集。

· AlertManager：告警管理器。

其他辅助支持工具。

Prometheus 的核心组件 Prometheus Server 的主要功能包括： 

· 从 Kubernetes Master 获取需要监控的资源或服务信息；

· 从各种 Exporter 抓取（Pull）指标数据，然后将指标数据保存在时序数据库（TSDB）中； 

· 向其他系统提供 HTTP API 进行查询；

· 提供基于 PromQL 语言的数据查询；

· 可以将告警数据推送（Push）给 AlertManager 等等。 

Grafana 是一个开箱即用的可视化工具，具有功能齐全的度量仪表盘和图形编辑器，有灵活丰富的图形化选项，可以混合多种风格，支持多个数据源特点。它可以配合 Prometheus 将监控数据可视化。下图是 Kubernetes 集群监控的一个典型 Dashbaord。

巡检 

云平台巡检是通过巡检软硬件的运行情况，确保云平台运行稳定。巡检通常可以通过调用容器  云平台的各组件的 API，以及监控/日志系统的数据进行整合和汇总。

巡检的内容通常包括：

1. Kubernetes 节点的运行状态，包括内存，网络，磁盘等；

2. Kubernetes 关键组件的运行状态，包括 API Server，ETCD，DNS 等；

3. Pod 的运行状态，CPU/内存等使用情况，重启次数等；

4. 业务的运行状态，包括 API 响应时间/错误率/吞吐量等。

灾备 

灾备（又称灾难恢复，disaster recovery）指的是，发生灾难时恢复业务的能力。灾备通常包含容灾和备份，容灾一般会在相隔距离比较远的两个机房搭建两套相同功能的 IT 系统，实现两地之间数据的同步和功能的切换，当一处机房因为操作不当或是气候等原因造成服务器停止工作  时，整个应用系统可以切换到另一台服务器，使得该系统可以正常工作，以保证数据的完成性  以及系统的正常运转，避免业务上的损失。同样数据的备份，也可增强数据的安全，将重要的数据以天/周为单位进行备份，实现数据的备份和保存。

灾备的目的就是，保存系统的核心部分。一个有效的 Kubernetes 容灾解决方案才能确保 Kubernetes 上运行的含有大量数据的应用程序在容灾恢复的时候，满足服务水平协议（SLA） 或相关法律要求，因此需要具备：

1. 容器粒度的控制

2. 能够备份数据和配置

3. Kubernetes 命名空间感知

4. 针对多云和混合云架构的优化

5. 保持应用的一致性

容器云 PaaS 平台根据所承载业务的重要性、故障处理的时间限制、对用户的影响范围等因素划分所承载业务的容灾等级，可以针对不同的容灾等级采用不同的容灾策略。在某个数据中心的  应用主机高负载运行产生告警，或在业务高峰期一个数据中心的容量不足时，容器云 PaaS 平台会自动进行应用容量的自动扩展，根据扩展策略（如 CPU/内存使用率、交易延时、业务量阈值等指标），自动启动容灾数据中心的容器服务来支撑业务。当某个数据中心发生故障时，容器  云 PaaS 平台会采用流程驱动的方式，实现快速容灾切换。

安全 

云上安全问题本质上都是由线下传统安全问题衍生而来的，但由于容器云平台底层使用了容器  技术，它又引入了新的安全风险。

除了传统的应用依赖包安全，应用安全，主机安全，网络安全之外，重点需要考虑一下与容器  相关的镜像安全和容器安全。

镜像安全 

镜像是创建容器的基础，容器是镜像的运行时，镜像安全直接影响着容器的安全。

对于从公有仓库获取的镜像，其安全问题一方面镜像中开源软件存在的安全风险，另一方面是  镜像内的挖矿程序、后门程序、病毒、木马等恶意程序。这种情况，一般可运行镜像，在里面  安装杀毒软件深度扫描，来确定镜像的安全性，并且确认请求指向官方源。

对于私有仓库中的镜像，通常是用户自己制作上传生成的，需要考虑到软件代码本身的脆弱性  与配置的风险。对于代码本身的问题，需要在开发过程中尽可能遵循 SDL（安全开发生命周期），在镜像的制作过程中，则要尽可能地只运行必要的服务，只暴露必要的端口。

因此常用的安全建议如下： 

• 使用可信基础镜像

• 精简镜像，减少受攻击可能性

• 及时更新漏洞库并周期性执行镜像扫描

• 使用镜像前，提前进行镜像扫描

• 使用带有认证功能的镜像仓库，保证客户端身份有效性

容器安全

容器提供了将应用程序的代码、配置、依赖项打包到单个对象的标准方法，其本质是隔离一个  运行环境，每个封装好的容器彼此相互隔离。但各个容器之间需要互相共享内核，分别通过 Linux 内核本身提供的 Namespace 与 Cgroups 两项关键技术实现。

容器一共有 7 个攻击面：

Linux Kernel、

Namespace/Cgroups/Aufs、

Seccomp-bpf、

Libs、

Language VM、

User Code、

Container(Docker) engine。

因此需要针对这七个攻击面制定相应的安全措施。例如 Docker 等容器引擎需要访问系统资源， 有 root 权限才方便为了整个系统的安全，对于整个系统而言，必须严格控制访问权限，不能随意 root 权限，需要明确划分出一块区域与其他容器和资源隔离，同时配以容器和资源实时监控，确保容器运行安全。

与用户权限相关的安全建议： 

• 禁止容器使用 root 用户

• 控制特权模式使用

• 控制系统调用使用

• 限制系统资源使用

往期推荐

关注 云世 微信公众号。

《最全云厂商及云方案能力报告【建议收藏】》

《最新Serverless服务研究报告【收藏参考】》

《云原生：一文读懂K8s架构》

《云原生：一文读懂Docker核心技术》

《云原生：一文读懂K8s架构原则和对象设计》

《云原生：一文读懂DevOps工具链》

下一节，分享容器云平台产品与应用，记得来读。

如果你觉得这个系列有价值，也欢迎转发给有需要的朋友。

云世 专注职场人的硬实力｜软技能提升。为企业应用上云和云原生前沿技术及落地实践布道，分享微服务、容器、K8s、Service Mesh、面向企业的 ToB 服务能力的体系化建设等方案、最佳实践、免费课程资料；持续发布职场做事方法论、管理提效等软技能。350 篇原创内容

公众号

喜欢就｜关注｜转发｜点赞｜订阅专题吧

公号专题

【职场硬实力】：「云原生」「微服务」「Service Mesh」「K8s」「Docker」

【职场软实力】：「职场养分」「职场软实力」「认知跨越」

---END---

⚡资料+视频课+课程下载⚡ 公众号后台：

回复：DDD，领取 DDD 实践全系列课程；

回复：DDD 源码，领取 DDD 系列 Git 源码；

回复：K8s，领取 K8s 架构实践全系列课程；

回复：微服务，领取微服务实践课程；

回复：Docker，领取 Docker 容器全系列学习课程；

回复：servicemesh，领取全系列课程；

回复：go，领取 Go 全系列学习课程；

回复：职场软技能，领取软技能系列课程；

回复：管理实践，领取管理实践+课程；

回复：面试技能，领取面试技能经验+课程；

回复：麦肯锡工作法，领取完整麦肯锡工作法；

回复：技术视频 3，领取 Servicemesh、Serverless 视频课（全套视频课更新）；

回复：serverless，领取全系列课程+实践；