使用nfs在k8s集群中实现持久化存储

准备NFS服务192.168.1.244
$ yum -y install nfs-utils rpcbind
$ systemctl start nfs-server rpcbind
$ systemctl enable nfs-server rpcbind
$ mkdir -p /data/k8s
$ cd /data/k8s
$ echo 11111111 > index.html
$ vim /etc/exports
/data/k8s *(rw,async,no_root_squash)
$ systemctl restart nfs-server
$ exportfs -arv
客户端测试，所有k8s节点都要安装nfs客户端
$ yum -y install nfs-utils rpcbind
$ systemctl start nfs rpcbind
$ systemctl enable nfs rpcbind
$ showmount -e 192.168.1.244

创建pod直接挂载nfs服务器

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: podxx
spec:
  volumes:
  - name: nfs
    nfs:
      server: 192.168.1.244
      path: /data/k8s
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: nfs

$ kubectl exec podxx -it bash

PV 的全称是：PersistentVolume（持久化卷），是对底层的共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS 等，都是通过插件机制完成与共享存储的对接。
PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。

Deployment/pod---->pvc---->pv---->共享存储
AccessModes（访问模式）
ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
persistentVolumeReclaimPolicy（回收策略）
Retain（保留）- 保留数据，需要管理员手工清理数据
Recycle（回收）- 清除 PV 中的数据，效果相当于执行 rm -rf /thevoluem/*
Delete（删除）- 与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务，比如 ASW EBS。
目前只有 NFS 和 HostPath 两种类型支持回收策略。当然一般来说还是设置为 Retain 这种策略保险一点。
一个 PV 的生命周期中，可能会处于4中不同的阶段
Available（可用）：表示可用状态，还未被任何 PVC 绑定
Bound（已绑定）：表示已经被 PVC 绑定
Released（已释放）：PVC 被删除，但是资源还未被集群重新声明
Failed（失败）： 表示该 PV 的自动回收失败

手动管理pv和pvc
创建顺序：后端存储---pv---pvc---pod
删除顺序：pod---pvc---pv
1、创建pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
  labels:
    app: nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /data/k8s
    server: 192.168.1.244

2、创建pvc

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc2-nfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  selector:
    matchLabels:
      app: nfs

上述pvc会自动和具有访问模式是ReadWriteOnce、storage大于等于1Gi、标签是app: nfs的pv进行绑定
3创建pod使用pvc

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-pvc
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nfs-pvc
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          subPath: nginx1        #需要手动指定nfs服务器中的子目录，该目录会自动创建
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: pvc2-nfs        #第2步中创建的pvc

结果是：共享存储中的/data/k8s/nginx1会被挂载到上述pod中的/usr/share/nginx/html目录

使用StorageClass管理pv和pvc
只有pv是动态生成的，其他的还是需要手动创建
动态生成pv需要StorageClass和nfs-client-provisioner的共同作用
1、创建nfs-client-provisioner
provisione直接使用nfs服务器
$ docker pull quay.io/external_storage/nfs-client-provisioner:latest

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.1.244
            - name: NFS_PATH
              value: /data/k8s
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.1.244
            path: /data/k8s
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

2、创建StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: course-nfs-storage
provisioner: fuseim.pri/ifs

3、创建pvc并动态生成pv

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
  annotations:
    volume.beta.kubernetes.io/storage-class: "course-nfs-storage"
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 500Mi

$ kubectl get pv #pv会自动生成，并和pvc绑定

4、使用上述pvc创建pod
和手动管理pv和pvc不同的是，使用StorageClass管理pv和pvc在创建pod时不用手动指定子目录，会在存储服务器根目录/data/k8s内自动生成一个随机子目录

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-pvc
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nfs-pvc
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: test-pvc

经过测试，不管是手动创建一个pod，还是用deployment创建多个pod，都只能生成一个随机目录，也就是一对pvc和pv对应一个持久存储目录

原文地址：https://blog.51cto.com/dongdong/2431706

时间： 2024-10-30 00:42:03

使用nfs在k8s集群中实现持久化存储的相关文章

K8S集群中部署jenkins

本文介绍在k8s环境中进行jenkins server的部署和配置.Jenkins是一个开源的.功能强大的持续集成和持续构建工具,采用master和salve架构,我们通过将jenkins集成环境部署在k8s集群中,可以实现jenkins slave按需创建.动态的伸缩.同时也提供了在k8s环境中应用的持续部署解决方案. 一.准备docker镜像文件 1.编译jenkins server docker镜像,默认的jenkis镜像已包含jdk,版本为1.8.0_171 # cat dockerfi

k8s集群中的存储持久化概述

存储分类:直连式存储,集中式共享存储,分布式存储文件存储,块存储,对象存储DAS,NAS,SANDAS属于直连式存储,将存储设备通过SCSI接口或者光纤通道直接和主板连接,不能实现数据共享NAS和SAN属于集中式共享存储NAS使用NFS和CIFS(原来叫SMB,微软的)协议SAN分为FC SAN和IP SANIP SAN使用iSCSI技术NFS实现linux之间共享,smaba基于CIFS协议,实现linux和windows之间文件共享ceph属于分布式共享系统 k8s集群中支持的持久存储主要包

【K8S学习笔记】Part2：获取K8S集群中运行的所有容器镜像

本文将介绍如何使用kubectl列举K8S集群中运行的Pod内的容器镜像. 注意:本文针对K8S的版本号为v1.9,其他版本可能会有少许不同. 0x00 准备工作 需要有一个K8S集群,并且配置好了kubectl命令行工具来与集群通信.如果未准备好集群,那么你可以使用Minikube创建一个K8S集群,或者你也可以使用下面K8S环境二者之一: Katacoda Play with Kubernetes 如果需要查看K8S版本信息,可以输入指令kubectl version. 在本练习中,我们将使

同一k8s集群中多nginx ingress controller

同一k8s集群中多nginx ingress controller同一k8s集群中,若有多个项目(对应多个namespace)共用一个nginx ingress controller,因此任意注册到ingress的服务有变更都会导致controller配置重载,当更新频率越来越高时,此controller压力会越来越大,理想的解决方案就是每个namespace对应一个nginx ingress controller,各司其职. NGINX ingress controller提供了ingress

将 master 节点服务器从 k8s 集群中移除并重新加入

背景 1 台 master 加入集群后发现忘了修改主机名,而在 k8s 集群中修改节点主机名非常麻烦,不如将 master 退出集群改名并重新加入集群(前提是用的是高可用集群). 操作步骤 ssh 登录另外一台 master 节点将要改名的 master 节点移出集群. kubectl drain blog-k8s-n0 kubectl delete node blog-k8s-n0 登录已退出集群的 master 服务器重置 kubelet 配置并重新加入集群. kubeadm reset k

k8s集群中的EFK日志搜集系统

Kubernetes 集群本身不提供日志收集的解决方案,一般来说有主要的3种方案来做日志收集:1.在每个节点上运行一个 agent 来收集日志由于这种 agent 必须在每个节点上运行,所以直接使用 DaemonSet 控制器运行该应用程序即可这种方法也仅仅适用于收集输出到 stdout 和 stderr 的应用程序日志简单来说,本方式就是在每个node上各运行一个日志代理容器,对本节点/var/log和 /var/lib/docker/containers/两个目录下的日志进行采集2.在每个

k8s集群中的rbac权限管理

启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,1.6 版本以上的都默认开启了RBAC查看是否开启:$ cat /etc/kubernetes/manifests/kube-apiserver.yaml spec: containers: - command: - kube-apiserver - --advertise-address=192.168.1.243 - --allow-privileged

实操教程丨如何在K8S集群中部署Traefik Ingress Controller

注:本文使用的Traefik为1.x的版本 在生产环境中,我们常常需要控制来自互联网的外部进入集群中,而这恰巧是Ingress的职责. Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务.这与Ingress控制如何将外部流量路由到集群有异曲同工之妙.接下来,我们举一个实际的例子来更清楚的说明Ingress的概念. 首先,想象一下在你的Kubernetes集群中有若干个微服务(小型应用程序之间彼此通信).这些服务能够在集群内部被访问,但我们想让我们的用户从集群外部也

在k8s集群中安装prometheus

在早期的版本中 Kubernetes 提供了 heapster.influxDB.grafana 的组合来监控系统,现在更加流行的监控工具是 prometheus,prometheus 是 Google 内部监控报警系统的开源版本 Prometheus 相比于其他传统监控工具主要有以下几个特点:具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型有一个灵活的查询语言不依赖分布式存储,只和本地磁盘有关通过 HTTP 的服务拉取时间序列数据也支持推送的方式来添加时间序列数据还支持通过