kubernetes（K8S）学习笔记P4：K8s核心概念2-Helm、持久化存储技术

5.Helm
- 5.1Helm 引入
- 5.2Helm 介绍
- 5.3Helm v3 变化
- 5.4安装与仓库配置
- - 5.4.1部署 helm 客户端
  - 5.4.2配置国内 chart 仓库（helm换源）
- 5.5Helm快速部署
- - 5.5.1基本命令
  - 5.5.2部署
- 5.6自定义chart
- 5.7chart 模板使用
6.持久化存储（nfs网络存储）
- 6.1安装部署nfs
7.持久化存储技术（PV、PVC）
- 7.1基本概念
- 7.2使用
- - 7.2.1创建PVC
  - 7.2.2创建PV

5.Helm

5.1Helm 引入

请添加图片描述
K8S 上的应用对象，都是由特定的资源描述组成，包括 deployment、service 等。都保存各自文件中或者集中写到一个配置文件。然后 kubectl apply – f 部署。如果应用只由一个或几个这样的服务组成，上面部署方式足够了。
而对于一个复杂的应用，会有很多类似上面的资源描述文件，例如微服务架构应用，组成应用的服务可能多达十个，几十个。如果有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，而这种组织和管理应用的方式就显得力不从心了。且由于缺少对发布过的应用版本管理和控制，使Kubernetes 上的应用维护和更新等面临诸多的挑战，主要面临以下问题：

如何将这些服务作为一个整体管理
这些资源文件如何高效复用
不支持应用级别的版本管理

5.2Helm 介绍

Helm 是一个 Kubernetes 的包管理工具，就像 Linux 下的包管理器，如 yum/apt 等，可以很方便的将之前打包好的 yaml 文件部署到 kubernetes 上。
Helm 有 3 个重要概念：
1. helm：一个命令行客户端工具，主要用于 Kubernetes 应用 chart 的创建、打包、发布和管理。
2. Chart： 应用描述，一系列用于描述 k8s 资源相关文件的集合（yaml集合）。
3. Release： 基于 Chart 的部署实体，一个 chart 被 Helm 运行后将会生成对应的一个release；将在 k8s 中创建出真实运行的资源对象。

5.3Helm v3 变化

在这里插入图片描述
2019 年 11 月 13 日， Helm 团队发布 Helm v3 的第一个稳定版本。
该版本主要变化如下：
架构变化：
1、最明显的变化是 Tiller 的删除
2、 Release 名称可以在不同命名空间重用
3、支持将 Chart 推送至 Docker 镜像仓库中
4、使用== JSONSchema 验证 chart values==
5、其他

5.4安装与仓库配置

5.4.1部署 helm 客户端

参考文档：https://helm.sh/zh/docs/intro/quickstart/
Helm 客户端下载地址： https://github.com/helm/helm/releases
解压移动到/usr/bin/目录即可。

wget https://get.helm.sh/helm-vv3.2.1-linux-amd64.tar.gz
tar zxvf helm-v3.2.1-linux-amd64.tar.gz
mv linux-amd64/helm /usr/bin/

5.4.2配置国内 chart 仓库（helm换源）

微软仓库（http://mirror.azure.cn/kubernetes/charts/） 这个仓库推荐，基本
上官网有的 chart 这里都有。
阿里云仓库（https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts ）
官方仓库（https://hub.kubeapps.com/charts/incubator）官方 chart 仓库，国内有点不好使。

添加存储库

helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo update

查看配置的存储库

helm repo list
helm search repo stable

删除存储库：

helm repo remove aliyun

5.5Helm快速部署

请添加图片描述

5.5.1基本命令

‘helm search’：查找 Charts
Helm 自带一个强大的搜索命令，可以用来从两种来源中进行搜索：
- helm search hub 从 Artifact Hub 中查找并列出 helm charts。 Artifact Hub中存放了大量不同的仓库。
- helm search repo 从你添加（使用 helm repo add）到本地 helm 客户端中的仓库中进行查找。该命令基于本地数据进行搜索，无需连接互联网。
‘helm install’：安装一个 helm 包
使用 helm install 命令来安装一个新的 helm 包。最简单的使用方法只需要传入两个参数：你命名的release名字和你想安装的chart的名称。
helm status 来追踪 release 的状态，或是重新读取配置信息：

