k8s学习-存储

时间：2020-05-31 21:39:55 阅读：92 评论：0 收藏：0 [点我收藏+]

标签：control Kubernete 情况客户不重启 name node 永久 try

4.6、存储

4.6.1、ConfigMap

创建方式

文件夹/文件创建

mkdir dir
cd dir
cat > c1.properties <<EOF
c1.name=c1
EOF
cat > c2.properties <<EOF
c2.name=c2
EOF

cd ..
cat > c3.properties <<EOF
c3.name=c3
EOF

# configmap 简写为 cm
# 根据目录创建
kubectl create configmap cm-c1 --from-file=dir
# 根据文件创建
kubectl create configmap cm-c2 --from-file=c3.properties

# 查看
[root@k8s-master configmap]# kubectl get cm
NAME    DATA   AGE
cm-c1   2      12s
cm-c2   1      7s

# 查看内容
[root@k8s-master configmap]# kubectl get cm cm-c2 -o yaml
apiVersion: v1
data:
  c3.properties: |
    c3.name=c3
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-08T02:55:45Z"
  name: cm-c2
  namespace: default
  resourceVersion: "280079"
  selfLink: /api/v1/namespaces/default/configmaps/cm-c2
  uid: d35bfd4e-42bc-491f-b30a-488633d36653

字面量创建

# 使用 --from-literal=KEY=VALUE 
kubectl create cm cm-literal --from-literal=lt.name=bart --from-literal=lt.age=16
# 查看
[root@k8s-master configmap]# kubectl get cm cm-literal -o yaml
apiVersion: v1
data:
  lt.age: "16"
  lt.name: bart
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-08T02:59:41Z"
  name: cm-literal
  namespace: default
  resourceVersion: "280454"
  selfLink: /api/v1/namespaces/default/configmaps/cm-literal
  uid: 5bd18816-bfd9-4f5d-abd8-5fc20d4ead92

配置文件创建

vim cm.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-special-config
data:
  special.how: very
  special.type: charm
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-env-config
data:
  log_level: INFO

kubectl create -f cm.yml
[root@k8s-master configmap]# kubectl get cm
NAME                DATA   AGE
cm-c1               2      46m
cm-c2               1      45m
cm-env-config       1      13s # 刚创建的
cm-literal          2      41m
cm-special-config   2      13s # 刚创建的

Pod中使用ConfigMap

env使用

vim env.yml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    command: ["/bin/sh", "-c", "env; echo -e $(SPECIAL_HOW)"] # 打印env和指定key
    env: # 容器添加环境变量
    - name: SPECIAL_HOW
      valueFrom: # 引用 configmap 的值
        configMapKeyRef:
          name: cm-special-config # configmap 的 name
          key: special.how # configmap 中的 key
    envFrom: # 环境变量导入
    - configMapRef:
        name: cm-env-config # configmap 的 name
  restartPolicy: Never # 不重启

kubectl create -f env.yaml
kubectl get pod
# 查看日志 
[root@k8s-master configmap]# kubectl logs cm-test-pod
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=cm-test-pod
HOME=/root
PKG_RELEASE=1~buster
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.17.9
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
NJS_VERSION=0.3.9
KUBERNETES_PORT_443_TCP_PROTO=tcp
log_level=INFO # fromEnv 中的值
SPECIAL_HOW=very
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
nvery # 打印的 env的value

挂载使用

vim volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod2
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    command: ["/bin/sh", "-c", "cat /etc/config/special.how"] # 文件名就是key，内容就是value
    volumeMounts:
    - name: config-volume # 挂载位置绑定挂在卷名字
      mountPath: /etc/config
  volumes:
  - name: config-volume # 定义一个挂载卷为configmap的内容
    configMap: 
      name: cm-special-config
  restartPolicy: Never # 不重启

kubectl create -f volume.yml
kubectl get pod
# 查看日志 
[root@k8s-master configmap]# kubectl logs cm-test-pod2
very

热更新

