k8s_day05_01

k8s_day05_01

回顾

1. 存储卷作用范围：隶属于Pod，而非容器； pause容器支撑

2. kubelet为了支持存储卷，内建了很多存储服务的客户端：

   • 临时存储：emptyDir
   • 主机级别的存储：hostPath
   • 网络级别的存储：具有持久能力的存储；
     • 云存储：awsEBS、…
     • NAS(network attached storage)：NFS、…
     • SAN(Storage Area Network)：FC，iSCSI, …
       SDS(Software Defined Storage): Ceph（rbd, cephfs）、…
     • pvc：
       pod调用pvc 插件的过程 Pod(pvc plugin) -> PVC(和pod同一名称空间) -> PV(全局级别)

   这些都是k8s In-Tree 存储插件

3. pv 、pvc 的作用

   PV、PVC：将存储消费，存储创建的职能分离开来

   • PV：

     ​ 由管理员定义的，将真正的存储设备上的一段存储空间抽象成的k8s的对象； 集群级别；NFS exported 目录；

   • PVC：

     ​ 由用户定义出存储消费需求，而后根据需求条件与现有各PV进行匹配检测，找出一个最佳的使用。名称空间级别，Pod只能调用与自己在同一名称空间中的PVC；

StorageClass

是什么：

​ 模板, 简称SC；PV和PVC都可属于某个特定的SC；

作用：

1. 模拟为名称空间：
   一个PVC只能够在自己所处的SC内找PV；或者，一个不属于任何SC的PVC只能够在不属于任何SC的PV中进行筛选；

2. 创建PV的模板：可以将某个存储服务与SC关联起来，并且将该存储服务的管理接口提供给SC，从而让SC能够在存储服务上CRUD（Create、Read、Update和Delete）存储单元；

   ​ 因而，在同一个SC上声明PVC时，若无现存可匹配的PV，则SC能够调用管理接口直接创建出一个符合PVC声明的需求的PV来。这种PV的提供机制，就称为Dynamic Provision。 （动态供给、预配）

注意：

​ nfs 是不支持动态预配机制的，因为没有一个很好的管理接口输出给sc 让sc 使用。ceph 可以但是

​ ceph中的rbd支持动态预配，但kubeadm部署的k8s集群，却不支持该功能，原因在于kube-controller-manager镜像内部未内置ceph客户端工具。

. 因为pv、pvc的功能需要借助控制器来完成 pv contoller、pvc Contoller , 而pv contoller、pvc Contoller 又是位于Controller manger 当中，但是kubeadm 安装k8s 时， Controller manger 被运行为一个静态pod. 容器的文件系统 不仅与其他容器文件系统隔离，而且还与主机文件系统。 任何存储组件访问存储空间 ，得先有客户端。很遗憾 ，这个Controller manger pod 没有内置ceph客户端.

有两种解决方式 ，一种是二进制安装，Controller manger 以二进制程序的方式运行在宿主机，直接在宿主机安装ceph 客户端就行。第二种对Controller manger 镜像重新构建

除非对控制器镜像重新封装ceph客户端的功能 ,缺点就是每次k8s系统版本升级时，自己也要更新镜像

ARG KUBE_VERSION="v1.19.4"

FROM registry.aliyuncs.com/google_containers/kube-controller-manager:${KUBE_VERSION}

RUN apt update && apt install -y wget  gnupg lsb-release

ARG CEPH_VERSION="octopus"
RUN wget -q -O - https://mirrors.aliyun.com/ceph/keys/release.asc | apt-key add - && \
   echo deb https://mirrors.aliyun.com/ceph/debian-${CEPH_VERSION}/ $(lsb_release -sc) main > /etc/apt/sources.list.d/ceph.list && \
   apt update && \
   apt install -y ceph-common ceph-fuse 

RUN rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*

sc的资源格式

​ StorageClass资源的期望状态直接与apiVersion、kind和metadata定义于同一级别而无须嵌套于spec字段中，它支持使用的字段包括如下几个：

• allowVolumeExpansion<boolean>：

  ​ 是否支持存储卷空间扩展功能； 有些空间是支持压缩扩展的比如lvm , 具体取决于底层的存储空间

