当前位置：首页 > news >正文

k8s系列（一）——什么是云原生

news 来源：原创 2024/4/20 8:04:46

缘由

在写此系列文章之前，我做了3年的Java开发，后来因为项目的变动，接触了大约半年的k8s相关东西，零零散散，似懂非懂的，而且在日常开发中，经常会卡壳，问人总会被怼，所以自己索性来系统的学学大名鼎鼎的k8s，为日后自己的职业规划做一些打算。

本篇作为k8s系列文章的开篇，主要介绍了什么是云原生、k8s的引入以及云原生未来如何。

另外：

由于【kubbernetes中文指南】书中对这块的介绍太好了，大部分内容是原封不动的搬运过来的，各位如果有兴趣的可以看看此书，强烈推荐！！！

我在这里贴出电子版的地址，大家可放心食用。
Kubernetes 中文指南——云原生应用架构实战手册

什么是云原生

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。

另外，云原生也很好地解释了云上运行的应用应该具备什么样的架构特性 —— 敏捷性、可扩展性、故障可恢复性。

在【kubbernetes中文指南】一书中提到：

云原生是一种行为方式和设计理念，究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。

Kubernetes 开启了云原生的序幕，服务网格 Istio 的出现，引领了后 Kubernetes 时代的微服务，Serverless 的兴起，使得云原生从基础设施层不断向应用架构层挺进。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施 和 声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

可能看起来有点晦涩难懂，我在这里说一下自己的理解：

所谓的原生，指的利用Java，php，c，c++，python等等开发语言开发出来的应用，应用需要部署到服务器上；而云指的是云服务器，那么云原生结合起来就是原生应用上云的过程，以及上云的一系列解决方案。

云原生不局限于 Kubernetes，还包括以下几大主题：

云原生开源组件
云原生应用与微服务架构
基于 Kubernetes 的服务网格（Service Mesh）架构

其设计理念如下：

面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
面向配置设计（Configuration）：一个镜像，多个环境配置；
面向韧性设计（Resistancy）：故障容忍和自愈；
面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
面向交付设计（Delivery）：自动拉起，缩短交付时间；
面向性能设计（Performance）：响应式，并发和资源高效利用；
面向自动化设计（Automation）：自动化的 DevOps；
面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

综上所述，云原生应用应该具备以下几个关键词：

敏捷
可靠
高弹性
易扩展
故障隔离保护
不中断业务持续更新

以上特性也是云原生区别于传统云应用的优势特点。

从宏观概念上讲，云原生是不同思想的集合，集目前各种热门技术之大成。

Kubernetes 与云原生的关系

Kuberentes 可以说是乘着 Docker 和微服务的东风，一经推出便迅速蹿红，它的很多设计思想都契合了微服务和云原生应用的设计法则，这其中最著名的就是开发了 Heroku PaaS 平台的工程师们总结的 Twelve-factor App 了。

下面讲解 Kubernetes 设计时是如何按照了十二因素应用法则，并给出 Kubernetes 中的应用示例，并附上一句话简短的介绍。

Kubernetes 介绍

Kubernetes 是 Google 基于 Borg 开源的容器编排调度引擎，作为 CNCF（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes 可以帮你将系统自动得达到和维持在这个状态。

更直白的说，Kubernetes 用户可以通过编写一个 YAML 或者 json 格式的配置文件，也可以通过工具 / 代码生成或直接请求 Kubernetes API 创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个 Kubernetes 集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求 Kubernetes API 来改变应用程序的状态。

因素应用

12 因素应用提出已经有几年的时间了，每个人对其可能都有自己的理解，切不可生搬硬套，也不一定所有云原生应用都必须符合这 12 条法则，其中有几条法则可能还有点争议，有人对其的解释和看法不同。

大家不要孤立的来看这每一个因素，将其与自己软件开发流程联系起来，这 12 个因素大致就是按照软件从开发到交付的流程顺序来写的。

1. 基准代码

每个代码仓库（repo）都生成 docker image 保存到镜像仓库中，并使用唯一的 ID 管理，在 Jenkins 中使用编译时的 ID。

2. 依赖

显式的声明代码中的依赖，使用软件包管理工具声明，比如 Go 中的 Glide。

3. 配置

将配置与代码分离，应用部署到 Kubernetes 中可以使用容器的环境变量或 ConfigMap 挂载到容器中。

4. 后端服务

把后端服务当作附加资源，实质上是计算存储分离和降低服务耦合，分解单体应用。

5. 构建、发布、运行

严格分离构建和运行，每次修改代码生成新的镜像，重新发布，不能直接修改运行时的代码和配置。

6. 进程

应用程序进程应该是无状态的，这意味着再次重启后还可以计算出原先的状态。

7. 端口绑定

在 Kubernetes 中每个 Pod 都有独立的 IP，每个运行在 Pod 中的应用不必关心端口是否重复，只需在 service 中指定端口，集群内的 service 通过配置互相发现。

8. 并发

每个容器都是一个进程，通过增加容器的副本数实现并发。

9. 易处理

快速启动和优雅终止可最大化健壮性，Kuberentes 优秀的 Pod 生存周期控制。

10. 开发环境与线上环境等价

在 Kubernetes 中可以创建多个 namespace，使用相同的镜像可以很方便的复制一套环境出来，镜像的使用可以很方便的部署一个后端服务。

11. 日志

把日志当作事件流，使用 stdout 输出并收集汇聚起来，例如到 ES 中统一查看。

12. 管理进程

后台管理任务当作一次性进程运行，kubectl exec 进入容器内部操作。

另外，Cloud Native Go 这本书的作者，CapitalOne 公司的 Kevin Hoffman 在 TalkingData T11 峰会上的 High Level Cloud Native 的演讲中讲述了云原生应用的 15 个因素，在原先的 12 因素应用的基础上又增加了如下三个因素：

API 优先