其实本章原来名为k8s，后来感觉云的概念/应用太多了，远远不止一个k8s，所以就以云为开始
云原生的定义
云原生（Cloud Native）这个词汇由来已久，以致于何时出现已无据可考。云原生开始大规模出现在受众视线中，与 Pivotal 提出的云原生应用的理念有着莫大的关系。我们现在谈到云原生，更多的指的是一种文化，而不具象为哪些技术体系。
早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做 迁移到云原生应用架构 的小册子，其中探讨了云原生应用架构的几个主要特征：
- 符合 12 因素应用
- 面向微服务架构
- 自服务敏捷架构
- 基于 API 的协作
- 抗脆弱性
到了 2015 年 Google 主导成立了云原生计算基金会（CNCF），起初 CNCF 对云原生（Cloud Native）的定义包含以下三个方面：
- 应用容器化
- 面向微服务架构
- 应用支持容器的编排调度
到了 2018 年，随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF 基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定位。
以下是 CNCF 对云原生的重新定义（中英对照）
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
设计理念
云原生系统的设计理念如下:
- 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
- 面向配置设计（Configuration）：一个镜像，多个环境配置；
- 面向韧性设计（Resistancy）：故障容忍和自愈；
- 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
- 面向交付设计（Delivery）：自动拉起，缩短交付时间；
- 面向性能设计（Performance）：响应式，并发和资源高效利用；
- 面向自动化设计（Automation）：自动化的 DevOps；
- 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
- 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；
容器
容器最初是通过开发者工具而流行，可以使用它来做隔离的开发测试环境和持续集成环境，这些都是因为容器轻量级，易于配置和使用带来的优势，docker 和 docker-compose 这样的工具极大的方便的了应用开发环境的搭建，开发者就像是化学家一样在其中小心翼翼的进行各种调试和开发。
随着容器的在开发者中的普及，已经大家对 CI 流程的熟悉，容器周边的各种工具蓬勃发展，俨然形成了一个小生态，在 2016 年达到顶峰，
容器生态涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面，随着在单主机中运行容器的成熟，集群管理和容器编排成为容器技术亟待解决的问题。譬如化学家在实验室中研究出来的新产品，如何推向市场，进行大规模生产，成了新的议题。
在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos 和 Kubernetes 的大战已经基本宣告结束，Kubernetes 成为了无可争议的赢家。
随着 Kubernetes 的日趋成熟，“Kubernetes is becoming boring”，基于该 “操作系统” 之上构建的适用于不同场景的应用将成为新的发展方向，就像我们将石油开采出来后，提炼出汽油、柴油、沥青等等，所有的材料都将找到自己的用途，Kubernetes 也是，毕竟我们谁也不是为了部署和管理容器而用 Kubernetes，承载其上的应用才是价值之所在
云端IDE
传统上，软件开发是（而且在很大程度上仍然是）在个人机器上使用集成开发环境（IDE）工具，如 VSCode、JetBrains、Eclipse 等完成。虽然这种 “离线” 开发的模式在早期运作得非常好，但人们很快就注意到，这种方法并非完美。
首先，合作起来很麻烦，因为写好的代码必须上传到网上供进一步审查。这样写出来的代码的可移植性也并不总是有保证，因为有各种各样的操作系统和其他限制条件，需要它来实现最佳的功能。
正如开发者和技术记者 Owen Williams 去年 在他的博客 Charged 上写道：“在设备之间同步你的文档和照片是微不足道的…… 这样你就可以在任何地方把它们调出来，但开发者工具仍然停留在过去 —— 每台笔记本电脑或 PC 都要单独配置，使你的环境设置得恰到好处。”
随着大流行期间越来越多的分布式团队和更多的敏捷工作方式，引入能够让开发人员在任何地方保持生产力的工具变得至关重要。这为什么会有 Gitpod、GitHub Codespaces、Replit 等基于云端 IDE 出现。
云端IDE的优点：
使用云端 IDE 无需担心配置
由于开发环境完全在浏览器上运行，因此不再需要梳理安装页面和弄清楚需要安装哪个软件包。
硬件的选择并不重要
基于云的集成开发环境消除了（好吧，几乎是！）开始进行网络开发的障碍。在任何支持现代网络浏览器都可以运行，你甚至不需要在不同的机器上从头开始重新配置一切。
在任何地方工作和协作都很容易
这些工具具有高度可定制的工作空间，可以在团队 / 个人层面上进行优化，它们不仅促进了更好的合作，而且完全消除了 “在我的机器上可以运行 “ 这种太过普遍的情况。鉴于这些主要的优点，很明显基于云的 IDE 已经获得了发展势头。
于云的 IDE 的许多缺点都与扩展问题有关，因为这些工具仍然处于成熟的早期阶段。以下是早期采用者可能会遇到的一些关键问题。
性能可能是不平衡的
由于云上的资源是由需求不稳定的消费者共享的，因此肯定有机会出现性能不一致的情况，特别是在对网络延迟、容量或整体产品的故障造成问题的情况下，更是如此。
故障的来源可能很难识别和解决
当你不知道根本原因时，很难修复一个问题，总的来说，这可能会导致此类产品的早期采用者有一个令人沮丧的体验。
大项目可能更适合使用离线 IDE
到今天为止，已经观察到一些初期问题，用户抱怨平均负载过高。对于大型开发项目，所需的数据传输和处理量将是巨大的。虽然它可能不会扼杀基于云的 IDE 的资源，但由于其实用性，在这种情况下，离线替代方案肯定是更佳选择。
供应商锁定会限制工具的可用性
另一个需要考虑的方面是当涉及到基于云端 IDE 时，工具包的可用性。大量的工具可以在本地与 IDE 配对使用。但是，对于基于云端 IDE，开发者被限制在供应商提供的集成选择上，这对于那些需要更广泛工具包的人来说可能是限制性的。
云端 IDE 需要 WiFi
最后一点往往被忽略，基于云的 IDE 在与真正强大的桌面 IDE 相媲美之前还有很长的路要走，这些 IDE 允许降低对 WiFi 等外部因素的依赖性。即使正在实施各种变通办法，其可靠性水平也远远不能与桌面 IDE 提供的离线体验相比。
云资源
国内云原生社区： https://cloudnative.to/
国外云原生社区：cncf
