DEVOPS: 容器与虚拟化与云原生

概述

• 传统虚拟机，利用 hypervisor，模拟出独立的硬件和系统，在此之上创建应用
• 虚拟机是一个主机模拟出多个主机
• 虚拟机需要先拥有独立的系统
• docker 是把应用及配套环境独立打包成一个单位
• docker 是在主机系统中建立多个应用及配套环境
• docker 是进程级的隔离
• 如下图所示：

Devops

• DevOps 是一个必然趋势，是一种方法，也是一种观念
• 原始的互联网公司工作模式是瀑布流，但用户越多，需求越大，公司的管理，人力成本都是问题
• 而如果更新间隔太慢，一定会导致用户的满意程度下滑，DevOps 的观念应运而生
• DevOps 实际上是两个单词：Development 和 Operations
• 开发人员：根据需求情况，把需求拆分成多个小需求，小步快跑大幅增加需求完成的频率
• 运维人员：运用自动化和 CI/CD 的概念，运用工具，实现稳定、快速的版本更新上线
• 打破开发人员和运维人员的壁垒
• 对运维人员的技术要求和经验大大提升。
  • 开发人员根据需求情况，把需求拆分成多个小需求，小步快跑大幅增加完成需求频率
  • 运维人员是运用自动化 CI/CD 的概念，运用工具，实现稳定，快速的版本更新上线
  • 运维和开发往底层说，实际就是岗位要的东西不一样
  • 运维要的是保持业务的稳定持续运行，开发是为了快速开发，开发完就快速上线
  • 一个要稳定，一个要赶紧上线，开发上线的越多，更新的就越多，运维就更不稳定
• 可能产生的问题
  • 问题 1：资源利用率
    • 服务器的治理，环境的迁移容灾上会产生问题，一个虚拟机要管多个配置的话
    • 治理起来一定是难度更大的，端口容易冲突，一个虚拟机跑多个项目
    • 治理、迁移、容灾？
  • 问题 2：扩容不及时
    • 脚本化启动 50 台虚拟机要多久？
    • 脚本化启动 50 台容器要多久？
    • 环境部署要多久？
    • 风险大不大？

容器

1 ) 容器是什么

• 一艘船的载重比如是 10000 吨，卡车本身体积很大
• 所有卡车上船加上货物也就 2000 吨，大部分载重都浪费了
• 但船不能少，油费人工等成本也不能少
• 这怎么办？是不是可以造小一点的船，载重也不用那么大，多造几艘，这样是不是解决了？
• 后来仔细一想，卡车完全没必要上船，只要货物上去就可以了！到了码头再卸下来
• 有人专门做过实验：如果运啤酒，用原始的卡车方法全程陆运，每吨成本是 27 美金
• 且非常慢, 如果用卡车运送到码头——卸载到船上——船到另一个码头——再装再到终端卸载
• 成本是 25美分！节省了 99%左右的运输成本。且因为船的负载和卡车负载根本没法比
• 效率还大大提高了，之后 Container（集装箱，容器）改变了整个世界物流行业的面貌
• 极大地推动了物流生产力的发展。到现在，集装箱都是外贸、零售、电商等交易的必不可少的环节
• 我个人不太喜欢把 container 翻译成容器，我更想把他叫做“集装箱”
• 现在是谁把“容器”命名成为 container 我暂时没办法考证，但我真心佩服这位命名者
• 它起这个名字，首先是非常形象，甚至解决的问题和解决的方案都能看到集装箱的影子
• 更重要的是，我能感受到他想要改变 IT 生态的一个理想和决心，而且他做到了！如他的命名
• 容器是什么？简单说，他就是一个集装箱，这个集装箱可以在各个系统之间来回搬运
• 集装箱里面，放着的是一个或多个应用，以及运行环境
• 作用简而言之，就是把环境和应用封装成一个标准的单元，用于开发、部署、交付等环节
• 他解决了几个重要的问题：
  • 一个应用，因为环境不同，可能会出现各种各样本可以避免的问题
  • 一个系统中，多个应用之间可能引发的各种冲突故障
  • 相比传统虚拟化，不吃资源、节省成本

2 ）注意

• 镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样
• 镜像是静态的定义，容器是镜像运行时的实体
• 容器可以被创建、启动、停止、删除、暂停等
• 容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 命名 空间
• 前面讲过镜像使用的是分层存储，容器也是如此
• 容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡
• 因此，任何保存于容器存储层的信息都会随容器删除而丢失

容器和虚拟化比较

1 ）特性

• 再次提高服务器资源利用率
• 重量更轻，体积更小
• 匹配微服务的需求
• 保持多环境运行的一致性
• 快速部署迁移，容错高
• 安全性较差
• 多容器管理存在难度。
• 稳定性较差
• 排错难度较大

2 ）与虚拟机的比较

3 ) 优缺点

• 容器的优点
  • 再次提高服务器资源利用率
  • 重量更轻，体积更小
  • 匹配微服务的需求
  • 保持多环境运行的一致性
  • 快速部署迁移，容错高
• 虚拟机的缺点
  • 安全性较差
  • 多容器管理存在难度
  • 稳定性较差
  • 排错难度较大

4 ) 容器与镜像

• 镜像可以看做是一个压缩包，里面包含所需要的应用和应用要的配置文件及底层的库、参数、环境变量等
• 容器是运行这个压缩包，实现具体功能的存在

docker 与容器

1 ）docker

• docker13 年初开源，公司本来叫 dotcloud，后改名叫 docker
• 被 Mitantis 收购。基于Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术
• 对进程进行封装隔离，属于操作系统层面的虚拟化技术
• 由于隔离的进程独立于宿主和其他的隔离的进程，因此也称其为容器
• docker 镜像是简化的 linux
  • 镜像里面只包含两种东西，它的依赖环境和它实际要做的一个应用
  • 镜像是把它两个融合在一起的
  • 就是应用和它底层的一些依赖环境变量，或者一些参数也好等等
  • 它把它们融合到一起了

