[系统运维]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:       <none>
Annotations:  <none>

Data
====
special.how:
----
very
special.type:
----
charm
Events:  <none>

利用 --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

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