vim hot.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cm-test-pod3
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: cm-test-pod3
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        volumeMounts:
        - name: config-volume # 挂载位置绑定挂在卷名字
          mountPath: /etc/config
      volumes:
      - name: config-volume # 定义一个挂载卷为configmap的内容
        configMap: 
          name: cm-special-config
      restartPolicy: Always # 不支持Never

kubectl create -f hot.yml
[root@k8s-master configmap]# kubectl get pod
NAME                            READY   STATUS      RESTARTS   AGE
cm-test-pod                     0/1     Completed   0          36m
cm-test-pod2                    0/1     Completed   0          22m
cm-test-pod3-75fbd58f94-v7rph   1/1     Running     0          5s
# 查看内容
kubectl exec cm-test-pod3-75fbd58f94-v7rph -it -- cat /etc/config/special.type

# 修改 cm-special-config 的值 
kubectl edit cm cm-special-config
# 再次查看 （大概10秒钟左右值会自动改变）
kubectl exec cm-test-pod3 -it -- cat /etc/config/special.type

# 修改pod内容强制触发滚动更新，适用于Env环境变量引用的configMap的情况
kubectl patch deployment cm-test-pod3 --patch ‘{"spec": {"template": {"metadata": {"annotations": {"version/config": "20200309"}}}}}‘

[root@k8s-master configmap]# kubectl get pod
NAME                          READY   STATUS      RESTARTS   AGE
cm-test-pod                   0/1     Completed   0          38m
cm-test-pod2                  0/1     Completed   0          24m
cm-test-pod3-59688486-xd5zs   1/1     Running     0          23s # pod 已经重启了

主意：！！！

使用ConfigMap挂载的Env不会同步更新（除非Pod重新加载）
使用ConfigMap挂载的Volume会更新（大概10秒）

4.6.2、Secret

Service Account

用来访问Kubernetes API，由Kubernetes自动创建，并会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount

# 假如有个pod为nginx
kubectl exec nignx -it -- ls /run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token

OpqueSecret

使用base64来加密一些配置项

echo "admin" | base64 # YWRtaW4K
echo "YWRtaW4K" | base64 -d # admin

echo "123456" | base64 # MTIzNDU2Cg==
echo "MTIzNDU2Cg==" | base64 -d # 123456

vim secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  name: YWRtaW4K
  password: MTIzNDU2Cg==

kubectl create -f secret.yml
# 查看内容
kubectl get secret mysecret -o yaml

vim pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
  - name: nginx
    image: habor-repo.com/library/nginx:v1
    env: # 容器添加环境变量
    - name: SEC_USER_NAME
      valueFrom: # 引用 secret 的值
        secretKeyRef:
          name: mysecret # mysecret 的 name
          key: name # mysecret 中的 key
    - name: SEC_USER_PASSWORD
      valueFrom: 
        secretKeyRef:
          name: mysecret 
          key: password 
    volumeMounts:
    - name: secret-volume # 挂载位置绑定挂在卷名字
      mountPath: /etc/config
  volumes:
  - name: secret-volume # 定义一个挂载卷为configmap的内容
    secret: 
      secretName: mysecret
  restartPolicy: Never # 不重启

kubectl create -f pod.yml
kubectl get pod
# 查看挂载文件
[root@k8s-master secret]# kubectl exec secret-test-pod -it -- ls /etc/config
name  password
# 查看环境变量（进入容器内部查看）
[root@k8s-master secret]# kubectl exec secret-test-pod -it -- /bin/bash
root@secret-test-pod:/# echo $SEC_USER_NAME $SEC_USER_PASSWORD
admin 123456

kubernetes.io/dockerconfigjson

使用kubectl创建docker registry认证的secret

kubectl create secret docker-registry <registrykey名字> --docker-server=<docker仓库域名> --docker-username=<仓库登录名> --docker-password=<登录密码> --docker-emai=<邮箱（随便给）>

# 使用 docker login登录也可以
docker login <docker仓库域名>

