服务器容器云设计

A. 什么是容器云

容器技术是近几年云行业发展中不可缺少的一环。Docker和k8s的大热极大可能会推动云计算PAAS层的完善和普及。

容器（Container）是一种更轻量级，更灵活的虚拟化处理方式，它将一个应用程序所需的一切打包在一起。

容器包括所有代码，各种依赖甚至操作系统，这让应用程序几乎在任何地方都可以运行。因此它的诞生，解决了一个重要问题：如何确保应用程序从一个环境移动到另一个环境的正确运行。它只是虚拟了操作系统，而不像虚拟机一样去虚拟底层计算机。

Docker 容器是一个开源的应用容器引擎，让开发者可以以统一的方式打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何安装了docker引擎的服务器上（包括流行的Linux机器、windows机器），也可以实现虚拟化。

容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

• 定期渗透测试，安全审计；

• 尽量采用image的正规镜像来源，相对于传统安全，容器安全受质疑很大程度上是在于镜像的维护及升级，因此在镜像源头保证安全和及时更新；

• 及时升级容器服务，比如采用rollingupdate的方式对跑服务的容器进行升级等方式。

Docker容器与其他的容器技术都是大致类似的。但是，Docker在一个单一的容器内捆绑了关键的应用程序组件，这也就让这容器可以在不同平台和云计算之间实现便携性。其结果就是，Docker就成为了需要实现跨多个不同环境运行的应用程序的理想容器技术选择。

Docker还可以让使用微服务的应用程序得益，所谓微服务就是把应用程序分解成为专门开发的更小服务。 这些服务使用通用的RESTAPI来进行交互。使用完全封装Docker容器的开发人员可以针对采用微服务的应用程序开发出一个更为高效的分发模式。

B. 云计算2020展望（技术篇）：Serverless、K8s、服务网格、OSS、HPC

回顾2019年中国云计算产业的发展，趁着“产业互联网”火热的东风，云计算也一路高歌前行。阿里巴巴、腾讯、网络、华为等 科技 互联网巨头企业都在持续布局。

Salesforce与阿里巴巴达成战略合作，阿里巴巴推出政务钉钉，网络云升级为网络智能云，网络推出爱番番CRM开放平台，销售易获腾讯独家1.2亿美元E轮融资，腾讯云全面升级弹性计算产品序列，计算性能提升30%；金山办公正式登陆科创板上市、华为新成立“华为云计算技术有限公司” ……这些“新鲜“的云计算故事，也都曾轰动一时，甚至时至今日，仍对云计算领域影响至深。

2020年刚起步，中国云计算“第一股”——UCloud成功登陆科创板，成为众多业内人士在武汉的新型冠状病毒肺炎爆发前，最关注的"热点”之一。

展望2020年，亿欧智库坚定看好云计算领域的发展机会，并将持续输出云计算产业细分领域，如PaaS、SaaS、云安全等领域的研究报告。

值得注意的是，亿欧智库此前发布的《2019年中国云计算行业发展研究报告》所总结的六条云计算产业发展趋势依旧具备长期预判价值。以下列出概括性的内容，具体详见报告正文：

基于此，亿欧智库进一步总结云计算产业的未来发展趋势，帮助业内人士更加及时把握云计算产业最新发展机遇。本篇将重点介绍五条云计算产业有希望快速落地或爆发的主流技术：

无服务器计算（Severless Computing，以下简称Serverless）是一种包含第三方BaaS（后端即服务）服务的应用程序设计方式，与包括FaaS（函数即服务）平台上的托管临时容器中运行的自定义代码。与很多技术趋势一样，Serverless至今还没有明确且清晰的定义，对于开发人员来说，其重点代表两个截然不同但有重合的概念：

Serverless相比IaaS和SaaS，可以更好更快的在云服务商平台上部署应用，完全不用提前测算资源需求，所有功能根据事件驱动，按需加载，执行完毕，资源释放，真正实现了用多少付费多少，降低成本的同时，还提高了开发人员的生产力。

Serverless主要适合于新兴的、事件驱动性的，类似于IoT等传感设备、金融交易类型等场景。

Serverless兴起于2017年，在最近两年伴随云原生概念的推广逐渐火热。

