请问“接口服务器”、“应用服务器” 、“数据库服务器”分别是指什么意思？

数据库：存储数据的应用软件。

服务器：公共的服务库。

应用服务器是应用的服务器，提供应用服务，也可以是自己的网络应用服务器，接口服务器是提供给第三方调用的服务，主要是为了自己的应用的安全性，所以只把能供给第三方调用的东西封装在应用服务器服务器。

根据应用环境的不同，需要的数据库服务器也不同，一般来说，如果数据库服务器需要连接的客户端多、并且是不同权限组的客户端的话需要网络接口比较多的，除此之外，数据库服务器的处理器性能要求比较高，因为其要进行频繁的操作，内存要求大，加快数据存取速度。

应用服务器相对而言要求低一些，如果是FTP服务器的话网卡的速率要求要高，起码是千兆的，网页服务器对于网卡的速率也同样有较高的要求，但对于处理器性能要求就不那么高了。

应用程序服务器是为应用程序提供业务逻辑的。它是基于组件的，位于以服务器为中心的架构的中间件。

这个架构通常是一个主要的基于Web的界面。中间件是业务逻辑所在的应用服务器。而第三层，后端是负责数据库的服务器。应用程序服务器充当用户和数据库之间的交互。

应用服务器通过各种协议向客户端应用程序打开业务逻辑。它还可以包括计算机，web服务器或其他应用服务器上的图形用户界面。业务逻辑通过组件API。它还管理自己的资源以及执行安全性，事务处理，资源和连接池以及消息传递。

对于高端要求，应用服务器往往具有高可用性监控，集群，负载平衡，集成冗余和高性能分布式应用服务，并支持复杂的数据库访问。

当需要与现有数据库和服务器（如Web服务器）集成时，应使用应用程序服务器，可以通过启用集中式方法来提供应用程序更新和升级来提供数据和代码的完整性。

可伸缩性是使用应用服务器的另一个原因和好处。应用程序服务器可以与数据库连接。这意味着企业可以扩展Web服务器群，而不需要增加数据库连接的数量。

从网页到数据库的直接链接如果暴露，可导致SQL注入攻击基础架构。

通过单独的数据访问层执行数据验证和／或显示业务逻辑，可以确保以Web表单输入的文本不被用作SQL调用。通过集中身份验证过程以及数据访问管理，还可以提高安全性。

应用程序服务器与Web服务器不同，因为前者通过多种协议处理向应用程序提供业务逻辑，而Web服务器响应并处理HTTP请求；托管一个网站并存储静态内容，如图像，CSS，JavaScript和HTML页面。

虽然Web服务器可能不支持事务或数据库连接，但可能具有容错和可扩展性功能，如负载平衡，缓存和集群。

与数据库服务器不同，因为该服务器执行诸如数据分析，存储，数据处理，归档以及其他数据管理相关任务之类的任务。

数据库服务器使用诸如ODBC，JDBC等协议。他们还将托管数据库，如Oracle，SQLServer，MySQL等。

扩展资料：

服务器是计算机局域网的核心部件。网络操作系统是在网络服务器上运行的，网络服务器的效率直接影响整个网络的效率。

因此，一般要用高档计算机或专用服务器计算机作为网络服务器。网络服务器主要有以下4个作用：

运行网络操作系统，控制和协调网络中各计算机之间的工作，最大限度地满足用户的要求，并做出响应和处理。

存储和管理网络中的共享资源，如数据库、文件、应用程序、磁盘空间、打印机、绘图仪等。

·为各工作站的应用程序服务，如采用客户／服务器（Client／Server）结构使网络服务器不仅担当网络服务器，而且还担当应用程序服务器。

对网络活动进行监督及控制，对网络进行实际管理，分配系统资源，了解和调整系统运行状态，关闭或启动某些资源等。

参考资料：

-网络服务器

　　通过使用web服务来调用各种EC2的API，接着API服务器便通过消息队列把请求送达至云内目标设施进行处理。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，把它叫做“OpenStack API”。

　　

