Kubernetes入门与进阶01

背景

容器的数据放在那里

1、常规理解，就是业务数据啊，日志数据啊，这些要给挂载映射到宿主机上的持久化的。

2、纯技术，容器分层图视角，就是容器本身是分层挂载，底层都是只读的，commit提交的才是用户可定义的数层。

对，你这个理解基本是对的，可以分成运维视角和底层原理视角两套来看。

常规说“容器数据放哪里”，一般指：

业务数据
配置文件
日志文件
上传文件
数据库数据
证书文件

这些不要只放在容器内部，应该用：

-v /data/app:/app/data
-v /data/logs:/app/logs
-v /data/config:/app/config

或者 docker-compose：

volumes:
  - /data/app:/app/data
  - /data/logs:/app/logs
  - /data/config:/app/config

否则容器一删：

docker rm xxx

容器内部改动的数据也可能跟着没了。

Docker 镜像是多层只读层：

镜像层1：基础系统层，只读
镜像层2：软件安装层，只读
镜像层3：应用代码层，只读

容器启动后，会在最上面加一层：

容器可写层

整体类似：

容器可写层    ← 运行时产生/修改的数据
镜像只读层3
镜像只读层2
镜像只读层1

容器里你创建文件、改配置、写日志，默认都写到这个容器可写层。

比如：

docker commit 容器ID myimage:v1

意思是：

把当前容器可写层保存成一个新的镜像层

但这个不适合保存业务数据。

它适合：

临时调试后固化环境
保存安装好的软件环境
制作测试镜像

不适合：

数据库数据
用户上传文件
运行日志
证书续期数据

你可以这样记：

镜像层：放程序、依赖、基础环境
容器可写层：临时运行变化
宿主机挂载卷：放真正要长期保存的数据
commit：把容器当前状态做成新镜像，不是持久化数据的正路

最推荐的生产方式：

应用容器可以随便删、随便重建
数据目录必须在宿主机或独立存储上
配置、日志、业务数据都明确挂载

一句话：

容器本身应该是“可替换的”，数据才是“要保护的”。