8. 老板 不加薪，我用了 这篇 加了 3K

时间  2020-10-23
标签 html nginx web docker shell json api 服务器 微信 网络 栏目 HTML 繁體版
原文   原文链接

在K8S中，容器自己是非持久化的，当容器崩溃后，kubelet将以镜像的初始状态从新启动容器，可是此时以前容器的数据已经丢失，咱们该如何保护好容器的数据呢？html

在同一Pod中的容器每每须要共享一些数据，此时咱们又该如何实现呢？nginx

这个时候就须要存储来解决这两个问题。web

1、ConfigMap

undefined

ConfigMap功能在 Kubernetes1.2版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。 ConfigMap API给咱们提供了向容器中注入配置信息的机制， ConfigMap能够被用来保存单个属性，也能够用来保存整个配置文件或者 JSON二进制大对象。docker

1.1 ConfigMap 的建立

① 使用目录建立shell

[root@master configmap]
apple=8.0
orange=3.5
[root@master configmap]
beef=55.0
pork=28.0

[root@master configmap]
configmap/shop-config created

[root@master configmap]
NAME          DATA   AGE
shop-config   2      8s

[root@master configmap]
[root@master configmap]

② 使用文件建立json

[root@master configmap]
tea=3.0
coffee=4.0

[root@master configmap]
configmap/drink-config created

[root@master configmap]

③ 使用字面值建立api

使用文字值建立，利用 --from-literal参数传递配置信息，该参数可使用屡次，格式以下：服务器

[root@master configmap]
configmap/snacks-config created

[root@master configmap]

1.2 使用 ConfigMap

使用 ConfigMap有三种方式，一种是经过环境变量的方式，直接传递 pod，另外一种是经过在 pod的命令行下运行的方式，第三种是使用 volume的方式挂载入到 pod内。微信

① 使用 ConfigMap 来替代环境变量网络

[root@master configmap]
apiVersion: v1
kind: ConfigMap
metadata:
  name: animal-config
  namespace: default
data:
  cat: cute
  dog: lovely

[root@master configmap]
configmap/animal-config created

[root@master configmap]
apiVersion: v1
kind: Pod
metadata:
  name: use-configmap-pod
spec:
  containers:
    - name: test-container
      image: hub.hc.com/library/myapp:v1
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: animal-config-cat
          valueFrom:
            configMapKeyRef:
              name: animal-config
              key: cat
        - name: animal-config-coffee
          valueFrom:
            configMapKeyRef:
              name: animal-config
              key: dog
      envFrom:
        - configMapRef:
            name: snacks-config
  restartPolicy: Never

[root@master configmap]
pod/use-configmap-pod created

[root@master configmap]

② 用 ConfigMap 设置命令行参数

apiVersion: v1
kind: Pod
metadata:
  name: use--configmap-pod2
spec:
  containers:
    - name: test-container
      image: hub.hc.com/library/myapp:v1
      command: [ "/bin/sh", "-c", "echo $(animal-config-cat) $(animal-config-dog)" ]
      env:
        - name: animal-config-cat
          valueFrom:
            configMapKeyRef:
              name: animal-config
              key: cat
        - name: animal-config-dog
          valueFrom:
            configMapKeyRef:
              name: animal-config
              key: dog
  restartPolicy: Never

③ 经过数据卷插件使用 ConfigMap

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

apiVersion: v1
kind: Pod
metadata:
  name: use-configmap-pod3