API 服务器为云控制器扮演着web服务前端的角色。这个云框架的核心是API服务器。API服务器命令和控制hypervisor，存储还有网络，让用户可以实现云计算。API端点是一个基础的HTTP网页服务，通过使用多种API接口（Amazon，Rackspace和相关的模型)来提供认证，授权和基础命令和控制功能，增强了API和多种其他供应商已经存在的资源池的兼容性。

　　

点菜单file\loadtextfile\选WIN32API文本文件就可查看了。

API 是windows 系统提供给开发人员的一种接口，都是一些封装了的类或函数。在C：\WINDOWS\SYSTEM32下面的那些动态加载文件（dll/ ocx）为后缀的很多都是。

安装完MicrosoftVisualStudio60后一般附有tools工具中有API查看器APITextViewer，点菜单file\loadtextfile\选WIN32API文本文件就可查看了。

虽然在API侧可以通过在HTTPS请求头部指定特定的属性，允许跨域访问，但基于业务的必要性和安全性考虑，后端接口在上线的时候，一般也不会打开允许跨域的能力。这就为前端的本地开发环境，调用开发环境，测试环境，线上环境的API带来了障碍。

（1）官方的解释相信大家都已经了解了，不了解也没有关系。现在从常识的角度来给大家解释和说明。

OpenStack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。

OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，OpenStack被公认作为基础设施即服务（简称IaaS）资源的通用前端。

如果这些还不明白，那么从另外的角度给大家介绍：

首先让大家看下面两个图就很简单明了了：

此图为openstack的登录界面

下面是openstack的一个管理界面

从这两个图，相信有一定开发经验，就能看出openstack是什么了。可以说他是一个框架，甚至可以从软件的角度来理解它。如果不明白，就从传统开发来讲解。不知道你是否了解oa，erp等系统，如果不了解可以到网上去找，资料一大把。他和oa，erp有什么不同。很简单就是openstack是用做云计算的一个平台，或则一个解决方案。它是云计算一个重要组成部分。

上面对openstack有了一个感性的认识。

（2）openstack能干什么。

大家都知道阿里云平台，百度云平台，而阿里云平台据传说就是对openstack的二次开发。对于二次开发相信只要接触过软件的都会明白这个概念。不明白的自己网上去查一下。也就是说openstack，可以搭建云平台，什么云平台，公有云，私有云。现在百度在招聘的私有云工程师，应该就是这方面的人才。

（3）openstack自身都包含什么

以下是5个OpenStack的重要构成部分：

l Nova – 计算服务

l Swift – 存储服务

l Glance – 镜像服务

l Keystone – 认证服务

l Horizon – UI服务

图1 OpenStack基本构架

下图展示了Keystone、Dashboard二者与其它OpenStack部分的交互。

下面详细介绍每一个服务：

（一）OpenStack计算设施—-Nova Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。

功能及特点

l 实例生命周期管理

l 计算资源管理

l 网络与授权管理

l 基于REST的API

l 异步连续通信

l 支持各种宿主：Xen、XenServer/XCP、KVM、UML、VMware vSphere及Hyper-V

OpenStack计算部件

l Nova弹性云包含以下主要部分：

l API Server（nova-api）

l 消息队列（rabbit-mq server）

l 运算工作站（nova-compute）

l 网络控制器（nova-network）

l 卷管理（nova-volume）

l 调度器（nova-scheduler）

API服务器（nova-api）

API服务器提供了云设施与外界交互的接口，它是外界用户对云实施管理的唯一通道。通过使用web服务来调用各种EC2的API，接着API服务器便通过消息队列把请求送达至云内目标设施进行处理。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，我们把它叫做“OpenStack API”。

消息队列（Rabbit MQ Server）

OpenStack内部在遵循AMQP（高级消息队列协议）的基础上采用消息队列进行通信。Nova对请求应答进行异步调用，当请求接收后便则立即触发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一份镜像的过程较为耗时，API调用就将等待返回结果而不影响其它操作，在此异步通信起到了很大作用，使整个系统变得更加高效。

运算工作站（nova-compute）