在创建Pod的时候指定imagePullSecrets参数

apiVersion: v1
kind: Pod
metadata:  
name: foo
spec:  
  containers:    
  - name: foo      
    image: roc/awangyang:v1  
  imagePullSecrets:     
  - name: myregistrykey # 对应上面创建的 <registrykey名字>

4.6.3、Volume

emptyDir

当 Pod 被分配给节点时，首先创建emptyDir卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir中的数据将被永久删除

emptyDir的用法有：

暂存空间，例如用于基于磁盘的合并排序
用作长时间计算崩溃恢复时的检查点
Web服务器容器提供数据时，保存内容管理器容器提取的文件

vim emptydir.yml

apiVersion: v1
kind: Pod
metadata:  
  name: test-pd
spec: 
  containers:
  - image: habor-repo.com/library/nginx:v1
    name: nginx
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  - image: habor-repo.com/library/busybox:v1
    command: ["/bin/sh", "-c", "sleep 3600s;"]
    name: busybox    
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  volumes:  
  - name: cache-volume 
    emptyDir: {}

kubectl create -f emptydir.yml
kubectl get pod 
kubectl describe pod test-pd
kubectl exec test-pd -c nginx -it -- /bin/bash
# date > /cache/a.txt 
kubectl exec test-pd -c nginx -it -- cat /cache/a.txt
# 查看另外一个 
kubectl exec test-pd -c busybox -it -- cat /cache/a.txt

hostPath

hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中

hostPath的用途如下：运行需要访问 Docker 内部的容器；使用/var/lib/docker的hostPath
在容器中运行 cAdvisor；使用/dev/cgroups的hostPath允许 pod 指定给定的 hostPath 是否应该在 pod
运行之前存在，是否应该创建，以及它应该以什么形式存在

除了所需的path属性之外，用户还可以为hostPath卷指定type

值	行为
	空字符串（默认）用于向后兼容，这意味着在挂载 hostPath 卷之前不会执行任何检查。
DirectoryOrCreate	如果在给定的路径上没有任何东西存在，那么将根据需要在那里创建一个空目录，权限设置为 0755，与 Kubelet 具有相同的组和所有权。
Directory	给定的路径下必须存在目录
FileOrCreate	如果在给定的路径上没有任何东西存在，那么会根据需要创建一个空文件，权限设置为 0644，与 Kubelet 具有相同的组和所有权。
File	给定的路径下必须存在文件
Socket	给定的路径下必须存在 UNIX 套接字
CharDevice	给定的路径下必须存在字符设备
BlockDevice	给定的路径下必须存在块设备

使用这种卷类型是请注意，因为：

由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不同
当 Kubernetes 按照计划添加资源感知调度时，将无法考虑hostPath使用的资源
在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入hostPath卷

vim hostpath.yml

apiVersion: v1
kind: Pod
metadata:  
  name: test-pd2
spec: 
  containers:
  - image: habor-repo.com/library/nginx:v1
    name: nginx
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  - image: habor-repo.com/library/busybox:v1
    command: ["/bin/sh", "-c", "sleep 3600s;"]
    name: busybox    
    volumeMounts:    
    - mountPath: /cache      
      name: cache-volume  
  volumes:  
  - name: cache-volume 
    hostPath: 
      path: /data # 本地路径
      type: Directory # 目录

# 在所有节点上创建 /data 目录
mkdir /data
kubectl create -f hostpath.yml
kubectl get pod -o wide 
# 假设在 k8s-node2 节点上
# date >/data/a.txt

kubectl exec test-pd2 -c nginx -it -- cat /cache/a.txt
# 查看另外一个 
kubectl exec test-pd2 -c busybox -it -- cat /cache/a.txt

# 发现有内容

4.6.4、PV&PVC

概念

PersistentVolume（PV）

是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统

PersistentVolumeClaim（PVC）

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）

