尝试通过k8s Tasks进行操作:为Pod配置使用卷进行存储
请提供相关资料
配置一个Pod以使用卷进行存储(kubernetes.io)
使用Kustomize进行Kubernetes对象的声明式管理(kubernetes.io)
空目录卷(kubernetes.io)
在中文中,这句话可以翻译为:可以学到什么?
-
- コンテナでデータを保存するにはVolumeを使う
Volume種別毎に、データの生存期間が異なる
预先的知识
-
- コンテナが終了(再起動)した時、コンテナが持っているファイルシステム内の変更は全て失われる
-
- →コンテナ生成元のイメージと同等の状態に戻る
- 上記の通りなので、コンテナをステートフルで使いたい(状態、データを保存したい)ならば、永続ストレージをコンテナへマウントしておく必要がある
前提条件 (Qian ti tiao jian)
-
- k8s v1.14以降 (Kustomizeが必要)
- k8sクラスタ起動済み
环境信息
-
- CNI実装: calico
-
- CRI実装: Docker
- ホストOS: Ubuntu 18.04
步骤
1/5:制作Pod并监控其状态。

要执行后续命令,请使用C-z将监视器切换到后台作业,或者启动一个新的shell(例如C-Shift-t)。
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml && \
kubectl get pod redis --watch
pod/redis created
NAME READY STATUS RESTARTS AGE
redis 0/1 ContainerCreating 0 0s
redis 1/1 Running 0 17s
2/5:使用我创建的Pod启动Shell。

kubectl exec -it redis -- /bin/bash
root@redis:/data#
3/5:使用启动的shell创建文件

cd /data/redis/
echo Hello > test-file && ls
test-file
更新Ubuntu存储库信息并安装procps包后,使用ps aux命令查看正在运行的进程信息。

…失败了。。coredns没有正确地运行。
apt-get update
Err:1 http://security.debian.org/debian-security buster/updates InRelease
Temporary failure resolving 'security.debian.org'
Err:2 http://deb.debian.org/debian buster InRelease
Temporary failure resolving 'deb.debian.org'
Err:3 http://deb.debian.org/debian buster-updates InRelease
Temporary failure resolving 'deb.debian.org'
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease Temporary failure resolving 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
由於在這篇文章中得到了解答,所以下面是解決後的情況。
apt-get update
Get:1 http://security-cdn.debian.org/debian-security buster/updates InRelease [39.1 kB]
Get:2 http://cdn-fastly.deb.debian.org/debian buster InRelease [118 kB]
Get:3 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease [46.8 kB]
Get:4 http://security-cdn.debian.org/debian-security buster/updates/main amd64 Packages [53.4 kB]
Get:5 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages [7897 kB]
Fetched 8154 kB in 6s (1375 kB/s)
Reading package lists... Done
apt-get install procps
...
ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.3 0.2 40704 4124 ? Ssl 06:26 0:06 redis-server *:6379
root 338 0.6 0.1 3868 2928 pts/0 Ss 07:02 0:00 /bin/bash
root 344 0.0 0.1 7640 2656 pts/0 R+ 07:02 0:00 ps aux
5/5:关闭Redis进程,启动Pod中的shell,并确认已创建的文件/data/redis/test-file存在

kill 1
root@redis:/data# command terminated with exit code 137
获取pod redis的后续状态,使用kubectl –watch
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 41m
redis 0/1 Completed 0 42m
redis 0/1 CrashLoopBackOff 0 43m
redis 1/1 Running 1 43m
kubectl exec -it redis -- /bin/bash
root@redis:/data# ls /data/redis
test-file
测试文件还活着,这次的任务成功了。
请在结束后清理一下。
kubectl delete pod redis
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 1 43m
redis 1/1 Terminating 1 53m
redis 0/1 Terminating 1 53m
请问?
有问题?
有疑问?
有什么问题?
有什么疑问?
/data/redis 该路径在主机操作系统的哪个位置挂载?
我们来看一下这次使用的Volume类型Volumes emptyDir(kubernetes.io)的规范。
在这个练习中,你创建一个运行一个容器的 Pod。这个 Pod 拥有一个 emptyDir 类型的卷,它会在 Pod 的生命周期内持续存在,即使容器终止并重新启动。这是用于 Pod 的配置文件。
在 Pod 从调度的 Node 上被驱逐之前,emptyDirVolume 似乎是存在的。
默认情况下,emptyDir卷会存储在支持节点的介质上,这可能是磁盘、固态硬盘(SSD)或网络存储,取决于您的环境。然而,您可以将emptyDir.medium字段设置为”Memory”,告诉Kubernetes来代替为您挂载一个tmpfs(基于内存的文件系统)。
空的目录(emptyDir)在默认情况下使用节点持有的存储空间,如果在emptyDir.medium字段中设置为”Memory”,则会在节点的内存上构建tmpfs(RAM磁盘)。
由于本次未进行任何设置,所以我认为test-file应该存在于主机操作系统内的存储根目录/分区以下…尝试使用locate kubernetes在主机操作系统内进行搜索,但并没有找到与创建的test-file相当的文件。
本次不再进一步深入探讨,到此为止。
检查当前Pod的卷状态。
kubectl describe pod redis
...
Containers:
redis:
Mounts:
/data/redis from redis-storage (rw)
...
redis-storage:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
总结
这次任务是简单地涉及到emptyDir这种Volume类型。
emptyDir基本上是一个在Pod被驱逐出Node之前一直存在的Volume。
这意味着即使Pod内的容器死了,只要在同一Node内重新启动,保存的数据也可以恢复。
(当Node本身不可信时,想要将Pod移动到其他Node的情况不适用…在k8s的运维中,这似乎不切实际)
无论如何,这次任务的重点是“在Pod内的容器中挂载Volume”,这一目标已经实现了。
来说,对于存储容量,需要深入了解各种知识,但至少
-
- マウント、アンマウントの方法と場所(お互いのパス、紐付け方)
-
- データの生存期間
- Volumeの指定方法(メモリ、永続ストレージ等)
我想如果抑制住它,应该就没问题了。
就这样。
附注:除了习惯用语之外的缩写词。
-
- k8s: Kubernetes
-
- CNI: Container Networking Interface
- CRI: Container Runtime Interface