kubernetes Spring Cloud 微服务架构— (3)Kubernetes spring cloud 微服务-Docker 镜像存储机制

简介: 第 3 章 Docker 镜像存储机制 本章节是对上章节Docker镜像原理理解的巩固,从Linux系统运行基础到OverlayFS存储机制去了解与分析;在底层,镜像是怎样实现存储的;并且会详细说明存储文件的作用。

3.1  Linux 系统运行基础

Linux 系统正常运行, 通常需要两个文件系统:

3.1.1 boot file system (bootfs)

1)包含 Boot LoaderKernel文件,用户不能修改这些文件。并且在系统启动过程完成之后, 整个系统的内核都会被加载进内存。此时bootfs会被卸载, 从而释放出所占用的系统内存。

2)在容器中可以运行不同版本的Linux, 说明对于同样内核版本的不同的 Linux 发行版的bootfs 都是一致的, 否则会无法启动。因此可以推断, Docker运行是需要内核支持的。

3) Linux系统中典型的bootfs目录: (核心) /boot/vmlinuz(核心解压缩所需 RAM Disk)

/boot/initramfs

 

3.1.2 root file system (rootfs)

1) 不同的Linux发行版本, bootfs相同, rootfs不同(二进制文件)

2)每个容器有自己的 rootfs, 它来自不同的Linux 发行版的基础镜像,包括 Ubuntu

Debian SUSE 等。

3)   使用不同的rootfs 就决定了, 在构建镜像的过程中, 可以使用哪些系统的命令。

4)   典型的rootfs 目录: /dev/proc/bin/etc /lib/usr

3.2  OverlayFS 存储原理

OverlayFS 结构分为三个层: LowerDirUpperdirMergedDir

1)LowerDir (只读) 只读的 image layer,其实就是 rootfs, 在使用 Dockfile 构建镜像的时候, Image Layer 可以分很多层,所以对应的 lowerdir 会很多(源镜像)。

2) Upperdir (读写)

upperdir 则是在 lowerdir 之上的一层, 为读写层。容器在启动的时候会创建, 所有对容器的修改, 都是在这层。比如容器启动写入的日志文件,或者是应用程序写入的临时文件。

3)MergedDir (展示)  merged 目录是容器的挂载点,在用户视角能够看到的所有文件,都是从这层展示的。

3.3 分析镜像存储结构

3.3.1 获取镜像存储路径 #通过镜像信息获取到物理存储位置

