openstack与k8s区别,2020-09-08：KVM和OpenStack的区别？

openstack与k8s区别,2020-09-08：KVM和OpenStack的区别？详细介绍

本文目录一览： openstack和k8s区别是什么？

openstack是1化N，通过虚拟化的方式提供弹性灵活高利用率的计算能力。
hadoop是N化1，通过分布式文件系统提供强大的数据处理能力。

什么是Kubernetes？

Kubernetes简称K8S，是用8代替名字中间的8个字符“ubernete”而成的缩写。它是当今业界的流行语，同时也是一款非常非常好用的编排工具，吸引了很多专业人士的喜欢。
Kubernetes是一个开源容器管理工具，负责容器部署，容器扩缩容以及负载平衡。
它提供了出色的社区，并与所有孕提供商合作。因此，我们可以说Kubernetes不是一个容器化平台，而是一个多容器管理解决方案。
Kubernetes也叫做K8s,是一种可以自动部署、拓展和管理的开源系统。

我们可以用OpenStack管理虚拟机资源，那针对容器技术是否有对应的开源平台呢？Kubernetes就是其中一个。

那如何使用Kubernetes去实现容器云呢？简单地说，当前最流行的组合方式就是Docker+Kubernetes。

早在2000年左右，Google内部就开始了容器技术的管理，当时命名叫Borg。未开源时，Kubernetes的代号是Seven，即《星际迷航》中的Borg（博格人，该系列剧中最大的反派，通过“同化”来繁衍）。

选择Kubernetes这个名字的原因之一是船舵有7个轮辐，代表着这个项目最初的名称“Project Seven of Nine”。

hadoop和OpenStack有什么区别，请帮我扫扫盲

openstack是一个iaas云平台（云计算saas，paas，iaas中的iaas），是亚马逊aws的开源实现。OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
hadoop是一个分布式的软件架构，有分布式计算和分布式存储。
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。
Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。

2020-09-08：KVM和OpenStack的区别？

福哥答案2020-09-08：
此答案来自知乎
KVM只是一个虚拟机技术，别的还有xen，商业的vmware、virtualbox等，它们都可以用来创建虚拟机。openstack是为了管理KVM之类的虚拟机而出现的管理平台。假设你有10台物理机，你有一个在这10台物理机上创建100台虚拟机的需求，openstack就可以帮你协调这些物理机，决定哪些虚拟机运行在哪些物理机上。以及它们的存储管理，还有相互之间的网络互通。以及和外界的通信等，各种围绕着这些虚拟机的配套服务。

评论

云计算培训学什么？

