云
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 ###
- 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
k3s
XMind: ZEN - Trial Version
