十一、容器化 vs 虚拟化-云原生

前言

云原生‌

云原生就是在云中构建、运行应用程序的一套完整的技术体系和方法论。 这里的技术体系和方法论就目前来说指的是微服务+容器化+DevOps+持续交付。

一、介绍

1. 概念

CNCF（Cloud Native Computing Foundation，云原生计算基金会）是云原生领域的权威组织，其对云原生提供了官方定义：

• 云原生技术使组织能够在新式动态环境（如公有云、私有云和混合云）中构建和运行可缩放的应用程序。
• 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

2. 优势

• 对于应用程序来说， 云原生可以赋予其更快速开发上线的能力。应用程序可以更实时、更稳定、更频繁地被部署，而无需完全重新部署。并且，还可以针对特定的服务进行扩缩容，以节省资源。
• 对于开发者来说，云原生提供的一些开箱即用的能力比如服务治理能力、DveOps，可以帮助我们更高效地进行开发。你不需要再花精力搭建复杂的持续交付环境，敏捷基础设施（如 K8S、Docke）开箱即用，自带一站式微服务开发解决方案。

3. 云原生技术体系

微服务

单体架构由于承载的业务庞大，服务内部逻辑变得复杂，扩展性非常差。这个时候，我们往往需要将单体架构拆分为，整体更松散，模块更内聚的微服务架构。

微服务架构的优势就是，服务解耦，高内聚，易变更。另外，结合DDD领域驱动设计，来进行微服务划分，则是大型应用的主流架构设计方式。

每个微服务都在运行在独立的线程下，它们之间通过轻量级通信机制（通常是 REST）进行通信。并且，各个微服务可以使用不同的技术栈，不同的存储技术。

各个微服务独立部署，对于单个微服务的修改，我们仅仅需要重新部署对应的微服务，而不需要重新部署整个系统。并且，系统中不同的微服务访问压力不同，我们可以对具体的微服务进行扩容缩容，这样更节省资源，节约成本。

微服务架构下，服务治理是不得不面临的一个难题。业界缺少一个多语言的、框架无关、支持异构基础设施的服务治理标准实现。

网关是整个微服务架构的流量入口，负责认证授权、请求分发、认证授权、限流、API 管 理、负载均衡等工作，是微服务架构中非常重要的一个组件。

ServiceMesh

Service Mesh(服务网格) 是 CNCF 推广的新一代微服务架构，是微服务时代的 TCP 协议，致力于解决微服务架构下的服务管理问题比如服务发现、负载均衡、服务监控，提供开箱即用的运维能力比如金丝雀发布、访问控制。

你可以将 Service Mesh 看作是为了简化开发工作专门抽象出来的一层，通常作为透明的一层接入到现有的分布式应用程序里。

服务网格的实现依赖于 Sidecar。这是一轻量级的网络代理，与应用程序部署在一起，但对应用程序来说是透明。所有应用程序间的流量都会通过 Sidecar，这样的话，它就可以对所有流入与流出的网络请求进行拦截处理，进而实现服务发现、负载均衡、服务监控、金丝雀发布等功能。

如下图所示，Sidecar 连接成网状结构，组成了 Service Mesh。

Istio 和 Linkerd 是目前比较流行的服务网格解决方案，都是开源软件。

容器化

没有容器之前，我们本地部署正常的应用程序到了生产环境很容易出现问题，经常修复各种部署错误就要花费数天的时间。有了容器化技术之后，就不存在这种问题了。容器通过操作系统虚拟化的方式，为应用程序提供了环境兼容性和平台无关性。

容器化技术是云原生发展的基石，应用最为广泛的容器引擎Docker提出一次构建，到处运行的口号。

容器平台和工具有很多，Docker 占据了最大长市场份额，已经成为打包、部署和运行云原生应用程序的事实上的标准。

容器化为微服务提供实施保障，起到应用隔离作用，K8s是容器编排系统，用于容器管理，扩缩容，容器间的负载均衡。

Kubernetes

对于一些大型的项目来说，一个应用程序的部署可能会涉及到成千上万台容器。这个时候，人工部署和管理容器就不太现实了。

于是，由 Google 主导孕育的 Kubernetes（简称 K8s） 就出现了，它就是帮助我们来做这些事情的，可以方便我们自动部署、扩缩和管理容器化的应用程序，减少重复劳动和出错的可能性。

K8s 被称为云原生时代的操作系统，云原生应用的优势与其提供的功能息息相关。