目前 Serverless 在国内的发展和采用依然处于初期阶段，业务实践偏少，仍在不断 探索 之中。相比之下，国外整体要领先 1-2 年，国外几大云厂商前期对整个研发生态的教育和布局较多，应用较早。

现在国外也已经出现不少 Serverless 框架，比较知名包括 Serverless.com 和 Zeit.com。

根据RightScale的2018年云状态报告，无服务器是当今增长速度很快的云服务模型，年增塑达75%，并有望于2020年超越该增速。亿欧智库也对Serverless的增长速度和市场规模持乐观态度。

Kubernetes（以下简称K8s） 是一个针对容器应用，进行自动部署，弹性伸缩，和管理的开源系统。主要负责在大规模服务器环境中管理容器组（pod）的扩展、复制、 健康 ，并解决 pod 的启动、负载均衡等问题。

K8s 能在实体机或虚拟机集群上调度和运行程序容器。K8s 也能让开发者斩断联系着实体机或虚拟机的“锁链”，从以主机为中心的架构跃至以容器为中心的架构。该架构最终提供给开发者诸多内在的优势，例如可移动、可扩展、自修复等。

K8s 也能兼容各种云服务提供商，例如 Google Cloud、Amazon、Microsoft Azure，还可以工作在 CloudStack、OpenStack、OVirt、Photon、VSphere。

K8s 源于 Google 内部的 Borg 项目，经 Google 使用 Go 语言重写后，被命名为Kubernetes，并于 2014 年 6 月开源。目前已有多家大公司，例如 Microsoft、 RedHat、 IBM、Docker，都支持K8s。

从近年来国外K8s发展来看， 巨头公司为自有K8s部门增添活力或构建全新产品的有效手段之一为收购 。

随着专注于容器初创公司逐渐增加，预计2020年各大云服务商将继续收购表现优秀的容器初创公司，以进军K8s市场，完善其产品体系。

不可否认，K8s作为一项新兴技术距全球普及它还有很长的路要走。但很明显，K8s已经是，并且将继续是软件世界中的主导力量。

服务网格（Service Mesh）是用于控制和监视微服务应用程序中的内部服务到服务流量的软件基础结构层。服务网格的独特之处在于它是为适应分布式微服务环境而构建的。

服务网格的兴起主要是为了解决Docker和Kubernetes无法解决的运行问题。因为诸如Docker和Kubernetes这样的工具主要解决的是部署的问题。但部署不是生产的最后一步，部署完之后，应用程序还必须运行，服务网格因解决运行问题应运而生。

2016年服务网格提出之后，以Linkerd和Envoy为代表的框架开始崭露头角。目前市面上没有现成的商业产品，大多数服务网格都是开源项目，需要一些技巧才能实现。最着名的有：

关于服务网格技术的并购目前也逐渐升温，着名的并购案有VMware在2019年7月以4.2亿美元收购了Avi Networks以及F5 Networks在2019年5月斥资2.5亿美元收购了NGINX。

2019年是被确定是适合解决服务网格问题的一年，2020年将会是核心服务网格用例出现的一年。

开源软件（Open Source Software，以下简称OSS）被定义为描述其源码可以被公众使用的软件，并且此软件的使用，修改和分发也不受许可证的限制。

1998年2月，“开源”一词首先被运用于软件。最初的开源软件项目并不是真正的企业，而是一些顶级程序员针对Microsoft、Oracle、SAP等老牌闭源公司对软件收费较高的一场革命。顶级开发人员通常以异步方式协同编写一些出色的软件。每个人不仅可以查看公开的软件，而且通过一种松散的治理模型，他们可以添加，改进和增强它。这是第一代的开源软件项目。

而经过10多年的发展，Linux、MySQL的成功为第二代开源软件公司奠定基础，比如Cloudera和Hortonworks。但第二代开源软件公司中，没有一家公司对软件拥有绝对的控制权，对手经常通过免费提供软件来进行竞争。

之后出现了像Elastic、Mongo和Confluent等第三代开源软件公司提供的Elastic Cloud，Confluent Cloud和MongoDB Atlas这样的服务，这种进化代表着开源软件公司这种模式有机会成为软件基础设施的主要商业模式。

