从零开始，轻松理解云原生的核心概念和关键技术
文章目录
- 前言
- 一. 云原生的介绍
- 1.1 什么是云原生
- 1.2 云原生的特征
- 1.3 云原生的历史和发展进程
- 二. 与云原生相关的产品和分类
- 2.1 云原生的技术分类
- 2.2 常用的服务和应用
- 2.2.1 应用定义和构建
- 2.2.2 CI/CD 持续交付和持续集成
- 2.2.3 调度和编排
- 2.2.4 API网关
- 2.2.5 服务网格
- 2.2.6 云原生存储
- 2.2.7 容器运行时
- 2.2.8 容器仓库
- 2.2.9 监控
- 2.2.10 日志
- 2.2.11 分布式追踪
- 2.2.12 混沌工程
- 参考资料
前言
一. 云原生的介绍
1.1 什么是云原生
先看网上的概念，一分钟把你搞懵逼的那种：
云原生是一种软件架构和运维模式，旨在使应用程序更快，更可靠，更灵活。简单来说，云原生是将应用程序打包为容器，并通过自动化部署和管理这些容器的方式来实现高度可伸缩和可靠性的现代化方法
在上面的概念中我们提取到了三个信息
-
云原生应用程序通常是由许多小型服务组成，每个服务都只关注特定的功能。这些服务被打包到称为“容器”的封闭环境中，容器可以在任何地方运行，因为它们不依赖于底层系统。
-
云原生应用程序部署和管理是自动化的，这意味着开发人员可以使用工具来自动构建，测试和部署应用程序，而不必手动干预。自动化还包括自动扩展和自动恢复，以确保应用程序在高负载和故障情况下保持可靠性。
-
云原生应用程序是可观察的，这意味着开发人员和运维人员可以实时监控应用程序的健康状况和性能，以便及时发现和解决问题。
云原生的核心思想：将应用程序打包为容器，并通过自动化来实现高度可伸缩和可靠性的现代化方法。
云原生计算基金会也提供了官方定义：
云原生技术使组织能够在新式动态环境（如公有云、私有云和混合云）中构建和运行可缩放的应用程序。 容器、服务网格、微服务、不可变基础结构和声明性 API 便是此方法的范例。
这些技术实现了可复原、可管理且可观察的松散耦合系统。 它们与强大的自动化相结合，使工程师能够在尽量减少工作量的情况下，以可预测的方式频繁地进行具有重大影响力的更改。
现如今互联网产品的发展，从实现业务功能到加快业务速度和增长，在实现业务功能阶段，一个运维只需要会基本的安装部署即可，但到了业务快速增长阶段， 版本迭代需求增加，业务系统也越来越复杂，用户要求越来越高。
比如以前的用户打开网站，一分钟打不开都觉得正常，现在三秒钟打不开就觉得卡顿， 一旦用户觉得你的网站反应迟钝，反复报错等，就会立即投入到竞争对手的网站。
所以云原生解决的问题，就是支持快速更改，大规模无感知操作和快速复原能力。
比如某信聊天软件，在生产环境近4000多种服务，每天部署超过了1000次，再用传统的方式就显得力不从心。
1.2 云原生的特征
云原生有一种被被广泛认可的用于构建基于云的应用程序的方法，开发人员在构建针对新式云环境进行优化的应用程序时需要遵循这些内容。 其中特别关注了跨环境的可移植性和声明性自动化。
这个就是十二要素应用程序，我们一起来看一下：
| 要素 | 介绍 |
|---|---|
| 基准代码 | 每个微服务都有单个基本代码，存储在其自己的存储库中。 它通过版本控制进行跟踪，可以部署到多个环境（QA、暂存、生产）。一份基准代码，多份部署（用同一个代码库进行版本控制，并可进行多次部署）。 |
| 依赖 | 显式地声明和隔离相互之间的依赖，每个微服务都隔离并打包其自己的依赖项，以在不影响整个系统的情况下进行更改。 |
| 配置 | 配置信息通过代码之外的配置管理工具移出微服务和实现外部化。 在应用了正确配置的情况下，相同部署可以在环境间传播。 |
| 支持服务 | 辅助资源（数据存储、缓存、消息中转站）应通过可寻址 URL 进行公开。 这样做可使资源与应用程序分离，使其可以互换。 |
| 构建，发布，运行 | 对程序执行构建或打包，并严格分离构建和运行，每个版本都必须在生成、发布和运行阶段执行严格的分离。 各自都应使用唯一 ID 进行标记，并支持回滚功能。 新式 CI/CD 系统有助于实现此原则 |
| 进程 | 每个微服务应在其自己的进程中执行，与其他正在运行的服务隔离。 将所需状态外部化到支持服务，如分布式缓存或数据存储。。 |
| 端口绑定 | 每个微服务都应是独立的，其接口和功能在自己的端口上公开。 这样做可与其他微服务隔离。 |
| 并发 | 当容量需要增加时，跨多个相同进程（副本）横向扩展服务，而不是在功能最强大的可用计算机上纵向扩展单个大型实例。 将应用程序开发为并发应用程序，从而无缝地在云环境中横向扩展。 |
| 易处理 | 服务实例应是可处置的。 支持快速启动以增加可伸缩性机会，以及支持正常关闭以使系统保持正确状态。 Docker 容器以及业务流程协调程序本质上满足此要求 |
| 开发环境与线上环境等价 | 尽可能的保持开发，预发布，线上环境相同。 |
| 日志记录 | 将所有运行中进程和后端服务的输出流按照时间顺序统一收集存储和展示。 |
| 管理进程 | 以一次性进程形式运行管理性/管理任务，例如数据清理或计算分析。 使用独立工具从生产环境调用这些任务，但独立于应用程序。 |
云原生最核心的特征：
-
云原生可以提高资源效率，用更少的服务器运行同样数量的服务，同样的服务器运行更多的服务；
-
云原生基础设施建设可以提高整个开发速度，同时还能降低风险；
-
Kubernetes 打通了所有云厂家的资源，使用户可以利用不同云厂商的基础建设无缝地运行应用；
-
云原生架构使“更快部署”成为可能，几个月的部署时间可以减少到几分钟。
1.3 云原生的历史和发展进程
2000 年以前，当时流行的技术是以 Sun 公司为代表的非虚拟化技术，在需要运行应用时，首先要购买物理服务器，然后在服务器上运行它。
-
2001年 VMware技术普及，可以实现在一台物理机上运行多个虚拟机。
-
2006年 IAAS 诞生，AWS 创建了以 EC2 服务器为代表的云计算和弹性计费的方式，用户在使用的时候可以按小时付费，AMI（Amazon Machine Image）镜像成为了程序打包和运行的普遍方式。
-
2009 年，PaaS（平台即服务）诞生
-
2010 年，IaaS 层的开源方案 OpenStack 诞生了，它由 AWS 和 VMWARE 完成，至今 OpenStack 在私有云的市场仍然是非常流行的解决方案。2011 年，Cloud Foundry 发布了开源的 PaaS 解决方案，它是 Heroku 的开源替代方案。
-
2013 年docker诞生，Docker 整合了 LXC、联合文件系统和 cgroups 技术并创建了一个容器化标准，改变了应用的构建，分享和交付。
-
2015年12月 CNCF成立
CNCF 成立于 2015 年 12 月，它是 Linux 基金会的一部分。在成立之初，CNCF 得到了 Google 和 SoundCloud 的支持，这两家公司分别捐赠了著名的 Kubernetes 以及 Prometheus，在当时，一并作为会员加入 CNCF 的企业还有：Cisco、CoreOS、Docker、Google、华为、IBM、Intel 和 Redhat 等。
开源项目是 CNCF 的核心资产，比如著名的 Kubernetes、etcd 和 Helm 等项目都是 CNCF 的托管项目。托管项目来自厂商的捐赠，捐赠内容包括源码、商标和网站等和项目相关的内容。
为了区分成熟度，CNCF把项目分为三个部分：
- Sandbox（沙箱阶段）
- Incubating（孵化阶段）
- Graduated（毕业阶段）
当一个项目被捐赠时，会首先进入到沙箱阶段，之后开始试用，等达到一定的人数和规模后会进入孵化近段，最后到毕业阶段，这是一个层层筛选的过程。
毕业的项目中，有我们常见的k8s，prometheus等。
CNCF的职业认证：
- CKA：Kubernetes 管理员认证
- CKAD：Kubernetes 开发者认证
- CKS：Kubernetes 安全认证
- KCNA：Kubernetes 管理员助理认证
- PCA：Prometheus 管理员认证
- KCSA：Kubernetes 安全助理认证
二. 与云原生相关的产品和分类
2.1 云原生的技术分类
- 数据库（Database）
- 数据流和消息（Streaming & Messaging）；
- 应用定义和镜像构建（Application Definition & Image Build）；
- 持续集成和持续交付（Continuous Integration & Delivery）；
- 调度和编排（Scheduling & Orchestration）；
- 协调和服务发现（Coordination & Service Discovery）；
- 远程调用（Remote Procedure Call）；
- 服务代理（Service Proxy）；
- API 网关（API Gateway）；
- 服务网格（Service Mesh）；
- 云原生存储（Cloud Native Storage）；
- 容器运行时（Container Runtime）；
- 云原生网络（Cloud Native Network）；
- 自动化和配置（Automation & Configuration）；
- 容器仓库（Container Registry）；
- 安全与合规（Security & Compliance）；
- 秘钥管理（Key Management）；
- 监控（Monitoring）；
- 日志（Logging）；
- 分布式追踪（Tracing）；
- 混沌工程（Chaos Engineering）；
- 持续优化（Continuous Optimization）。
2.2 常用的服务和应用
上面的22项，不需要全部都研究，我们重点学习和研究以下几个方向，后期的文章更新也是在这几个方向上：
2.2.1 应用定义和构建
云原生应用以及构建容器镜像上，例如应用编写、打包、测试、安装和升级。主要有以下几个：
- helm
- Buildpacks
- KubeVela
- Nocalhost
- Telepresence
- Manifest
- Dockerfile
2.2.2 CI/CD 持续交付和持续集成
- ArgoCD
- FluxCD
- Tekton
- Spinnaker
- jenkins
- Gitlab CI
对于大部分 Kubernetes 业务应用来说，持续集成主要的功能是自动化测试和构建镜像，持续部署主要的功能是将应用部署到 Kubernetes。这样的话， Tekton(CI) + ArgoCD(GitOps) 的搭配就是一个不错的选择，
当部署环境涉及多云以及混合的运行环境时，例如， Kubernetes 应用和 VM 应用共存时，可以考虑使用 Spinnaker。
2.2.3 调度和编排
这个方向聚焦在容器调度和基础设施的编排上，例如跨集群调度和管理容器。主要的产品包括 Kubernetes 和 Crossplane
- kubernetes
- Nomad
- Docker-commpose
- Terraform
- CrossPlane
2.2.4 API网关
这个方向聚焦在基于 Kubernetes 的 API 网关上，主要的产品有下面几类：
- Emissary-ingress
- Ingress-nginx
- Traefik
- Kong
- Apisix
Ingress-nginx 和 Traefik-ingress 是项目中比较常用的 API 网关。
2.2.5 服务网格
服务网格是一种管理服务之间通信的工具，为了简化服务之间的通信和管理，许多开源产品提供了服务网格的实现。以下是一些常见的服务网格开源产品：
-
Istio：Istio是Google、IBM和Lyft等公司开发的开源服务网格项目，支持Kubernetes和其他容器平台，并提供流量管理、服务间认证、安全等功能。
-
Linkerd2：Linkerd是由Buoyant公司开发的轻量级服务网格项目，基于Kubernetes和Docker等容器平台，提供负载均衡、故障转移、监控等功能。
-
Consul：Consul是HashiCorp公司开发的开源服务发现和配置管理工具，同时也支持服务网格功能，提供负载均衡、服务间认证、流量管理等功能。
-
Envoy：Envoy是由Lyft公司开发的开源高性能代理服务器，可用于服务网格的数据面，支持多种协议和平台。
-
Maesh：Maesh是由Containous公司开发的轻量级服务网格项目，基于Kubernetes和Docker等容器平台，提供负载均衡、流量管理、服务间认证等功能。
服务网格能够以无侵入的方式为服务调用提供可观察性、流量管理和安全性等方面的支持。在我们最关注的流量管理方面，服务网格可以无侵入实现服务熔断和降级、金丝雀和灰度发布、访问速率控制、加密以及端到端的身份验证。
2.2.6 云原生存储
这一方向聚焦在 Kubernetes 的存储解决方案，也就是提供持久卷的存储能力上。主要的产品有 Rock、 Longhorn 和 Velero，ceph
-
Kubernetes本地存储：Kubernetes本地存储是Kubernetes官方提供的一种轻量级、快速的存储解决方案，通过提供空间卷和持久化卷两种模式，为应用程序提供了本地磁盘和网络存储两种类型的数据存储支持。
-
Rook：Rook是一个开源的云原生存储编排框架，支持多种存储类型，包括Ceph、EdgeFS、Minio、NFS等，可以与Kubernetes无缝集成，提供数据可靠性、高可用性和灵活性等功能。
-
OpenEBS：OpenEBS是一个开源的云原生存储解决方案，支持多种存储引擎，包括ZFS、Ceph、Local PV等，可与Kubernetes、OpenShift等容器平台无缝集成，提供高性能、可靠性和灵活性等功能。
-
Longhorn：Longhorn是一个开源的云原生分布式块存储解决方案，支持Kubernetes、Rancher等容器平台，提供高性能、高可靠性、动态扩展等功能，同时也提供了快照、备份和恢复等数据管理功能。
-
Portworx：Portworx是一个开源的云原生存储解决方案，支持Kubernetes、Mesos等容器平台，提供高性能、高可靠性、动态扩展等功能，同时也提供了快照、备份和恢复等数据管理功能。
2.2.7 容器运行时
容器运行时是 Kubernetes 执行容器化动作的软件，主要有：
- Containerd
- CRI-O
- Kata-Containers
- gVisor
2.2.8 容器仓库
这个方向聚焦在为镜像提供推送、存储和下载功能。主要的产品有 Harbor 和 Dragonfly2。
容器仓库本质上是一组 Web API 接口，它允许容器运行时推送、查找和下载容器镜像
2.2.9 监控
该方向聚焦在为 Kubernetes 提供监控指标采集、查询和可视化服务上，主要的产品有 Prometheus、 Thanos 和 Grafana。
在云原生监控方向，Prometheus + Grafana 已经成为非常流行的开源技术选型方案。要快速搭建它们相对容易，但要长期使用的话，这个方案对运维要求还是比较高的，尤其是要面对 Prometheus 的大规模集群和持久化的后端存储方面的挑战。
2.2.10 日志
日志方向主要聚焦在为 Kubernetes 应用提供日志采集、存储和分析功能，主要产品有 Fluentd 和 Loki。
日志方向有不少开源的技术选型，例如我们常见的 EFK 技术栈。EFK 由 Elasticsearch、Fluentd 和 Kibana 组成，其中，Elasticsearch 主要负责存储日志和查询分析，Fluentd 作为 Agent 负责采集日志信息并将日志发送到 Elasticsearch 中存储，Kibana 则作为展示查询结果的 UI 界面。
在一些中小型的应用场景中，Loki 是一个更流行的选择。特别是对于已经采用 Prometheus 作为监控的团队来说，Prometheus + Loki + Grafana 可以一次性解决监控和日志问题。
2.2.11 分布式追踪
该方向致力于为 Kubernetes 应用提供分布式调用链追踪能力。主要产品有 Jaeger、 Skywalking 和 Grafana Tempo。
Jaeger 是一个非常不错的选择，但它的代价是需要集成相对应的 SDK，对业务有一定的侵入性。
2.2.12 混沌工程
该方向聚焦在为 Kubernetes 应用提供混沌工程实验平台，主要的产品为 Chaos-Mesh 和 Chaosblade。
混沌工程（Chaos Engineering）是一种系统设计和测试方法，旨在通过有意识地在生产环境中引入故障和异常情况，从而识别和纠正潜在的系统故障点。混沌工程的目标是确保系统的可靠性、弹性和容错性，并使团队能够更快地发现和解决故障。
在云原生环境中，混沌工程被用来测试和验证云原生应用程序的弹性和可靠性。云原生应用程序通常由许多微服务组成，这些微服务需要在分布式环境中协同工作。混沌工程通过模拟真实世界中的故障场景，例如故障节点、网络延迟和磁盘故障，来测试系统的可靠性和弹性。
混沌工程通常包括以下步骤：
定义实验范围和目标
设计和实现实验
执行实验
监控和测量实验结果
分析和总结实验结果
根据实验结果改进系统设计和实现
混沌工程需要对系统进行有目的的攻击和测试，因此需要进行慎重的计划和执行。同时，混沌工程也可以提高团队的应急响应和故障处理能力，从而加强系统的可靠性和弹性。
参考资料
亚马逊： https://aws.amazon.com/cn/what-is/cloud-native/
CNCF: https://www.cncf.io/