❶ 2021-10-这一篇 K8S（Kubernetes）我觉得可以了解一下！！！28
Kubernetes 是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。
Kubernetes 简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes 首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。
Kubernetes 即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从 创建应用>应用部署>提供服高绝务>动态伸缩>应用更新 一系列服务，提高了容器集群管理的便捷性。
大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。
但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：
如果我想要部署，以下几台机器：
如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。
并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务弹性扩容机制也能够很好的应对突发流量。
Docker-Compose 是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去操作，是非常耗费时间的，如果有了 Docker-Compose 只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose 只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。
Docker Swarm 是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose 单节点的缺陷， Docker Swarm 可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，
Kubernetes 它本身的角色定位是和 Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes 正在成为容器编排领域的领导者，其 可配戚则姿置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。
在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，盯悔通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种
打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。
Pod里面到底装的是什么？
具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。
pause容器：
Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的
一个Pod中的应用容器共享同一个资源：
在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。
在 Kubernetes 中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service
Service 是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信
我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service 是通过 Label Selector 来进行定义的。
使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。
Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行操作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行操作。
用户通过 Kubectl 提交一个创建 Replication Controller 请求，这个请求通过 API Server 写入 etcd 中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server 写到我们 etcd 里面
到下面，如果被 Scheler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人操心，然后通过 API Server 将这个结果也写到etcd中，随后，我们的 Node 上运行的小管家 Kubelet 进程通过 API Server 检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。
然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server 写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server 查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。
kube-proxy： 是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的
kubelet： 用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里
etcd： 用于持久化存储集群中所有的资源对象，API Server提供了操作 etcd的封装接口API，这些API基本上都是对资源对象的操作和监听资源变化的接口
API Server ： 提供资源对象的操作入口，其他组件都需要通过它提供操作的API来操作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。
Scheler ： 调度器，负责Pod在集群节点中的调度分配。
Controller Manager： 集群内部管理控制中心，主要是实现 Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由 Controller Manager 完成。
到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。
关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。
我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。
❷ 通过K8S部署对象存储MinIO
MinIO 是全球领先的对象存储先锋，以 Apache License v2.0 发布的对象存储服务器，是为云应用和虚拟机而设计的分布式对象存储服务器。在标准硬件上，读/写速度上高达183GB/s和171GB/s。它与 Amazon S3 云存储服务兼容。 它最适用租察于存储非结构迅念化数据，如照片、视频、日志文件、备份和容器/虚拟机映像。 对象的大小可以从几KB 到最大5TB。
MinIO是一个非常轻量的服务,可以很简单的和其他应用的结弊昌茄合，类似 NodeJS, Redis 或者 MySQL。
MinIO支持多种灵活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，详见官网： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux
这里着重介绍K8S下部署
1、standalone模式
由于service采用NodePort类型，通过主机IP:32593访问web
2、distributed模式
分布式部署，实例数至少4个，所以需要另外创建4个pv
❸ 请问一下，服务器、云服务器和虚拟主机有什么区别
物理服务器是一种为客户机提供服务的高性能计算机，是构建云计算和数据中心的最核心基础设备，而云服务器和虚拟主机都是基于云计算技术进行研发的。服务器、云服务器和虚拟主机的区别主要表现在以下几个方面：
1、性能方面：服务器的性能好坏影响着后续开发的使用效果，所以服务器必须要有承担服务、保障服务的能力。物理服务器的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面，性能方面是最好的。由于云服务器属于公有性质，它的性能瓶颈受到底层服务器的硬件制约。而虚拟主机在使用中一旦数据访问量过大，就会变得卡慢，而且虚拟主机升级也比较麻烦。
2、安全性：传统的物理服务器是独立服务器，只有一个操作系统直接安装在服务器上，专用于单个租户，租户与租户之间是基于物理隔离，安全性最高。云服务器基于云计算的架构，可自主切换故障节点到正常的主机，其稳定性较强，提供多种数据恢复的措施，安全性也是可以的。虚拟主机由于带宽是共享的，虚拟主机使用共享IP的话，安全性就会降低。
3、实惠性：随着云平台的产品的推广逐渐得到大众的认可，云的发展前景越来越好，云服务器的价格也有所降低。这样，用户不仅可以节约自身成本，还能获得高性能、可灵活扩展的计算机资数前源。与传统物理服务器相比，云服务器更经济实惠。虚拟主机跟相同配置的云服务器相比，会更便宜一些。
4、灵活扩展性：云服务器可支持弹性扩展，可根据需求选择云服务器再付费。当服务器性能不能满足企业或用户的业务发展需求时，可以随时进行扩容，升级云服务器的主衫弯机CPU、内存、硬盘和带宽等系统配置，能够灵活扩展。而虚拟主机的升级或扩容就相对麻烦，需重新租用新的虚拟主机空间。
5、技能门槛：云服务器通常在控制台中提供先进的管理功能，使云服务器的管理变得更加简单。虚拟主机同样管理相对简单，使用效率更高。物理服务器则需要具备服务器配置知识、细致的薯塌清规划和管理，以及了解相关所需的资源，需要较为完备的知识储备。
总体来说，云服务器的综合能力是最平均的，随着云计算技术的不断发展，在信息化建设模式上上云是大势所趋。由数通畅联自主研发的UMC云管理平台是云平台开发、部署、管理、运维的统一管理中心，对K8S集群配置、运行状态等进行统一管理，满足云原生四个基本要素：容器化、微服务、DevOPS持续交付、多租户管理。由UMC、容器化的AEAI套件及CI/CD管理机制组合形成了AEAIiPaaS平台。主要通过连接、协同实现业务集成，支撑业务中台，通过连接、共享实现数据集成，成就数据中台。
❹ 云计算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：日新月异的中国保险业
❺ 什么是K8S
k8s是什么?
Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。
为什么现在流行使用容器?
早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.
后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.
现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.
为什么需要使用k8s容器?
若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.
k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理
名词解释
secret
Secret有三种类型：
k8s的组成
k8s是由组件,API,对象等组成.
包含所有相互关联组件的 Kubernetes 集群图如下:
组件
API
Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。
对象
Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.
具体来说，他们可以描述：
Kubernetes 架构
Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.
master 流程图
节点
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.
节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。
节点状态
可以使用 kubectl 来查看节点状态和其他细节信息：
kubectl describe node <�节点名称>
一个节点包含以下信息:
控制面到节点通信
控制器
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。
举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。
控制器模式分为直接控制和通过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架构常见问题
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架构下常见的开放服务指纹如下:
注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务
了解各个组件被攻击时所造成的影响
组件分工图:
假如用户想在集群里面新建一个容器集合单元, 流程如下:
攻击apiserver
apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.
在攻击者眼中Kubernetes APIServer
默认情况下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总体步骤如下:
攻击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 设置如下:
后通过skip登陆dashboard便有了管理集群的权限.
创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。
新建一个Pod如下:
通过该容器的tmp目录管理node节点的文件
攻击etcd
Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。
未授权访问流程:
攻击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 从而使功能实现的。
例如:
类似于这样去调用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
❻ k8s之存储
k8s的存储常用的就是上面几种模式，分为临时存储，半持久化存储链消，与持久化存储这三类，本章我们着重讲解emptydir与hostpath与pvc跟pv等
当pod的存储方案设定为emptydir的时候，pod启动时，就会在pod所在节点的磁盘空间开辟出一块空卷，最开始里面是什么都没有的，pod启动后容器产生的数据会存放到那个空卷中。空卷变成了一个临时卷
供pod内的容器读取和写入数据，一旦pod容器消失，节点上开辟出的这个临时卷就会随着pod的销毁而销毁
一般来说emptydir的用途都是用来充当临时存储空间，例如一些不需要数据持久化的微服务，我们都可以用emptydir来当做微服务pod的存储方案
k8s存储emptdir实战例子：以之前的myapp应用为例
创建应用
观察是否生产data目录，并在/data目录创建文件test.txt
手动删除容器模拟容器销毁，用于是pod是被控制器管理的，删除后会被重建新棚橘知的pod
这时候在看我们之前创建的data.txt已经不见了
hostPath类型则是映射node文件系统中的文件或者目录到pod里。在使用hostPath类型的存储卷时，也可以设置type字段，支持的类型有文件、目录、File、Socket、CharDevice和BlockDevice（我只映射过文件与目录）。
其实这个功能就相当于docker中的-v 目录映射，只不过在k8s中的时候，pod会漂移，当pod漂移到其他node节点的时候，pod不会跨节点的去读取目录。所以说hostpath只能算一种半持久化的存储方式
实战例子
创建应用
在node节点可以看到生成了/data/volume目录，在里面创建测试文件
检验pod里面的/data是否存在这个映射目录的文件
可以看到刚才创建的文件已经映射到我们的目录里边了
为了验证是否映射到容器里面的目录也会随着pod生命周期的消失而消失，我们手动删除pod模拟容器终止
可以看到容器被删除后，新建的pod也可以看到我们映射的目录，而且里面数据test.txt还在伍伏。
这有个缺点就是不能够跨容器去读取数据，如果删除后的pod被调度到其他节点的话，原来的数据也就没有了，如果能不受节点的影响，并且挂载的数据不会随生命周期的结束而结束，我们应该怎么解决呢？就是我们后面讲到的持久化存储了
上面介绍了俩种临时存储于半持久化存储的方案。在k8s实际生产环境中，一般会选用私有云持久化存储方案还有公有云持久化存储方案，私有云存储方案包括nfs，ceph，glusterfs等方案。公有云存储会用到AWS等方案
存储方案各有各的优缺点，可参考 https://www.cnblogs.com/yswenli/p/7234579.html 这篇文章。今天我们主要讲解pvc，pv，nfs之间的关系。
简单来说，要使用持久化存储，就需要使用pvc去跟pv去申请，然后pv查看自己有没有合适的存储空间卷，有合适的就与pvc进行绑定。pv与pvc是一一对应绑定的。现在我们用一幅图来说明pvc，pv，nfs的关系
实战例子
准备存储服务安装nfs
接下来创建pv与nfs绑定
创建pvc与pv关联
创建并查看结果
注意：STATUS为Bound说明该pvc已经与pv绑定了
接下来创建pod来引用pvc
创建pod
接下来验证一下在nfs创建一个测试文件，看是否被映射到容器中
可以看到容器里面也可以看到创建的文件
手动删除容器，或者调度到其他节点原来的文件还是不会被删除的，这里就省略验证了，这就是nfs的好处，不过企业一般不会选用nfs，磁盘IO,性能读取方面不太理想，毕竟是本地存储，还是有一定的风险。推荐用用云存储。
文件存储提供无限扩展的文件系统来给云服务器存取数据实际上相当于nfs
1、已注册阿里云账号，并完成实名认证。
如果没有，请先注册阿里云账号，详情请参见阿里云账号注册流程。
2、已开通NAS服务。
首次登录NAS控制台时，根据页面提示开通NAS服务。
3、在需要创建文件系统的地域，已有可用的云服务器ECS。
k8s应用NAS实战例子
1、打开阿里云NAS控制台确认已创建好文件系统
2、把复制挂载参数把它挂载到服务器中创建测试目录，前提是服务器需要安装nfs客户端。
安装完成挂载到本地目录并创建test目录作为测试目录
并在里面创建一个测试文件1.txt
接下来可以创建pvc和pv了
创建并查看
接下来创建pod去引用pvc
创建pod
检验刚才的1.txt是否挂到容器的/data/nas下
云存储适合于生产环境k8s的存储解决方案
❼ kubernetes cloud-provider for aliyun
CloudProvider 提供kubernetes与云厂商基础服务的对接能力，由 cloud-controller-manager组件实现(lb,云盘，安全组等等)。
aliyun-cloud-provider这个组件主要是aliyun平台的对接插件，可以让用户在创建k8s LoadBalancer 类型的service的时候自动的为用户创建一个阿里云SLB，同时动态的绑定与解绑SLB后端，并且提供了丰富的配置允许用户自定义生成的LoadBalancer.
其他cloud-provider比如aws可提供elb，ebs，安全组等能力，阿里云这里实现了service_controller和route_controller，所以暂时只提供了对接slb资源，其他资源需要单独插件在cloud-provider上层实现，比如cluster-autoscaler需依赖cloud-provider完成node初始化.
所以cloud-provider的能力仅仅对接云厂商基础服陵和历务给kubernetes集群使用,我们使用aliyun-cloud-provider 主要也是对接aliyun ess资源，使用cluster-autoscaler动态/定时伸缩kubernetes node节点。
集群环境：
kubele 启动参数添加--cloud-provider=external --hostname override= instance id--provider id= instance id参数并重启kubelet。棚扮格式为 Instance。
以下命令可找到REGION_ID 和INSTANCE_ID
然后重启kubelet kubectl get node 查看hostname是否生效，也可以delete node,重新注册到集群。
cloud-provider需要一定的权限才能访问阿里云，需要为ECS实例创建一些RAM策尺搜略，或者直接使用accesskeyid&secret，由于我们容器部署cloud-provider所以这里采用AK。
1.配置aliyun-cloud-provider AK(access key) 权限
创建自定义策略，然后将策略绑定到k8s-cloud-provider用户，创建其AK提供给aliyun-cloud-provider使用，保证只能访问我们授权的资源。或者参考地址: https://github.com/kubernetes/cloud-provider-alibaba-cloud/blob/master/docs/examples/master.policy
创建cloud-config configmap 为cloud-provider提供配置，主要存放AK信息
替换$CA_DATA 为cat /etc/kubernetes/pki/ca.crt|base64 -w 0输出结果或者kubectl config view --flatten=true可查看CA data ,以及将apiserver替换自己kubernetes apiserver的服务器地址. 我们通过configmap 挂载到cloud-provider容器中.
一旦云控制器管理器启动并运行，运行一个示例nginx部署：
然后使用以下类型创建服务：LoadBalancer:
其他SLB相关创建annotation参考： https://github.com/kubernetes/cloud-provider-alibaba-cloud/blob/master/docs/zh/usage.md
cloud-provider注意事项 :
通过cloud-provider动态管理SLB最佳实践：
FAQ:
参考链接:
❽ 腾讯轻量云服务器搭建k8s环境
4C4G机器设置为k8smaster节点，另外一台机器设置为k8snode节点
分别进入两台的 /ect/hosts 目录，设置r如下host
由于k8s内部节点之间的通讯使用的是内网ip，我们需要把内网ip的重定向到公网ip上
由于两台机器是处于公网环境，且k8s节点之间需要通讯，所以需要开放一些端口，端口配置可以直接进到腾讯云控制台进行配置
以下是官网要求的master节点的端口配置
可以进入腾讯云服务器的防火墙配置开放相应端口，端口可以限定来源，只允许node节点(192.168.2.2)访问
以下是官网要求的node节点的端口配置
同理，也设置node节点的端口
master节点需要安装
node节点需要安装
添加安装源(所有节点)
安装命令
设置开机启动
修改docker配置（所有节点）
组件安装完成后就可以启动了，首先启动master节点，然后让node节点加入master几点即可。
在master节点使用kubeadm初始化集群
这里需要保存token，token是用于node节点加入maste节点的凭证
node节点加入master节点
安装网络插件，否则node是NotReady状态（主节点跑）
kubectl get nodes
❾ Docker+ Kubernetes已成为云计算的主流（二十六）
最近正在抽时间编写k8s的相关教程，很是费时，等相关内容初步完成后，再和大家分享。对于k8s，还是上云更为简单、稳定并且节省成本，因此我们需要对主流云服务的容器服务进行了解，以便更好地应用于生产。
主流云服务容器服务介绍
Docker+ Kubernetes已成为云计算的主流
亚马逊AWS
Amazon Web Services (AWS) 是亚马逊公司旗下云计算服务平台，为全世界范围内的客户提供云解决方案。AWS面向用户提供包括弹性计算、存储、数据库、应用程序在内的一整套云计算服务，帮助企业降低IT投入成本和维护成本。
那么如何在AWS上运行Docker呢？AWS 同时为 Docker 开源解决方案和商业解决方案提供支持，并且可通过多种方式在 AWS 上运行容器：
微软Azure
Microsoft Azure 是一个开放而灵活的企业级云计算平台。通过 IaaS + PaaS 帮助用户加快发展步伐，提高工作效率并节省运营成本。
Azure是一种灵活和支持互操作的平台，它可以被用来创建云中运行的应用或者通过基于云的特性来加强现有应用。它开放式的架构给开发者提供了Web应用、互联设备的应用、个人电脑、服务器、或者提供最优在线复杂解决方案的选择。
在容器这块，Azure同样的提供了众多解决方案：
下面我们侧重介绍下以下服务：
阿里云
阿里云（www.aliyun.com）创立于2009年，是全球领先的云计算及人工智能 科技 公司，为200多个国家和地区的企业、开发者和政府机构提供服务。2017年1月阿里云成为奥运会全球指定云服务商。2017年8月阿里巴巴财报数据显示，阿里云付费云计算用户超过100万。阿里云致力于以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，让计算和人工智能成为普惠 科技 。阿里云在全球18个地域开放了49个可用区，为全球数十亿用户提供可靠的计算支持。此外，阿里云为全球客户部署200多个飞天数据中心，通过底层统一的飞天操作系统，为客户提供全球独有的混合云体验。
飞天（Apsara）是由阿里云自主研发、服务全球的超大规模通用计算操作系统。 它可以将遍布全球的百万级服务器连成一台超级计算机，以在线公共服务的方式为 社会 提供计算能力。 从PC互联网到移动互联网到万物互联网，互联网成为世界新的基础设施。飞天希望解决人类计算的规模、效率和安全问题。飞天的革命性在于将云计算的三个方向整合起来：提供足够强大的计算能力，提供通用的计算能力，提供普惠的计算能力。飞天诞生于2009年2月，目前为全球200多个国家和地区的创新创业企业、政府、机构等提供服务。
同样，阿里云对容器也提供了友好的支持：
容器服务提供高性能可伸缩的容器应用管理服务，支持用Docker和Kubernetes进行容器化应用的生命周期管理，提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务简化了容器管理集群的搭建工作，整合了阿里云虚拟化、存储、网络和安全能力，打造云端最佳容器运行环境。
容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级 Kubernetes 容器化应用的全生命周期管理。容器服务 Kubernetes 版简化集群的搭建和扩容等工作，整合阿里云虚拟化、存储、网络和安全能力，打造云端最佳的 Kubernetes 容器化应用运行环境。
阿里云弹性容器实例（Elastic Container Instance）是 Serverless 和容器化的弹性计算服务。用户无需管理底层 ECS 服务器，只需要提供打包好的镜像，即可运行容器，并仅为容器实际运行消耗的资源付费。
容器镜像服务（Container Registry）提供安全的镜像托管能力，稳定的国内外镜像构建服务，便捷的镜像授权功能，方便用户进行镜像全生命周期管理。容器镜像服务简化了Registry的搭建运维工作，支持多地域的镜像托管，并联合容器服务等云产品，为用户打造云上使用Docker的一体化体验。
腾讯云
腾讯云为腾讯倾力打造的云计算品牌，以卓越 科技 能力助力各行各业数字化转型，为全球客户提供领先的云计算、大数据、人工智能服务，以及定制化行业解决方案。其基于QQ、微信、腾讯 游戏 等海量业务的技术锤炼，从基础架构到精细化运营，从平台实力到生态能力建设，腾讯云将之整合并面向市场，使之能够为企业和创业者提供集云计算、云数据、云运营于一体的云端服务体验。
在容器这块，腾讯云提供了如下解决方案：
腾讯云容器服务（Tencent Kubernetes Engine ，TKE）基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务。腾讯云容器服务完全兼容原生 kubernetes API ，扩展了腾讯云的 CBS、CLB 等 kubernetes 插件，为容器化的应用提供高效部署、资源调度、服务发现和动态伸缩等一系列完整功能，解决用户开发、测试及运维过程的环境一致性问题，提高了大规模容器集群管理的便捷性，帮助用户降低成本，提高效率。容器服务提供免费使用，涉及的其他云产品另外单独计费。
容器实例服务（Container Instance Service , CIS）可以帮用户在云上快捷、灵活的部署容器，让用户专注于构建程序和使用容器而非管理设备上。无需预购 CVM（云服务器），就可以在几秒内启动一批容器来执行任务。同时，开发者也可以通过 kubernetes API 把已有kubernetes 集群的 pod 调度到 CIS 上以处理突增业务。CIS 根据实际使用的资源计费，可以帮用户节约计算成本。使用 CIS 可以极大降低用户部署容器的门槛，降低用户执行 batch 型任务或处理业务突增的成本。
从上面主流的云服务中我们可以看到，没有哪家云厂商不支持Docker，同样的，也没有哪家云厂商不支持Kubernetes！也就是说，Docker+ Kubernetes已经成为云计算的主流！
什么是Kubernetes（k8s）
Kubernetes（简称k8s）诞生于谷歌，是一个开源的，用于管理云平台中多个主机上的容器化的应用，k8s的目标是让部署容器化的应用简单并且高效，其提供了应用部署、规划、更新、维护的机制。
k8s主要有以下特点：
支持公有云，私有云，混合云，多重云（multi-cloud） 。可以将容器化的工作负载从本地开发计算机无缝移动到生产环境。在本地基础结构以及公共云和混合云中，在不同环境中协调容器，保持一致性。
支持模块化，插件化，可挂载，可组合。并且k8s的扩展和插件在社区开发者和各大公司的支持下高速增长，用户可以充分利用这些社区产品/服务以添加各种功能。
支持自动部署，自动重启，自动复制，自动伸缩/扩展，并且可以定义复杂的容器化应用程序并将其部署在服务器群集甚至多个群集上——因为k8s会根据所需状态优化资源。通过内置的自动缩放器，k8s可轻松地水平缩放应用程序，同时自动监视和维护容器的正常运行。
Kubernetes正在塑造应用程序开发和管理的未来
k8s构建于 Google 数十年经验，一大半来源于 Google 生产环境规模的经验。结合了社区最佳的想法和实践，而且还在不断地高速迭代和更新之中。
她衔着金钥匙出生，一诞生就广受欢迎，更是在2017，其打败了所有的竞争对手，赢得了云计算的战争——主流的云厂商基本上都纷纷放弃了自己造“轮子”的举动，终止了各自的容器编排工具，加盟了k8s阵营，其中包括Red Hat、微软、IBM、阿里、腾讯、华为和甲骨文等。
k8s像风暴一样席卷了应用开发领域，并且已成为云原生应用程序（架构、组件、部署和管理方式）的事实标准，大量的开发者和企业正在使用k8s创建由微服务和无服务器功能组成的现代架构。
Docker+ Kubernetes已成为云计算的主流
容器是现代软件交付的未来，而Kubernetes是编排容器的最佳方案（事实上的标准）。
Docker 和Kubernetes相辅相成，联手打下了云计算的“万里江山”。Docker 为打包和分发容器化应用程序提供了一个开放的标准，而 Kubernetes 则协调和管理通过 Docker 创建的分布式容器化应用程序。换句话说，Kubernetes 提供了部署和运行通过Docker生成的应用程序所需的基础结构。
在主流的云服务，基于Docker+k8s的新型PaaS平台具有敏捷部署、弹性伸缩、灵活调度、故障自动恢复等优势，充分满足业务扩展中的资源支持，因此在短短两年之内，便从Docker Swarm、Cloud Foundry Diego、Kontena、Apache Mesos、Amazon ECS…等大量对手中脱颖而出，拿下了皇冠。
k8s和Docker的胜利意味着这是有史以来第一次，无论使用哪一种云平台，研发人员都可以拥有完全相同的计算环境。
❿ 如何搭建小企业的私有云服务器
首先确定私有云服务是什么类型的服务：
用来共享文档等资料的私有云存储。
这种私有云存储的可以搭建owncloud，seafile等这些是免费的产品。如果想才有商业版可以采购坚果云。这个云存储我目前一直在用很稳定，而且实时同步的功能太爽了。
2.用来支持业务系统运行的运行平台
搭建基于dockerswarm的云平台旁物，这种方案比较简单，搭建速度快，运维简单。
搭建基于k8s+docker的云平台，功能超强，搭建难度大，运维难度也大。需要有专业运维人员。
针对以上两种情况搭建方案是：
采购基础设施资源，服务器，网络设备等硬件设备
安装操作系统，一般情况下都是安装Linux操作系统
安装运行环境软件，然后将软件包放入运行目录直接运行即可。（针对云存储）
docker公司官方文档部署docker软件，然后通过dockerswarm构建一个集群。（针对dockerswarm私有云）
安装运袭液docker然后参考k8s官方部署软件进行部署等。不推禅亮荐使用二进制的方式部署k8s平台。
笔者多年专注云计算工作，该领域有一定的积累，希望和大家一份分享。