云计算作为IT行业的热门技术，它频繁出现在各大媒体的新闻报道中。BAT这样的互联网企业，也经常把它挂在嘴边。相信很多人都想学习云计算，跟上技术潮流。如果对云计算有一定了解的话，应该会或多或少地听到这些名词——OpenStack、Hypervisor、KVM、Docker、K8S…
首先以上这些名词，全部都属于云计算的范畴以前电脑被发明的时候，还没有网络，每个电脑（PC），就是一个单机。这台单机，包括CPU、内存、硬盘、显卡等硬件。用户在单机上，安装操作系统和应用软件，完成自己的工作。后来，有了网络（Network），单机与单机之间，可以交换信息，协同工作。再后来，单机性能越来越强，就有了服务器（Server）。人们发现，可以把一些服务器集中起来，放在机房里，然后让用户通过网络，去访问和使用机房里的计算机资源。
再再后来，小型网络变成了大型网络，就有了互联网（Internet）。小型机房变成了大型机房，就有了IDC（Internet Data Center，互联网数据中心）。当越来越多的计算机资源和应用服务（Application，例如看网页，下电影）被集中起来，就变成了——“云计算（Cloud Computing）”。无数的大型机房，就成了“云端”。
云计算的道理是简单的，说白了，就是把计算机资源集中起来，放在网络上。但是，云计算的实现方式，就复杂了。这个计算机资源，实际上，分为好几种层次：
第一层次，是最底层的硬件资源，主要包括CPU（计算资源），硬盘（存储资源），还有网卡（网络资源）等。
第二层次，要高级一些，我不打算直接使用CPU、硬盘、网卡，我希望你把操作系统（例如Windows、Linux）装好，把数据库软件装好，我再来使用。
第三层次，更高级一些，你不但要装好操作系统这些基本的，还要把具体的应用软件装好，例如FTP服务端软件、在线视频服务端软件等，我可以直接使用服务。
这三种层次，就是大家经常听到的IaaS、Paas、SaaS。
SaaS: Software-as-a-Service（软件即服务）
PaaS: Platform-as-a-Service（平台即服务）
IaaS: Infrastructure-as-a-Service（基础设施即服务）
结合实际案例来说明一下打两个比喻：
自来水
云计算其实就像家里自来水一样。为了喝上干净的自来水，我们家里有没有必要建一个自来水厂？显然不需要。只需要把水龙头打开就可以获得要喝的水。云计算给大家提供了一种模式，其实就类似自来水一样。未来你想获得什么东西，不需要有很大的硬盘，也不需要你的电脑有非常强的处理能力，只要需要，随时随地可以获得。这种新型计算，在无所不在的网络环境下给大家带来了一种新的信息获得方式或者是信息使用模式就是云计算模式。
挖掘机
例如小明是做挖掘机业务的，买了3台挖掘机，王村有工地就去给王村挖，李村要盖房就去给李村挖……于是，王村的老王和李村的老李都高兴了，终于不用花钱买个挖掘机就用那么三两次了，小明也高兴了，有了好机器我只要揽活儿就稳挣钱了！所以这就是云计算，老张老李就是客户端，小明就是云端，挖掘就是计算。
培训学什么主要还是看企业需要用的云计算所涉及到的技术，比如千锋的培训课程就是以下四个阶段：
第一阶段：云计算基础，包含Linux系统管理及服务配置实战和Linux云计算网络管理实战，学完此阶段可以带领学员走入网络的世界、了解重定向工作原理、磁盘列阵RAID、构建企业级交换网络；
第二阶段：云计算高级，包含开源数据库SQL运维实战、Linux Shell自动化运维编程实战、python自动化运维开发，学完此阶段学员可以实现MySQL数据实时备份、将海量小文件快速复制到远程主机、构建企业级路由网络、操作数据库、异常处理；
第三阶段：云计算项目，包含大型网站高并发架构及自动化运维项目、公有云运维技术项目实战、web安全渗透攻防项目实战，学完此阶段学员可以保证服务的在线率、提高网站的并发量、整合Kafka和ELK，进行日志采集平台的建设、web安全渗透实验室构建；
第四阶段：包含企业私有云容器化架构运维实战和企业级大型综合项目实战演练，学完此阶段学员可以理解容器编排、部署kubernetes集群-kubeadm方式、并完成链家网机遇容器的企业级缓存服务器环境部署实战和新浪基于容器环境的大型网站CI/CD综合应用实战等项目。
云计算的学习，照顾计算机0基础的人员就会从计算机基础讲起（计算机硬件、口速度、虚拟机NAT网络设置等等），Raid设置与网络服务基础。
服务器基础毕竟还是Linux，所以还学好Linux运维之后再完善好云部分知识。其中学习的内容有：网络基础；系统基础；系统基础命令；脚本shell；Python编程；常用服务安装与配置；Linux核心服务实战；WEB服务（nginx）配置与优化；数据库（MySQL安装、配置、备份、恢复）；Nosql 数据库（Redis\MongoDB）；负载均衡与高可用架构实践；监控服务；企业生产项目实践；常用中间件服务（Kafka\Rabbitmq\Zookeeper等）；
云计算集群：Docker 容器技术；代码管理（Git）；日志平台；Kubernetes 技术实践；自动化系列（DevOps）；常用工具；K8s。
云计算学习还是比较系统的，薪享宏福是线下面授学习效果较好。还能对接就业岗位工作。
大数据：
一个数据库可以用于某种专项目的。比如小学生管理数据库，可有姓名，年龄，成绩等。
如果把许多数据库综合起来使用，可以达到各种各样的目的。这个组合而成的数据库集合，就是「大数据」
云计算：
一般计算机可完成很多工作，但它实质性的工作只是「计算」。把这个计算工作，不在本地，或者说不在自己家里计算机做，通过联网，在巨大的计算机中心去计算。这就是「云计算」。为什么是云呢，是联网示图上通常把网络用云形符号表示。
头一阶段为Linux云计算网络管理实战;
第二阶段为Linux云主机系统管理和服务配置实战;
第三阶段为Linux shell脚本自动化编程实战;
第四阶段为开源库SQL/NOSQL运维实战;
第五阶段为大型网站高并发架构及自动化运维项目;
第六阶段为网站安全渗透测试及性能调优项目实战;
第七阶段为公有云运维技术项目实战;
第八阶段为企业私有云架构及运维实战;
第九阶段为Python自动化运维开发基础
第十阶段为Python自动化运维开发项目实战
　　你将学到这些内容：
第一阶段课程为Linux云计算网络管理实战，学完此阶段学员可以根据网络协议准确判断error的位置、可以在交换机上进行VLAN的划分、可以利用抓包工具分析网络数据;第二阶段课程为Linux云主机系统管理和服务配置实战，学完此阶段学员可对Linux系统进行基本的管理操作、可以在Linux系统中配置部署域名解析服务、能够在Linux系统中配置LAMP架构的网站服务;第三阶段课程为Linux Shell脚本自动化编程实战，学完此阶段学员可以使用awk or sed在命令行中处理文本文件、实现服务器的初始化、批量传输文件、编写运维工具;第四阶段为开源数据库MySQL DBA运维实战，学完此阶段学员可以搭建MySQL主从复制的架构实现数据实时备份、可以运维MySQL组建的集群、能够实现数据可视化操作;第五阶段课程为企业级自动化项目及公有云运维实战，学完此阶段学员能够部署出一台服务器给多台主机安装系统、可以利用Ansible管理成千上百台服务器、利用Nginx部署支持高并发的网站、部署Zabbix来监控主机的异常情况，以及编写自定义报警处理脚本;第六阶段课程为大型网站高并发架构运维实战，学完此阶段学员可以做网站的容灾策略，保证服务的在线率、利用Nginx缓存加快用户访问网站的速度、提高网站的并发量;第七阶段为Python Linux自动化运维开发实战，学习目标1.python运维工具编写2.python管理Amazon EC2服务器3.python管理数据库;第八阶段为企业私有云架构及运维实战，学习目标：1)能够在企业中构建私有云平台;2)维护私有云出现的错误;3)搭建混合云。

