KVM虚拟化与Docker基础实践-第二章

一、KVM操作

KVM存储管理

执行以下操作进行查看默认存储池、创建自定义本地存储池、存储池的启动、停止等操作

virsh pool-list --all

virsh pool-start default

virsh pool-autostart default

mkdir -p /kvmdata

virsh pool-define-as mypool dir - - - - "/kvmdata"

virsh pool-start mypool

virsh pool-autostart mypool

virsh pool-list --all

virsh pool-info mypool

virsh pool-destroy mypool

virsh pool-start mypool

上图最后一行命令是对KVM-Test1虚拟机扩展磁盘。

qemu-img resize /var/lib/libvirt/images/KVM-Test1.qcow2 +5G

扩展成功后我们登录网址，打开KVM-Test1虚拟机，使用root用户进行登录，继续对该虚拟机进行分区，格式化操作，具体命令和截图如下：

tee /sys/block/vda/device/rescan

lsblk

fdisk -l /dev/vda

出现Command (m for help) 后，依次输入n，p，默认3（这里不用输，只是确认）然后回车就行，知道再次出现又输入w回车

完成以后继续执行

mkfs.ext4 /dev/vda3

mkdir /data

mount /dev/vda3 /data

echo '/dev/vda3 /data ext4 defaults 0 0' >> /etc/fstab

KVM快照与克隆

完成存储管理后，按照图片所示进行KVM的快照和克隆

如果你的磁盘空间不足可能会导致图形化操作方式的克隆虚拟机不成功，转到命令行界面执行命令行操作使用越过扫描的方式进行克隆，成功后我们打开克隆好的KVM-Clone1及逆行网络配置修改，我这么打开后发现他自动获取了一个与主机不冲突的地址我就没有修改了，如果你们ip a查看地址发现冲突就自行修改。然后我们执行连通性测试ping -c 2 192.168.11.145，ping -c 2 8.8.8.8

这里我们观察到都能成功ping通，可能有的人会很奇怪，KVM-Test1不是采用的桥连接嘛，不是拒绝外部访问嘛，这里我们是克隆出来的机器，二者是在一个网段内的，所以应该是要ping通才对的，不通就得检查网关和ip了。

KVM资源优化

完成后我们关闭克隆机，接下来对KVM-Test2进行操作，主要是对它进行内存的调整，配置内存气球技术，比较简单，可以选择使用图形化界面直接在设置中修改，我这里演示命令行操作，因为我们本次实验主要是对KVM-Test1进行图形化，KVM-Test2进行命令行操作，以对比二者区别。

首先我们输入virsh edit KVM-Test2进入文本编辑

然后就在文本中的前面几行，找到以下内容并修改为如图所示

这样主要修改CPU配置。完成后保存退出，继续执行virsh start KVM-Test2启动它，virsh dominfo KVM-Test2查看修改后的内容

我们也可以来到图形化界面，能更直观看到改变

二、Docker基础与环境部署

Docker理论知识

一、Docker核心组件：镜像、容器、仓库

1. 镜像（Image）

镜像是Docker的基石。它是一个静态的、只读的模板，包含了运行一个应用程序所需的所有东西：代码、运行时环境（如JDK、Python）、系统工具、库文件、环境变量和配置文件。可以把它理解为一个软件的"安装包"或"模具"------一个镜像可以创建出无数个容器。

技术本质：镜像采用分层存储结构（UnionFS联合文件系统），每一层都是文件系统的增量修改。例如一个Python应用镜像可能包含OS基础层（如Ubuntu）、环境层（如Python安装）、依赖层（如pip安装的包）、代码层（应用代码），这些层像千层饼一样叠加起来。这种设计带来了显著优势：多个镜像可共享相同的基础层（如Ubuntu层），大幅节省磁盘空间；构建镜像时，只有发生变化的层需要重新构建，效率极高。

关键特性：

只读性：镜像本身不可修改，只能基于它创建新镜像
内容寻址：每层通过SHA256哈希值唯一标识
写时复制（Copy-on-Write）：当容器需要修改文件时，会从只读层复制到可写层再修改，原始镜像保持不变

2. 容器（Container）

容器是镜像的运行实例。如果把镜像比作"类"（Class），容器就是"对象"（Object）；如果把镜像比作"食谱"，容器就是按照食谱做出来的"那道菜"------同一张食谱可以做出无数盘菜，彼此独立、互不影响。