经过22年的发展，如今OSS已经无处不在。OSS领域也发声了一些“大事件”：IBM以320亿美元的价格收购了Redhat（是2014年市值的3倍）；Mulesoft在上市后以65亿美金的价格被Salesforce收购；MongoDB现在市值超过40亿美元；Elastic则为60亿美元；并且，通过Cloudera和Hortonworks的合并，将出现一个市值超过40亿美元的新公司……

当然还有很多OSS的公司在路上，例如Confluent、HashiCorp、DataBricks、Kong、Cockroach Labs等。

展望2020年，OSS的理念将与云计算SaaS（软件即服务）的理念更加契合，将大大推动软件产业的创新，并有机会迎来新一轮的发展高潮。

高性能计算（High Performance Computing，以下简称HPC）指能够执行一般个人电脑无法处理的大资料量与高速运算的电脑，其基本组成组件与个人电脑的概念无太大差异，但规格与性能则强大许多。

HPC能够在非常短的时间内执行大量计算，正从过去主要传统科研领域计算密集型为主，逐渐向新兴的大数据、人工智能以及深度学习等方向进行融合和演进。

从应用领域来看，HPC是不同行业中非常专业的领域，可以用于预报天气，也可以是分析风险，还可以分析农场数据，以根据不断变化的天气条件找到最佳的农作物种植地点。

在中国市场当中，主要有联想、浪潮和曙光三家公司处于领先的地位，占据了超过90%的市场份额。这三家公司作为中国HPC市场的状元、榜眼和探花，共同将中国HPC推上了世界第一的位置。

其中，联想连续五年蝉联“HPC China TOP100榜单”第一名，并于2019年11月8日发布“深腾X9000”高性能融合计算平台，该平台在兼顾算的更快、更准、更全面的同时，也使联想成为HPC绿色数据中心的积极倡导者，继续领跑HPC水冷解决方案。

除此之外，联想还在全球160多个国家开展众多领域的突破性研究，这些领域包括癌症、大脑研究、天体物理学、人工智能、气候科学、化学、生物学、 汽车 和航空等。

公开调研资料显示，2018年企业中使用了HPC的比例是36%。随着云计算领域的基础设施完备、资源和数据的增加，HPC的需求也将在2020年有所增加，云服务商有望对HPC进行投资。

众所周知，技术的进步对产业发展和创新具有积极推动作用。

正如近年来区块链、5G、机器学习等技术的发展对传统产业的转型促进一样，Serverless、Service Mesh、K8s、OSS、HPC这些云技术也必将提升IaaS、PaaS、SaaS等传统云计算模式的弹性、灵活性、计算能力等，并与传统模式融合互补，协同助推各产业转型升级。

推荐阅读：

千淘万漉，吹尽黄沙，中国智能制造哨声洪亮 | 预见2020

2020银行业展望：对外开放加快，理财转型提速， 科技 深度赋能……

2020物流业新态势：巨头效应显着、 科技 赋能、智慧物流建设加快……

拨云见日，始得真金，产业互联网迎来高光时刻丨预见2020

预见2020：日新月异的中国保险业

C. Docker容器与容器云 这本书看过吗

Docker是什么？

简单得来说，Docker是一个由GO语言写的程序运行的“容器”（Linux containers， LXCs）； 目前云服务的基石是操作系统级别的隔离，在同一台物理服务器上虚拟出多个主机。Docker则实现了一种应用程序级别的隔离； 它改变我们基本的开发、操作单元，由直接操作虚拟主机（VM）,转换到操作程序运行的“容器”上来。

Docker是为开发者和系统管理员设计的，用来发布和运行分布式应用程序的一个开放性。由两部分组成：

Docker Engine: 一个便携式、轻量级的运行环境和包管理器。（注* 单OS vs 单线程，是不是跟NodeJS特别像？）

Docker Hub: 为创建自动化工作流和分享应用创建的云服务组成。（注* 云端镜像/包管理 vs npm包管理，是不是跟npm特别像？）

从2013年3月20日，第一个版本的Docker正式发布到 2014年6月Docker 1.0 正式发布，经历了15个月。 虽然发展历程很短，但Docker正在有越来越流行的趋势。

