k8s--数据存储、HostPath、NFS 存储

简介: k8s--数据存储、HostPath、NFS 存储

HostPath


在使用 EmptyDir 的时候,EmptyDir 中数据不会被持久化,它会随着 pod 的结束而销毁,如果想简单的将数据持久化到主机中,可以选择 HostPath

HostPath 就是将 Node 主机中一个实际目录挂载到 pod 中,以供容器使用,这样的设计就可以保证 pod 销毁了,但是数据依然可以存在于 Node 主机上

创建一个 volume-hostpath.yaml,内容如下

apiVersion: v1
kind: Pod # 类型为 pod
metadata:
  name: volume-hostpath # pod 的名称
  namespace: zouzou
spec:
  containers:
  - name: nginx
    image: nginx:1.14
    ports:
    - containerPort: 80 # 暴露容器的端口
    volumeMounts: # 挂载
    - name: logs-volume # 要和 volumes 的name 一致
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume  #
    hostPath: 
      path: /tmp/logs # 挂载到 node 主机上的 /tmp/log 目录下
      type: DirectoryOrCreate  # 目录存在就使用,不存在就先创建后使用

关于type的值的一点说明:

  • DirectoryOrCreate:目录存在就使用,不存在就先创建后使用
  • Directory:目录必须存在
  • FileOrCreate:文件存在就使用,不存在就先创建后使用
  • File:文件必须存在
  • Socket:unix 套接字必须存在
  • CharDevice:字符设备必须存在
  • BlockDevice:块设备必须存在

创建 pod

# 创建 pod
[root@dce-10-6-215-215 pod-dir]# kubectl apply -f volume-hostpath.yaml
pod/volume-hostpath created

查看 pod

# pod 的 ip 地址为 172.29.35.63,并且在 dce-10-6-215-200 的节点上创建了
[root@dce-10-6-215-215 pod-dir]# kubectl get pod -n zouzou -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP             NODE               NOMINATED NODE   READINESS GATES
volume-hostpath   2/2     Running   0          32s   172.29.35.63   dce-10-6-215-200   <none>           <none>

我们登录到 dce-10-6-215-200 的 node 节点上,看 /tmp/logs 目录存在不

可以看到,目录自动创建了,并且创建了两个日志文件,我们打印下 access.log 文件里的内容

# 实时查看日志,在 node 节点上查看
tail -f access.log

因为 pod 是我们刚创建的,还没有访问 nginx,所以还没有日志产生,接下来,我们访问下 nginx

# ip 换成你自己的 ip
curl 172.29.35.63:80

访问几次后,在 node 节点上去查看日志,这时候发现已经有日志输出了

然后我们删除 pod,查看文件里里面的内容是否还存在

# 删除 pod
kubectl delete -f volume-hostpath.yaml

删除 pod 之前在去 dce-10-6-215-200 的 node 节点上查看,发现文件和文件里面的内容还是存在的。当我们重新创建 pod 时,在访问,日志会接着往里面写入,不会删除之前的日志


NFS


HostPath 可以解决数据持久化的问题,但是一旦 Node 节点故障了,pod 如果转移到了别的节点,又会出现问题了,此时需要准备单独的网络存储系统,比较常用的是 NFS、CIFS

NFS 是一个网络文件存储系统,可以搭建一台 NFS 服务器,然后将 pod 中的存储直接连接到 NFS 系统上,这样的话,无论 pod 在节点上怎么转移,只要 Node 跟 NFS 的对接没问题,数据就可以访问成功

首先要准备 nfs 的服务器,这里为了简单,直接是 master 节点做 nfs 服务器

在 master 机器上安装 nfs 服务

# 安装 nfs 服务
yum install nfs-utils -y

在 master 上准备一个共享目录

# 创建一个共享目录,-p 递归创建,-v 显示创建信息
[root@dce-10-6-215-215 ~]# mkdir /root/data/nfs -pv
mkdir: created directory ‘/root/data’
mkdir: created directory ‘/root/data/nfs’

