kubernets存储

ConfigMap 创建的三种方式 1、使用目录创建

[root@master config]# ls /opt/k8s/config
game.properties  ui.properties
[root@master config]# cat game.properties 
enemies=aliens
lives=3
[root@master config]# cat ui.properties 
color.good=purple
color.bad=yellow
[root@master config]# kubectl create configmap game-config(cm名称) --from-file=../config/
#查看详细信息
[root@master config]# kubectl get cm
NAME          DATA   AGE
game-config   2      4m42s
[root@master config]# kubectl get cm -o yaml 或者  kubectl describe cm game-config

–from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容

2、指定单个文件创建

[root@master config]# kubectl create configmap game-config-2 --from-file=../config/game.properties
[root@master config]# kubectl  get cm
NAME            DATA   AGE
game-config     2      9m26s
game-config-2   1      15s

–from-file 这个参数可以使用多次，你可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的

3、命令行创建

[root@master config]# kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
[root@master config]# kubectl get cm
NAME             DATA   AGE
game-config      2      11m
game-config-2    1      2m47s
special-config   2      28s
[root@master config]# kubectl describe cm special-config
Name:         special-config
Namespace:    default
Labels:       
Annotations:  

Data
====
special.how:
----
very
special.type:
----
charm
Events:

利用 --from-literal 参数传递配置信息，该参数可以使用多次

pod中通过数据卷插件使用configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm
---
apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
    - name: test-container
      image: registry:5000/nginx:v1
      command: [ "/bin/sh", "-c","cat /etc/config/special.how" ]
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
          name: special-config
   restartPolicy: Never

在数据卷里面使用这个 ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容

configMap热更新

[root@master config]# kubectl edit configmap special-config

Secret 类型

Service Account ：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的
/run/secrets/kubernetes.io/serviceaccount 目录中Opaque ：base64编码格式的Secret，用来存储密码、密钥等kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息 kubernetes.io/dockerconfigjson

[root@master config]# kubectl create secret docker-registry myregistrykey --docker-server=registry.sudytech.com:35000 -- docker-username=admin --docker-password=admin --docker-email=DOCKER_EMAIL

在创建 Pod 的时候，通过 imagePullSecrets 来引用刚创建的 `myregistrykey`
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
    - name: foo
      image: registry.sudytech.com:35000/awangyang:v1
  imagePullSecrets:
    - name: myregistrykey

Volume 背景

Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所f以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes支持多种类型的卷，Pod 可以同时使用任意数量的卷

Pod被创建时，会默认创建Pause的底层容器，Pod中的其他所有容器共享Pause的网站栈与共享卷，Volume与Pause进行挂载，当容器重启时，并不影响Pause容器，所以Volume也不会收到影响，但是当Pod不复存在时，Pause容器也不复存在，所以Volume也不复存在

类型 emptyDir

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

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

apiVersion: v1
kind: Pod
metadata:
   name: test-pd
spec:
  containers:
     - name: test-container1
       image: myapp:v1    
       volumeMounts:
         - name: cache-volume
           mountPath: /cache
     - name: test-container2
       image: myapp:v2 
       volumeMounts:
         - name: cache-volume
           mountPath: /test 
  volumes:
      - name: cache-volume
        emptyDir: {}

运行上述yaml文件后，Pod中两个容器/test目录和/cache目录共享

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	给定的路径下必须存在块设备

apiVersion: v1
kind: Pod
metadata:
   name: test-pd
spec:
   containers:
      - image: k8s.gcr.io/test-webserver
        name: test-container
        volumeMounts:
           - name: test-volume
             mountPath: /test-pd             
   volumes:
      - name: test-volume
        hostPath:
        # directory location on host
        path: /data
        # this field is optional
        type: Directory

运行上述ymal文件，查看Pod运行在哪个node节点中,该node节点服务器/data目录与容器中/test-pd目录共享

PersistentVolume、PersistentVolumeClaim 概念

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

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

绑定

每个pod都有自己的请求模板，创建对应pvc,pvc通过storageClassName、accessModes参数与pv进行匹配，匹配成功后与之绑定。一旦 PV 和 PVC 绑定后， PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 Pod、PVC 跟PV 绑定是一对一的映射

访问模式（accessModes）

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

ReadOnlyMany——该卷可以被多个节点以只读模式挂载

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

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

RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany

回收策略

Retain（保留）——手动回收Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）
将被删除状态

卷可以处于以下的某种状态：Available（可用）——一块空闲资源还没有被任何声明绑定Bound（已绑定）——卷已经被声明绑定Released（已释放）——声明被删除，但是资源还未被集群重新声明Failed（失败）——该卷的自动回收失败演示说明创建nfs服务端、客户端

yum install -y nfs-common nfs-utils rpcbind
mkdir /nfsdata
chmod 666 /nfsdata
chown nfsnobody /nfsdata
cat /etc/exports
/nfsdata *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs

master与node节点创建客户端
yum -y install nfs-util rpcbind

部署pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
     storage: 1Gi
  accessModes:
    - ReadWriteonce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfsdata
    server: 10.66.66.10

创建服务使用pvc绑定

apiVersion: v1
kind: Service
metadata:
   name: nginx
   labels:
     app: nginx
spec:
   ports:
     - port: 80
       name: web
    clusterIP: None
    selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
   name: web
spec:
   selector:
     matchLabels:
        app: nginx
    serviceName: "nginx"
    replicas: 3
    template:
    metadata:
       labels:
         app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
          - containerPort: 80
            name: web
          volumeMounts:
          - name: www
            mountPath: /usr/share/nginx/html
    volumeClaimTemplates:
    - metadata:
        name: www
      spec:
         accessModes: [ "ReadWriteOnce" ]
         storageClassName: "nfs"
         resources:
          requests:
            storage: 1Gi

kubernets存储

Linux相关栏目本月热门文章