spec:
  containers:
    - name: test-container
      image: hub.hc.com/library/myapp:v1
      command: [ "/bin/sh", "-c", "ls /etc/config" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: animal-config
  restartPolicy: Never

1.3 ConfigMap 热更新

[root@master configmap]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: hub.hc.com/library/myapp:v1
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: snacks-config

[root@master configmap]
deployment.extensions/my-nginx created
[root@master configmap]
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-bc7499bd8-hrgl9   1/1     Running   0          2s

[root@master configmap]
6.9

[root@master configmap]

[root@master configmap]
8.8

2、Secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不须要把这些敏感数据暴露到镜像或者 Pod Spec中。Secret 能够以 Volume 或者环境变量的方式使用

Secret有三种类型：

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

2.1 Service Account

[root@master ~]

ca.crt	namespace  token

2.2 Opaque

Opaque类型的数据是一个 map类型，要求 value是 base64编码格式：

[root@master ~]
YWRtaW4=
[root@master ~]
MWYyZDFlMmU2N2Rm

建立 Opaque类型的 secret:

[root@master secert]
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

[root@master secert]
secret/mysecret created
[root@master secert]
NAME                  TYPE                                  DATA   AGE
mysecret              Opaque                                2      93s

将 Secret 挂载到 Volume 中：

[root@master secert]
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: secret-test
  name: secret-test
spec:
  volumes:
  - name: secrets
    secret:
      secretName: mysecret
  containers:
  - image: hub.hc.com/library/myapp:v1
    name: db
    volumeMounts:
    - name: secrets
      mountPath: /etc/config

[root@master secert]
pod/secret-test created
[root@master secert]
/

/etc/config
1f2d1e2e67df
admin

将 Secret 导出到环境变量中：

[root@master secert]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: pod-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: pod-deployment
    spec:
      containers:
      - name: pod-1
        image: hub.hc.com/library/myapp:v1
        command: [ "/bin/sh", "-c", "env" ]
        ports:
        - containerPort: 80
        env:
        - name: TEST_USER
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
        - name: TEST_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password

[root@master secert]
deployment.extensions/pod-deployment created

2.3 kubernetes.io/dockerconfigjson

[root@master secert]
secret "myregistrykey" created

[root@master secert]
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
    - name: foo
      image: roc/awangyang:v1
  imagePullSecrets:
    - name: myregistrykey

undefined

3、Volume

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时， kubelet会重启它，可是容器中的文件将丢失，容器以干净的状态（镜像最初的状态）从新启动。其次，在 Pod中同时运行多个容器时，这些容器之间一般须要共享文件。 Kubernetes中的 Volume抽象就很好的解决了这些问题。

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

3.1 emptyDir

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

emptyDir 的用法有：

  • 暂存空间，例如用于基于磁盘的合并排序
  • 用做长时间计算崩溃恢复时的检查点
  • Web服务器容器提供数据时，保存内容管理器容器提取的文件
[root@master volume]
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: hub.hc.com/library/myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - image: busybox
    name: test-container2
    imagePullPolicy: IfNotPresent
    command: ['/bin/sh','-c','sleep 3600']
    volumeMounts:
    - mountPath: /test
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

[root@master volume]

[root@master volume]
'NAME                      READY   STATUS    RESTARTS   AGE
test-pd                   2/2     Running   0          8m32s

[root@master volume]
/
/cache
/cache
Wed Aug 12 07:43:08 UTC 2020

[root@master ~]
/
/test
Wed Aug 12 07:43:08 UTC 2020

3.2 hostPath

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

hostPath 的用途以下：

  • 运行须要访问 Docker内部的容器；使用 /var/lib/docker的 hostPath
  • 在容器中运行 cAdvisor；使用 /dev/cgroups的 hostPath

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

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

使用这种卷类型时请注意：

  • 因为每一个节点上的文件都不一样，具备相同配置（例如从 podTemplate建立的）的 pod在不一样节点上的行为可能会有所不一样
  • 当 Kubernetes按照计划添加资源感知调度时，将没法考虑 hostPath使用的资源
  • 在底层主机上建立的文件或目录只能由 root写入。您须要在特权容器中以 root身份运行进程，或修改主机上的文件权限以便写入 hostPath卷
[root@master volume]
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: hub.hc.com/library/myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:

      path: /data

      type: Directory

[root@master volume]
[root@master volume]
/
/test-pd

[root@worker1 data]

[root@worker2 data]
2020年 08月 12日 星期三 17:52:43 CST

4、PV-PVC

4.1 相关概念

① 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绑定是一对一的映射

4.2 PV说明

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

PV演示代码

apiVersion: v1
kind: PersistentVolumemeta
data:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

PV类型
PV类型以插件形式实现。 K8S目前支持如下插件类型：

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

  • ReadWriteOnce：该卷能够被单个节点以读/写模式挂载
  • ReadOnlyMany：该卷能够被多个节点以只读模式挂载
  • ReadWriteMany：该卷能够被多个节点以读/写模式挂载

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

  • RWO： ReadWriteOnce
  • ROX： ReadOnlyMany
  • RWX： ReadWriteMany


回收策略

  • 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的名称

4.3 持久化演示说明 - NFS

① 安装 NFS 服务器

[root@master ~]
[root@master ~]
[root@master ~]
/nfs *(rw,no_root_squash,no_all_squash,sync)
[root@master ~]

[root@worker1 ~]
[root@worker1 ~]
Export list for 192.168.182.100:
/nfs *
[root@worker1 ~]
[root@worker1 /]

② 部署 PV

[root@master pv]
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfs
    server: 192.168.182.100
[root@master pv]
persistentvolume/nfs-pv1 created
[root@master pv]
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv1   1Gi        RWO            Retain           Available           nfs                     5s

③ 建立服务并使用 PVC

[root@master /]
[root@master /]
[root@master /]
/nfs *(rw,no_root_squash,no_all_squash,sync)
/nfs2 *(rw,no_root_squash,no_all_squash,sync)
/nfs3 *(rw,no_root_squash,no_all_squash,sync)

[root@master pv]

[root@master pv]
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfs
    server: 192.168.182.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv2
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nfs2
    server: 192.168.182.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv3
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  nfs:
    path: /nfs3
    server: 192.168.182.100
[root@master pv]

NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv1   1Gi        RWO            Retain           Available           nfs                     23s
nfs-pv2   5Gi        ROX            Retain           Available           nfs                     23s
nfs-pv3   1Gi        RWX            Retain           Available           slow                     23s

[root@master pv]
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: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: hub.hc.com/library/myapp:v1
        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

[root@master pv]
NAME                      READY   STATUS    RESTARTS   AGE
web-0                     1/1     Running   0          7s
web-1                     0/1     Pending   0          5s

[root@master pv]
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM               STORAGECLASS   REASON   AGE
nfs-pv1   1Gi        RWO            Retain           Bound       default/www-web-0   nfs                     4m40s
nfs-pv2   5Gi        ROX            Retain           Available                       nfs                     4m40s
nfs-pv3   1Gi        RWO            Retain           Bound       default/www-web-1   nfs                     4m40s
[root@master pv]
NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
web-0                     1/1     Running   0          15m   10.244.2.84   worker2   <none>           <none>
web-1                     1/1     Running   0          15m   10.244.1.58   worker1   <none>           <none>

[root@master pv]
Hello PV
[root@master pv]
Hello PV
[root@master pv]
pod "web-0" deleted
[root@master pv]
NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
web-0                     1/1     Running   0          3s    10.244.2.85   worker2   <none>           <none>
web-1                     1/1     Running   0          18m   10.244.1.58   worker1   <none>           <none>

[root@master pv]
Hello PV

4.4 关于 StatefulSet

  • 匹配 Pod name ( 网络标识 ) 的模式为： $(statefulset&#x540D;&#x79F0;)-$(&#x5E8F;&#x53F7;)，好比上面的示例： web-0、 web-1
  • StatefulSet为每一个 Pod副本建立了一个 DNS域名，这个域名的格式为： $(podname).(headless servername)，也就意味着服务间是经过 Pod域名来通讯而非 Pod IP，由于当 Pod所在 Node发生故障时， Pod会被飘移到其它 Node上， Pod IP会发生变化，可是 Pod域名不会有变化
  • StatefulSet使用 Headless服务来控制 Pod的域名，这个域名的 FQDN为： $(servicename).$(namespace).svc.cluster.local，其中， cluster.local指的是集群的域名
  • 根据 volumeClaimTemplates，为每一个 Pod建立一个 pvc， pvc的命名规则匹配模式： (volumeClaimTemplates.name)-(pod_name)，好比上面的 volumeMounts.name=www， Podname=web-[0-2]，所以建立出来的 PVC是 www-web-0、 www-web-1
  • 删除 Pod不会删除其 pvc，手动删除 pvc将自动释放 pv

Statefulset 的启停顺序：

  • 有序部署：部署 StatefulSet时，若是有多个 Pod副本，它们会被顺序地建立（从 0到 N-1）而且，在下一个 Pod运行以前全部以前的 Pod必须都是 Running和 Ready状态
  • 有序删除：当 Pod被删除时，它们被终止的顺序是从 N-1到 0
  • 有序扩展：当对 Pod执行扩展操做时，与部署同样，它前面的 Pod必须都处于 Running和 Ready状态

StatefulSet 使用场景：

  • 稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于 PVC来实现
  • 稳定的网络标识符，即 Pod从新调度后其 PodName和 HostName不变
  • 有序部署，有序扩展，基于 init containers来实现
  • 有序收缩

微信搜一搜 : 全栈小刘 ，获取文章 pdf 版本

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程