• allowedTopologies <[]Object>：

  ​ 定义可以动态配置存储卷的节点拓扑，仅启用了卷调度功能的服务器才会用到该字段；每个卷插件都有自己支持的拓扑规范，空的拓扑选择器表示无拓扑限制；

• provisioner <string>：

  ​ 必选字段，用于指定存储服务方（provisioner，或称为预备器），存储类要依赖该字段值来判定要使用的存储插件以便适配到目标存储系统；Kubernetes内建支持许多的Provisioner，它们的名字都以kubernetes.io/为前缀，例如kubernetes.io/glusterfs等；

• parameters <map[string]string>：

  ​ 定义连接至指定的Provisioner类别下的某特定存储时需要使用的各相关参数；不同Provisioner的可用的参数各不相同；

• reclaimPolicy <string>：

  ​ 由当前存储类动态创建的PV资源的默认回收策略，可用值为Delete（默认）和Retain两个；但那些静态PV的回收策略则取决于它们自身的定义；

• volumeBindingMode <string>：

  ​ 定义如何为PVC完成预配和绑定，默认值

• VolumeBindingImmediate；

  ​ 该字段仅在启用了存储卷调度功能时才能生效；

• mountOptions <[]string>：

  ​ 由当前类动态创建的PV资源的默认挂载选项列表。

eg

如果nfs 想使用动态预配的存储卷 ，nfs 可以使用第三方的nfs provisioner。

Out-of-Tree 类型的存储： Longhorn

由管理员通过flexVolume或CSI接入的第三方存储卷类型； （flexVolume 已逐渐弃用）

​ Rancher 是k8s的发行版本之一，openshift 是红帽的发行版， Rancher 现在被SUSE收购， Rancher 牵头下开发了 一个存储服务 Longhorn ，是云原生的 ，借助磁盘本地节点具有冗余机制的高可用服务，第三方的存储服务只能借助csi 接口完成

Longhorn 能在整个k8s 节点上 将pod 的相关数据 ，存储于节点本地磁盘之上的一种解决方案。并不依赖于像nfs ceph外部存储系统。 nfs 作为外部存储空间，具有单点失败的可能性。Longhorn 是一种轻量级 借助节点的各个本地磁盘 作为存储服务 。

​ 同时对于一个pod 来说 ，当我们需要用到存储系统的时候， 它借助csi 对接到Longhorn 一个叫Engine的地方 ， 每个pod都有一个自己独立使用的Engine , Engine 可以理解为伴随着pod 运行的另外一个pod ,它与我们pod 是一 一对应的。 ENgine 用来 将它所对应的pod 中的数据 ，以指定副本的数量【比如一个pod 数据要存2个副本 engine 就会管理2个副本进程 replica 每个replica 会选择一个节点，找这个节点上的某一个磁盘存储空间】 ，将数据存于对应的磁盘之上 。

Longhorn 必须以csi 的方式接入到k8s系统中， 默认不能被kubelet 所支持，

Longhorn 的优点

• 高可用

• 简单的 快照 和恢复

• 跨集群的灾难恢复

• 已经从cncf 毕业了 ，生产初步可用

longhorn-manager  是longhorn 的核心控制主键，有3个副本， 需要选举，所以至少三个节点
longhorn-ui  web 访问入口

Longhorn 关于 StorageClass 部分的定义

---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "2880"
  fromBackup: ""
#  diskSelector: "ssd,fast"
#  nodeSelector: "storage,fast"
#  recurringJobs: '[{"name":"snap", "task":"snapshot", "cron":"*/1 * * * *", "retain":1},
#                   {"name":"backup", "task":"backup", "cron":"*/2 * * * *", "retain":1,
#                    "labels": {"interval":"2m"}}]'
---

provisioner: driver.longhorn.io 自己提供的

allowVolumeExpansion: true 支持存储卷扩展

numberOfReplicas 每个数据要存几个副本 ，默认是3

staleReplicaTimeout 复制操作的过期时间

fromBackup 故障时 ，从哪个快照恢复

安装longhorn

参考 https://longhorn.io/docs/1.2.2/deploy/install/install-with-kubectl/

1. 安装依赖包
   yum install iscsi-initiator-utils