2 ) 区别

• docker 就是容器，容器就是 docker，并不是这样的，容器就是一个技术类型
• 而 docker 是当下最主流的，容器的一种实现容器的方案
• docker 只是容器其中一种实现方案，其他方案包括：LXC，Mesos，RKT 等等
• 最大区别当容器和服务器的数量达到一定规模的时候，就会碰到管理的问题
• 即如何有效管理大量的服务器和容器，保证应用的稳定运行、方便升级和故障的快速解决
• 容器编排工具提供图形化界面或者命令行来管理容器和服务器集群
• 提供容器配置、任务发布、服务发现、负载均衡、系统监控和故障恢复、声明式系统配置
• 以及有关容器部署和性能的规则和约束定义机制等

3 ）进程级封装

• docker 或者容器和传统虚拟化最大的一点区别
• 就是虚拟化的封装是系统级的封装，docker或者其他容器是进程级的封装
• 和传统虚拟化最大的一点区别，就是虚拟化是系统级的封装，进程级封装
• 用户量越来越大，功能越来越多。代码越来越重。耦合越来越高
• 一旦某个哪怕小的逻辑出错，甚至会影响整个站点
• bug 频率大增，bug 频率增加耦合越来越高，简直对于互联网公司来说就是灾难
• 代码重复率高，维护难度大
• 代码越来越吃性能，服务器成本大增

4 ）docker 底层技术

4.1 Namespaces

作用：访问隔离

• Docker 主要就是借助 Linux 内核技术 Namespace 来做到隔离的，Linux Namespaces 机制提供一种资源隔离方案
• PID,IPC,Network 等系统资源不再是全局性的，而是属于某个特定的 Namespace
• 每个 namespace 下的资源对于其他 namespace 下的资源都是透明，不可见的
• 因此在操作系统层面上看，就会出现多个相同 pid 的进程
• 系统中可以同时存在两个进程号为 0, 1,2 的进程，由于属于不同的 namespace，所以它们之间并不冲突
• 而在用户层面上只能看到属于用户自己 namespace 下的资源
• 例如使用 ps 命令只能列出自己 namespace 下的进程
• 这样每个 namespace 看上去就像一个单独的 Linux 系统

4.2 Control groups

作用：做资源控制，CPU\MEM\宽带等

• 提供的一种可以限制、记录、隔离进程组所使用的物理资源(如 cpu、memory、磁盘 IO 等等)
  的机制，被 LXC、docker 等很多项目用于实现进程资源控制
• cgroup 将任意进程进行分组化管理的 Linux 内核功能
• cgroup 本身是提供将进程进行分组化管理的功能和接口的基础结构
• I/O 或内存的分配控制等具体的资源管理功能是通过这个功能来实现的

4.3 Rootfs

作用：文件系统隔离

k8s－容器编排管理工具

1 ) K8s 功能

• 微服务需要跑多个容器，容器多又会涉及到通信、架构、伸缩、更新、监控等等问题
• 自愈：重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器
• 弹性伸缩：通过监控容器的 cpu 的负载值，如果这个平均高于 80%，增加容器的数量，如果这
  个平均低于 10%，减少容器的数量
• 服务的自动发现和负载均衡：不需要修改应用程序来使用不熟悉的服务发现机制

2 ）K8s 作用

• Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡
• 滚动升级和一键回滚
  • Kubernetes 逐渐部署对应用程序或其配置的更改
  • 同时监视应用程序运行状况，以确保它不会同时终止所有实例
• 如果出现问题，Kubernetes 会恢复更改，利用日益增长的部署解决方案的生态系统
• 要使用 Kubernetes，你需要用 Kubernetes API 对象 来描述集群的 预期状态（desired state）
• 包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等
• 你可以使用命令行工具 kubectl 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态
• 你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态
• 一旦你设置了你所需的目标状态，Kubernetes 控制面（control plane）
  • 会通过 Pod 生命周期事件生成器（ PLEG )，促成集群的当前状态符合其预期状态
  • 为此，Kubernet es 会自动执行各类任务
  • 比如运行或者重启容器、调整给定应用的副本数等等
• Kubernetes 控制面由一组运行在集群上的进程组成

云原生

• 云原生是一个生态概念、是一线互联网公司发展到某个极端的必然选择
• 包含三大要素：容器及编排管理、DevOps、微服务

1 ）技术模块

• 应用定义及部署（App Definition and Development)
• 编排与管理（Orchestration & Management)
• 运行环境（Runtime)
• 配置（Provisioning)
• 平台（Platform)
• 可观测性和分析（Observability and Analysis)
• 无服务（Serverless)

2 ）云原生时代

• 技术升级，概念先行。云原生、容器、devops 等一定是未来若干年的发展方向
• 为什么说容器划时代？
  • 一方面容器解决了大型架构的发展瓶颈
  • 另一方面，从运维岗位讲，传统运维已经跟不上脚步了
  • 会新技术的运维一定会取代传统运维，更别说其他运维岗位
• docker 是云原生时代的基石也是应用基础
• 而这个基础也需要有一定的经验积累才能学通
• 所以，对运维的要求越来越高

云原生的技术栈

• 云原生的技术栈实际上三个方面，devops，微服务，还有一块是容器 K8s，从系统层次来看，从上到下分别是：
  • 应用层：应用定义及部署（App Definition and Development)、配置（Provisioning)、可
    观测性和分析（Observability and Analysis)、无服务（Serverless)
  • 集群：编排与管理（Orchestration & Management)
  • 底层运行环境：运行环境（Runtime)