雲-雲原生-K8s-devops相關資料備註-腦圖
雲
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)
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 Linux二、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集成
雲原生
雲原生架構進階實戰git
十二要素
- 一份基準代碼(Codebase),多份部署(Deploy)
- 顯式聲明依賴關係(Dependency)
- 在環境中存儲
- 把後端服務(backing services)看成附加
- 嚴格分離構建、發佈和運行
- 以一個或多個無狀態進程運行應用
- 經過端口綁定(Port binding)來提供服務
- 經過進程模型進行擴展
- 快速啓動和優雅終止可最大化健壯性
- 儘量地保持開發、預發佈和線上環境相同
- 儘量地保持開發、預發佈和線上環境相同
- 後臺管理任務看成一次性進程運行
k8s
- kubectl run -it --rm busybox --image=busybox -- ping ###
- run -it --rm busybox --image=busybox -- curl ###
devops
虛擬化
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
rancher
k3s
歡迎關注本站公眾號,獲取更多信息