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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 第 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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1天前
|
Java 微服务 Spring
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
文章介绍了如何利用Spring Cloud Alibaba快速构建大型电商系统的分布式微服务,包括服务限流降级等主要功能的实现,并通过注解和配置简化了Spring Cloud应用的接入和搭建过程。
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
|
12天前
|
前端开发 Java UED
"揭秘!如何以戏剧性姿态,利用SpringCloud铸就无懈可击的异常处理铁壁,让你的微服务架构稳如泰山,震撼业界!"
【8月更文挑战第8天】随着Spring Cloud在微服务架构中的广泛应用,统一异常处理成为确保系统稳定性和提升用户体验的关键。传统方式在各服务中单独处理异常导致代码冗余且不一致。因此,采用Spring Cloud封装统一异常处理机制变得尤为重要:它减少了冗余代码,提升了异常处理的一致性和系统的可维护性,并通过统一错误响应格式优化了用户体验。实现这一机制可通过定义全局异常处理器、自定义业务异常并在服务中适当抛出这些异常来完成。这种方式遵循了微服务设计中的“服务治理”和“契约先行”原则,为构建健壮的微服务系统打下了基础。
25 1
|
3天前
|
Java 数据库连接 Nacos
SpringCloud微服务配置管理、配置热更新
SpringCloud微服务配置管理、配置热更新
14 0
|
3天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
13天前
|
缓存 监控 API
【微服务战场上的神秘守门人】:揭秘API网关的超能力 —— 探索微服务架构中的终极守护者与它的神奇魔法!
【8月更文挑战第7天】随着微服务架构的流行,企业应用被拆分为围绕特定业务功能构建的小型服务。API网关作为微服务间的通信管理核心,对请求进行路由、认证、限流等处理,简化客户端集成并提升用户体验。以电商应用为例,通过Kong部署API网关,配置产品目录等服务的API及JWT认证插件,确保安全高效的数据交互。这种方式不仅增强了系统的可维护性和扩展性,还提供了额外的安全保障。
31 2
|
20天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
【7月更文挑战第30天】在微服务架构的复杂网络中,API网关扮演着交通枢纽的角色,不仅简化了客户端与各微服务的交互,还提升了系统的安全性和可维护性。本文将深入探讨API网关的设计原则、核心功能以及在实际应用中的部署策略,旨在为后端开发者提供一套完整的API网关解决方案。
|
21天前
|
安全 前端开发 API
探索微服务架构中的API网关模式
【7月更文挑战第30天】在微服务架构的海洋中,API网关是一艘至关重要的航船。它不仅是服务的入口,更是流量控制、安全认证与协议转换的枢纽。本文将深入探讨API网关的核心作用,揭示其在微服务生态中的价值,并指导如何有效实现和部署这一关键组件。
52 6
|
22天前
|
运维 Kubernetes 开发者
构建高效后端服务:微服务架构与容器化部署的实践
【7月更文挑战第29天】 在现代软件开发中,后端服务的构建不再仅仅是代码的堆砌,而是需要考虑到可扩展性、可靠性和快速迭代等多重因素。本文将探讨如何通过微服务架构和容器化技术来构建一个高效的后端服务系统。我们将从微服务的概念出发,分析其在后端开发中的应用优势,并结合容器化技术,特别是Docker和Kubernetes的使用,来展示如何在保证服务高可用性和伸缩性的同时,简化开发和部署流程。文章还将涵盖如何应对微服务架构下的数据一致性挑战,以及如何利用现代云平台资源来优化后端服务的性能和成本效益。
|
23天前
|
存储 负载均衡 算法
深入理解微服务架构中的服务发现与注册机制
【7月更文挑战第28天】在现代软件开发的复杂性中,微服务架构以其灵活性和可扩展性受到青睐。本文将深入探讨微服务架构的核心组件之一——服务发现与注册机制,分析其工作原理、实现方式及面临的挑战,并结合实际案例,为读者提供全面的理解和应用指南。