❶ 雲原生有哪些優勢
第一，極致彈性能力，以容器化方式運行的應用程序，其啟動和停止非常快，一般處在秒級或毫秒級。
第二，故障自愈、服務自治能力，採用容器編排框架，可以管理成千上萬的應用容器，當某個應用出現故障時，編排系統能夠及時發現並自動摘除問題應用，同時智能調度到有效資源上，保證了應用系統的穩定運行。
第三，大規模跨環境擴展能力，基於容器編排系統的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就可以。
彈性伸縮
當性能要求不斷增加的時候，雲開發可以彈性擴展性能