K8s持久化存储

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
要使用 Volume，Pod 必须事先知道如下信息：
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
要么询问管理员。
要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是什么 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
1、配置nfs
需要安装
k8s-master：nfs-server
k8s-node1：nfs-client
k8s-node2：nfs-client
所有节点安装nfs
在master节点创建共享目录
编辑exports文件
启动rpc和nfs（注意顺序）
作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata：
2、创建PV
下面创建一个 PV mypv，配置文件 nfs-pv.yml 如下：
① capacity 指定 PV 的容量为 1G。
② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce：PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany：PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany ：PV 能以 read-write 模式 mount 到多个节点。
③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain： 需要管理员手工回收。
Recycle：清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete： 删除 Storage Provider 上面的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、- OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
⑤ 指定 PV 在 NFS 服务器上对应的目录。
创建 mypv：
STATUS 为 Available，表示 mypv 就绪，可以被 PVC 申请。
3、创建PVC
接下来创建 PVC mypvc，配置文件 nfs-pvc.yml 如下：
部署pvc
4、创建pod
上面已经创建好了pv和pvc，pod中直接使用这个pvc即可
与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc 申请的 Volume。
通过命令创建mypod：
在这里，可以尝试在任何一方删除文件，文件在两端都会消失；
当 PV 不再需要时，可通过删除 PVC 回收。未删除pvc之前 pv的状态是Bound
删除pod
删除pvc
再次查看pv的状态
删除pvc之后pv的状态变为Available，，此时解除绑定后则可以被新的 PVC 申请。
/nfsdata文件中的文件被删除了
因为 PV 的回收策略设置为 Recycle，所以数据会被清除，
但这可能不是我们想要的结果。如果我们希望保留数据，可以将策略设置为 Retain
虽然 mypv 中的数据得到了保留，但其 PV 状态会一直处于 Released，不能被其他 PVC 申请。为了重新使用存储资源，可以删除并重新创建 mypv。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。
PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
基于NFS的PV动态供给(StorageClass)
静态：pod-->pvc-->pv
动态：pod -->pvc-->storageclass
去官网下载三个文件
这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
使用脚本批量下载：
其中deployment.yaml需要修改一下挂载的地址,目录,镜像版本
然后分别去应用这三个文件
创建pod进行测试
查看pv和pvc
在部署 statefulset 类型的工作负载时，动态创建 PV/PVC 是一种比较常用的配置方式，动态创建 PV/PVC 的方法基本如下：
一直启动不起来，查看 pvc 和 pods 信息如下：
从上边的现象来看，是 PVC 没有创建成功，动态 PVC 中，是 provisioner 中来负责创建，查看其日志，看到如下错误信息：
Google 之后，找到主要原因是，官方在 k8s 1.20 中基于对性能和统一 apiserver 调用方式的初衷，移除了对 SelfLink 的支持，而 nfs-provisioner 需要 SelfLink 该项功能。具体计划和原因可查看这个 issue[2] 和 KEP[3] 。
K3S 为兼容 K8S 应该也继承了该项修改，按 K8S 的方式修改测试了下，完美解决。
解决问题主要有下边两种方式：
1、修改 apiserver 的配置文件，重新启用 SelfLink 功能。针对 K8S，可添加如下配置：
K3S 中没有 apiserver 的配置文件，可通过 systemd 的启动文件添加该参数，如下：
若为新安装，可如下启用：
2、使用新的不基于 SelfLink 功能的 provisioner 镜像，重新创建 provisioner 容器。
若你能科学上网，可使用这个镜像：
国内可使用这个镜像【若不可用自己查找】：

