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
kubectl apply -f pvc.yaml