将共享目录以读写权限暴露给 10.6.215.0/24 网段中的所有主机(注意,网段要是你自己的网段,我这里 master 和 node 节点的 ip 都是 10.6.215.xxx

# 在 /etc 创建个 exports 文件
vim /etc/exports

将下面内容写入到文件里

/root/data/nfs     10.6.215.0/24(rw,no_root_squash)
  • rw :表示读写模式
  • no_root_squash :登入 NFS 主机使用分享目录的使用者,如果是 root 的话,那么对于这个分享的目录来说,他就具有 root 的权限

启动 nfs 服务

systemctl restart nfs

接下来,要在每 个node 节点上都安装下 nfs,这样的目的是为了 node 节点可以驱动 nfs 设备。只安装就可以了,不需要启动 nfs 服务

# 在所有 node 节点上安装 nfs,不需要启动
yum install nfs-utils -y

接下来,就可以编写 pod 的配置文件了,创建 volume-nfs.yaml,内容如下

apiVersion: v1
kind: Pod # 类型为 pod
metadata:
  name: volume-nfs # pod 的名称
  namespace: zouzou
spec:
  containers:
  - name: nginx
    image: nginx:1.14
    ports:
    - containerPort: 80 # 暴露容器里面的 80 端口
    volumeMounts: # 挂载
    - name: logs-volume # 名字要和 volumes 里的一致
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"] 
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume
    nfs: # nfs 类型
      server: 10.6.215.215  # nfs 服务器地址
      path: /root/data/nfs # 共享文件路径

创建 pod

# 创建 pod
[root@dce-10-6-215-215 nfs]# kubectl apply -f volume-nfs.yaml
pod/volume-nfs created

查看 pod

# 查看 pod,pod 的 ip 为 172.29.35.63
[root@dce-10-6-215-215 nfs]# kubectl get pods volume-nfs -n zouzou -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP             NODE               NOMINATED NODE   READINESS GATES
volume-nfs   2/2     Running   0          98s   172.29.35.63   dce-10-6-215-200   <none>           <none>

查看 nfs 服务器上的共享目录,发现已经有文件了

查看下 access.log 文件里的内容

tail -f access.log

刚开始是没有的,用 pod 的 ip 访问下 nginx

curl 172.29.35.63:80


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
1天前
|
存储 Kubernetes 数据安全/隐私保护
|
10天前
|
存储 Kubernetes 调度
K8S常见的持久化(存储)方案用法详解
K8S常见的持久化(存储)方案用法详解
|
27天前
|
存储 运维 Kubernetes
Kubernetes存储卷
Kubernetes存储卷
30 0
|
1月前
|
存储 Kubernetes 容器
K8S中使用nfs作为存储卷
K8S中使用nfs作为存储卷
17 0
|
2月前
|
存储 运维 Kubernetes
K8S基于NFS来动态创建PV【亲测可用】
K8S基于NFS来动态创建PV【亲测可用】
82 2
|
13天前
|
运维 Kubernetes 监控
Kubernetes 集群的持续性能优化实践
【4月更文挑战第26天】 在动态且不断增长的云计算环境中,维护高性能的 Kubernetes 集群是一个挑战。本文将探讨一系列实用的策略和工具,旨在帮助运维专家监控、分析和优化 Kubernetes 集群的性能。我们将讨论资源分配的最佳实践,包括 CPU 和内存管理,以及集群规模调整的策略。此外,文中还将介绍延迟和吞吐量的重要性,并提供日志和监控工具的使用技巧,以实现持续改进的目标。
|
1天前
|
Kubernetes Java API
Kubernetes详解(三)——Kubernetes集群组件
Kubernetes详解(三)——Kubernetes集群组件
9 1
|
6天前
|
运维 监控 Kubernetes
Kubernetes 集群的监控与维护策略
【5月更文挑战第4天】 在当今微服务架构盛行的时代,容器化技术已成为软件开发和部署的标准实践。Kubernetes 作为一个开源的容器编排平台,因其强大的功能和灵活性而广受欢迎。然而,随着 Kubernetes 集群规模的扩大,集群的监控和维护变得日益复杂。本文将探讨 Kubernetes 集群监控的重要性,分析常见的监控工具,并提出一套有效的集群维护策略,以帮助运维人员确保集群的健康运行和高可用性。
37 10
|
7天前
|
存储 运维 监控
Kubernetes 集群的持续监控与优化策略
【5月更文挑战第3天】在微服务架构和容器化部署日益普及的背景下,Kubernetes 已成为众多企业的首选容器编排平台。然而,随着集群规模的增长和业务复杂度的提升,有效的集群监控和性能优化成为确保系统稳定性和提升资源利用率的关键。本文将深入探讨针对 Kubernetes 集群的监控工具选择、监控指标的重要性解读以及基于数据驱动的性能优化实践,为运维人员提供一套系统的持续监控与优化策略。
|
9天前
|
运维 Kubernetes 监控
Kubernetes 集群的监控与维护策略
【4月更文挑战第30天】 在现代云计算环境中,容器化技术已成为应用程序部署和管理的重要手段。其中,Kubernetes 作为一个开源的容器编排平台,以其强大的功能和灵活性受到广泛欢迎。然而,随之而来的是对 Kubernetes 集群监控和维护的复杂性增加。本文将探讨针对 Kubernetes 集群的监控策略和维护技巧,旨在帮助运维人员确保集群的稳定性和高效性。通过分析常见的性能瓶颈、故障诊断方法以及自动化维护工具的应用,我们将提供一套实用的解决方案,以优化 Kubernetes 环境的性能和可靠性。