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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 第 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搭建和管理企业级网站应用
相关文章
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
19天前
|
运维 Kubernetes Docker
利用Docker和Kubernetes构建微服务架构
利用Docker和Kubernetes构建微服务架构
|
15天前
|
SQL Java 数据库连接
Mybatis架构原理和机制,图文详解版,超详细!
MyBatis 是 Java 生态中非常著名的一款 ORM 框架,在一线互联网大厂中应用广泛,Mybatis已经成为了一个必会框架。本文详细解析了MyBatis的架构原理与机制,帮助读者全面提升对MyBatis的理解和应用能力。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
Mybatis架构原理和机制,图文详解版,超详细!
|
16天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
35 1
服务架构的演进:从单体到微服务的探索之旅
|
14天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
37 8
|
15天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5
|
17天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
42 7
|
16天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5
|
16天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####