root@master jdk]# docker image inspect jre8:1.3 
 "Architecture": "amd64", 
 "Os": "linux", 
 "Size": 136406576, 
 "VirtualSize": 136406576, 
 "GraphDriver": { 
     "Data": { 
         "LowerDir": 
"/var/lib/docker/overlay2/ba469a9497fe6894e9022c2cb8b4217cd5aa1d0b35653ccd927a247bff3d2a81/diff:/var/lib/docker/overlay2/785564c2852e5b5b8f53d84ab4350c7aec6cb5a0 f44e457779877f06a95354ad/diff:/var/lib/docker/overlay2/101c2e9852e1b3e4a593f1b4ca8770fdd2b2c4656b3447dc96799527f03767c6/diff:/var/lib/docker/overlay2/fb940d476e39c
51cace728b5d709fff21c5c6421227c7ec7b2c421875767bc26/diff:/var/lib/docker/overlay2/271a364d00b2aabce86f2cb7d6c1abead3e1c8903cdd25e07a901964e3534978/diff",
         "MergedDir": "/var/lib/docker/overlay2/6700cb0c98e3e7af8bdd97d4e40d673e3a0cf0fc6768323e8d4372afde12aff2/merged",
         "UpperDir": "/var/lib/docker/overlay2/6700cb0c98e3e7af8bdd97d4e40d673e3a0cf0fc6768323e8d4372afde12aff2/diff",
         "WorkDir": "/var/lib/docker/overlay2/6700cb0c98e3e7af8bdd97d4e40d673e3a0cf0fc6768323e8d4372afde12aff2/work"
     }, 
     "Name": "overlay2" 
 }, 
 "RootFS": { 
     "Type": "layers", 
     "Layers": [ 
        "sha256:5216338b40a7b96416b8b9858974bbe4acc3096ee60acbc4dfb1ee02aecceb10",
        "sha256:3219209e108e14824bd77c247110bbdb0e8ab392a016c634b8f031b610673fac",
        "sha256:d5aea7d9c0743772a38d8d81c4f1be709890827bc915465a7048a7d718fbf859",
        "sha256:3ff10a379107fb9e679ac8c001e5edbc4a01ec7b3bd86162e5932aa5ea2f8808",
        "sha256:c86fc31cf85edab6d1b9aa4750656496e0925186c112092ddd0a5909ba4a8b9b",
        "sha256:27d22f85ea93e4cbdf47b565433be94f6ce46f4e822abe6352c0f5b028bd2150"
     ]

 

3.3.2 分析Lower

#LowerDir 层的存储是不允许创建文件, 此时的LowerDir实际上是其他的镜像的UpperDir层,也就是说在构建镜像的时候, 如果发现构建的内容相同, 那么不会重复的构建目录,而是使用其他镜像的Upper 层来作为本镜像的Lower

[root@master jdk]# touch /var/lib/docker/overlay2/ba469a9497fe6894e9022c2cb8b4217cd5aa1d0b35653ccd927a247bff3d2a81/diff/lower.txt


3.3.3 分析Upper层
#在Upper层创建文件

[root@master jdk]# touch /var/lib/docker/overlay2/6700cb0c98e3e7af8bdd97d4e40d673e3a0cf0fc6768323e8d4372afde12aff2/diff/upper.txt

3.4 运行中容器的存储结构

3.4.1 启动容器

#前台启动,直接进入到容器

[root@master jdk]# docker run -it jre8:1.3 bash

3.4.2 查看容器挂在信息

#容器启动以后,挂载mergedlowerdirupperdir以及workdir目录 #lowerdir是只读的image layer,其实就是rootfs

#获取容器 ID

/

[root@master ~]# docker ps 
CONTAINER ID        IMAGE          COMMAND                  CREATED             STATUS              PORTS                  NAMES 
39d421864be6  jre8:1.3 "bash"                  11 seconds ago      Up 10 seconds              agitated_heyrovsky

 

3.4.3 查看容器存储目录信息

#注意在所有的启动容器中会自动添加init目录, 此目录是存放系统的hostname与域名解析文件

[root@master ~]# docker inspect 39d421864be6 
        "GraphDriver": { 
            "Data": { 
                "LowerDir":   "/var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794dinit/diff:/var/lib/docker/overlay2/6700cb0c98e3e7af8bdd97d4e40d673e3a0cf0fc6768323e8d4372afde12aff2/diff:/var/lib/docker/overlay2/ba469a9497fe6 894e9022c2cb8b4217cd5aa1d0b35653ccd927a247bff3d2a81/diff:/var/lib/docker/overlay2/785564c2852e5b5b8f53d84ab4350c7aec6cb5a0f44e4577798 77f06a95354ad/diff:/var/lib/docker/overlay2/101c2e9852e1b3e4a593f1b4ca8770fdd2b2c4656b3447dc96799527f03767c6/diff:/var/lib/docker/overlay2/f b940d476e39c51cace728b5d709fff21c5c6421227c7ec7b2c421875767bc26/diff:/var/lib/docker/overlay2/271a364d00b2aabce86f2cb7d6c1abead3e1c89
03cdd25e07a901964e3534978/diff", 
                "MergedDir": "/var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d/merged", 
                "UpperDir": "/var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d/diff", 
                "WorkDir": "/var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d/work" 
            }, 
            "Name": "overlay2" 
        }, 
        "Mounts": [], 
        "Config": { 
            "Env": [ 
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/java/jdk/jre1.8.0_211/bin",                 "GLIBC_VERSION=2.31-r0", 
                "JAVA_HOME=/usr/java/jdk/jre1.8.0_211" 
            ], 
            "Cmd": [ 
                "bash" 
            ], 
            "Image": "jre8:1.3", 
            "Volumes": null, 
            "WorkingDir": "/opt", 
            "Entrypoint": null, 
            "OnBuild": null, 
            "Labels": {} 
        }, 
    } 
] 

3.5 容器文件存储解析

3.5.1 容器运行时的UpperDir目录结构

[root@master ~]# touch /var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d/diff/c1.txt 
#在进入到操作查看 
bash-4.3# cat /c1.txt 

3.5.1.1 Work 目录

work目录用于联合挂载指定的工作目录,overlay 把文件挂载到 upperdir, work内容会被清空,且在使用过程中(为空)其内容用户不可见。

 

3.5.1.3 用户视角层Merged

#    后给用户展示的层,一般看到为一个完整的操作系统文件系统结构

 

[root@master ~]# ll    /var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d/merged   
total 4 
….省略…… 
-rw-r--r-- 1 root root    0 Mar 14 03:58 lower.txt -rw-r--r-- 1   root root    0 Mar 14 04:03 upper.txt drwxr-xr-x 1 root   root   18 Mar 14 03:10 usr

3.5.2 Lower 层

Lower 包括两个层:

a. 系统的initb.容器的镜像层

Lower 记录父层的链接名称

[root@node-2 ~]# cat /var/lib/docker/overlay2/d4dc057329ecbf5a2f97293b6d49078e9cce6869a9f049ba5bc365f6fba424d2/lower  l/QCXVWDWYPFM5NRVMB2ZC2BE5WU:l/PUSOZBTJKJ2OBNKK2UQDNQLHCU init 层 / 容器镜像层

 