其实Container技术并非Docker的创新，HeroKu, NodeJitsu 等云服务商都采用了类似这种轻量级的虚拟化技术，但Docker是第一个将这这种Container技术大规模开源并被社区广泛接受的。

好的部分
Docker相对于VM虚拟机的优势十分明显，那就是轻量和高性能和便捷性， 以下部分摘自：KVM and Docker LXC Benchmarking with OpenStack

快
运行时的性能可以获取极大提升（经典的案例是提升97%）

管理操作（启动，停止，开始，重启等等） 都是以秒或毫秒为单位的。

敏捷
像虚拟机一样敏捷，而且会更便宜，在bare metal（裸机）上布署像点个按钮一样简单。

灵活
将应用和系统“容器化”，不添加额外的操作系统，

轻量
你会拥有足够的“操作系统”，仅需添加或减小镜像即可。在一台服务器上可以布署100~1000个Containers容器。

便宜
开源的，的，低成本的。由现代Linux内核支持并驱动。注* 轻量的Container必定可以在一个物理机上开启更多“容器”，注定比VMs要便宜。

生态系统
正在越来越受欢迎，只需要看一看Google的趋势就知道了，docker or LXC.

还有不计其数的社区和第三方应用。

云支持
不计其数的云服务提供创建和管理Linux容器框架。

有关Docker性能方面的优势，还可参考此IBM工程师对性能提升的评测，从各个方面比VMs（OS系统级别虚拟化）都有非常大的提升。转载，仅供参考。

D. 什么是K8S

‍

k8s是什么?

Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

secret

Secret有三种类型：

• Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；
• /run/secrets/kubernetes.io/serviceaccount
• Opaque：base64编码格式的Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

k8s的组成

k8s是由组件,API,对象等组成.

包含所有相互关联组件的 Kubernetes 集群图如下:

组件

• 控制平面组件
  • kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据.
    • 保证集群状态访问的安全
    • 隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。
  • etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。
  • kube-scheler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。
  • cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件
• Node 组件
  • kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。
  • kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
  • 容器运行时: 负责运行容器的软件。
• 插件(Addons)
  • DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
  • Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。
  • 容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
  • 集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

API

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

具体来说，他们可以描述：

• 容器化应用正在运行(以及在哪些节点上)
• 这些应用可用的资源
• 关于这些应用如何运行的策略，如重新策略，升级和容错

Kubernetes 架构

Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

master 流程图

• Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。
• Kubernetes Client将请求发送给API server。
• API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。
• REST Storage API对的请求作相应的处理。
• 将处理的结果存入高可用键值存储系统Etcd中。
• 在API Server响应Kubecfg的请求后，Scheler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。
• 依据从Kubernetes Client获取的信息，Scheler将未分发的Pod分发到可用的Minion/Node节点上。

节点

节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

可以使用 kubectl 来查看节点状态和其他细节信息：

kubectl describe node <�节点名称>

一个节点包含以下信息:

• 地址
  • HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。
  • ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
  • InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
• 状况(conditions 字段描述了所有 Running 节点的状态)
  • Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 40 秒）没有收到节点的消息
  • DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 False
  • MemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 False
  • PIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 False
  • NetworkUnavailable为True则表示节点网络配置不正确；否则为 False
• 容量与可分配
  • 描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
• 信息
  • 关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

控制面到节点通信

• 节点到控制面
  • apiserver在安全的 HTTPS 端口（443）上监听远程连接请求
  • 以客户端证书的形式将客户端凭据提供给 kubelet
• 控制面到节点
  • API 服务器到 kubelet连接用于
    • 获取 Pod 日志
    • 挂接（通过 kubectl）到运行中的 Pod
    • 提供 kubelet 的端口转发功能。
    • (注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全.)
  • apiserver 到节点、Pod 和服务
    • SSH 隧道(目前已经废弃)
      • 产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.
      • Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。
    • Konnectivity 服务
      • 为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。

控制器

在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。

控制器模式分为直接控制和通过API服务器来控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。

云控制器管理器中的控制器包括：

• 节点控制器
  • 节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。
  • 执行功能:
    • 针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象
    • 利用特定云平台的信息为 Node 对象添加注解和标签
    • 获取节点的网络地址和主机名
    • 检查节点的健康状况。
• 路由控制器
  • Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。
