雲-雲原生-K8s-devops相關資料備注-腦圖

雲

Service Mesh實戰：用Istio軟負載實作服務網格/周遙著.—北京：電子工業出版社，2019.5

雲原生的本質，是解決應用的彈性（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
• 掃描
• 開源鏡像倉庫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 ###

1. 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
• https://cd.foundation/projects/
• 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

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