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 ）与虚拟机的比较

	容器	虚拟机
启动速度	秒级	分钟级
性能	接近原生	较弱
内存代价	很少	较多
硬盘使用	一般为 MB 虚拟机	一般为 GB
运行密度	单机支持千个容器	一般几十个
隔离性	安全隔离	完全隔离
迁移性	优秀	一般

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)