运维从零认识云原生
需求
云原生的理念经过几年发展，不断丰富、落地、实践，云原生已经渡过了概念普及阶段，进入了快速发展期。而无论我们所在的企业是否已经开启了云原生建设，运维都需要去充分的认识云原生，不断的储备和云原生相关的知识点。
CNCF 云原生定义v1.0
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
❝https://github.com/cncf/toc/blob/main/DEFINITION.md
❞
云原生技术代表
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。对于容器、服务网格、微服务这三种技术运维都熟悉，但是对于不可变基础设施和声明式API运维可能还是比较陌生的，因此在此想把这两个概念弄明白，并知道它们所代表的技术实践是什么。
1.声明式API
声明式 API 是云原生重要的设计理念，有助于将系统复杂性下沉，交给基础设施进行实现和持续优化。
Kubernetes 和 基础设施即代码（Infrastructure-as-Code，IaC）使用的都是声明式API。
Kubernetes 采用声明式 API，让开发者可以专注于应用自身，而非系统执行细节。比如，在 Kubernetes 之上，提供了 Deployment、StatefulSet、Job 等不同类型应用负载的抽象。
基础设施即代码是一种典型的声明式 API，它改变了云上资源管理、配置和协同的方式。利用 IaC 工具，我们可以将云服务器、网络和数据库等不同云资源进行自动化的创建、组装和变配。将 IaC 概念进行延伸，可以覆盖整个云原生软件的交付、运维流程，即 Everything as Code。
❝Chef、Puppet、红帽 Ansible 自动化平台Saltstack、Terraform、AWS CloudFormation 等配置管理工具都是基础设施即代码的具体实践。
❞
2.不可变基础设施(Immutable Infrastructure)
不可变基础设施（Immutable Infrastructure）是由 Chad Fowler 于 2013 年提出的一个理念，其核心思想是“任何基础设施实例一旦创建，就变成为只读状态，如需要修改和升级，则使用新的实例进行替换。”这种模式可以减少配置管理的复杂性，确保系统配置变更可以可靠地、重复地执行。而且一旦部署出错时可进行快速回滚。
Docker 和 Kubernetes 容器技术正是实现 Immutable Infrastructure 模式的最佳方式。当我们为容器应用更新一个镜像版本的时候，Kubernetes 会新创建一个容器，并且通过负载均衡将新请求路由到新容器，然后销毁老容器，这避免了令人头疼的配置漂移问题。
❝云原生时代的运维体系进化 https://developer.aliyun.com/article/841569
什么是基础架构即代码（IaC）？https://www.redhat.com/zh/topics/automation/what-is-infrastructure-as-code-iac
❞
云原生要素
一种被广泛接受的构建基于云的应用程序的方法是十二因素应用程序。它描述了开发人员在构建针对现代云环境优化的应用程序时遵循的一组原则和实践。特别关注跨环境的可移植性和声明式自动化。十二因素是构建云原生应用程序的坚实基础。基于这些原则构建的系统可以快速部署和扩展，并添加功能以快速响应市场变化。
运维虽然不是开发，但是通过对云原生要素的认识，可以更好的协助研发构建并交付应用。
十二因素解释如下：
基准代码
每个微服务的单个代码库，存储在自己的存储库中。通过版本控制跟踪，它可以部署到多个环境（QA、Staging、Production）。
依赖项
每个微服务都隔离和打包自己的依赖项，在不影响整个系统的情况下接受更改。
配置
配置信息被移出微服务并通过代码外部的配置管理工具进行外部化。相同的部署可以在应用了正确配置的环境中传播。
后端服务
辅助资源（数据存储、缓存、消息代理）应通过可寻址的 URL 公开。这样做可以将资源与应用程序分离，使其可以互换。
构建、发布、运行
每个版本都必须严格区分构建、发布和运行阶段。每个都应该用一个唯一的 ID 进行标记，并支持回滚的能力。现代 CI/CD 系统有助于实现这一原则。
进程
每个微服务都应该在自己的进程中执行，与其他正在运行的服务隔离。将所需状态外部化到支持服务，例如分布式缓存或数据存储。
端口绑定
每个微服务都应该是自包含的，其接口和功能暴露在自己的端口上。这样做可以与其他微服务隔离。
并发
当容量需要增加时，横向扩展多个相同进程（副本）的服务，而不是在最强大的可用机器上扩展单个大型实例。将应用程序开发为并发，从而在云环境中无缝扩展。
易处理
服务实例应该是易处理的。支持快速启动以增加可扩展性机会和优雅关闭以使系统处于正确状态。Docker 容器和编排器天生就可以满足这一要求。
开发/生产环境相同
在整个应用程序生命周期中保持环境尽可能相似，避免代价高昂的捷径。在这里，容器的采用可以通过促进相同的执行环境做出巨大贡献。
日志
将微服务生成的日志视为事件流。使用事件聚合器处理它们。将日志数据传播到相关数据挖掘/日志管理工具，并最终传播到长期存档。
管理进程
作为一次性流程运行管理/管理任务，例如数据清理或计算分析。使用独立工具从生产环境调用这些任务，但与应用程序分开。
在《超越十二因素应用程序》一书中，作者凯文霍夫曼详细介绍了最初的 12 个因素（写于 2011 年）。此外，他还讨论了反映当今现代云应用程序设计的三个额外因素：
API设计有限
在开放服务之前，首先设计服务的API。
远程监控
对应用的健康和性能状况进行监控。
认证和授权
考虑安全，暴露端点受RBAC模式保护。
❝https://12factor.net/
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
❞
总结
云原生已至，其实并不是打破我们的知识堡垒，而是更好的去加固。当我们还停留在Iac、DevOps、GitOps、ChatOps 阶段时，为了更好的为云原生服务Immutable Infrastructure、声明式API、CloudOps、DevSecOps 等概念又顺势而生，我们也需要在学习的道路上不断的去慢慢适应。
札记：对的那条路，往往不是最好走的！