• 服务控制器
  • 服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。

Kubernetes 安全性

云原生安全

云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

Kubetnetes 基础架构关注领域

建议

通过网络访问 API 服务（控制平面)

所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。

通过网络访问 Node（节点)

节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。

Kubernetes 云访问提供商的 API

每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

访问 etcd

对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

etcd 加密

在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。

集群组件安全

• 运行的应用程序的安全性关注领域
  • 访问控制授权(访问 Kubernetes API)
  • 认证方式
  • 应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)
  • Pod 安全策略
  • 服务质量（和集群资源管理）
  • 网络策略
  • Kubernetes Ingress 的 TLS 支持

容器安全

• 容器安全性关注领域
  • 容器搭建配置(配置不当,危险挂载, 特权用户)
  • 容器服务自身缺陷
  • Linux内核漏洞
  • 镜像签名和执行

代码安全

• 代码安全关注领域
  • 仅通过 TLS 访问(流量加密)
  • 限制通信端口范围
  • 第三方依赖性安全
  • 静态代码分析
  • 动态探测攻击(黑盒)

Kubernetes架构常见问题

Kubernetes ATTACK 矩阵

信息泄露

云账号AK泄露

API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

API凭证相当于登录密码，用于程序方式调用云服务API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。

云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。

Master节点SSH登录泄露

常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。

云服务器提供了通过ssh登陆的形式进行登陆master节点.

若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

容器组件未鉴权服务

Kubernetes架构下常见的开放服务指纹如下:

• kube-apiserver: 6443, 8080
• kubectl proxy: 8080, 8081
• kubelet: 10250, 10255, 4149
• dashboard: 30000
• docker api: 2375
• etcd: 2379, 2380
• kube-controller-manager: 10252
• kube-proxy: 10256, 31442
• kube-scheler: 10251
• weave: 6781, 6782, 6783
• kubeflow-dashboard: 8080

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

1. 用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)
2. kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https
3. apiserver 会协同 ETCD, kube-controller-manager, scheler 等组件准备下发新建容器的配置给到节点，协议：http/https
4. apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
5. kubelet 与Docker等容器引擎进行交互，创建容器，协议：http/unix socket.
6. 容器已然在集群节点上创建成功

攻击apiserver

apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.

在攻击者眼中Kubernetes APIServer

• 容器编排K8S总控组件
• pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,
• endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,
• persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …
• 可控以上所有k8s资源
• 可获取几乎所有容器的交互式shell
• 利用一定技巧可获取所有容器母机的交互式shell

默认情况下apiserver都有鉴权:

未鉴权配置如下:

对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：

如何通过apiserver来进行渗透,可参考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

攻击kubelet

每一个Node节点都有一个kubelet(每个节点上运行的代理)服务，kubelet监听了10250，10248，10255等端口。

10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下，不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.

在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看

根据在pods中获取的信息,我们可以在容器中执行命令

curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} -d 'input=1' -d 'output=1' -d 'tty=1' -d 'command=whoami'

上述命令得到websocket地址，连接websocket得到命令结果：

使用wscat工具连接websocket

wscat -c “https://X.X.X.X:10250/{websocket}” --no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets/kubernetes.io/serviceaccount

然后即可访问kube-api server,获取集群权限

curl -ks -H "Authorization: Bearer ttps://master:6443/api/v1/namespaces/{namespace}/secrets

"

攻击kubelet总体步骤如下:

• 访问pods获取信息
• 获取namespace、podsname、containername
• 执行exec获取token
• /var/run/secrets/kubernetes.io/serviceaccount
• 利用Token访问API Server进行对pods操作。

攻击dashboard

dashboard登陆链接如下:

http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下，通过dashboard我们可以控制整个集群。

默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.

通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理，不同的serviceaccount拥有不同的集群权限。

但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole（cluster-admin拥有管理集群的最高权限）.

为Kubernetes-dashboard绑定cluster-admin 设置如下:

1. 新建dashboard-admin.yaml内容
2. apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
3. kubectl create -f dashboard-admin.yaml

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

• 检查是否正常链接
• etcdctl endpoint health
• 读取service account token
• etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
• 通过token认访问API-Server端口6443，接管集群：
• kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="[ey...]" -n kube-system get pods

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接操作：

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