全面认识openstack，它到底是什么？包含什么

OpenStack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，OpenStack被公认作为基础设施即服务（简称IaaS）资源的通用前端。
openstack自身都包含什么
以下是5个OpenStack的重要构成部分：
l Nova – 计算服务
l Swift – 存储服务
l Glance – 镜像服务
l Keystone – 认证服务
l Horizon – UI服务
OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。
OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它的社区拥有超过130家企业及1350位开发者，这些机构与个人都将OpenStack作为基础设施即服务（IaaS）资源的通用前端。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。本文希望通过提供必要的指导信息，帮助大家利用OpenStack前端来设置及管理自己的公共云或私有云。
OpenStack云计算平台，帮助服务商和企业内部实现类似于 Amazon EC2 和 S3 的云基础架构服务(Infrastructure as a Service, IaaS)。OpenStack 包含两个主要模块：Nova 和 Swift，前者是 NASA 开发的虚拟服务器部署和业务计算模块；后者是 Rackspace开发的分布式云存储模块，两者可以一起用，也可以分开单独用。OpenStack除了有 Rackspace 和 NASA 的大力支持外，还有包括 Dell、Citrix、 Cisco、 Canonical等重量级公司的贡献和支持，发展速度非常快，有取代另一个业界领先开源云平台 Eucalyptus 的态势。
（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://blog.sina.com.cn/s/blog_70064f190100undy.html]
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 为项目下载环境变量

