纯小白也能看懂，十分钟帮你了解云原生技术

一、麻烦的一天
二、魔法的种子
- [1. Docker](#1. Docker)
- [2. Kubernetes](#2. Kubernetes)
三、渐入佳境
- [1. 技术与术语](#1. 技术与术语)
- [2. 组件与框架](#2. 组件与框架)
- - Docker
  - Kubernetes
  - Helm
  - Istio
  - Prometheus
  - Jaeger
  - Envoy
四、前路漫漫

随着云原生相关技术的蓬勃发展，不管你是刚入职的小白，还是多年经验的老手，都在关注这种技术趋势。但相关内容太多，导致一些小白无从入手，也没有一个全局的概念。那就花10分钟看完本文，帮你快速了解云原生的起源和发展，并介绍一些技术现状

📕作者简介：战斧，从事金融IT行业，有着多年一线开发、架构经验；爱好广泛，乐于分享，致力于创作更多高质量内容

📗本文收录于云原生，有需要者，可直接订阅专栏实时获取更新

📘高质量专栏 RabbitMQ、Spring全家桶等仍在更新，欢迎指导

📙Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待

一、麻烦的一天

小明是一个小企业的程序猿，他觉得他的工作麻烦又枯燥。每天，他需要处理一大堆服务器和应用程序，手动部署和维护它们。这让他感觉像是在重复地做着无尽的琐碎工作。

每当有新的应用需要部署，或者把同一个应用部署在不同的服务器上时，小明都得花费大量时间来配置服务器、安装依赖和解决各种兼容性问题。今天这台机器mysql端口与众不同要重新配置，明天那台机器环境依赖发生冲突要解决冲突，有时候，一个小小的错误就可能导致整个应用无法正常运行，让他陷入绝望。

而且，每当服务器出现故障时，他必须赶紧跑去现场解决问题，有时候甚至要在深夜起床处理紧急事务。这让他感到心力交瘁，无法得到休息。

另外，应用程序的扩展也是一个头疼的问题。每当用户量激增时，他得手动调整服务器资源，希望能满足需求。但有时候，应用程序还是会因为资源不足而崩溃，让他倍感无奈。

二、魔法的种子

1. Docker

假设你是一位热爱烹饪的厨师，有一天你决定去朋友家里做一道特别的美食。然而，你们两个的厨房设备和材料不完全相同，你的厨房里有一些特殊的调味料和器具，而你朋友的厨房里则有一些其他的特色食材。

在传统情况下，为了做这道美食，你需要将所有的调味料和器具都带到朋友家，而且可能还需要重新学习适应朋友的厨房设备。这样做不仅麻烦，还浪费时间和精力。

但是，你可以将所有的调味料、食材和器具都装进一个精美的密封箱子中，在箱子里，你的食材和调味料都是独立的、封闭的，不会与其他东西混合，也不会受到外界的干扰。你可以轻松地将这个箱子带到朋友家，只需要在朋友的厨房里打开箱子，就可以开始烹饪了。

这样一来，你不需要在朋友家里携带大量的物品，也不需要适应不同的环境。你可以专注于烹饪美食，保持高效和一致的操作，而不用担心与朋友的厨房设备产生冲突。

而对于程序猿，不仅仅是小明，实际上小张、小李等无数程序猿也饱受煎熬。大家一致认为，程序猿的天职是写代码实现业务，现在却被繁琐的部署配置，故障解决搞得焦头烂额，真是天理不容。

于是Docker公司于2013年推出了Docker容器，该技术通过将应用程序及其所有依赖项（例如库、配置文件等）打包在一个独立的运行环境中，形成一个封闭的容器。容器可以在任何支持容器引擎的环境中运行，而不受环境差异的影响，保证了应用程序在不同环境中运行的一致性。

2. Kubernetes

自从有了箱子之后，你感觉轻松了很多，各种不同的环境你都能烹饪出同样的美食。终于成为了酒店大厨，你现在甚至可以弄出一个箱子，然后参照着复制出10个箱子，这样你就可以同时炒10份了。但你很快又发现了问题，尽管开始时10份菜是一样的食材，但在炒菜的过程中，10份菜火候却没法保证完全一致，有的还是生的，有的却还没熟，而且此时如果又来了一批客人，需要你同时炒更多份菜，你还得抽身去复制箱子然后起锅烧油。这让你分身乏术，手忙脚乱。

最后，你选择请了个专业的厨师助手，它会自动根据你的需求，调整每个容器的火力和烹饪时间。当一道菜煮熟了，它会自动关掉相应的火力，而不会让食物过熟。当有更多的客人来访时，助手会自动为帮你复制箱子，并且起锅开始炒。

你不再需要手动管理每个锅，也不用担心忘记照顾其中的一道菜。你可以轻松地同时烹饪多道菜，而且每一道菜都能在适当的时候煮熟，保持美味和口感。你的得力厨师助手，让你的烹饪过程更加高效和愉快

在Docker推出仅仅一年以后，Google的工程师Brendan Burns、Joe Beda和Craig McLuckie 在2014年提出Kubernetes（K8s）这样一个开源容器集群管理系统，其作用是帮助用户管理包括容器的创建、配置和自动化部署等一系列工作，还能够提供高可用性、负载均衡、自动扩容和自动恢复。

需要注意的是，Google早在2000年就开始运行自己的容器技术，Kubernetes的出现是为了推广容器技术。Kubernetes本身不依赖于Docker，除了Docker外，Kubernetes还支持其他容器运行时，如rkt、CRI-O和Frakti，Kubernetes的容器运行时接口（CRI）定义了容器运行时与Kubernetes API的交互方式，因此如果有符合CRI规范的容器运行时，就可以在Kubernetes上使用它们来运行容器

这里我们可以说句题外话，K8s目前已经成了事实上的行业标准，而且其可以踢开Docker选用其他容器，尽管由于Docker曾经的垄断地位和巨大名气，现在很多人依旧选择Docker，但其在市场上的占有率却有所下降

三、渐入佳境

1. 技术与术语

随着K8s的推广，一种软件开发和运维的理念，逐渐发展和完善起来。这就是我们所说的云原生：云原生是一种基于云计算的应用程序开发和部署方法，它依托于云计算与云架构；会使用容器化、微服务架构和自动化管理技术来实现高效、弹性、可伸缩和可靠的云部署。当然，这云计算伴随着不少技术和术语，让我为你进行一些常用技术的解释：

容器化技术

容器化技术是将应用程序及其依赖的组件、库等打包到一个可移植的容器中 ，并提供统一的运行环境，从而实现跨平台和快速部署的技术。目前常用的容器化技术有 Docker、LXC等。

Pod

Pod是Kubernetes中最基本的调度单位。可以类比成进程，一个进程中可以只有一个线程，也能有多个共用资源的线程。一个Pod则代表着集群中运行的一个进程，一个Pod中可以装一个容器(建议)，也可以同时封装几个紧密耦合互相协作的容器，它们之间共享资源，相互协作成为一个service单位。

DevOps

包含 development 和 operations ，即开发和运维两个单词的组合。是一种将开发和运维融合起来 的方法论和实践（最初是这样，但现在这个词的语义越来越大，从需求-设计-开发-测试-上线-运维整条线路，能缩短周期，提高稳定的方法都可以算在里面），目的是提高软件开发和部署的速度、质量和可靠性，其一般手段有：

持续集成和持续交付
这其实也是个老概念，持续集成和持续交付（CI/CD ），代表着一种软件开发流程。在以往，开发人员写完代码需要手动打包编译，然后交给测试团队，测试团队拿到包要先部署，然后开始测试。发现问题后又需要改代码打包编译，如此反复。其实很多内容可以不用人工操作，现在我们可以自动化构建、测试、部署和交付应用程序，只需做好设定，如定时触发，其就会源源不断的执行扫描检测-编译-打包-部署乃至自动化测试等操作，如果出现故障，会及时进行邮件通知 。
自动化运维
利用软件技术实现运维工作自动化和标准化。它将重复性、繁琐的运维工作通过自动化程序进行处理，以提高工作效率和服务质量。比如自动化部署、自动化监控、自动化备份等

弹性伸缩

弹性伸缩是指根据应用负载和资源消耗情况，自动调整云原生应用的资源配额和容器数量等资源分配策略，以满足应用的性能需求和业务变化，比如我们可以设置当CPU使用率超过90%时，自动增加一个Pod实例。当CPU使用率低于50%时，自动减少一个Pod实例。

Sidecar

Sidecar的字面意思为边车，就像下图这样，摩托车附带个车斗。

在云原生领域，Sidecar是指一种类似的模式，用于将一些辅助服务（例如日志收集、监控和调试）部署在与主要应用程序部署同一容器，或Pod中的辅助容器中，这种设计还是符合Sidecar的形象的。通常，Sidecar容器与主应用程序容器共享相同的网络和存储卷，它们可以通过共享文件系统来进行通信和协作。这种模式可以使应用程序容器保持单一职责（Single Responsibility Principle），便于管理和维护

服务网格

服务网格（Service Mesh）是指将网络功能划分为一些小的、独立的组件，以点对点通信和 API 网关等方式实现服务间通信和控制的技术方案。比如有一个电商系统，其中包含了商品服务、订单服务和支付服务三个微服务，这三个服务需要相互通信，以往每个微服务都需要通过自己的代码来实现服务发现、负载均衡、故障处理等功能。现在这些与业务无关的内容都下沉到基础设施层了。