-H

因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击kubectl proxy

二次开发所产生的问题

管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能，其实都是间接在和 APIServer 做交互.

如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。

例如:

• 给用户销毁自己POD的能力
• DELETE https://apiserver:8443/api/v1/namespaces/default/pods/sleep-75c6fd99c-g5kss

类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.

推荐工具

Kube-Hunter扫描漏洞

kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器

下载地址: https://github.com/aquasecurity/kube-hunter

CDK(强推)

CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

下载地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN

参考链接

https://developer.aliyun.com/article/765449?groupCode=aliyunsecurity
https://xz.aliyun.com/t/4276#toc-2
https://www.secrss.com/articles/29544
https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-pod
https://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.html
https://www.kubernetes.org.cn/service-account
https://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
https://www.cdxy.me/?p=827

E. 云容器和虚拟机哪个好

原生的对立面当然是非原生（虚拟化），即使是在CPU 和操作系统内核支持的情况下虚拟机上的操作系统及业务系统所使用硬件资源仍然不直接寻址的。一个基于虚拟机运行的业务系统与原生操作系统中间隔着一个虚拟系统，有如人与人之间隔阂，不仅会损失硬件性能还会让多可以直接寻址的接口操作都需要驱动级的映射才能完成，兼容性的问题有时也困扰运维人员。而容器技术越发成熟之后各个沙盒间的相互独立互不影响，却能直接使用原生系统的资源。硬件资源的利用率更高。而且容器的创建与维护比虚拟机更简单，一个业务系统在虚拟机上交付，需要有足够的资源来创建虚拟机，然后为虚拟机安装操作系统、部署业务系统所需的各种支持环境。如果多个业务系统所需要支持环境依赖库间有冲突互斥你则需要新建更多的虚拟机。反之对于容器而言只需要再开一个镜像即可。

云原生更节省物理服务器的硬件资源；更易于业务系统的快速交付。是微服务架构、无服务器架构的时代这项技术更为云平台服务提供了基础支撑，在虚拟化时代一个开发人员为了发布自己的应用，需要去租用一个云主机或VPS ，自由的按需配置管理云主机的操作系统与支持环境配置及参数，然后发布自己业务和WEB应用。在采用无服务架构在模式下，你可能根本不需要一台服务器，更不用去关于如何去配置服务器，需要只是服务本身，云端的容器中的WEB 服务或数据库服务会提供接口给开发者，开发者只用关心程序的实现，不用折腾服务器与环境的配置。

F. 容器云技术有什么特点

1.容器云技术在计算形态上面是一种轻量级的虚拟化技术，是进程级的虚拟化形态封装，容器的启动和部署的迅速，可以在应用层面按照资源进行快速的部署和调度的，这样生命周期的变化速度也就很快了。
2.它是可以移植的一种技术，能够降低成本。当前容器云技术的现代形式，主要是体现在应用程序容器化和系统容器化方面。这两种形式的容器都是可以让IT团队从底层的架构中抽象出程度代码的，这样就可以实现跨各种部署环境的可移植性了。
3.容器一般是位于物理服务器以及主机操作系统之上的。它可以通过单个的操作系统安装去运行多个工作环境，因此容器是非常轻的，它们只有几兆的字节，只需要几秒钟就可以启动了。另外，内存，存储和CPU效率的提高，是容器云技术的关键优势。它可以在同一基础架构上面支持更多的容器，这样就可以减少管理方面的开支了。
国内做的比较好的我推荐时速云，他们服务过500+的中大型客户，不仅涵盖容器云 PaaS、DevOps、微服务、ServiceMesh、API 网关等核心云原生产品，还可以为企业提供数据开发、数据治理、数据资产、数据服务等数据能力。感兴趣的可以去了解一下！

G. 容器云部署前后应该注意的事情有哪些