我们把一个有效的 Kubernetes 部署称为集群。你可以将 Kubernetes 集群视为两个部分：

• 控制平面：容器编排层，它暴露 API 和接口来定义、 部署容器和管理容器的生命周期。

• 节点：节点由控制平面管理。通常集群中会有若干个节点，每个节点都是其自己的 Linux 环境，并且可以是物理机或虚拟机。一个节点中通常运行有多个容器。

为了提升节点资源利用率，解决节点维护、资源规划等各种各样的运维问题，部分云厂商在 Kubernetes 的基础上提供了自己的解决方案来解决这些问题，就比如腾讯云新推出的TKE HouseKeeper 原生节点。

HouseKeeper 在产品能力上有这些特点：

• K8s 运维新范式：提供基础设施声明式 API，像管理 workload 一样管理节点，可通过 kubernetes api、云 API、控制台三种方式管理节点；

• 自研智能运维系统：支持操作系统/运行时/k8s 层面的故障检测和自动升级，多维度助力用户降低运维负担；

• 结合主流云厂商内部云原生技术实践，对操作系统、运行时、kubernetes 进行全方位参数调优和适配，节点初始化稳定性显著增强；

DevOps

DevOps 是一种软件交付的理念和方法。从名字可以看出，DevOps 是个组合词，Dev+Ops，将开发（Development）和运维（Operations）合体。不过，DevOps 所代表的理念和实践要比这广阔，还包括测试等。DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

DevOps 关注的是如何实现应用程序的全生命周期（开发，测试，运维）自动化管理，从而实现更快速、更高质量、更频繁、更稳定的软件交付。DevOps 团队通常会使用微服务架构来构建应用程序，借助于持续集成和持续部署（CI/CD）来实施 DevOps。

持续交付

持续交付（Continuous Delivery, CD）是 DevOps 实践中的核心理念之一，目标是让软件在任何时刻都处于可安全、快速、可靠地发布到生产环境的状态。它强调自动化、质量内建和快速反馈，是实现高效软件交付的关键能力。

定义（来自《持续交付》作者 Jez Humble & David Farley）：
持续交付是一种软件工程方法，通过在短周期内完成软件的构建、测试和发布，使软件可以随时可靠地部署到生产环境。

持续交付不是工具，而是一种能力。
它通过自动化 + 质量内建 + 快速反馈，让团队能够以低风险、高频率的方式向用户交付价值。

4. 十二要素应用程序

十二要素应用程序定义了构建一个优雅的互联网应用需要遵循的一些基本原则和方法论，也被用来指导开发者构建专为云环境优化的应用程序。

基于这些基本原则和方法论构建的系统，可以快速部署（适合云上部署）、快速扩展，可移植性和可维护性也增强不少。

十二要素应用程序内容如下图所示。

《超越十二要素应用》这本书补充了反映当今新式云应用程序设计的三个额外要素。

5. 总结

云原生就是在云中构建、运行应用程序的一套完整的技术体系和方法论。

对于开发者来说，云原生提供的一些开箱即用的能力可以帮助我们更高效地进行开发。你不需要再花精力搭建复杂的持续交付环境，敏捷基础设施（如 K8S、Docke）开箱即用，自带一站式微服务开发解决方案。在不久的将来，掌握云原生技术会成为发者必备的能力之一。

下面是云原生时代开发者必须掌握的一些能力：

• 微服务（更适合云原生的一种架构模式）

• ServiceMesh（服务网格，新一代微服务架构）

• 容器（一次构建，到处运行）

• Kubernetes（自动部署、扩缩和管理容器化的应用程序）

• DevOps（实现应用程序的全生命周期自动化管理）

• 十二要素应用程序（指导开发者构建专为云环境优化的应用程序）

二、实战

在现代云原生开发与交付流程中，Dockerfile → Kubernetes Deployment → CI/CD流水线 构成了从代码到生产部署的核心链路。

1. 整体流程概览（执行顺序）

1. 开发者编写应用代码 + Dockerfile ↓ 2. CI 流水线触发（如 Git Push） ├─ 构建镜像（docker build -t ...） ├─ 推送镜像到镜像仓库（docker push） ↓ 3. CD 流水线触发（或与 CI 合并） ├─ 渲染 K8s Deployment YAML（注入镜像标签等参数） ├─ kubectl apply -f deployment.yaml ↓ 4. Kubernetes 调度 Pod，拉取镜像并运行容器

✅ 关键点：参数（如镜像 tag、环境变量、资源限制等）从流水线 → Deployment → 容器逐层传递。