静态 pv：
- 集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费
动态：
- 当管理员创建的静态 PV 都不匹配用户的PersistentVolumeClaim时，集群可能会尝试动态地为 PVC 创建卷。此配置基于StorageClasses：PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效地禁用其动态配置
- 要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的DefaultStorageClass[准入控制器]。例如，通过确保DefaultStorageClass位于 API server 组件的--admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作
绑定：
- master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim绑定是排他性的，不管它们是如何绑定的。 PVC 跟PV 绑定是一对一的映射

持久化卷声明的保护

PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用

PersistentVolume类型以插件形式实现。Kubernetes 目前支持以下插件类型：

GCEPersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC (Fibre Channel)
FlexVolume、Flocker、NFS、iSCSI、RBD (Ceph Block Device)、CephFS
Cinder (OpenStack block storage)、Glusterfs、VsphereVolume、Quobyte Volumes
HostPath、 VMware Photon、Portworx Volumes、ScaleIO Volumes、StorageOS

PV 访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式：

ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载

在命令行中，访问模式缩写为：

RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany

Volume 插件	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStoreAWSElasticBlockStore	?	-	-
AzureFile	?	?	?
AzureDisk	?	-	-
CephFS	?	?	?
Cinder	?	-	-
FC	?	?	-
FlexVolume	?	?	-
Flocker	?	-	-
GCEPersistentDisk	?	?	-
Glusterfs	?	?	?
HostPath	?	-	-
iSCSI	?	?	-
PhotonPersistentDisk	?	-	-
Quobyte	?	?	?
NFS	?	?	?
RBD	?	?	-
VsphereVolume	?	-	- （pod 并列时有效）
PortworxVolume	?	-	?
ScaleIO	?	?	-
StorageOS	?	-	-

回收策略

