❶ 云原生有哪些优势
第一，极致弹性能力，以容器化方式运行的应用程序，其启动和停止非常快，一般处在秒级或毫秒级。
第二，故障自愈、服务自治能力，采用容器编排框架，可以管理成千上万的应用容器，当某个应用出现故障时，编排系统能够及时发现并自动摘除问题应用，同时智能调度到有效资源上，保证了应用系统的稳定运行。
第三，大规模跨环境扩展能力，基于容器编排系统的PaaS平台，可以跨越部署到不同的环境中，包括不同的网络环境，不同的机房，不同的数据中心或不同的公有云，利用联邦集群的模式，可以让应用在跨云的环境中流转，可以让不同的云环境作为资源补充，或者创建相同的应用到不同的数据中心，以此作为容灾备份。
基于云原生以上的几个特点，在容器云PaaS、DevOps、微服务治理、服务网格、API网关等等方面，时速云做的还不错，他们是一家全栈云原生技术服务提供商，你可以了解一下。
❷ NeonIO 云原生存储简介与应用
NeonIO 是一款支持容器化部署的企业级分布式块存储系统，能够给 Kubernetes 平台上提供动态创建（dynamic provisioning）持久存储卷（persistent volume）的能力，支持 clone、snapshot、resstore、resize 等功能。
NeonIO 架构如图上所示。
(1) 组件容器化：服务组件、CSI、Portal 容器化。
(2) 支持 CSI：提供标准的 IO 接入能力，可静态、动态创建 PV。
(3) UI 界面，运维方便：
(4) 与云原生高度融合：
(5) 一键式部署：helm install neonio ./neonio -- namespace kube-system。
(6) 部署简单灵活：和 Rook-Ceph 对比：
(1) 全闪的分布式存储架构
(2) 极短的 IO 路径：抛弃文件系统，自研元数据管理系统，使 IO 路径极短
(3) 使用 HostNetwork 网络模式
好处：
(1) 服务组件可靠性与可用性
(2) 数据的可靠性与可用性
(1) Pod 跨节点重建高效：2000PV 的挂载/卸载 16s。
(2) 批量创建 PV 能力：2000PV 的创建 5min。
测试平台：NeonIO 超融合一体机集群（3 个节点，192.168.101.174 - 192.168.101.176）。
注意：所有测试均使用 NVMe SSD，卷大小 = 1TiB。性能工具： https://github.com/leeliu/dbench
图中黄色表示的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从结果来看，无论是单副本还是 3 副本，NeonIO 在 IOPS、时延都有明显的优势。
存储大师班 | ZFS存储池块管理与事务模型
对象存储手把手教四 | Bucket 生命周期管理
❸ 超融合软件解决方案可以适用哪些场景
首先，软件方案和一体机方案如何选择？
❹ 从云计算到云原生：从概念到落地
云计算最近几年已经火得不行， 云原生 （Cloud Native）这个概念又来了，如果上云不“原生”，那就等于白上云。究竟什么是云原生？云原生有何优势？怎么从“不原生”一步一步做到云原生？本文将给出切实可行的云原生落地指南。
我们先从云计算说起 。在云计算普及之前，一个应用想要发布到互联网，就需要企业自己先买几台服务器，找一个IDC机房，租几个机架，把服务器放进去。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。
这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的问题有这么几个：
解决方案是上云 。上云不能解决所有问题，但部分解决了前两个问题：
但是如果仅仅满足上云，把物理机换成虚拟机，把物理网换成虚拟专用网（VPC），是远远不够的。这些是计算资源和网络资源层面的简化。应用方面，如果延续旧的一套开发、测试、部署流程，做不到快速迭代。
要做到快速迭代，敏捷开发，就需要DevOps，即开发运维由一个团队负责，开发阶段，就要把部署、运维的工作考虑进去，而不是发布一个war包或者jar包后扔给运维不管了。
重开发、轻部署，直接后果就是缺少自动化发布流程。想要把部署规范化，就需要整体考虑一系列问题。
还是以Java应用为例，如果是手动部署，那么就上传war包到服务器，覆盖原有的版本，重启Tomcat，再测试。如果发现有严重问题要回滚怎么办？把老版本再传一遍，然后重启Tomcat。
手动部署，每次部署都是一次生死考验，所以最好不要安排在半夜，以免手抖敲错了命令，本来中断10分钟的服务，变成了灾备恢复，中断3天。
稍微靠谱一点的是写脚本部署，但各家写出来的脚本都有各家特色，不通用，不易维护，所以更好的方式是用成熟的部署方案，比如Ansible，把脚本标准化，比如做成蓝绿发布，把服务器分组，比如A、B两组，先把流量切到B组，升级A组服务器，有问题就回滚，没问题了，再把流量切到A组，升级B组服务器，最后，恢复正常流量，整个部署完成。
但是回滚这个事情，远没有那么简单。做过开发的同学都知道，升级新版本，一般要加配置，改配置，如果回滚到旧版本，忘了把配置改回去，那旧版本可能也不能正常工作。
上云，除了物理变虚拟，简化运维外，最重要的特点——弹性计算，一定要充分利用。
理论指导实践，实践完善理论。如果我们分析大多数基于互联网的应用，可以看到，一个应用，通常用到的资源如下：
上云后，云服务商通常都提供托管的数据库，以及大规模存储系统（S3），可解决存储资源问题。通过云服务商提供的负载均衡（Load Balancer），也无需自行部署Nginx等网关，免去了运维的问题。各种标准的业务组件如Redis、Kafka等，均可直接租用云服务商提供的资源。
我们重点讨论计算资源，也就是云上的虚拟机资源。对于应用来说，可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着，如果有本地文件的修改，它就是有状态的。有状态的应用既不利于扩展，也不利于部署。反过来，如果一个应用在运行期数据总是存在数据库或者缓存集群，本地文件无任何修改，它就是无状态的。
无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要，它是指，一台虚拟机通过一个固定的镜像（预先内置好必要的支持环境，如JRE等）启动后，部署一个应用（对应一个war包或者jar包），该虚拟机状态就不再变化了，直接运行到销毁。
有的同学会问：如果给这台虚拟机重新部署一个新的应用版本，它的状态不就发生了变化？
确实如此。为了确保虚拟机的不变性，一旦启动后部署了某个版本，就不允许再重新部署。这样一来，对虚拟机这种计算资源来说，就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的，与之打包的配置文件是确定的，不存在今天是版本1，明天变成版本2，后天回滚到版本1的情况。
计算资源不变，能确保启动一台虚拟机，对应发布的应用版本和配置是确定的且不变的，对于运维、排错非常重要。
那么如何在保持计算资源不变的前提下发布新版本？
我们以AWS的CodeDeploy服务为例，假设一组正在运行的某应用v1集群包含3台虚拟机：
现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的一模一样的虚拟机，只是部署的应用是v2。现在，一共有6台虚拟机，其中3台运行v1版本，另外3台运行v2版本，但此刻负载均衡控制的网络流量仍然导向v1集群，用户感受不到任何变化：
v2集群部署成功后，做一些自动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次部署失败，但无需回滚。如果没有问题，通过负载均衡把流量从v1集群切到v2，用户可无感知地直接访问v2版本：
稳定一段时间（例如15分钟）后，销毁v1集群。至此，整个升级完成。
上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布，适用于更大规模的应用。
把计算资源不可变应用到部署上，实际上是充分利用了弹性计算这个优势，短时间创建和销毁虚拟机，只有上云才能做到，并且针对云计算，把部署流程变得更加简单可靠，每天发几个版本甚至几十、几百个版本都变得可能，DevOps能落地，有点“云原生”的味道了。
说到AWS的CodeDeploy，最早我使用AWS时，对于它的计费采用Reserved Instance预付模型感到很不理解，租用一台虚拟机，按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗？如果仅仅把上云变成租用虚拟机，那就完全丧失了弹性计算的优势，相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机，而是一种规格的虚拟机。
我们还是举例说明，如果我们有1台2v4G规格的虚拟机，并购买了1年的Reserved Instance，那么，我随时可以销毁这台虚拟机，并重新创建一台同样规格的新的虚拟机，Reserved Instance计费会自动匹配到新的虚拟机上，这样才能实现计算资源不变，频繁实施蓝绿部署，真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式，有点真正的云计算的付费味道了，但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。
讲了这么多自动化部署，实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点，设计一整套开发、部署、测试的流程，就是云原生。弹性资源利用得越充分，云原生的“浓度”就越高，就越容易实施小步快跑的快速迭代。
那么虚拟机是不是弹性最好的计算资源呢？从应用的角度看，显然容器是一种比虚拟机更具弹性，更加抽象，也更容易部署的计算资源。
容器和虚拟机相比，它实际上是一种资源隔离的进程，运行在容器中的应用比独占一个虚拟机消耗的资源更少，启动速度更快。此外，容器的镜像包含了完整的运行时环境，部署的时候，无需考虑任何额外的组件，比其他任何部署方式都简单。使用容器，开发部署流程就变成了开发，生成镜像，推送至Docker Hub或云服务商提供的Registry，直接启动容器，整个过程大大简化。
使用容器比使用CodeDeploy部署还要更加简单，因为CodeDeploy需要在虚拟机镜像中预置Agent，由于没有统一的发布标准，还需要配置CodeDeploy，告诉它去哪拉取最新版本，这又涉及到一系列权限配置。而容器作为标准的部署方案，连发布系统都以Registry对各个镜像版本进行了有效管理，所以部署非常简单。
容器作为一种弹性计算资源，也应遵循计算不变性，即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则，因为通过一个镜像启动一个容器，在运行过程中，是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统，因为重启后这些修改将全部丢失。
容器的启动和销毁非常容易，不过，容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等，Kubernetes作为事实上的容器编排标准平台，已经成为各个云服务商的标配。
如果要直接使用K8s，在云环境中首先要有一组虚拟机资源作为底层资源，然后搭建K8s环境，定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务，但直接管理K8s仍然需要非常熟悉K8s的工程师。
还有一种更简单的使用容器的方式，即完全将底层虚拟机和K8s托管给云服务商，企业客户只需关心如何部署容器，底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载均衡，托管的数据库、消息系统、日志系统等组件服务，应该是目前最“云原生”的一种方案。
最后，我们总结一下云原生的特点：
所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。
云原生是一个大方向，在上云的过程中，逐步改造应用架构和部署流程，从手动往自动转，逐步增加计算资源的弹性，就能把云原生一步步落地。
❺ 云原生|Kubernetes技术架构
Kubernetes核心组件
Controller Manager主要提供了一个分发事件的能力，而不同的Controller只需要注册对应的Handler来等待接受和处理事件。
在Controller Manager的帮助下， Controller的逻辑可以做的非常纯粹，只需要实现相应的EventHandler即可，以Deployment controller为例。
Kubernetes default scheler的特点：基于队列的调度器；一次调度一个Pod；调度时刻全局最优。
云计算批量计算面临的挑战：1、作业管理缺失；2、调度策略局限；3、领域计算框架支持不足；4、资源规划复用、异构计算支持不足
与临时存储相比，持久化存储的优势：
引入PV/SC之后带来更大的效益：
pv/pvc适合在资源管理比较严格的场景
pvc绑定pv的流程
无论在资源管控严格还是资源管控敏捷的场景，资源管理员都希望通过创建K8S的存储接口来管理容器存储资源
K8S通过存储声明（PVC）、存储类（SC）和存储插件（driver）联合工作，满足用户一键式定义，创建存储。
CSI架构：部署简单、功能强大、扩展灵活、容器存储接口的标准
无状态工作负载（deployment）更新
容器健康检查使用 liveness probe (工作负载存活探针)和 readiness probe (工作负载业务探针)。
Kubernetes支持如下三种探测机制：
弹性伸缩是根据业务需求和策略，经济地自动调整弹性计算资源的管理服务。包括 工作负载弹性收缩 和 节点弹性收缩 。
云原生应用特点：
云原生可观测性
指标（Metrics）是在许多个连续的时间周期里度量的KPI数值，一般将指标进行如下分类：
目前，Prometheus已经成为云原生监控领域的事实标准
Kubernetes本身并没有用户管理能力，无法像操作Pod一样，通过API的方式创建/删除一个用户实例，也无法在etcd中找到用户对应的存储对象
在Kubernetes的访问控制流程中，用户模型是通过请求方的访问控制凭证（如Kubectl使用的kube-config中的证书、Pod中引入的ServerAccount）产生
认证
鉴权
Istio架构分层主要分为：控制面Istiod(Pilot Citadel Galley Sidecar-Injector)和数据面(Envoy Pilot-Agent)
Sidecar基本介绍
流量治理基本API
简化服务治理配置：熔断、降级，超时，重试，A/B测试，金丝雀发布，基于权重的流量切分，故障检测与恢复
Istio提供以下可观测能力（非侵入）：
课程链接： https://e.huaweicloud.com/activity/Cloud-native2.html
打卡链接： https://bbs.huaweicloud.com/forum/thread-136621-1-1.html
❻ [转]K8S 六种存储解决方案的性能比较测试
原文地址： https://toutiao.io/posts/nmflsd/preview
大多数开发人员都认为在部署集群时选择合适的存储技术极为重要。但是，在 Kubernetes 这片市场上，人们对于存储技术的选择并没有一个标准的答案。本文将 介绍 Kubernetes 中常用的 6 种存储，分析它们的使用场景和优缺点，并对它们进行性能测试，找出哪种存储解决方案才是最理想的选择。
存储技术的选择在很大程度上取决于工程师们要运行的工作负载类型。如果你正在使用 Kubernetes，你可能偏向于通过动态配置使用 volume 来进行块存储。对于裸机集群，你就需要为你的用例选择最为合适的技术，并将其集成到你的硬件上。
此外，例如 AKS、EKS 和 GKE 等公有云可以开箱即用并带有块存储，但这并不意味着它们是最好的选择。在许多情况下，默认公有云存储类的故障转移时间较长。例如，在 AWS EBS 中存在一个故障的 VM，附在此 VM Pod 上的 volume 需要 5 分钟以上的时间才能在另一个节点上重新联机。但是，像 Portworx 和 OpenEBS 此类云原生存储就可以很快解决这种问题。
本文的目的就是寻找在 Kubernetes 中最常用的存储解决方案，并进行基本性能比较。本次测试使用以下存储后端对 Azure AKS 执行所有测试：
测试结果
*注：请将结果作为存储选择期间的标准之一，但不要仅根据本文的数据做出最终判断。
在描述过程之前，我们先总结一下最终结论。如果我们忽略本地 Azure pvc 或 hostPath，测试结果是：
那么这究竟是为什么呢？让我们从每个后端存储介绍安装说明开始，详述 AKS 测试的具体过程！
各存储解决方案的安装及优缺点
*注：本节不含 Azure hostpath 的安装介绍。
本文将把 Azure 原生 Storage Class 作为所有测试的基线。Azure 会动态创建托管磁盘并将其映射到 VM 中，其中 Kubernetes 为 Pod 的 volume。
如果只是为了使用它，你没有必要再做其他事情。当你配置新的 AKS 集群时，它会自动预定义为“default”和“managed-premium”两种存储类。Premium 类将使用基于 SSD 的高性能和低延迟磁盘。
优点：
弊端：
Ceph Rook 需要设计特定的硬件配置，根据数据类型生成 pg 组，配置日志 SSD 分区（在 bluestore 之前）并定义 crush 映射。 它是一种处理整个存储集群安装的简洁方法。
在 AKS 上安装 Ceph Rook ：
优点：
弊端：
GlusterFS 是一个的开源存储解决方案。 Heketi 是 GlusterFS RESTful volume 的管理界面。它提供了一种便捷的方式让 GlusterFS 具有动态配置的能力。如果没有这种访问权限，用户就必须手动创建 GlusterFS volume 并将其映射到 Kubernetes pv 上。
*注：关于 GlusterFS 的更多信息，见： https://docs.gluster.org/en/latest/Install-Guide/Overview/
这里使用了 Heketi 快速入门指南[2]进行安装：
以下是修复该问题的 PR：
同时，动态配置问题也会对测试造成一定影响。对于 Kubernetes 控制平面，Heketi restURL 是不可用的。测试人员尝试利用 kube dns record、Pod IP 和 svc IP 来解决这个问题，但是都没有奏效。为此，他们最后选择通过 Heketi CLI 手动创建 volume。
以下是在 Kubernetes 上安装 Heketi Gluster 的更多内容：
优点：
弊端：
OpenEBS 代表了一种新的 CAS（Container Attached Storage）概念，属于云原生存储类别。 它是基于单个微服务的存储控制器和基于多个微服务的存储复制品。
作为开源项目，目前它提供 2 个后端：Jiva 和 cStor。cStor 作为控制器，它的副本部署在一个 namespace（安装 openebs 的 namespace）中，也可以说它采用的是原始磁盘而不是格式化分区。每个 Kubernetes volume 都有自己的存储控制器，它可以在节点可用存储容量范围内进行扩展。
在 AKS 上安装它非常简单：
优点：
弊端：
*注：OpenEBS 团队帮忙修改的测试用例场景，见： https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench
最后为大家介绍一种比较新颖的解决方案。
Portworx 是另一个专为 Kubernetes 设计的云原生存储，专注于高度分散的环境。它是一个主机可寻址存储，每个 volume 都直接映射到它所连接的主机上。它根据应用程序 I/O 的类型提供自动调整。 不幸的是，它不是开源的存储方案。然而，它免费提供了 3 个节点可进行试用。
*注：关于 Portworx 更多信息，见： https://portworx.com/makes-portworx-unique/
在 AKS 上安装 Portworx 很容易，可以使用 Kubernetes 规格生成器：
优点：
弊端：
AKS 测试环境
在本次测试中，测试人员配置了具有 3 个 VM 的基本 Azure AKS 集群。为了能够连接托管的 Premium SSD，测试人员必须使用 E 类型大小的 VM。因此他们选择了 Standard_E2s_v3，只有 2 个 vCPU 和 16GB RAM。
每个 AKS 集群都会自动配置第二个资源组（RG）MC_ <name>，你可以在其中找到所有 VM、NIC 。在 RG 内部，测试人员创建了 3 个 1TB 高级 SSD 托管磁盘并手动将它们连接到每个 VM 中。
它允许我在每个专用于测试的实例中获得 1TB 的空磁盘。据 Azure 称，它的性能可以在 5000 IOPS 和 200 MB/s 吞吐量之间，具体取决于 VM 和磁盘大小。
性能结果
重要说明：单个存储性能测试的结果是无法单独评估的，它们必须相互比较才能显示出差距。测试的方法有很多种，下面是其中较为简单的一种方法。
为了进行测试，测试人员决定使用名为 Dbench 的负载测试器。 它是 Pod 的 Kubernetes 部署清单 , 同时它也是运行 FIO 的地方，并且带有 Flexible IO Tester 等 8 个测试用例。
测试在 Docker 镜像的入口点指定:
注：所有测试的完整测试输出，见：
https://gist.github.com/pupapaik/
随机读/写带宽
随机读取测试表明，GlusterFS、Ceph 和 Portworx 在读取时的性能比 AWS 本地磁盘上的主机路径快好几倍，因为它们读取的是缓存。GlusterFS 写入速度最快，它与本地磁盘几乎达到了相同的值。
随机读/写 IOPS
随机 IOPS 显示 Portworx 和 Ceph 效果最佳。Portworx 在写入时的 IOPS 与本机 Azure pvc 几乎相同，这非常好。
读/写延迟
延迟测试返回了有趣的结果，因为本机 Azure pvc 比大多数其他测试存储都慢。Portworx 和 Ceph 实现了最佳读取速度。但是对于写入，GlusterFS 比 Ceph 更好。与其他存储相比，OpenEBS 延迟非常高。
顺序读/写
顺序读/写测试显示与随机测试类似的结果，但 Ceph 的读取是 GlusterFS 的 2 倍多。除了表现非常差的 OpenEBS 之外，写入结果几乎都在同一级别上。
混合读/写 IOPS
最后一个测试用例验证了混合读/写 IOPS，即使在 mixed write 上，Portworx 和 Ceph 也提供了比原生 Azure pvc 更好的 IOPS。
以上就是所有测试结果，希望这篇文章对你有所帮助。
--
参考文献：
[1] https://github.com/rook/rook/blob/master/Documentation/ceph-quickstart.md#ceph-storage-quickstart
[2] https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup-guide.md#deployment
❼ 现在大家都在说的云原生到底是什么
云原生是一个组合词，可以拆分为“云”和“原生”两个词，“云”我们都知道，即在线网络，传统的应用原本都跑在本地服务器上，很有可能需要停机更新，且无法动态扩展，“云”表示应用程序运行在分布式的云环境中，可以频繁变更，持续交付。
“原生”表示应用程序在设计前期就考虑到了云平台的弹性和分布式特性，也就是为云设计的。
可以简单理解为：云原生=微服务+DevOps+持续交付+容器化
| 微服务 |
即软件架构，使用微服务架构可以将一个大型的应用程序按照功能模块拆分成多个独立自治的微服务，每个微服务仅仅实现一种功能，具有很明确的边界。
带来的好处有哪些?
1)服务的独立部署
每个服务都是独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
2)服务的快速启动
拆分之后服务启动的速度要比拆分之前快很多，因为依赖的库少了，代码量也少了。
3)更加适合敏捷开发。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
4)职责专一，由专门的团队负责专门的服务。
业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
5)服务可以动态按需扩容
当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
6)代码的复用
每个服务都提供REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
| 容器化 |
是云原生的核心技术，它是一种相对于虚拟机来说更加轻量的虚拟化技术。能为我们提供一种可移植、可重用的方式来打包、分发和运行程序。
容器的基本思想就是将需要执行的所有软件打包到一个可执行程序包。例如，将一个Java虚拟机、Tomcat服务器以及应用程序本身打包进一个容器镜像。用户可以在基础设施环境中使用这个容器镜像启动容器并运行应用程序。
而Docker是目前应用最为广泛的容器引擎，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，Docker和K8s都采用Go编写，(K8s全称Kubernetes,由首字母K,结尾字母s以及中间的8个字母组成，所以简称为K8s)。
| DevOps |
是软件开发人员和IT运维人员之间的合作过程，是一种工作环境、文化和实践的集合，目标是高效地自动执行软件交付和基础架构更改流程。开发和运维人员通过持续不断的沟通和协作，可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。
| 持续交付 |
就是不误时开发，不停机更新，是一种软件开发方法，它利用自动化来加快新代码的发布。在持续交付流程中，开发人员对应用所做的更改可通过自动化被推送至代码存储库或容器镜像仓库。
❽ 什么是“云原生存储”产品有哪些特点有哪些商用的产品
1、云原生存储
云原生存储的概念来源于云原生应用，指一个应用为了满足云原生特性的要求，其对存储所要求的特性是云原生存储的特性，而满足这些特性的存储方案，可以称其为倾向云原生的存储。能够提供这类服务的产品，就是云原生存储产品。
2、云原生存储产品有哪些特点？
块接口——优点：高可用、低延迟、单应用吞吐更高 缺点：容量弹缩弱、数据共享性差。
文件系统接口——优点：多负载共享数据、多负载吞吐更高 缺点：共享数据时，文件锁性能差。
对象存储接口——优点：高可用、大容量、多负载共享数据、多负载吞吐更高 缺点：时延高。
3、具体推荐要根据实际情况来定，不同的接口偏向不同的业务。
❾ 深挖Kubernetes存储为何如此难及其解决方案
以Kubernetes为代表的容器编排工具在应用开发部署领域起正发挥着颠覆性的变革作用。随着微服务架构的发展，从开发人员的角度来看，应用逻辑架构与基础设施架构之间开始解耦，这意味着开发者能够将精力更多集中在软件构建以及价值交付身上。
当管理Docker镜像的时候，Kubernetes也让实际应用变的十分便捷灵活。在利用Kubernetes进行容器架构的应用部署时，管理员们将在无需修改底层代码的前提下将其部署在任何位置——包括公有云、混合云乃至私有云。
虽然Kubernetes在扩展性、便携性与管理性等方面的表现都相当给力，但截至目前，它仍然不支持存储状态。与之对应的是，如今的大多数应用都是有状态的——换言之，要求在一定程度上配合外部存储资源。
Kubernetes架构本身非常灵活的，能够根据开发者的需求、规范以及实际负载情况，对容器进行随意创建与撤销。此外，Pod和容器还具有自我修复与复制能力。因此从本质上讲，它们的生命周期普遍非常短暂。
但是，现有持久存储解决方法无法支持动态的应用场景，而持久化存储也无法满足动态创建与撤销的需求。
当我们需要将有状态应用部署到其它基础架构平台，或者另一家内部或混合云供应商的环境中时，可移植性低下无疑将成为我们面临的巨大挑战。更具体地讲，持久化存储解决方案往往会锁定于特定云服务供应商，而无法灵活完成转移。
另外，云原生应用中的存储机制也相当复杂、难于理解。Kubernetes中的不少存储术语极易混淆，其中包含着复杂的含义与微妙的变化。再有，在原生Kubernetes、开源框架以及托管与付费服务之间还存在着诸多选项，这极大增加了开发人员在做出决定之前的考量与试验成本。
以下是CNCF列出的云原生存储可选方案：
我们首先从最简单的场景出发，即在Kubernetes当中部署一套数据库。具体流程包括：选择一套符合需求的数据库，让它在本地磁盘上运行，然后将其作为新的工作负载部署到集群当中。但是，由于数据库中存在的一些固有属性，这种方式往往无法带来符合预期的效果。
容器本身是基于无状态原则进行构建的，凭借这一天然属性，我们才能如此轻松地启动或撤销容器环境。由于不存在需要保存及迁移的数据，集群也就不需要同磁盘读写这类密集型操作绑定在一起了。
但对于数据库，其状态必须随时保存。如果以容器方式部署在集群当中的数据库不需要进行迁移，或者不需要频繁开关，那么其基本属性就相当于一种物理存储设备。在理想情况下，使用数据的容器应该与该数据库处于同一Pod当中。
当然，这并不是说将数据库部署在容器中的作法不可取。在某些应用场景下，这样的设计完全能够满足需求。举例来说，在测试环境或者处理非生产级数据时，由于总体数据量很小，将数据库纳入集群完全没有问题。但在实际生产中，开发人员往往需要仰仗于外部存储机制。
Kubernetes到底是如何与存储资源彼此通信的？其利用的是控制层接口。这些接口负责将Kubernetes与外部存储相对接。接入Kubernetes的外部存储解决方案被称为“卷插件（Volume Plugins）”。正是有了卷插件的存在，存储资源才得以抽象化并实现可移植性。
以前，卷插件一般由核心Kubernetes代码库进行构建、链接、编译以及装载。这样就极大的限制了开发人员的发挥空间，同时也带来了额外的维护开销。因此，项目维护人员们决定在Kubernete的代码库上增加一些新的存储功能。
随着CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全无需更改代码库。
原生Kubernetes与存储
持久卷是由管理员负责配置的存储单元，它们独立于任何单一Pod之外，因此不受Pod生命周期的影响。
存储资源有两种使用方式：静态存储与动态存储。
实际上，静态定义的持久卷并不能适应Kubernetes的可移植特性，因为存储资源具有对环境的依赖性——例如AWS EBS或者GCE Persistent Disk。另外，手动绑定还需要根据不同供应商的存储方案修改YAML文件。
在资源分配方面，静态配置实际上也违背了Kubernetes的设计原则。后者的CPU与内存并非事先被分配好绑定在Pod或者容器上，而是以被动态形式进行分配。
通过简单的说明，相信大家已经了解了原生Kubernetes对外部存储资源的使用方式。当然，这里仅仅做出概括，实际使用场景中还有更多其它因素需要考量。
CSI——容器存储接口
下面来看容器存储接口（简称CSI）。CSI是由CNCF存储工作组创建的统一标准，旨在定义一个标准的容器存储接口，从而使存储驱动程序能够在任意容器架构下正常起效。
CSI规范目前已经在Kubernetes中得到普及，大量驱动插件被预先部署在Kubernetes集群内供开发人员使用。如此一来，我们就可以利用Kubernetes上的CSI卷来访问与CSI兼容的开放存储卷。
CSI的引入，意味着存储资源能够作为Kubernetes集群上的另一种工作负载实现容器化以及部署。
相关开源项目
目前，围绕云原生技术涌现出大量工具与项目。但作为生产场景中的一大突出问题，我们往往很难在云原生架构中选择最合适的开源项目。换言之，解决方案选项太多，反而令存储需求变得更难解决。
我们再看一次CNCF列出的云原生存储的可选方案：
下面我会分享一下当下流行的存储方案Ceph与Rook，还有Rancher开源的容器化分布式存储Longhorn。
Ceph
Ceph是一种动态托管、横向扩展的分布式存储集群。Ceph面向存储资源提供一种逻辑抽象机制，其设计理念包括无单点故障、自管理以及软件定义等特性。Ceph可以面向同一套存储集群分别提供块存储、对象存储以及文件存储的对应接口。
Ceph架构相当复杂的，其中使用到大量的底层技术，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性组件。这里我们先不谈它的底层架构，关键在于Ceph属于一种分布式存储集群，这使得扩展更便利、能够在不牺牲性能的前提下消除单点故障，且提供涵盖对象存储、块存储以及文件存储的统一存储体系。
Ceph架构图
Rook
另一个有趣且颇具人气的项目是Rook，这是一项旨在将Kubernetes与Ceph融合起来的技术方案。从本质上讲，它将计算节点和存储节点放进了同一个集群当中。
Rook是一种云原生编排器，并对Kubernetes做出扩展。Rook允许用户将Ceph放置在容器内，同时提供卷管理逻辑以立足Kubernetes之上实现Ceph的可靠运行。Rook还使本应由集群管理员操作的多种任务完成了自动化实现，其中包括部署、引导、配置、扩展以及负载均衡等等。
Rook自身不具备持久状态，也不需要单独管理。这，才是真正与Kubernetes设计原则相符的存储资源管理方案。
Rook凭借着将Ceph与Kubernetes协同起来的强大能力而颇受欢迎，在GitHub上获得近4000颗星，1600多万次的下载，并吸引到100多名贡献者，现已进入CNCF孵化阶段。
Longhorn
Longhorn项目是Rancher Labs推出的开源的基于云和容器部署的分布式块存储新方式。Longhorn遵循微服务的原则，利用容器将小型独立组件构建为分布式块存储，并使用容器编排来协调这些组件，形成弹性分布式系统。
如今，基于云和容器的部署规模日益扩大，分布式块存储系统也正变得越来越复杂，单个存储控制器上的volume数量在不断增加。2000年代初，存储控制器上的volume数量只有几十个，但现代云环境却需要数万到数百万的分布式块存储卷。存储控制器变成了高度复杂的分布式系统。
Longhorn充分利用了近年来关于 如何编排大量的容器和虚拟机的核心技术 。例如，Longhorn并没有构建一个可以扩展到100,000个volume的高度复杂的控制器，而是出于让存储控制器简单轻便的考虑，创建了100,000个单独的控制器。然后，我们可以利用像Kubernetes这样的最先进的编排系统来调度这些独立的控制器，共享一组磁盘中的资源，协同工作，形成一个弹性的分布式块存储系统。
Longhorn基于微服务的设计还有很多其他优势。因为每个volume都有自己的控制器，在升级每个volume的控制器和replica容器时，是不会导致IO操作明显的中断的。Longhorn可以创建一个长期运行的工作来编排所有live volume的升级，同时确保不会中断系统正在进行的操作。为确保升级不会导致意外的问题，Longhorn可以选择升级一小部分volume，并在升级过程中出现问题时回滚到旧版本。这些做法在现代微服务应用中已得到广泛应用，但在存储系统中并不常见。希望Longhorn可以 助力于微服务在存储领域的更多应用。
结 语
对于实际应用层面出现的任何问题，最重要的自然是判断需求、设计系统或者选择适当的工具。同样的道理也适用于云原生环境。虽然具体问题非常复杂，但也必然会出现大量工具方案尝试解决。随着云原生世界的持续发展，我们可以肯定，新的解决方案将不断涌现。未来，一切都会更加美好！
❿ 什么是云原生为啥这么火
一、云原生是什么？
云原生是基于分布部署和统一运管的分布式云 ，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
云是相对于本地而言的，传统的应用都是运行在本地机房的服务器上，而云的应用则是运行在云端（如IAAS、PAAS、SAAS）。原生就是亲生的、土生土长的意思，即应用一诞生就是基于云的，可以直接在云平台上运行或非常轻松的迁移到云平台。我们可以这么来定义云原生：是一种新型技术体系，是云计算未来的发展方向。
云原生应用要运行在云平台， 那么就必须要有云的特点，比如弹性伸缩、分布式、快速部署、快速迭代、高效、持续。 这可不止是简单的把原先在物理服务器上的应用迁移到虚拟机里，不止是基础设施和运行平台在云上，应用架构、应用开发方式、应用部署方式、应用维护方式全都要做出改变。
二、云原生的核心
云原生的四大核心要素便是微服务技术、DevOps、持续交付、容器化。微服务技术使得应用原子化，所有的应用都可以独立的部署、迭代。DevOps使得应用可以快速编译、自动化测试、部署、发布、回滚，让开发和运维一体化。持续交付让应用可以频繁发布、快速交付、快速反馈、降低发布风险。容器使得应用整体开发以容器为基础，形成代码组件复用、资源隔离。
微服务
微服务是一个独立发布的应用服务，可以作为独立组件升级、灰度或复用等，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构更精简，沟通成本低、效率高。
devOps
持续交付
敏捷开发要求持续交付，因为敏捷开发要求随时有一个版本可以上到大群环境，所以要持续交付。持续交付目的的快速应对客户的需求变化，要求发布非常频繁，所以会存在多个版本同时提供服务的情况，因此需要支持灰度发布/金丝雀发布等。
容器化
Docker是软件行业最受欢迎的软件容器项目，Docker起到应用隔离作用，为微服务及其所需的所有配置、依赖关系和环境变量移动到全新、无差别的运行环境，移植性强。
三、云原生的优势
快速上线，云开发可以在最短时间内上线。
专注业务逻辑
提高开发效率
云开发模式提供API接口，通过API实现数据的存储，文件的上传等操作，大大提升开发效率。不需要学习新的语言，只需要掌握javascript就可以。
弹性伸缩
当性能要求不断增加的时候，云开发可以弹性扩展性能