3.5.2.1 查看init层地址指向

#容器在启动的过程中, Lower 会自动挂载init的一些文件

[root@master~]#ls /var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d-init/diff/etc/hostname  hosts mtab  resolv.conf

3.5.2.2 init层主要内容是什么?

init层是以一个uuid+-init结尾表示,放在只读层(Lower)和读写层(upperdir)之间, 作用只是存放/etc/hosts/etc/resolv.conf 等文件,

 

3.4.2.3 为什么需要init层?

1)容器在启动以后, 默认情况下lower层是不能够修改内容的, 但是用户有需求需要修改主机名与域名地址, 那么就需要添加init层中的文件(hostname, resolv.conf), 用于解决此类问题. 2) 修改的内容只对当前的容器生效,而在docker commit提交为镜像时候,并不会将init层提交。

3) init 文件存放的目录为/var/lib/docker/overlay2/<init_id>/diff

 

3.5.2.4 查看init层文件

#hostnameresolv.conf 全部为空文件, 在系统启动以后由系统写入.

 

[root@master ~]# ll   /var/lib/docker/overlay2/7397527ac0e1088be96ee714bb6caf78e88badd567477f7bfbec9717a975794d-init/diff/etc/ 
total 0 
-rwxr-xr-x 1 root root  0 Mar 14 04:09 hostname -rwxr-xr-x 1 root   root  0 Mar 14 04:09 hosts lrwxrwxrwx 1   root root 12 Mar 14 04:09 mtab -> /proc/mounts 
-rwxr-xr-x 1 root   root  0 Mar 14 04:09 resolv.conf

#总结

1)镜像所挂载的目录层为 Lower 层,然后通过 Merged 展示所有的文件目录与文件。用户写入的所有文件都是在 UpperDir 目录,并且会在UpperDir 建立于 Merged 层展示的文件目录结构,所以用户就可以看到写入的文件。并且底层的镜像是不能被修改(如果挂载目录为 UpperDir,则可以修改源镜像)

2)在下次重新启动已经停止的容器的时候, 如果容器的 ID 没有发生改变,那么所写入的文件是存在物理系统中的; 反之就会是一个新的容器,之前手工创建的文件是不存在的。

3)基于容器创建的镜像,就相当于容器的快照, 可以删除原来的容器, 但是不能删除原来的镜像

4) 基于镜像创建的镜像,原来的镜像就是新镜像的low (build), tag 则是没有区别

5) 容器启动以后,镜像就存在于容器的 lower层,所有的写入都是在 upper

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
7月前
|
Kubernetes Docker Python
Docker 与 Kubernetes 容器化部署核心技术及企业级应用实践全方案解析
本文详解Docker与Kubernetes容器化技术,涵盖概念原理、环境搭建、镜像构建、应用部署及监控扩展,助你掌握企业级容器化方案,提升应用开发与运维效率。
1112 108
|
6月前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
2158 10
|
6月前
|
Kubernetes Devops Docker
Kubernetes 和 Docker Swarm:现代 DevOps 的理想容器编排工具
本指南深入解析 Kubernetes 与 Docker Swarm 两大主流容器编排工具,涵盖安装、架构、网络、监控等核心维度,助您根据团队能力与业务需求精准选型,把握云原生时代的技术主动权。
634 115
|
9月前
|
存储 Kubernetes 监控
Docker与Kubernetes集成挑战及方案
面对这些挑战,并不存在一键解决方案。如同搭建灌溉系统需要考虑多种因素,集成Docker与Kubernetes也需要深思熟虑的规划、相当的技术知识和不断的调试。只有这样,才能建立起一个稳定、健康、高效的Docker-Kubernetes生态,让你的应用像花园中的植物一样繁荣生长。
396 63
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
1732 70
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
11月前
|
存储 Kubernetes 调度
Kubernetes、Docker和Containerd的关系解析
总的来说,Docker、Containerd和Kubernetes之间的关系可以用一个形象的比喻来描述:Docker就像是一辆装满货物的卡车,Containerd就像是卡车的引擎,而Kubernetes就像是调度中心,负责指挥卡车何时何地送货。
486 12
|
Kubernetes Docker 容器
Kubernetes与Docker参数对照:理解Pod中的command、args与Dockerfile中的CMD、ENTRYPOINT。
需要明确的是,理解这些都需要对Docker和Kubernetes有一定深度的理解,才能把握二者的区别和联系。虽然它们都是容器技术的二个重要组成部分,但各有其特性和适用场景,理解它们的本质和工作方式,才能更好的使用这些工具,将各自的优点整合到生产环境中,实现软件的快速开发和部署。
485 25
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
584 82