运算工作站的主要任务是管理实例的整个生命周期。他们通过消息队列接收请求并执行，从而对实例进行各种操作。在典型实际生产环境下，会架设许多运算工作站，根据调度算法，一个实例可以在可用的任意一台运算工作站上部署。

网络控制器（nova-network）

网络控制器处理主机的网络配置，例如IP地址分配，配置项目VLAN，设定安全群组以及为计算节点配置网络。

卷工作站（nova-volume）

卷工作站管理基于LVM的实例卷，它能够为一个实例创建、删除、附加卷，也可以从一个实例中分离卷。卷管理为何如此重要？因为它提供了一种保持实例持续存储的手段，比如当结束一个实例后，根分区如果是非持续化的，那么对其的任何改变都将丢失。可是，如果从一个实例中将卷分离出来，或者为这个实例附加上卷的话，即使实例被关闭，数据仍然保存其中。这些数据可以通过将卷附加到原实例或其他实例的方式而重新访问。

因此，为了日后访问，重要数据务必要写入卷中。这种应用对于数据服务器实例的存储而言，尤为重要。

调度器（nova-scheduler）

调度器负责把nova-API调用送达给目标。调度器以名为“nova-schedule”的守护进程方式运行，并根据调度算法从可用资源池中恰当地选择运算服务器。有很多因素都可以影响调度结果，比如负载、内存、子节点的远近、CPU架构等等。强大的是nova调度器采用的是可插入式架构。

目前nova调度器使用了几种基本的调度算法：

随机化：主机随机选择可用节点；

可用化：与随机相似，只是随机选择的范围被指定；

简单化：应用这种方式，主机选择负载最小者来运行实例。负载数据可以从别处获得，如负载均衡服务器。

（二）OpenStack镜像服务器—-GlanceOpenStack镜像服务器是一套虚拟机镜像发现、注册、检索系统，我们可以将镜像存储到以下任意一种存储中：

本地文件系统（默认）

l OpenStack对象存储

l S3直接存储

l S3对象存储（作为S3访问的中间渠道）

l HTTP（只读）

功能及特点

提供镜像相关服务

Glance构件

l Glance控制器

l Glance注册器

（三）OpenStack存储设施—-Swift

Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于Amazon Web Service的S3简单存储服务。Swift具有跨节点百级对象的存储能力。Swift内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。

功能及特点

l 海量对象存储

l 大文件（对象）存储

l 数据冗余管理

l 归档能力—–处理大数据集

l 为虚拟机和云应用提供数据容器

l 处理流媒体

l 对象安全存储

l 备份与归档

l 良好的可伸缩性

Swift组件

l Swift账户

l Swift容器

l Swift对象

l Swift代理

l Swift RING

Swift代理服务器

用户都是通过Swift-API与代理服务器进行交互，代理服务器正是接收外界请求的门卫，它检测合法的实体位置并路由它们的请求。

此外，代理服务器也同时处理实体失效而转移时，故障切换的实体重复路由请求。

Swift对象服务器

对象服务器是一种二进制存储，它负责处理本地存储中的对象数据的存储、检索和删除。对象都是文件系统中存放的典型的二进制文件，具有扩展文件属性的元数据（xattr）。

注意：xattr格式被Linux中的ext3/4，XFS，Btrfs，JFS和ReiserFS所支持，但是并没有有效测试证明在XFS，JFS，ReiserFS，Reiser4和ZFS下也同样能运行良好。不过，XFS被认为是当前最好的选择。

Swift容器服务器

容器服务器将列出一个容器中的所有对象，默认对象列表将存储为SQLite文件（译者注：也可以修改为MySQL，安装中就是以MySQL为例）。容器服务器也会统计容器中包含的对象数量及容器的存储空间耗费。

Swift账户服务器

账户服务器与容器服务器类似，将列出容器中的对象。

Ring（索引环）

Ring容器记录着Swift中物理存储对象的位置信息，它是真实物理存储位置的实体名的虚拟映射，类似于查找及定位不同集群的实体真实物理位置的索引服务。这里所谓的实体指账户、容器、对象，它们都拥有属于自己的不同的Rings。