主要介绍三个命令：

chart install
chart upgrade
chart rollback

5.5.2部署

搜索chart
```
helm search repo weave
```
安装
```
helm install ui stable/weave-scope
```
查看发布状态
```
helm list
helm status ui
```

5.6自定义chart

请添加图片描述

创建chart
```
helm create mychart
```

进入templates 文件目录下创建自己编写的yaml文件

kubectl create deployment web1 --image=nginx --dry-run -o yaml > deployment.yaml

kubectl create deployment web1 --image=nginx

kubectl expose deployment web1 --port=80 --target-port=80 --type=NodePort --dry-run -o yaml >service.yaml

安装mychart
```
helm install web1 mychart/
```
应用升级
```
helm upgrade web1 mychart/
```

5.7chart 模板使用

请添加图片描述

Helm 最核心的就是模板，即模板化的 K8S manifests 文件。
它本质上就是一个 Go 的 template 模板。 Helm 在 Go template 模板的基础上，还会增加很多东西。如一些自定义的元数据信息、扩展的库以及一些类似于编程形式的工作流，例如条件语句、管道等等。这些东西都会使得我们的模板变得更加丰富。
有了模板，我们怎么把我们的配置融入进去呢？
用的就是这个 values .yaml文件。这两部分内容其实就是 chart 的核心功能。

6.持久化存储（nfs网络存储）

请添加图片描述

6.1安装部署nfs

再服务器上安装nfts
```
yum install -y nfs-utils
```
设置挂载目录
```
vi /etc/expose
```
挂载路径需要创建出来
k8s集群node节点安装nfs
```
yum install -y nfs-utils
```
在nfs服务器启动nfs服务
```
systemctl start nfs

ps -ef | grep nfs
```

在k8s中部署应用，使用nfs持久网络
创建 nfs-nginx.yaml,并执行

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dep1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: wwwroot
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
      volumes:
        - name: wwwroot
          nfs:
            server: 192.168.44.134 # 服务地址
            path: /data/nfs # 挂载目录

7.持久化存储技术（PV、PVC）

请添加图片描述

7.1基本概念

管理存储是管理计算的一个明显问题。该 PersistentVolume 子系统为用户和管理员提供了一个 API，用于抽象如何根据消费方式提供存储的详细信息。为此，我们引入了两个新的API 资源： PersistentVolume 和 PersistentVolumeClaim

PersistentVolume（ PV） 是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源一样。 PV 是容量插件，如Volumes，但其生命周期独立于使用 PV 的任何单个 pod。此 API 对象捕获存储实现的详细信息，包括 NFS， iSCSI 或特定于云提供程序的存储系统。
PersistentVolumeClaim（ PVC） 是由用户进行存储的请求。它类似于 pod。 Pod 消耗节点资源， PVC 消耗 PV 资源。 Pod 可以请求特定级别的资源（ CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但是 PersistentVolumes 对于不同的问题，用户通常需要具有不同属性（例如性能）。群集管理员需要能够提供各种PersistentVolumes 不同的方式，而不仅仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有 StorageClass 资源。
StorageClass 为管理员提供了一种描述他们提供的存储的“ 类” 的方法。不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 Kubernetes 本身对于什么类别代表是不言而喻的。这个概念有时在其他存储系统中称为“ 配置文件” 。

PVC 和 PV 是一一对应的。

7.2使用

7.2.1创建PVC

创建一个yaml文件，pvc.yaml，并执行

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dep1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: wwwroot
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: my-pvc

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

kubectl apply -f pvc.yaml

7.2.2创建PV

创建，pv.yaml，并执行

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /data/nfs
    server: 192.168.44.134