2. 各组件详解与参数传递机制

1.Dockerfile：定义容器镜像内容

• 作用：声明如何构建应用的运行环境。

• 参数传递方式：

  • ARG：构建时传入（仅在构建阶段可用）

    1ARG APP_VERSION=1.0 2ENV VERSION=$APP_VERSION

    构建命令：

    1docker build --build-argAPP_VERSION=v2.1 -t myapp:v2.1.

• • ENV：设置容器运行时环境变量（可被覆盖）

    1ENV DB_HOST=localhost

⚠️ARG不会保留在最终镜像中（除非赋值给ENV），而ENV会。

2.Kubernetes Deployment：定义应用部署策略

• 作用：声明 Pod 副本数、更新策略、容器配置等。
• 参数注入方式：

(1)镜像标签（最关键参数）

yaml

编辑

1spec: 2 template: 3 spec: 4 containers: 5 - name: app 6 image: registry.example.com/myapp:{{IMAGE_TAG}} # ← 需动态替换

实际 YAML 中不能直接写{{}}，需通过模板引擎（如 Helm、Kustomize）或脚本替换。

(2)环境变量（覆盖 Dockerfile 中的 ENV）

yaml

编辑

1env: 2 - name: DB_HOST 3 value: "prod-db.internal" 4 - name: LOG_LEVEL 5 valueFrom: 6 configMapKeyRef: 7 name: app-config 8 key: log_level

(3)启动参数 / 命令

yaml

编辑

1args: ["--port", "8080", "--debug"] 2# 或 3command: ["/app/start.sh"]

3.CI/CD 流水线（如 Jenkins、GitLab CI、GitHub Actions、Tekton）

• 作用：自动化构建、测试、部署。
• 参数定义与传递流程：

▶ 步骤 1：定义参数（Pipeline Parameters）

yaml

编辑

1# GitLab CI 示例 (.gitlab-ci.yml) 2variables: 3 IMAGE_TAG: $CI_COMMIT_SHORT_SHA # 自动从 Git 提取 4 APP_ENV: production

▶ 步骤 2：构建镜像（传递 ARG）

bash

编辑

1docker build --build-arg GIT_COMMIT=$CI_COMMIT_SHA -t my-registry/app:$IMAGE_TAG . 2docker push my-registry/app:$IMAGE_TAG

▶ 步骤 3：部署到 K8s（传递 IMAGE_TAG 到 Deployment）

方式 A：使用sed替换（简单场景）

1sed"s/{{IMAGE_TAG}}/$IMAGE_TAG/g"deployment.yaml|kubectl apply -f -

方式 B：使用Helm（推荐）

1helm upgrade --install myapp ./chart\2--set image.tag=$IMAGE_TAG\3--setenv=$APP_ENV\4--namespace prod

Helm values.yaml 中定义默认值，--set覆盖。

方式 C：使用Kustomize

1# kustomization.yaml2images:3- name: myapp4newTag:$IMAGE_TAG56# 流水线中7kustomize editsetimagemyapp=my-registry/app:$IMAGE_TAG8kubectl apply -k.

3. 参数传递全景图

4. 最佳实践

1. 镜像标签使用 Git Commit SHA

• 保证可追溯性（如myapp:abc1234）
• 避免使用latest

2. 敏感参数不硬编码

• 使用 K8sSecrets/ConfigMaps
• 流水线中通过 Vault 或外部密钥管理注入

3. Deployment 模板化

• 优先使用Helm或Kustomize，避免手写 YAML

4. 参数分层管理

• 全局参数（如 registry 地址）→ 流水线变量
• 环境特有参数（如 DB 地址）→ Helm values-per-env 或 Kustomize overlays

5. 验证部署结果

• 流水线最后加入健康检查（如kubectl rollout status）

5. 示例：完整 GitLab CI 流水线片段

stages:-build-deploybuild-image:stage:buildscript:-docker build--build-arg COMMIT_SHA=$CI_COMMIT_SHA-t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .-docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHAdeploy-prod:stage:deployscript:-helm upgrade--install myapp ./helm-chart \--set image.repository=$CI_REGISTRY_IMAGE \--set image.tag=$CI_COMMIT_SHORT_SHA \--set environment=production \--namespace prodonly:-main

如有具体工具链（如 Jenkins + Helm、Argo CD、Tekton 等）或语言框架（如 Spring Boot、Node.js）需求，则需要进一步细化参数传递方案。

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识
一文讲明白什么是云原生，有什么优势
云原生技术详解