（四）OpenStack认证服务（Keystone）

Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。如下图所示：

Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。除此之外，Keystone提供以下三种服务：

l 令牌服务：含有授权用户的授权信息

l 目录服务：含有用户合法操作的可用服务列表

l 策略服务：利用Keystone具体指定用户或群组某些访问权限

认证服务组件

服务入口：如Nova、Swift和Glance一样每个OpenStack服务都拥有一个指定的端口和专属的URL，我们称其为入口（endpoints）。

l 区位：在某个数据中心，一个区位具体指定了一处物理位置。在典型的云架构中，如果不是所有的服务都访问分布式数据中心或服务器的话，则也称其为区位。

l 用户：Keystone授权使用者

译者注：代表一个个体，OpenStack以用户的形式来授权服务给它们。用户拥有证书（credentials），且可能分配给一个或多个租户。经过验证后，会为每个单独的租户提供一个特定的令牌。[来源：http://blogsinacomcn/s/blog_70064f190100undyhtml]

l 服务：总体而言，任何通过Keystone进行连接或管理的组件都被称为服务。举个例子，我们可以称Glance为Keystone的服务。

l 角色：为了维护安全限定，就云内特定用户可执行的操作而言，该用户关联的角色是非常重要的。

译者注：一个角色是应用于某个租户的使用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑分组，它使得通用的权限可以简单地分组并绑定到与某个指定租户相关的用户。

l 租间：租间指的是具有全部服务入口并配有特定成员角色的一个项目。

译者注：一个租间映射到一个Nova的“project-id”，在对象存储中，一个租间可以有多个容器。根据不同的安装方式，一个租间可以代表一个客户、帐号、组织或项目。

（五）OpenStack管理的Web接口—-Horizon

Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。除此之外，用户还可以在控制面板中使用终端（console）或VNC直接访问实例。总之，Horizon具有如下一些特点：

l 实例管理：创建、终止实例，查看终端日志，VNC连接，添加卷等

l 访问与安全管理：创建安全群组，管理密匙对，设置浮动IP等

l 偏好设定：对虚拟硬件模板可以进行不同偏好设定

l 镜像管理：编辑或删除镜像

l 查看服务目录

l 管理用户、配额及项目用途

l 用户管理：创建用户等

l 卷管理：创建卷和快照

l 对象存储处理：创建、删除容器和对象

l 为项目下载环境变量

本篇文章是深入理解Terraform系列的第一部分。在介绍文章中，我们讨论了为什么每家互联网软件公司都应该使用基础设施即代码（IAC）。那么本篇，我们打算讨论下为什么我们选择Terraform 作为我们的IAC 工具。

如果你在网上搜索“instrastructure-as-code”，很容易看到很多受欢迎的工具：

筛选出它们中你应该使用哪个不是很容易。所有这些上述工具都可以用于基础设施即代码。它们都是开源的，背靠庞大的贡献者社区，可以很好配合各种不同的云服务商。它们都提供商业支持，提供良好的文档——在官方文档和社区资源方面（比如博客文章和StackOverflow问答）。

本篇文章，我们会分成几个特定原因来解释为什么我们会选择Terraform作为IAC工具。与所有技术决策一样，这是一个权衡和优先级的问题，虽然您的特定优先级可能与我们的不同，但我们希望分享我们的思维过程将帮助您做出自己的决定。以下是我们考虑的主要权衡因素：

Chef, Puppet, Ansible, and SaltStack 都是配置管理工具，这意味着它们设计初衷都是在现有的服务器上安装和管理软件。CloudFormation 和 Terraform 是配置（provisioning）工具，这意味这它们的设计初衷是配置服务器本身的（以及基础设施的其他部分，比如负载均衡器，数据库，网络配置等），将配置这些服务器的工作留给其他工具。这两类工具互相不排斥的。因为大多数配置管理工具可以在某种程度上多一些配置工作而大多数配置工具也可以在某种程度上做配置管理的工作。但是聚焦于配置管理或者配置意味着，这些工具对于特定类型的任务会更加合适。

想Chef,Puppt,Ansible 这样的配置管理工具默认针对一种可变的基础设施范例。比如，如果你告诉Chef 安装一个新版本的OpenSSL,它就会在你现有的服务器上运行软件更新并且就地生效。随着时间推移，你会更新的更多，每台服务器都会构建一个唯一的修改 历史 。这通常会导致称为配置漂移或者误差的现象，其中每个服务器与所有其他服务器略有不同，导致难以诊断且几乎不可能再现的细微配置错误。

如果你正在使用像Terraform这样的配置工具来部署由Docker 或者 Packer创建的镜像，那么每次"修改"事实上都是一次新服务器的部署（就像是函数式编程中每次变量的修改事实上会返回新的变量）。比如，当我们部署一个新版本的OpenSSL，你会用装有新版本OpenSSL的Packer或者Docker来创建镜像，然后在整组新服务器中部署那个镜像，同时卸载老的镜像。这种方法减少了配置偏差问题的可能性，使得了解服务器上运行了哪些软件变得更加容易，同时可以让你任何时候都可以轻松部署任何版本的软件。当然，也可以强制配置管理工具来做不可变部署。但是对这些工具来说，这不是惯用的方式。不管怎样，使用配置工具都是一种更加自然的方式。

Chef和Ansible鼓励一种程序风格，您可以编写代码，逐步指定如何实现预期状态。 Terraform，CloudFormation，SaltStack和Puppet都鼓励更具说明性的风格，您可以编写指定所需最终状态的代码，IAC工具本身负责确定如何实现该状态。

例如，假设您要部署10台服务器（AWS术语中的“EC2 Instances”）来运行应用程序的v1版本。以下是使用过程方法执行此操作的Ansible模板的简化示例：

表面上看，这两种方法可能看起来相似，当您最初使用Ansible或Terraform执行它们时，它们将产生类似的结果。有趣的是，当您想要进行更改时会发生什么。

例如，假设流量增加，并且您希望将服务器数量增加到15。使用Ansible，您之前编写的过程代码就没法使用了;如果您刚刚将服务器数量更新为15并重新启动该代码，那么它将部署15台新服务器，总共25台服务器！因此，您必须了解已部署的内容并编写一个全新的过程脚本来添加5台新服务器：

如果你执行了这个模板，Terraform会意识到它已经创建了10个服务器，因此它需要做的只是创建5个新服务器。实际上，在运行此模板之前，您可以使用Terraform的 plan 命令来预览它将进行的更改：

显然，上述例子是简化的。 Ansible允许您在部署新的EC2实例之前使用标签来搜索现有的EC2实例（例如，使用instance_tags和count_tag参数），但是必须根据每个资源的情况为Ansible管理的每个资源手动找出这种逻辑。 过去的 历史 ，可能会令人惊讶地复杂化（例如，不仅通过标签，还可以通过图像版本，可用区域等查找现有实例）。 这突出了程序IAC工具的两个主要问题：

默认情况下，Chef，Puppet和SaltStack都要求您运行主服务器以存储基础设施的状态并分发更新。 每次要更新基础设施中的某些内容时，都使用客户端（例如，命令行工具）向主服务器发出新命令，主服务器将更新推送到所有其他服务器或那些服务器定期从主服务器中提取最新的更新。

主服务器提供了一些优点。 首先，它是一个单一的中心位置，您可以在其中查看和管理基础设施的状态。 许多配置管理工具甚至为主服务器提供Web界面（例如，Chef Console，Puppet Enterprise Console），以便更容易查看正在发生的事情。 其次，一些主服务器可以在后台连续运行，并强制执行您的配置。 这样，如果有人在服务器上进行手动更改，主服务器可以还原该更改以防止配置偏移。

但是，必须运行主服务器有一些严重的缺点：

Chef，Puppet和SaltStack对无主模式有不同程度的支持，您只需在每个服务器上运行代理软件，通常在一定周期内（例如，每5分钟运行一次的cron作业），并使用它从版本控制（而不是从主服务器）下拉最新更新。 这显着减少了变动的次数，但是，如下一节所述，这仍然留下了许多未答复的问题，尤其是关于如何配置服务器以及首先在其上安装代理软件的问题。

Ansible，CloudFormation，Heat和Terraform默认都是无主的。 或者，更准确一些，它们中的一些可能依赖于主服务器，但它已经是您正在使用的基础设施的一部分，而不是您必须管理的额外部分。 例如，Terraform使用云提供商的API与云提供商进行通信，因此在某种意义上，API服务器是主服务器，除了它们不需要任何额外的基础设施或任何额外的认证机制（即，只使用您的API密钥）。 Ansible的工作方式是通过SSH直接连接到每个服务器，因此，您不必再运行任何额外的基础结构或管理额外的身份验证机制（即只使用SSH密钥）。

Chef，Puppet和SaltStack都要求您在要配置的每台服务器上安装代理软件（例如，Chef Client，Puppet Agent，Salt Minion）。 代理通常在每个服务器的后台运行并负责

安装最新的配置管理更新。

这有一些缺点：

再强调一次，Chef，Puppet和SaltStack都对无代理模式（例如，salt-ssh）有不同程度的支持，但是这些通常感觉它们是作为事后的想法加入的，并不总是支持完整的配置管理工具的功能集。这就是为什么Chef，Puppet和SaltStack的默认或惯用配置几乎总是包含一个代理，通常也包含一个master。

所有这些额外的动态部分都会在您的基础架构中引入大量新的故障模式。 每次凌晨3点收到错误报告时，您都必须弄清楚它是否是应用程序代码，IAC代码，配置管理客户端，主服务器或者服务器中的错误。 客户端与主服务器通信，或者其他服务器与主服务器通信的方式，或者

Ansible，CloudFormation，Heat和Terraform不要求您安装任何额外的代理。 或者，更准确一些，它们中的一些需要代理，但这些代理通常已作为您正在使用的基础结构的一部分安装。 例如，AWS，Azure，Google Cloud和所有其他云提供商负责在每台物理服务器上安装，管理和验证代理软件。 作为Terraform的用户，您不必担心任何问题：您只需发出命令然后云服务商会在所有你的服务器上为你执行它们。 使用Ansible，您的服务器需要运行SSH守护程序，不管怎么样，这都会普遍运行在大多数服务器上的。

选择任何技术时要考虑的另一个关键因素是成熟度。 下表显示了每个IAC工具的初始发布日期和当前版本号（截至2019年5月）。

同样，这不是一个同类的比较，因为不同的工具有不同的版本控制方案，但一些趋势是明确的。 到目前为止，Terraform是此比较中最年轻的IAC工具。 它仍然是处于100版本之前，因此无法保证稳定或向后兼容的API，并且错误相对常见（尽管大多数都是次要的）。 这是Terraform最大的弱点：虽然它在短时间内变得非常受欢迎，但使用这种新的尖端工具所付出的代价是它不像其他一些IAC选项那样成熟。

虽然我一直在比较整个博客文章中的IAC工具，但事实是您可能需要使用多种工具来构建您的基础设施。 您看到的每个工具都有优点和缺点，因此您需要为正确的工作选择合适的工具。

以下是我见过的三种常见组合在很多公司都很好用：

配置 + 配置管理

示例：Terraform和Ansible。 您可以使用Terraform部署所有底层基础设施，包括网络拓扑（即VPC，子网，路由表），数据存储（例如，MySQL，Redis），负载均衡器和服务器。 然后，您使用Ansible在这些服务器之上部署您的应用程序。

这是一个简单的方法，因为没有运行额外的基础设施（Terraform和Ansible都是客户端应用程序），并且有很多方法可以使Ansible和Terraform一起工作（例如，Terraform为您的服务器添加特殊标签然后Ansible使用这些标签来查找服务器并对其进行配置。 主要缺点是使用Ansible通常意味着您编写了大量程序式代码，使用可变服务器，因此随着代码库，基础架构和团队的增长，维护可能会变得更加困难。

配置 + 服务器模板

示例：Terraform和Packer。您使用Packer将应用程序打包为虚拟机镜像。然后使用Terraform部署（a）具有这些虚拟机镜像的服务器和（b）基础架构的其余部分，包括网络拓扑（即VPC，子网，路由表），数据存储（例如，MySQL，Redis），和负载均衡器。

这也是一种简单的方法，因为没有运行额外的基础设施（Terraform和Packer都是仅客户端应用程序）。此外，这是一种不可变的基础架构方法，这将使维护更容易。但是，有两个主要缺点。首先，虚拟机可能需要很长时间才能构建和部署，这会降低迭代速度。其次，您可以使用Terraform实施的部署策略是有限的（例如，您无法在Terraform中本地实施蓝绿色部署），因此您要么最终编写大量复杂的部署脚本，要么转向编排工具，如下所述。

配置 + 服务器模板 + 编排

示例：Terraform，Packer，Docker和Kubernetes。 您使用Packer创建安装了Docker和Kubernetes的虚拟机映像。 然后使用Terraform部署（a）服务器集群，每个服务器运行此虚拟机镜像，以及（b）基础架构的其余部分，包括网络拓扑（即VPC，子网，路由表），数据存储（ 例如，MySQL，Redis）和负载均衡器。 最后，当服务器集群启动时，它形成一个Kubernetes集群，用于运行和管理Dockerized应用程序。

这种方法的优点是Docker镜像构建相当快，您可以在本地计算机上运行和测试它们，并且您可以利用Kubernetes的所有内置功能，包括各种部署策略，自动修复，自动缩放， 等等。 缺点是增加了复杂性，无论是在运行额外的基础设施方面（Kubernetes集群都很难部署和运营，尽管大多数主要的云提供商现在提供托管的Kubernetes服务，可以减轻部分工作），还是学习、管理和debug额外的抽象层（Kubernetes，Docker，Packer）方面。

‍

k8s是什么

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

为什么现在流行使用容器

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

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

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

为什么需要使用k8s容器

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

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

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

名词解释

secret

Secret有三种类型：

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

k8s的组成

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

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

组件

控制平面组件kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据保证集群状态访问的安全隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。kube-scheduler: 收集和分析当前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的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。依据从Kubernetes Client获取的信息，Scheduler将未分发的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, 否则为 FalseMemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 FalsePIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 FalseNetworkUnavailable为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, 8080kubectl proxy: 8080, 8081kubelet: 10250, 10255, 4149dashboard: 30000docker api: 2375etcd: 2379, 2380kube-controller-manager: 10252kube-proxy: 10256, 31442kube-scheduler: 10251weave: 6781, 6782, 6783kubeflow-dashboard: 8080

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

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

组件分工图:

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

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

攻击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://Kubernetesio/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://XXXX:10250/{websocket}” --no-check

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

获取token

/var/run/secrets/kubernetesio/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/kubernetesio/serviceaccount利用Token访问API Server进行对pods操作。

攻击dashboard

dashboard登陆链接如下:

http://xxxxxxxxxxxx: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 设置如下:

新建dashboard-adminyaml内容apiVersion: rbacauthorizationk8sio/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbacauthorizationk8sio kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboardkubectl create -f dashboard-adminyaml

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

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

新建一个Pod如下:

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

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na

etcd对内暴露2379端口，本地127001可免认证访问 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

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

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

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

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

docker daemon -H=0000: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://githubcom/aquasecurity/kube-hunter

CDK(强推)

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

下载地址: https://githubcom/cdk-team/CDK/wiki/CDK-Home-CN

参考链接

https://developeraliyuncom/article/765449groupCode=aliyunsecurity

https://xzaliyuncom/t/4276#toc-2

https://wwwsecrsscom/articles/29544

https://kubernetesio/zh/docs/concepts/workloads/pods/#what-is-a-pod

https://wwwhuweihuangcom/kubernetes-notes/concepts/architecture/kubernetes-architecturehtml

https://wwwkubernetesorgcn/service-account

https://wwwaquaseccom/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/

https://wwwcdxyme/p=827