Retain（保留）——手动回收
Recycle（回收）——基本擦除（rm -rf /thevolume/*）
Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除

当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略

状态

卷可以处于以下的某种状态：

Available（可用）：一块空闲资源还没有被任何声明绑定
Bound（已绑定）：卷已经被声明绑定
Released（已释放）：声明被删除，但是资源还未被集群重新声明
Failed（失败）：该卷的自动回收失败

命令行会显示绑定到 PV 的 PVC 的名称

例子

安装nfs

1）NFS 服务主要进程：

rpc.nfsd：最主要的 NFS 进程，管理客户端是否可登录
rpc.mountd：挂载和卸载 NFS 文件系统，包括权限管理
rpc.lockd：非必要，管理文件锁，避免同时写出错
rpc.statd：非必要，检查文件一致性，可修复文件

2）关键工具

主要配置文件：/etc/exports
NFS 文件系统维护命令：/usr/bin/exportfs
共享资源的日志文件：/var/lib/nfs/*tab
客户端查询共享资源命令：/usr/sbin/showmount
端口配置：/etc/sysconfig/nfs

3）NFS 服务端配置

在 NFS 服务器端的主要配置文件为 /etc/exports 时，通过此配置文件可以设置共享文件目录。每条配置记录由 NFS 共享目录、NFS 客户端地址和参数这 3 部分组成，格式如下：

[NFS 共享目录] [NFS 客户端地址 1 (参数 1, 参数 2, 参数 3……)] [客户端地址 2 (参数 1, 参数 2, 参数 3……)]

NFS 共享目录：服务器上共享出去的文件目录
NFS 客户端地址：允许其访问的 NFS 服务器的客户端地址，可以是客户端 IP 地址，也可以是一个网段 (192.168.141.0/24)
访问参数：括号中逗号分隔项，主要是一些权限选项

3.1）访问权限参数：

ro：客户端对于共享文件目录为只读权限。默认
rw：客户端对于共享文件目录具有读写权限

3.2）用户映射参数

root_squash：使客户端使用 root 账户访冋时，服务器映射为服务器本地的匿名账号
no_root_squash：客户端连接服务端时如果使用的是 root，那么也拥有对服务端分享的目录的 root 权限
all_squash：将所有客户端用户请求映射到匿名用户或用户组（nfsnobody)
no_all_squash：与上相反。默认
anonuid=xxx：将远程访问的所有用户都映射为匿名用户，并指定该用户为本地用户(UID=xxx)
anongid=xxx：将远程访问的所有用户组都映射为匿名用户组账户，并指定该匿名用户组账户为本地用户组账户(GUI=xxx)

3.3）其它配置参数

sync：同步写操作，数据写入存储设备后返回成功信息。默认
async：异步写提作，数据在未完全写入存储设备前就返回成功信息，实际还在内存
wdelay：延迟写入选项，将多个写提请求合并后写入硬盘，减少 I/O 次数， NFS 非正常关闭数据可能丢失。默认
no_wdelay：与上相反，不与 async 同时生效，如果 NFS 服务器主要收到小且不相关的请求，该选项实际会降低性能
subtree：若输出目录是一个子目录，则 NFS 服务器将检查其父目录的权限。默认
no_subtree：即使输出目录是一个子目录， NFS 服务器也不检查其父目录的权限，这样可以提高效率
secure：限制客户端只能从小于 1024 的 TCP/IP 端口连接 NFS 服务器。默认
insecure：允许客户端从大于 1024 的 TCP/IP 端口连接服务器

4）安装：

#创建一个目录作为共享文件目录
mkdir -p /usr/local/kubernetes/volumes

#给目录增加读写权限
chmod a+rw /usr/local/kubernetes/volumes

#**************** 安装 NFS 服务端 *******************
rpm -qa nfs-utils rpcbind
yum install -y nfs-utils rpcbind
systemctl start rpcbind #启动rpc服务 
systemctl status rpcbind #查看rpc服务状态 
systemctl start nfs #启动nfs服务 
systemctl status nfs #查看nfs服务状态 
# 注意：必须要先启动rpc服务，然后再启动NFS服务，如果先启动NFS服务，启动服务时会失败
# 检查开机是否自启动
# 1）. chkconfig 配置开机自启动
chkconfig nfs on 
chkconfig rpcbind on 
chkconfig --list nfs 
#nfs  0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭 
chkconfig --list rpcbind 
#rpcbind 0:关闭  1:关闭  2:启用  3:启用  4:启用  5:启用  6:关闭 
# 2）. /etc/rc.local 配置开机自启动
vim /etc/rc.local # 添加下面两行
systemctl start rpcbind
systemctl start nfs

#**************** 安装 NFS 客户端 *******************
# 安装客户端，实际上和服务端一样的
rpm -qa nfs-utils rpcbind
yum install -y nfs-utils rpcbind
systemctl start rpcbind #启动rpc服务 
systemctl status rpcbind #查看rpc服务状态 
systemctl start nfs #启动nfs服务 
systemctl status nfs #查看nfs服务状态

#**************** 分享目录 *******************
mkdir -p /usr/local/kubernetes/volumes
vi /etc/exports
/usr/local/kubernetes/volumes *(rw,sync,no_subtree_check)
# 说明：
# /usr/local/kubernetes/volumes：作为服务目录向客户端开放
# *：表示任何 IP 都可以访问
# rw：读写权限
# sync：同步权限
# no_subtree_check：表示如果输出目录是一个子目录，NFS 服务器不检查其父目录的权限 /usr/local/kubernetes/volumes *(rw,sync,no_subtree_check)
# 重启服务，使配置生效：
systemctl restart nfs

#**************** 客户端挂载分享目录 *******************
# 创建挂载目录
mkdir -p /usr/local/kubernetes/volumes-mount
# 将服务端的目录挂载到本地
mount 192.168.0.130:/usr/local/kubernetes/volumes /usr/local/kubernetes/volumes-mount
#使用 df 查看挂载
# 取消挂载
umount /usr/local/kubernetes/volumes-mount

测试

创建PV

vim pv.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-test
spec:
  # 设置容量
  capacity:
    storage: 1Gi
  # 访问模式
  accessModes:
    # 该卷能够以读写模式被多个节点同时加载
    - ReadWriteMany
  # 回收策略，这里是基础擦除 `rm-rf/thevolume/*`
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    # NFS 服务端配置的路径
    path: "/usr/local/kubernetes/volumes"
    # NFS 服务端地址
    server: 192.168.0.130
    readOnly: false

# 部署
kubectl create -f pv.yml

# 查看
[root@k8s-master pv]# kubectl get pv
NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv-test   1Gi        RWX            Recycle          Available           nfs                     2s
# 删除
kubectl delete pv --all

# 释放资源，删除对应的claimRef保存退出即可
kubectl edit pv nfs-pv-test

创建服务和PVC

1）使用spec.template.volumeClaimTemplates定义pvc

vim pvc.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-pvc-nginx
  labels:
    app: svc-pvc-nginx
spec:
  selector:
    app: nginx
  ports:
  - name: web
    port: 8090
    targetPort: 80
  clusterIP: None # headless
---
apiVersion: apps/v1
kind: StatefulSet
metadata:  
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: svc-pvc-nginx
  replicas: 1 # 为什么给1因为上面创建了一个pv，但是pvc和是一一对应的关系，如果多了就会出问题
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      #必须和要使用的pv的accessModes一致，根据accessModes和storageClassName去请求
      accessModes: ["ReadWriteMany"] 
      storageClassName: nfs
      resources:
        requests: # 请求使用资源
          #Ki、Mi、Gi、Ti、Pi、Ei(International System of units)
          #http://physics.nist.gov/cuu/Units/binary.html
          storage: 500Mi

kubectl apply -f pvc.yml
kubectl get statefulset
kubectl get pvc
kubectl get pod

# 测试
# 进入 nfs 服务端的分享目录
cd /usr/local/kubernetes/volumes
date >index.html

# 请求测试
kubectl get pod -o wide
[root@k8s-master pv]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          33s   10.244.2.155   k8s-node2   <none>           <none>
[root@k8s-master pv]# curl 10.244.2.155
2020年 03月 08日 星期日 19:31:19 CST

# 删除
kubectl delete statefulset --all
kubectl delete pvc --all
kubectl delete pod --all

2）使用PersistentVolume定义pvc

vim pvc2.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-pvc-nginx
  labels:
    app: svc-pvc-nginx
spec:
  selector:
    app: nginx
  ports:
  - name: web
    port: 8090
    targetPort: 80
  clusterIP: None # headless
---
apiVersion: apps/v1
kind: StatefulSet
metadata:  
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: svc-pvc-nginx
  replicas: 1 # 为什么给1因为上面创建了一个pv，但是pvc和是一一对应的关系，如果多了就会出问题
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: habor-repo.com/library/nginx:v1
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: mypd
          mountPath: /usr/share/nginx/html
      volumes:
      - name: mypd
        persistentVolumeClaim:
          claimName: www
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: www
spec:
  #必须和要使用的pv的accessModes一致，根据accessModes和storageClassName去请求
  accessModes: ["ReadWriteMany"] 
  storageClassName: nfs
  resources:
    requests:
      storage: 100Mi

kubectl apply -f pvc2.yml
kubectl get statefulset
kubectl get pvc
kubectl get pod

# 测试
# 进入 nfs 服务端的分享目录
cd /usr/local/kubernetes/volumes
date >>index.html

# 请求测试
kubectl get pod -o wide
[root@k8s-master pv]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          33s   10.244.2.155   k8s-node2   <none>           <none>
[root@k8s-master pv]# curl 10.244.2.155
2020年 03月 08日 星期日 19:31:19 CST
2020年 03月 08日 星期日 20:00:38 CST

# 删除
kubectl delete statefulset --all
kubectl delete pvc --all
kubectl delete pod --all

k8s学习-存储

标签：control Kubernete 情况客户不重启 name node 永久 try

原文地址：https://www.cnblogs.com/bartggg/p/13021377.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行