第一，在进行容器云部署之前先要做到事情就是了解目标服务器，因为服务器缔造了整个系统的环境，因此就要先了解其特征如何。像服务器的内存参数多大以及服务器的代码优化做到哪一步，这些都会和项目所需要的内存多大以及代码性能优化工作有直接关系，同样是在部署之前要做的工作还有对于数据库的了解和目标机器的基本了解等。
第二，在进行容器云部署的时候自然要委托专业团队来做，这里需要专业的开发团队，可以了解一下时速云的案例，他们服务过500+的中大型客户，有丰富的经验，过程中要注意随时记录问题。在实际部署过程中需要考虑的情况很多，更多的问题都是需要随机应变的，同时还应该注意的就是使用的软件应该是新版本的以及网络环境的勘测和了解。
第三，在容器云部署之后还要重视客户的反馈情况，然后根据客户反馈来进行系统的隐患排查和代码程序的优化，同时还要注意的就是反馈后找到系统中同类问题，这样才能更好的进行优化。

H. 容器云技术的优势是什么

1.容器云技术在计算形态上面是一种轻量级的虚拟化技术，是进程级的虚拟化形态封装，容器的启动和部署的迅速，可以在应用层面按照资源进行快速的部署和调度的，这样生命周期的变化速度也就很快了。
2.它是可以移植的一种技术，能够降低成本。当前容器云技术的现代形式，主要是体现在应用程序容器化和系统容器化方面。这两种形式的容器都是可以让IT团队从底层的架构中抽象出程度代码的，这样就可以实现跨各种部署环境的可移植性了。
3.容器一般是位于物理服务器以及主机操作系统之上的。它可以通过单个的操作系统安装去运行多个工作环境，因此容器是非常轻的，它们只有几兆的字节，只需要几秒钟就可以启动了。另外，内存，存储和CPU效率的提高，是容器云技术的关键优势。它可以在同一基础架构上面支持更多的容器，这样就可以减少管理方面的开支了。
国内做的比较好的我推荐时速云，他们服务过500+的中大型客户，不仅涵盖容器云 PaaS、DevOps、微服务、ServiceMesh、API 网关等核心云原生产品，还可以为企业提供数据开发、数据治理、数据资产、数据服务等数据能力。感兴趣的可以去了解一下！

I. 容器云是什么技术对比于虚拟机有什么特点

容器云是近两年在云计算技术中新兴的一种产品形式，容器在计算形态上是归属于轻量级的虚拟化技术。和传统虚拟化内核级的Guest OS的封装不同，容器服务是进程级的虚拟化形态封装，启动速度和部署的速度都十分迅速，能够在应用层面根据资源的需求进行快速部署与调度，生命周期变化速度快。
之所以会有容器云的出现，主要还是因为时代的发展趋势所导致。由于在2010年，国外Cloud，Docker等容器技术刚刚创立，这无非给云计算指明了一条明确的道理，此后K8s和Docker等技术就火的一塌糊涂。
而对比于传统虚拟机，容器云有什么特点呢？
一：可移植性
目前容器技术主要体现在应用程序容器化（Docker）和系统容器化上。这两种形式的容器都能让IT团队从底层架构中抽象出程序代码，进一步实现各种部署环境的可移植性。
二：轻量级
容器通常部署在物理服务器及其主机操作系统上，它可以通过单个操作系统安装来运行多个工作环境，因此容器云特别“轻”，仅仅需要几秒钟就可以启动。
三：降低成本
与传统虚拟机相比，CPU,内存和存储效率的提高是容器技术最大优势。在同一基础架构上支持更多容器，那么这些资源的减少就转化成巨大的成本，同时也大大减少了管理开销。

J. 什么是容器云

容器云是PaaS 层的云交付模式。容器云可以通过两种方式部署：一种是在虚拟机上部署容器(在许多传统企业中，容器部署在虚拟机上)；另一种方法是在裸机服务器上直接部署容器。将容器部署到虚拟机的原因是它们需要虚拟机的隔离和安全特性。
事实上，为了达到同样的效果，不需要使用虚拟机，或者随着技术的发展，这些问题都有可能在容器中解决。将来，那些可以在虚拟机上运行的应用程序可以运行到容器中，因此容器云将取代传统的IaaS。然而，对于大多数企业来说，这仍然是一件相对遥远的事情。现在，最重要的是结合自身实际需要，充分利用集装箱技术。
无论是虚拟机与容器的结合，还是容器直接部署在裸金属服务器上，只要容器技术能为企业创造业务价值，就有价值和意义。