技术本质：容器本质上是一个被隔离的进程。Docker利用Linux内核的Namespace（命名空间）实现进程、网络、文件系统、用户等维度的隔离，使用Cgroups（控制组）实现对CPU、内存、磁盘I/O等资源的配额限制。容器在启动时，会在镜像的只读层之上挂载一个"读写层"（容器层），所有程序运行时产生的数据（日志、临时文件、配置修改）都写入这一层。

关键特性：

可读可写：容器层是可读可写的，程序运行时的所有修改都发生在此
临时性：容器停止后，容器层的修改默认会丢失（除非通过挂载卷进行持久化）
轻量独立：每个容器拥有独立的进程空间和网络命名空间

3. 仓库（Repository）

仓库是集中存放和分发镜像的地方，相当于镜像的"超市"或"图书馆"。全球最大的公共镜像是Docker Hub，国内常用的有阿里云容器镜像服务（ACR）、腾讯云镜像仓库等。

核心操作：

docker pull：从仓库下载镜像到本地
docker push：将本地镜像上传到仓库
docker build：通过Dockerfile构建镜像

三者协作流程：开发者在本地编写Dockerfile → 通过docker build构建镜像 → 通过docker push将镜像推送到仓库 → 部署时通过docker pull拉取镜像 → 通过docker run基于镜像启动容器。这套流程实现了"一次构建，到处运行"的理念。

二、Docker的核心优势

Docker之所以在云计算和软件开发领域迅速普及，主要得益于以下几个核心优势：

1. 轻量化与极低资源开销

Docker容器共享宿主机的操作系统内核，无需为每个应用运行一整套完整的操作系统，也不需要模拟虚拟硬件。单个容器镜像通常仅几十MB，而传统虚拟机镜像往往达到GB级别。以CentOS为例，完整镜像从1.2GB降至120MB（缩减90%以上）。在相同硬件配置下，单台物理机可运行的容器实例数量往往是虚拟机的数倍甚至数十倍。

2. 毫秒级启动速度

传统虚拟机启动应用服务往往需要数分钟（因为需要引导完整的操作系统），而Docker容器直接运行于宿主机内核，可以做到秒级甚至毫秒级的启动时间。这意味着你可以像调用函数一样"随手创建、用完即删"一个容器，无需漫长的等待。

3. 环境一致性

这是Docker最著名的价值：根治"在我机器上能跑"的顽疾。Docker镜像将应用程序及其完整的运行环境（包括操作系统文件、依赖库、配置文件）打包在一起。无论这个镜像是在开发环境构建的、在测试环境中运行的、还是最终部署到生产环境的，其运行环境完全一致。

4. 高效的资源利用

由于不需要运行独立的Guest OS，容器对CPU、内存的占用远低于虚拟机。相同场景下，容器内存占用可控制在2GB以内，而虚拟机可能需要数GB甚至更多。实际企业实践数据显示，采用容器化后服务器资源成本可降低28%，CPU/内存利用率提升3-5倍。

5. 标准化交付与可移植性

镜像成为应用的标准交付单元。通过镜像仓库，团队可以便捷地共享和版本化管理镜像。由于镜像封装了完整的运行时环境，应用可以在物理机、虚拟机、不同云平台间轻松迁移，运行结果一致。

三、Docker容器与传统虚拟机的核心差异

Docker容器与传统虚拟机（如VMware、KVM）虽然都提供了应用隔离的能力，但二者的技术实现方式和适用场景有本质区别。下表是核心差异对比：

对比维度	Docker容器	传统虚拟机
虚拟化层级	操作系统级虚拟化（进程级隔离）	硬件级虚拟化（通过Hypervisor模拟完整硬件）
内核	所有容器共享宿主机内核	每个VM拥有独立的操作系统内核
启动时间	毫秒级	分钟级（30秒-数分钟）
镜像/磁盘大小	MB级别（几十~数百MB）	GB级别（数GB~数十GB）
资源占用	极少，无Guest OS开销	较大，每个VM需运行完整OS
性能	接近原生物理机	有一定Hypervisor层损耗
隔离性	中等（Namespace + Cgroups），容器共享内核	强（完全硬件隔离），不同VM互不影响
可移植性	高（镜像跨平台标准）	较低（依赖特定Hypervisor和硬件）
管理复杂度	低（轻量，可快速创建/销毁/扩展）	高（需管理完整OS生命周期）
典型场景	微服务、CI/CD、开发测试环境	多租户强隔离、遗留应用、不同OS共存
[对比]