# 云
## Service Mesh實戰：用Istio軟負載實作服務網格/周遙著.—北京：電子工業出版社，2019.5
### 云原生的本質，是解決應用的彈性（resiliency）、易用性（usability）和可移植性（portability）
### 云原生的本質，是解決應用的彈性（resiliency）、易用性（usability）和可移植性（portability）
### 云原生的本質，是解決應用的彈性（resiliency）、易用性（usability）和可移植性（portability）
### 軟負載到底是如何由最基礎的硬體服務一步步演化到服務網格（Service Mesh）
* 單機小型機時期
* 集群化時期
* 服務化時期
* 微服務時期
* 服務網格（Service Mesh）新時期
* 第一代服務網格架構
* Service Mesh 是一個“基礎設施”層，用于處理服務間通信，云原生應用有著復雜的服務拓撲，Service Mesh 保證請求可以在這些“拓撲”中“可靠”地穿梭，在實際應用當中，Service Mesh 通常是由一系列輕量級的“網路代理”組成的，它們與應用程式部署在一起，但應用程式“不需要知道”它們的存在，
Linkerd
* 第二代服務網格架構
* 第二代服務網格典型的特點便是同時擁有了資料接管與集中控制能力，Google 分別將兩個能力對應的系統定義為“資料平面（Data Plane）”及“控制平面（Control Plane）”，
### 服務網格的未來，是將服務間通信的能力下沉到基礎設施，然后充分利用底層基礎設施的能力來架構整個體系，所以不僅服務網格是趨勢，Kubernetes 也是未來運維的一部分，
## 云原生應用構建：基于OpenShift魏新宇 王洪濤 陳耿 著
### 云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用，云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API，
## Kubernetes權威指南：從Docker到Kubernetes實踐全接觸
### 企業級容器云技術選型
* 場景一：企業規模不是很大，應用不是太復雜在這種簡單場景下，Swarm是比較好用的，能和Docker很好地結合在一起，并且能和Docker Compose很好地一起作業，因此非常適合對其他調度器不太了解的開發者
* 場景二：企業規模較大，應用較復雜，有多種應用框架
在集群規模和節點較多，且擁有多個作業任務（Hadoop、Spark、Kafka等）時，使用Swarm就顯得力不從心了，這時可以使用Mesos和Marathon，Mesos是一個非常優秀的調度器，強調的是資源混用的能力，它引入了模塊化架構，雙層調度機制可以使集群的規模大很多，Mesos Master的資源管理器為不同的應用框架提供底層資源，同時保持各應用框架的底層資源相互隔離，它的優勢是在相同的基礎設施上使用不同的作業負載，通過傳統的應用程式Java、無狀態服務、批處理作業、實時分析任務等，提高利用率并節約成本，這種方法允許每個作業負載都有自己專用的應用程式調度器，并了解其對部署、縮放和升級的具體操作需求，
* 場景三：企業規模大，業務復雜，應用粒度劃分更細在這種場景下，采用Kubernetes就更適合了，其核心優勢是為應用程式開發人員提供了強大的工具來編排無狀態的Docker容器，而不必與底層基礎設施互動，并在跨云環境下為應用程式提供了標準的部署介面和模板，Kubernetes提供了強大的自動化機制和微服務管理機制，可以使后期的系統運維難度和運維成本大幅度降低，Kubernetes模塊的劃分更細、更多，比Marathon和Mesos的功能更豐富，而且模塊之間完全松耦合，可以非常方便地進行定制，
### Kubernetes Ingress提供具體Controller的開源工具包括Nginx、HAProxy和Traefik，
## 深入淺出Serverless：技術原理與應用實踐
### Serverless是一種軟體系統架構思想和方法，它的核心思想是用戶無須關注支撐應用服務運行的底層主機，這種架構的思想和方法將對未來軟體應用的設計、開發和運營產生深遠的影響，
### AWS Lambda，最早被大眾所認可的Serverless實作，·Azure Functions，來自微軟公有云的Serverless實作，·OpenWhisk，Apache社區的開源Serverless框架，·Kubeless，基于Kubernetes架構實作的開源Serverless框架，·Fission，Platform9推出的開源Serverless框架，·OpenFaaS，以容器技術為核心的開源Serverless框架，·Fn，來自Oracle的開源Serverless框架，由原Iron Functions團隊開發，
### Serverless實作按功能而言，主要為應用服務提供了兩個方面的支持：函式即服務（Function as a Service，FaaS）以及后臺即服務（Backend as a Service，BaaS）
### Serverless相關資源串列：https://github.com/anaibol/awesome-serverless，
### Serverless導覽圖的參考地址：https://github.com/cncf/wg-serverless，值得一提的是，CNCF基金會還維護了一些關于構建、設計和運行云原生應用的資源導覽圖，可以在如下GitHub倉庫中查閱：https://github.com/cncf/landscape
## DEVOPS
### 自動部署
* Ansible
* Inventory
* Playbook
* AdHoc
* console
* doc
* role
* galaxy
* SaltStack
* Puppet
* Chef
* Fabric
### 工件庫
制品庫
* sonatype nexus
* docker
* Docker registery
* Harbor
Harbor權威指南
* Helm
* docker
* 掃描
* 開源鏡像倉庫Harbor專案，解決了用戶管理容器鏡像的諸多痛點，如權限控制、遠程復制、漏洞分析等
* Harbor在Docker Registry的基礎上增加了企業用戶必需的權限控制、鏡像簽名、安全漏洞掃描和遠程復制等重要功能，還提供了圖形管理界面及面向國內用戶的中文支持，開源后迅速在中國開發者和用戶社區流行，成為中國云原生用戶的主流容器鏡像倉庫，
* github.com/goharbor/harbor/
* helm repo add harbon https://helm.goharbor.io
* --with-notary：選擇安裝鏡像簽名組件Notary，其中包括Notary Server和Notary Signer如果指定安裝Notary，則必須配置Harbor的網路協議為HTTPS，◎ --with-clair：選擇安裝鏡像掃描組件Clair，◎ --with-trivy：選擇安裝鏡像掃描組件Trivy，◎ --with-chartmuseum：選擇安裝Chart檔案管理組件ChartMuseum，
* Harbor的管理員密碼的默認值為Harbor12345
* 掃描器
* Trivy既能夠檢測出許多作業系統中的漏洞，包括Alpine、RHEL、CentOS、Debian、Ubuntu、SUSE、Oracle Linux、Photon OS和Amazon Linux等；也能發現應用程式依賴中的漏洞，包括Bundler、Composer、Pipenv、Poetry、npm、Yarn和Cargo等，據Aqua公司所稱，相比于其他掃描器，Trivy在檢測漏洞方面具有很高的準確性，尤其是在Alpine Linux和RHEL/CentOS上，
* Clair可以交叉檢查容器鏡像的作業系統，以及安裝于其上的任何軟體包是否與已知的具有漏洞的不安全版本相匹配，漏洞資訊從特定作業系統的CVE資料庫中獲取，目前支持的作業系統包括Debian、Ubuntu、CentOS、Oracle Linux、Amazon Linux、OpenSUSE和Alpine等，Clair是一種靜態掃描工具，在其掃描程序中不需要實際運行容器，
* Anchore引擎會從與Docker V2兼容的鏡像倉庫中下載并分析容器鏡像，然后根據用戶可自定義的相關策略進行評估，以執行安全性、合規性和最佳實踐的檢查，Anchore引擎支持掃描的作業系統包括Alpine、Amazon Linux2、CentOS、Debian、Google Distroless、Oracle Linux、RHEL、Red Hat UBI和Ubuntu；支持的應用包依賴包括GEM、Java Archive檔案（Jar、War、Ear）、NPM和Python（PIP），其商業軟體Anchore的企業版構建于開源的Anchore引擎之上，提供了更易于運維管理的操作界面和其他后臺功能與模塊，
* Aqua CSP是Aqua公司旗下專注于云原生平臺與環境安全的平臺服務，其目標是加速容器采用并縮小DevOps與IT安全之間的差距，
* DoSecDoSec掃描器由中國云安全產品提供商小佑科技開發并提供，是唯一支持中文漏洞庫的掃描器，開箱即用，考慮到很多用戶在無互聯網的環境下使用掃描器，此掃描器在安裝時包含了版本發布時的全部最新漏洞庫，其中包括最新的CNNVD中文漏洞庫，不過掃描器也支持實時在線更新漏洞庫，在網路環境下可獲取最近的更新，目前其支持掃描的作業系統包括Debian（7及以上版本）、Ubuntu LTS（12.04及以上版本）、RHEL（5及以上版本）、CentOS（5及以上版本）、Alpine（3.3及以上版本）、Oracle Linux（5及以上版本），
* 未來會有更多的掃描器（比如Sysdig等）支持此框架，以便與Harbor集成
## 云原生
云原生架構進階實戰
### 十二要素
* 一份基準代碼（Codebase），多份部署（Deploy）
* 顯式宣告依賴關系（Dependency）
* 在環境中存盤
* 把后端服務（backing services）當作附加
* 嚴格分離構建、發布和運行
* 以一個或多個無狀態行程運行應用
* 通過埠系結（Port binding）來提供服務
* 通過行程模型進行擴展
* 快速啟動和優雅終止可最大化健壯性
* 盡可能地保持開發、預發布和線上環境相同
* 盡可能地保持開發、預發布和線上環境相同
* 后臺管理任務當作一次性行程運行
### k8s
* kubectl run -it --rm busybox --image=busybox -- ping ###
kubectl run -it --rm busybox --image=busybox -- curl ###
* glusterfs
* 熟悉Ansible，建議使用該方法部署，具體可以參考https://github.com/gluster/gluster-ansible，
* 若使用容器部署，則可以參考https://github.com/gluster/gluster-containers，
### devops
* 構建服務器
* Jenkins和GitLab Runner，
* Jenkins X
* 部署
* 應用部署策略主要有六種：重建部署、滾動部署、藍綠部署、金絲雀部署、A/B部署以及影子部署
* ContainerSolutions的k8s-deployment-strategies鏡像（https://github.com/ContainerSolutions/k8s-deployment-strategies）
* 在Kubernetes集群中運行GitLabGitLab公司建議使用helm在Kubernetes中部署GitLab，可以參考https://docs.gitlab.com/charts
* 持續方法主要有三種：● 持續集成（Continuous Integration, CI）● 持續交付（Continuous Delivery, CD）● 持續部署（Continuous Deployment, CD）
* 持續集成是指標對每次推送到代碼庫中的代碼，通過一組腳本來自動構建、測驗，從而減少向應用程式引入錯誤的可能性，
* 持續交付是持續集成的一個步驟，代碼推送到代碼庫后通過一系列構建和測驗，然后進行持續部署，如果部署是手動觸發的，稱為持續交付；如果是自動觸發的，則稱為持續部署，
* CDGitLab CI/CD是GitLab內置的強大工具，允許企業將所有持續方法（持續集成、交付和部署）應用于企業開發程序，而無須第三方應用程式或集成，只需要在專案根目錄下添加.gitlab-ci.yml檔案，即可啟用GitLab CI/CD，
* 工具集
* 早期工具
* jenkins
比較早期的
* TFS
* 在線代碼庫自有
* github Action
* .travis.yml
* gitlab Runner
* .gitlab-ci.yml
* 云原生
k8s
* https://cd.foundation/projects/
* Jenkins X
Tekton
* 獨立的工具
* Draft
* https://gitee.com/mirrors/draft
* Skaffold
* https://skaffold.dev/docs/install/
* https://skaffold-latest.firebaseapp.com/docs/
* skaffold.yaml完整的語法 https://skaffold-latest.firebaseapp.com/docs/references/yaml/
## 虛擬化
### KVM實戰：原理、進階與性能調優
* 軟體虛擬化技術
* 最純粹的軟體虛擬化實作當屬QEMU，在沒有啟用硬體虛擬化輔助的時候，它通過軟體的二進制翻譯 仿真出目標平臺呈現給客戶機，客戶機的每一條目標平臺指令都會被QEMU截取，并翻譯成宿主機平臺的指令，然后交給實際的物理平臺執行
* 硬體虛擬化技術
* 硬體虛擬化技術就是指計算機硬體本身提供能力讓客戶機指令獨立執行，而不需要（嚴格來說是不完全需要）VMM截獲重定向，
Intel VT和AMD-V
* 軟體框架的角度上，根據虛擬化層是直接位于硬體之上還是在一個宿主作業系統之上，將虛擬化劃分為Typel和Type2
* Type1（型別1）Hypervisor也叫native或bare-metal Hypervisor，這類虛擬化層直接運行在硬體之上，沒有所謂的宿主機作業系統，它們直接控制硬體資源以及客戶機，典型地如Xen和VMware ESX
* Type2（型別2）Hypervisor運行在一個宿主機作業系統之上，如VMware Workstation；或系統里，如KVM，
* KVM全稱是Kernel-based Virtual Machine，即基于內核的虛擬機，是采用硬體虛擬化技術的全虛擬化解決方案
* RHEL發行版中集成KVM，逐步取代Xen，并從RHEL7開始，正式不支持Xen，
* 一個KVM客戶機對應于一個Linux行程，每個vCPU則是這個行程下的一個執行緒，還有單獨的處理IO的執行緒，也在一個執行緒組內，所以，宿主機上各個客戶機是由宿主機內核像調度普通行程一樣調度的，即可以通過Linux的各種行程調度的手段來實作不同客戶機的權限限定、優先級等功能，客戶機所看到的硬體設備是QEMU模擬出來的（不包括VT-d透傳的設備），當客戶機對模擬設備進行操作時，由QEMU截獲并轉換為對實際的物理設備（可能設定都不實際物理地存在）的驅動操作來完成，
* Hypervisor，又稱虛擬機監視器（英語：virtual machine monitor，縮寫為 VMM）
* KVM是Openstack的默認Hypervisor
* VMware EXS
* 微軟的Hyper-V
* KVM架構
* KVM內核模塊
* 一個是處理器架構無關的部分，用lsmod命令中可以看到，叫作kvm模塊
* 另一個是處理器架構相關的部分，在Intel平臺上就是kvm_intel這個內核模塊，
* QEMU用戶態工具
* QEMU除了提供完全模擬的設備（如：e1000網卡、IDE磁盤等）以外，還支持virtio協議的設備模擬，virtio是一個溝通客戶機前端設備與宿主機上設備后端模擬的比較高性能的協議，在前端客戶機中需要安裝相應的virtio-blk、virtio-scsi、virtio-net等驅動，而QEMU就實作了virtio的虛擬化后端，
* KVM上層管理工具
* libvirt libvirt是使用最廣泛的對KVM虛擬化進行管理的工具和應用程式介面
* virsh virsh是一個常用的管理KVM虛擬化的命令列工具，對于系統管理員在單個宿主機上進行運維操作
* virt-manager是專門針對虛擬機的圖形化管理軟體，底層與虛擬化互動的部分仍然是呼叫libvirt API來操作的
* MISC
* oVirt
* oVirt是面向KVM
* RedHat 商業版本虛擬化軟體 RHEV 的開源版本
* Openstack
* 面向多種系統虛擬機，通過抽象虛擬資源和虛擬機來實作一整套資料中心方案，在對KVM的支持上，Open stack不如oVirt，
* 概要: https://www.cnovirt.com/archives/2598
oVirt與OpenStack之間如何選擇
* 概要: 半虛擬化和全虛擬化
### Vagrant
## k8s
### dashboard
### Octant
* https://github.com/vmware-tanzu/octant
Octant 是一個客戶端工具，用戶不需要在集群中安裝任何東西就可以使用它，因為 Octant 在本地運行，所以它使用開發人員的本地憑證和權限來查詢集群中的物件，
### rancher
* https://www.rancher.cn/
* https://github.com/rancher/rancher
### k3s
*XMind: ZEN - Trial Version*
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/184390.html
標籤：其他
上一篇：MySQL 之 基礎操作