雲原生技術的了解
參考資料
什么是雲原生
- 雲原生應用架構的幾個主要特征：
- 符合12因素應用
- 面向微服務架構
- 自服務敏捷架構
- 基於API的協作
- 抗脆弱性
- 到了2015年Google主導成立了雲原生計算基金會（CNCF），起初CNCF對雲原生（Cloud Native）的定義包含以下三個方面：
- 應用容器化
- 面向微服務架構
- 應用支持容器的編排調度
- 雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
- 這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。
- 雲原生本身甚至不能稱為是一種架構，它首先是一種基礎設施，運行在其上的應用稱作雲原生應用，只有符合雲原生設計哲學的應用架構才叫雲原生應用架構。
- 雲原生系統的設計理念如下:
- 面向分布式設計（Distribution）：容器、微服務、API 驅動的開發；
- 面向配置設計（Configuration）：一個鏡像，多個環境配置；
- 面向韌性設計（Resistancy）：故障容忍和自愈；
- 面向彈性設計（Elasticity）：彈性擴展和對環境變化（負載）做出響應；
- 面向交付設計（Delivery）：自動拉起，縮短交付時間;
- 面向性能設計（Performance）：響應式，並發和資源高效利用；
- 面向自動化設計（Automation）：自動化的 DevOps；
- 面向診斷性設計（Diagnosability）：集群級別的日志、metric 和追蹤；
- 面向安全性設計（Security）：安全端點、API Gateway、端到端加密；
- 雲原生基礎設施不等於在公有雲上運行的基礎設施。光是租用服務器並不會使您的基礎設施雲原生化。
- 雲原生不是指在容器中運行應用程序。
- 不意味着您只能運行容器編排器（例如Kubernetes和Mesos）。容器編排器提供了雲原生基礎設施所需的許多平台功能，但並未按預期方式使用這些功能，這意味着您的應用程序會在一組服務器上運行，被動態調度。
- 編排器負責集群中的所有資源利用（例如：存儲，網絡和CPU）。該術語典型地用於描述執行許多任務的產品，如健康檢查和雲自動化。
- 調度器是編排平台的一個子集，僅負責選擇運行在每台服務器上的進程和服務。
- 雲原生不是微服務或基礎設施即代碼。
- 雲原生應用程序也改變了應用程序和基礎設施之間的關系。
- 雲原生應用程序被設計為在平台上運行，並設計用於彈性，敏捷性，可操作性和可觀察性。
- 彈性包含失敗而不是試圖阻止它們；它利用了在平台上運行的動態特性。
- 敏捷性允許快速部署和快速迭代。
- 可操作性從應用程序內部控制應用程序生命周期，而不是依賴外部進程和監視器。
- 可觀察性提供信息來回答有關應用程序狀態的問題。
- 微服務、健康報告、遙測數據、彈性、聲明式的，而不是命令式的
- 提供健康檢查的應用程序示例包括Zookeeper的ruok命令和etcd的HTTP / 健康端點。
- 我們將在雲原生應用程序中考慮彈性的兩個主要方面：為失敗設計和優雅降級。
- 盡管優雅的降級和失敗處理都應該在應用程序中實現，但平台的多個層面應該提供幫助。
- 在雲原生應用程序中，與任何事物進行通信的方式都是通過網絡進行的。很多時候，網絡通信都是通過RESTful HTTP調用完成的，但它也可以通過其他接口（如遠程過程調用（RPC））來實現。
- Serverless: 無服務器平台是雲原生化的，並通過設計對事件做出響應。他們在雲中工作得很好的原因是他們通過HTTP API進行通信，是單用途功能，並且在他們所稱的功能中聲明。該平台還可以通過在雲中進行擴展和訪問來提供幫助。
- 雲原生應用程序不能直接在PaaS上運行或與服務器的操作系統緊密耦合。它們期望在一個擁有大多數自治系統的動態環境中運行。
- 雲原生基礎設施在提供自主應用管理的IaaS之上創建了一個平台。該平台建立在動態創建的基礎設施之上，以抽象出單個服務器並促進動態資源分配調度。
- 雲原生是關於不需要人類做出決定的自治系統。它仍然使用自動化，但只有在決定了所需的操作之后。只有在系統不能自動確定正確的事情時才應該通知人。
- 雲原生應用程序不依賴於人員設置ping檢查或創建Syslog規則。他們需要從選擇基本操作系統或軟件包管理器的過程中提取自助服務資源，並依靠服務發現和強大的網絡通信來提供豐富的功能體驗。
- 雲原生准確來說是一種文化，更是一種潮流，它是雲計算的一個必然導向。它的意義在於讓雲成為雲化戰略成功的基石，而不是阻礙，如果業務應用上雲之后開發和運維人員比原先還痛苦，成本還高的話，這樣的雲我們寧願不上。
- 雲原生也很好地解釋了雲上運行的應用應該具備什么樣的架構特性——敏捷性、可擴展性、故障可恢復性。
- 敏捷, 可靠, 高彈性, 易擴展, 故障隔離保護, 不中斷業務持續更新
- Kubernetes是Google基於Borg開源的容器編排調度引擎，作為CNCF（Cloud Native Computing Foundation）最重要的組件之一，它的目標不僅僅是一個編排系統，而是提供一個規范，可以讓你來描述集群的架構，定義服務的最終狀態，Kubernetes可以幫你將系統自動得達到和維持在這個狀態。
- Kubernetes 用戶可以通過編寫一個yaml或者json格式的配置文件，也可以通過工具/代碼生成或直接請求Kubernetes API創建應用，該配置文件中包含了用戶想要應用程序保持的狀態，不論整個Kubernetes集群中的個別主機發生什么問題，都不會影響應用程序的狀態，你還可以通過改變該配置文件或請求Kubernetes API來改變應用程序的狀態。
- restful api 詳解
- Kubernetes在設計之初就充分考慮了針對容器的服務發現與負載均衡機制，提供了Service資源，並通過kube-proxy配合cloud provider來適應不同的應用場景。應用場景：
- Service：直接用Service提供cluster內部的負載均衡，並借助cloud provider提供的LB提供外部訪問
- Ingress：還是用Service提供cluster內部的負載均衡，但是通過自定義LB提供外部訪問
- Service Load Balancer：把load balancer直接跑在容器中，實現Bare Metal的Service Load Balancer
- Custom Load Balancer：自定義負載均衡，並替代kube-proxy，一般在物理部署Kubernetes時使用，方便接入公司已有的外部服務
- Service Mesh，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對於編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關心服務之間的那些原來是通過應用程序或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。
- 技術路線: 容器->Kubernetes->微服務->Cloud Native（雲原生）->Service Mesh（服務網格）->使用場景->Open Source（開源）。
- Kubernetes是容器編排系統的事實標准, Kubernetes——讓容器應用進入大規模工業生產。
- Kubernetes有機會成為跨雲的真正的雲原生應用的操作系統。
- 包括微服務和FaaS/Serverless架構，都可以作為雲原生應用的架構。
- 當前最成熟最完整的微服務框架可以說非Spring莫屬，而Spring又僅限於Java語言開發，其架構本身又跟Kubernetes存在很多重合的部分，如何探索將Kubernetes作為微服務架構平台就成為一個熱點話題。
- Kubernetes中則可以使用DNS、Service和Ingress來實現，不需要修改應用代碼，直接從網絡層面來實現。
- 我們知道Kubernetes中的所有應用的部署都是基於YAML文件的，這實際上就是一種Infrastructure as code，完全可以通過Git來管控基礎設施和部署環境的變更。
- Kubernetes中的基本資源類型分成了三類：
- 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob
- 服務：Service、Ingress
- 存儲：PV、PVC、ConfigMap、Secret
- Kubernetes主要由以下幾個核心組件組成：
- etcd 保存了整個集群的狀態；
- apiserver 提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API注冊和發現等機制；
- controller manager 負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；
- scheduler 負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；
- kubelet 負責維護容器的生命周期，同時也負責 Volume（CSI）和網絡（CNI）的管理；
- Container runtime 負責鏡像管理以及Pod和容器的真正運行（CRI）；
- kube-proxy 負責為Service提供cluster內部的服務發現和負載均衡；
- 除了核心組件，還有一些推薦的插件，其中有的已經成為CNCF中的托管項目：
- CoreDNS 負責為整個集群提供DNS服務
- Ingress Controller 為服務提供外網入口
- Prometheus 提供資源監控
- Dashboard 提供GUI
- Federation 提供跨可用區的集群
- 從Kubernetes的系統架構、技術概念和設計理念，我們可以看到Kubernetes系統最核心的兩個設計理念：一個是容錯性，一個是易擴展性。容錯性實際是保證Kubernetes系統穩定性和安全性的基礎，易擴展性是保證Kubernetes對變更友好，可以快速迭代增加新功能的基礎。
- Kubernetes作為雲原生應用的基礎調度平台，相當於雲原生的操作系統，為了便於系統的擴展，Kubernetes中開放的以下接口，可以分別對接不同的后端，來實現自己的業務邏輯：
- CRI（Container Runtime Interface）：容器運行時接口，提供計算資源
- CNI（Container Network Interface）：容器網絡接口，提供網絡資源
- CSI（Container Storage Interface）：容器存儲接口，提供存儲資源
- 以下列舉的內容都是 kubernetes 中的 Object，這些對象都可以在 yaml 文件中作為一種 API 類型來配置:
- Pod
- Node
- Namespace
- Service
- Volume
- PersistentVolume
- Deployment
- Secret
- StatefulSet
- DaemonSet
- ServiceAccount
- ReplicationController
- ReplicaSet
- Job
- CronJob
- SecurityContext
- ResourceQuota
- LimitRange
- HorizontalPodAutoscaling
- Ingress
- ConfigMap
- Label
- CustomResourceDefinition
- Role
- ClusterRole
- Controller可以創建和管理多個Pod，提供副本管理、滾動升級和集群級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節點上的Pod調度到其他健康的Node上。
- Pod hook（鈎子）是由Kubernetes管理的kubelet發起的，當容器中的進程啟動前或者容器中的進程終止之前運行，這是包含在容器的生命周期之中。可以同時為Pod中的所有容器都配置hook。
- Hook的類型包括兩種：
- exec：執行一段命令
- HTTP：發送HTTP請求。
- Hook的類型包括兩種：