云原生必须容器化吗云原生和容器

转载

落花有意飞花 2023-09-07 19:31:05

文章标签 云原生必须容器化吗云原生容器 docker Docker 文章分类 云原生云计算

云原生

什么是云原生
云原生的代表技术

容器

Docker

主要应用方向：
Docker的优点：
核心概念 [^1]

Kubernetes

一些概念

服务网格

什么是云原生

点题，云原生–>最重要的自然是“云”。

云原生不是一种技术，而是一种以云为基础来进行的一系列开发、部署、交付的流程；凡是能够提高云资源的利用率和交付效率（容错性好、易于管理、松耦合）的方式都可以称之为云原生。

代表技术有：容器化、服务网格、微服务、不可变基础设施和声明式API。

云原生必须容器化吗云原生和容器_云原生必须容器化吗

云原生的代表技术

容器

容器包含了一个应用运行所需的环境，具有一致性、轻量级、可移植、语言无关等特性，实现 “一次发布，随处运行”（开发、测试、生产），使应用的构建、分发和交付完全标准化。是不可变基础设施的核心基础。

目前容器化部署应用比较广泛的就是Docker，Docker 是一个用于开发，交付和运行应用程序的开放平台，可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。

Docker

主要应用方向：

web应用的自动化打包和发布
自动化测试的持续集成、发布
在服务型环境中调整数据库或其他的后台应用
从头编译或扩展现有的OpenShift/Cloud Foundry平台来搭建自己的PaaS环境

Docker的优点：

快速交付，测试和部署代码。容器化部署非常适合持续集成和持续交付(CI/CD)工作流程：
2.1. 使用 Docker 将其应用程序推送到测试环境中，并执行自动或手动测试。
2.2. 当开发人员发现错误时，他们可以在开发环境中对其进行修复，然后将其重新部署到测试环境中，以进行测试和验证。
2.3. 测试完成后，将修补程序推送给生产环境，就像将更新的镜像推送到生产环境一样简单。
响应式部署和扩展：一次打包，到处运行
在同一硬件上运行更多的容器：对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行 10 个不同的应用就要起 10 个虚拟机，而Docker 只需要启动 10 个隔离的应用即可。
高效的部署和扩容：Docker 容器几乎可以在任意的平台上运行，包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。这种兼容性可以让用户把一个应用程序从一个平台直接迁移到另外一个。Docker的兼容性和轻量特性可以很轻松的实现负载的动态管理。你可以快速扩容或方便的下线的你的应用和服务，这种速度趋近实时。

核心概念 ¹

镜像（Image）
是容器所需要的所有文件的集合，具备一次构建，到处运行的特点。
一个镜像包含了一个完整的操作系统环境，里面仅安装了用户需要的应用程序。一个镜像可以用来创建很多个Docker容器。
仓库（Repository）
用于集中存放镜像，分为共有仓库和私有仓库(类似git hub)。
当用户创建了自己的镜像之后可以使用push命令上传到仓库中，下次在其他机器使用该镜像时只需要pull下来。
容器（Container）
容器是一个进程集合，各个容器之间是相互隔离的。
Docker 利用容器来运行应用。容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看做是一个简易版的 Linux 环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。
容器的定义和镜像几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。
一个运行态容器被定义为一个可读写的统一文件系统加上隔离的进程空间和包含其中的进程。下面这张图片展示了一个运行中的容器。
正是文件系统隔离技术使得Docker成为了一个非常有潜力的虚拟化技术。一个容器中的进程可能会对文件进行修改、删除、创建，这些改变都将作用于可读写层。

那么，当我们有很多容器的时候，如何很好的管理它们呢？这就需要k8s了。

Kubernetes

Docker是一个应用容器引擎，k8s就是一个容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

一些概念

namespace：通过namespace可以将k8s划分为不同的域，各个域之间是相互独立的，管理员还可以对每个namespace设置权限和quota(namespace的容量)。
deployment²：一个namespace中可以包含若干个deployments(具体数量由每个namespace的quota决定)。deplolyment用于管理工作负载资源，可以通过更改deployment对应的yaml中的spec来对其下属的pod、replica进行管理，eg:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
# 创建3个pod 副本
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers: 
       #指定容器的名称
      - name: nginx
      # 所选取的镜像
        image: nginx:1.14.2
        ports:
        - containerPort: 80

pod³： pod是可以在k8s中创建和管理的最小可部署计算单元。Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面，即用来隔离 Docker 容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。Deployment 控制器针对每个 Deployment 对象确保运行中的 Pod 与当前的 Pod 模板匹配。如果模板被更新，则 Deployment 必须删除现有的 Pod，基于更新后的模板创建新的 Pod。每个工作负载资源都实现了自己的规则，用来处理对 Pod 模板的更新。修改 Pod 模板或者切换到新的 Pod 模板都不会对已经存在的 Pod 起作用。 Pod 不会直接收到模板的更新。相反，新的 Pod 会被创建出来，与更改后的 Pod 模板匹配。
replica⁴：是pod的副本集。虽然 Pod 是一个物理性的运行任务，但通常使用单个实例是不够的。为了冗余并处理负载，出于某种原因（比如“伸缩”）需要对 Pod 进行复制。为了实现负责扩展和复制的层，Kubernetes 使用了 ReplicaSet。这个层以副本的数量表示系统的期望状态，并在任意给定时刻保持该系统的当前状态。
这也是配置自动伸缩的所在，在系统高负载时创建额外的副本，并在不再需要这些资源来支撑所运行的工作负载时进行缩容。

服务网格

Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。
可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
特性/功能⁵