深入理解Kubernetes的认证与授权机制

众所周知，任意一个系统的安全机制的核心都是基于 认证与授权 （Authentication and Authorization）,即首先通过某种方式确认“你”的身份，再根据一定的授权策略确定“你”在我的系统里面能做什么操作。对于K8S来说，就是体现为客户端对于 kube-apiserver 的api接口操作的鉴权（客户端可以是集群内的工作负载pod，任意服务器上的kubectl程序，或是计算节点上的kubelet组件等等）。Kubernets项目作为一个成熟的开源云计算基础设施项目，让我们来看看他们是如何解决认证与授权这两个核心问题的：
k8s的用户认证机制的官方文档地址： https://kubernetes.io/docs/reference/access-authn-authz/authentication/ 。
Kubernetes中的用户类型分为 service accounts 和 normal users 两类。service accounts是k8s内部自建的一套用户认证体系，主要用于pod里直接调用kube-apiserver过程中的认证。而普通用户类型依赖于外部认证服务，k8本身不关心。
当创建service account对象时，会对应的创建一个secret对象，内含了这个用户的认证token，当pod启动时，只要yaml里申明了绑定特定的service account账号，那么系统会自动把secret的token注入到pod中的指定目录，接下来当pod调用apiserver接口时，系统都会自动的附加上这个token，这样apiserver就可以识别出这个pod的身份，结合role和rolebinding的配置信息，就可以正确的授权了。service account是基于k8内部的认证体系，使用起来比较方便，直接在集群内创建sa资源即可。此种类型的用户不是本篇文章讨论的重点，想了解具体的操作可以参考我之前的这篇文章： 构建云原生微服务网关系列-篇二：Zuul ，里面有详细的service account的使用说明。
本文讨论的重点，针对普通用户类型，很多人的理解会比较模糊，对此官网有一段说明：
也就是说，k8项目认为普通用户认证应该由外部服务供应商解决，k8本身不关心认证过程，只要告诉他最终的认证结果，即这个用户是“谁”。认证方式可以用公私钥对，或者openstack 的 keystone认证服务、google的Google Accounts服务，甚至是一个有着用户名和密码列表的文件，对于k8s来说，都是一样的。不管用何种方式去认证，最终结果都是告诉k8s，这个用户是“谁”，也就是它的用户id。这里需要注意的时，对于普通用户类型，k8是不会存储用户信息的，而对于service account类型的用户，k8会保存在etcd里面。普通用户也无法通过api调用直接创建。
Kubernetes 支持使用客户端证书、bearer token、认证代理或者http basic auth等方式进行认证，而无论使用哪种方式，认证插件都需要将以下的用户信息和http请求进行关联：
api-server目前支持的认证方式有：
使用由 k8s 根 CA 签发的证书，提取cn字段作为用户id，O字段作为用户组。我们可以使用openssl工具来进行证书的签发（kubernetes 1.4之后支持了证书中携带用户组信息）：
上述操作会生成一个证书请求，username为 jbeda ，并同时属于两个用户组 app1 和 app2 。
静态token列表文件，需要预先在 API Server 服务器上放置该文件，并且在api server的启动参数中加上 --token-auth-file=SOMEFILE ,token文件为csv格式，应至少包含token, user name, user uid这三个字段(逗号分隔)以及一个可选的group names字段，例如：
注意如果用户组有多个的话，整个用户组需要用双引号括起来。
1.18版本进入稳定版的新特性，支持可以在集群启动时动态的创建和管理token，配置比较多，这里不多赘述，有兴趣直接参考官方文档
跟静态 Token 文件类似，只是使用了用户名密码的形式进行认证，使用的是http basic auth类型的认证方式，启动参数为 --basic-auth-file=SOMEFILE ，文件格式为：
很好理解，不多说了
之前介绍过了，k8s内部用户体系 Service Account 使用的 Token，认证方式也是bearer token。这里需要注意的是官方文档有一个描述：
因为api-server本身并不关注流量是从哪里过来的，所以基于service account创建的token，只要你拿到了这个token，是可以从 集群外部 发起请求的，api-server会将此请求认证为对应的service account用户。拿到token的方式官网也做了说明：
注意和serviceaccount绑定的secret类型为 kubernetes.io/service-account-token ，其中token字段即为我们需要的令牌（jwt格式），拿着这个令牌就可以直接发起请求了。 注意在secret中保存的token是经过base64编码的，实际使用时还需要先进行base64解码操作，可以使用jwt.io网站来查看这个令牌，以下是k8s签发的一个jwt令牌payload部分字段的示例：
新出来的一种认证方式，基于Oauth2，比较复杂，有兴趣可以参考官方文档，这里不介绍了。对于Oauth2认证以及JWT技术比较感兴趣的，可以参考我之前的博文 深入理解Spring Cloud Security OAuth2及JWT 。（阅读量4万多了，也算爆款了:）
搞定了认证，接下来就是授权了。得益于k8s优良的设计，认证和授权是解耦的，所以只要k8系统识别出了用户身份（username或者uid），接下来要做的事情就是一样的了。关于授权部分的官方文档地址： https://kubernetes.io/docs/reference/access-authn-authz/rbac/
事实上k8s本身也支持多种授权类型，比如rbac，abac，node，dynamic admission 等等。这里只介绍下最常用的rbac（基于角色的访问控制），实际使用中，api-server开启 --authorization-mode=RBAC 参数，即启动了rbac功能。
如果你对于rbac本身已经比较了解，那么其实k8s里面的rbac功能就非常容易理解了。涉及rbac的有两个api对象，role定义了一个角色，申明了此角色可以操作的功能列表，rolebinding其实就是把用户和角色做了一个绑定。
role的api对象示例：
这个yaml定义了一个Role对象，名称为 pod-reader ， 作用域为 default 这个namespace，可以对 pods 这个对象进行 get 、 watch 、 list 操作。 kubernetes完整的操作类型列表如下，都很好理解，不一一说明了：
值得注意的是，有些资源还有子类型，比如pod的logs，如果需要查看，也是需要授权的(添加 pods/log 资源类型)
RoleBinding资源的作用也非常容易理解， 就是绑定Role和用户。下面是一个RoleBinding的示例：
这个例子里把一个类型为User，name叫做jane的用户，和pod-reader的Role做了绑定。注意subjects里面的 kind 字段，即用户类型，前面介绍过了，分别是 User 、 Group 和 ServiceAccount 。绑定完成之后，当使用 jane 这个用户身份对k8s的api进行调用，就可以进行指定的 watch 、 get 、 list 操作了。
这两资源其实和Role、RoleBinding的配置方式是完全一样的，区别在于ClusterRole和ClusterRoleBinding的作用域是集群范围的，并且可以操作 node 这样的集群范围资源，而Role、RoleBinding在metadata中需要指定namespace字段，其他方面没有区别。
弄清原理之后，现在让我们来实际操作一下，目标是使用kubectl客户端工具对于给定的k8集群进行受限操作。基于上述的认证策略的介绍，我们使用 客户端证书 方式来进行用户认证，即使用K8集群的根证书来签发一个用户证书，使用该证书来进行用户认证及授权操作。
关于RSA证书的制作，可以参考官网文档： https://kubernetes.io/docs/concepts/cluster-administration/certificates/ ，这里我们使用常用的openssl工具来制作证书：
1、创建一个2048位长度的RSA格式私钥
2、创建证书签名请求(csr)，CN-对应Username O-对应用户组，上面的文章中已经介绍过
3、使用集群根证书签发这个证书请求(days是证书到期时间，可根据实际需要配置)
首先先找到一台准备作为客户端访问k8集群的linux服务器（或者windows、mac都可以），确保客户端与集群的api-server端口网络联通（一般为6443端口，注意必须是https连接），出于安全考虑，最好开一个操作k8的专用的操作系统账号。把集群master节点中的kubectl二进制文件拷贝至此服务器/usr/bin目录内，同时拷贝release.csr、release.key、ca.pem这三个文件至服务器上的指定目录。
在新建用户的home目录下创建.kube目录，在此目录下新建config文件（或者直接执行kubectl config set-cluster test操作，kubectl会自动创建该文件），编辑该文件填写如下内容：
完成之后可以执行 kubectl config view 来验证一下配置是否正确。
使用管理员登陆k8集群，进行权限配置，这里以添加集群范围的运维用户权限为例：
可以看到，我们定义了一个角色 release ，用于应用的部署及日常运维操作。为了满足日常运维，给其分配了一组受限的资源权限。
具体来说，该角色对"deployments","services","configmap","pvc"资源有全部的操作权限，对于"nodes","events","pods","pods/log","endpoints"只有查看权限，对于其他资源没有任何权限。
这里我们定义了一个ClusterRoleBinding，把User和ClusterRole进行了绑定，到这里全部操作就完成了。
登陆客户端，一切顺利的话，执行 kubectl get pods 就可以返回远程集群的default命名空间下的pods列表了，其他配置的权限应该也可以正常操作。而如果这个用户想访问受限资源，比如想查看secrets信息，则会出现如下的报错信息(403 Forbidden)：
验证成功！
基于上述的描述，可以知道，其实在集群里面创建一个service account，把它的token拷贝出来，配置在客户端的kubectl配置文件中，可以达到同样的效果，这里就不再演示了。
因为service account的token机密信息实际上都是存放于secret对象中，而secret经常被人吐槽的是存放的数据是明文（只是做了base64编码），所以这里多说一句secret的安全性问题。其实k8s是支持secret加密存放的，支持的加密类型还挺多，具体可以看我这篇文章： 使用加密插件加密secrets中的数据 。但其实我并不建议使用这种方式，原因是使用加密插件只能加密存放在etcd里面的数据，而使用api server调取出的数据仍然是解密过后的，这意味着你执行 kubectl get secrets 或者是进入容器的环境变量查看，仍然可以看到明文数据。k8s项目更推荐的权限管理方式是：
做好上面两点，对于一般公司的安全管控来讲已经足够，毕竟集群管理员的权限只是掌握在很小一部分人的手中。而对于安全审计要求更高的企业（比如金融机构），审计可能会有要求敏感数据必须加密存放，此时可使用api-server的加密插件。

关于k8s使用ovs internal port的一些问题

openstack 的软路由，虚拟机port已经在用internal port来接入ovs bridge，而且在性能上确实比veth-pair有提升

ovs-internal-port 11.1-11.4Gb/s (1 process) 12.9-13.3Gb/s (4 process)
veth-pair-device 10.8-11.0Gb/s (1 process) 11.8-12.2Gb/s (4 process)

但是k8s获取pod ip的方式就是通过 eth0来获取的，这是一个硬编码。

这样就要求pod内部必须要有一个eth0网卡。

为了使用internal port，
可以先创建port，接入到br-int，（不同pod使用不同的port 名）

然后将该port设备，放入pod ns内部，并进行重命名。

那么问题来了，当创建新的port的时候，或者重启openvswitch。
已经配置好的port就会从pod ns内部移出。 这样就会导致网络问题。

如果不这样做，就需要采用两个网卡的方案，用原生port名直接放进去，配置好ip，然后弄一个dummy eth0网卡，也配上ip。
但是这个逻辑又过于复杂，pod内部多网卡也不够简洁。

结论： ovs 对internal 网卡的重命名支持的不够好。

https://github.com/antrea-io/antrea/issues/1691