2. 创建pod

   kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.2/deploy/longhorn.yaml
   

3. 修改ui 访问入口
   把 Service/longhorn-ui 的type 改为 NodePort 删除nodePort: null

   可以修改默认的

   reclaimpolicy 为 retain

   mountPath 把 /var/lib/longhorn/ 改成磁盘挂载点， 或者把磁盘挂载在这个目录下

4. 当longhorn-system 下的pod 为ready 状态时即可

   访问前端

   [root@node01 ~]# kubectl get svc/longhorn-frontend -n longhorn-system
   NAME                TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
   longhorn-frontend   NodePort   10.111.42.184   <none>        80:32739/TCP   28m
   

pvc 调用sc的 示例

搭建longhorn 成功后会自动生成sc/longhorn

[root@node01 chapter5]# kubectl get sc
NAME       PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn   driver.longhorn.io   Delete          Immediate           true                   58m
[root@node01 chapter5]# 

创建pvc ，使用sc longhorn

[root@node01 chapter5]# cat pvc-dyn-longhorn-demo.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dyn-longhorn-demo
  namespace: default
spec:
  accessModes: ["ReadWriteOnce"]
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi
    limits:
      storage: 10Gi
  storageClassName: longhorn

发现会自动创建pv 并且绑定在pvc-dyn-longhorn-demo 上。 webui 也会有

[root@node01 chapter5]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                           STORAGECLASS   REASON   AGE
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41   3Gi        RWO            Delete           Bound    default/pvc-dyn-longhorn-demo   longhorn                73s
[root@node01 chapter5]# 

同样在webui 可以看到pv 对应的副本数量 以及位置

[root@node01 replicas]# kubectl get lhr  -n longhorn-system 
NAME                                                  AGE
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41-r-9533a7f2   120m
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41-r-f0b4cfef   120m
[root@node01 replicas]# 

eg: 验证sc/longhorn 的持久性

[root@node01 chapter5]# cat volumes-pvc-longhorn-demo.yaml 
# Maintainer: MageEdu <mage@magedu.com>
# URL: http://www.magedu.com
---
apiVersion: v1
kind: Pod
metadata:
  name: volumes-pvc-longhorn-demo
  namespace: default
spec:
  nodeName: node03
  containers:
  - name: redis
    image: redis:alpine
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
      name: redisport
    volumeMounts:
    - mountPath: /data
      name: redis-data-vol
  volumes:
  - name: redis-data-vol
    persistentVolumeClaim:
      claimName: pvc-dyn-longhorn-demo
[root@node01 chapter5]# kubectl apply -f  volumes-pvc-longhorn-demo.yaml 

进入pod/volumes-pvc-longhorn-demo 后 ，存key,删除。 然后修改 nodeName，让它运行在 node02上， 再进去发现之前存的key 依然存在。

同时 pv 在longhorn 前端显示为健康状态

存储卷总结：

​ 介绍的存储卷：emptyDir，hostPath， NFS， Longhorn,
​ CSI: 外置存储服务，带来了扩展功能，快照、恢复；也会引入CRD【customer resources definition】类型的CR

[root@node01 ~]# kubectl api-resources    --api-group=longhorn.io
NAME               SHORTNAMES   APIVERSION            NAMESPACED   KIND
engineimages       lhei         longhorn.io/v1beta1   true         EngineImage
engines            lhe          longhorn.io/v1beta1   true         Engine
instancemanagers   lhim         longhorn.io/v1beta1   true         InstanceManager
nodes              lhn          longhorn.io/v1beta1   true         Node
replicas           lhr          longhorn.io/v1beta1   true         Replica
settings           lhs          longhorn.io/v1beta1   true         Setting
volumes            lhv          longhorn.io/v1beta1   true         Volume

查看 longhorn-system 类型的 pv

[root@node01 ~]# kubectl  get lhv  -n longhorn-system
NAME                                       AGE
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41   177m
[root@node01 ~]# 

查看 longhorn-system 的副本

[root@node01 ~]# kubectl  get lhr  -n longhorn-system
NAME                                                  AGE
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41-r-9533a7f2   177m
pvc-e4d4a1ac-bebc-4933-87cf-096ac6bf7b41-r-f0b4cfef   177m