45-53-k8s-helm-持久化技术:
1、为什么引入Helm
集中管理yaml配置文件,高效复用,使用应用级别的管理。
在原来项目中都是基于yaml文件来进行部署发布的,而目前项目大部分微服务化或者模块化,会分成很多个组件来部署,每个组件可能对应一个deployment.yaml,一个service.yaml,一个Ingress.yaml还可能存在各种依赖关系,这样一个项目如果有5个组件,很可能就有15个不同的yaml文件,这些yaml分散存放,如果某天进行项目恢复的话,很难知道部署顺序,依赖关系等,而所有这些包括
但是这种方式部署,会有什么问题呢?
Helm的引入,就是为了解决这个问题
2、Helm介绍
Helm是k8s的包管理工具,就像Linux下的包管理器,如yum/apt等,可以很方便的将之前打包好的yaml文件部署到kubernetes上。
Helm有三个重要概念:
3、Helm v3变化
2019年11月13日,Helm团队发布了Helm v3的第一个稳定版本
该版本主要变化如下
架构变化
V3之前
官网 https://helm.sh/docs/intro/quickstart/
yum需要配置yum源,那么helm就就要配置helm源
添加仓库
helm repo add 仓库名 仓库地址
例如
# 配置微软源
helm repo add stable http://mirror.azure.cn/kubernetes/charts
# 配置阿里源
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
# 配置google源
helm repo add google https://kubernetes-charts.storage.googleapis.com/
# 更新
helm repo update
然后可以查看我们添加的仓库地址
# 查看全部
helm repo list
# 查看某个
helm search repo stable
或者可以删除我们添加的源
helm repo remove stable
首先使用命令搜索我们需要安装的应用
# 搜索 weave仓库
helm search repo weave
根据搜索内容选择安装
搜索完成后,使用命令进行安装
helm install ui aliyun/weave-scope
可以通过下面命令,来下载yaml文件【如果】
kubectl apply -f weave-scope.yaml
安装完成后,通过下面命令即可查看
helm list
同时可以通过下面命令,查看更新具体的信息
helm status ui
但是我们通过查看 svc状态,发现没有对象暴露端口
kubectl get svc
修改service.yaml
所以我们需要修改service的yaml文件,添加NodePort
kubectl edit svc ui-weave-scope
这样就可以对外暴露端口了,然后通过 ip + 32238 即可访问
使用命令,自己创建Chart
helm create mychart
创建完成后,我们就能看到在当前文件夹下,创建了一个 mychart目录
目录格式
在templates文件夹创建两个文件
我们创建以下两个
可以通过下面命令创建出yaml文件
# 导出deployment.yaml
kubectl create deployment web1 --image=nginx可能需要创建 deployment,不然会报错】
kubectl create deployment web1 --image=nginx --dry-run -o yaml > deployment.yaml
# 导出service.yaml 【可能需要创建 deployment,不然会报错】
kubectl expose deployment web1 --port=80 --target-port=80 --type=NodePort --dry-run -o yaml > service.yaml
kubectl delete deployment web1
安装mychart
执行命令创建
helm install web1 mychart
应用升级
当我们修改了mychart中的东西后,就可以进行升级操作
helm upgrade web1 mychart
通过传递参数,动态渲染模板,yaml内容动态从传入参数生成,修改values.yaml
刚刚我们创建mychart的时候,看到有values.yaml文件,这个文件就是一些全局的变量,然后在templates中能取到变量的值,完成一个动态模板
我们通过表达式形式 使用全局变量 {{ .Values.变量名称}}
例如: {{ .Release.Name}}
安装应用
在我们修改完上述的信息后,就可以尝试的创建应用了
helm install --dry-run web2 mychart(尝试运行)
helm install web2 mychart(创建)
之前提到数据卷:emptydir
,是本地存储,pod重启,数据就不存在了,需要对数据持久化存储,对于数据持久化存储【pod重启,数据还存在】,nfs,pv_pvc两种方式
使用命令安装nfs
yum install -y nfs-utils
首先创建存放数据的目录
mkdir -p /data/nfs
设置挂载路径
# 打开文件
vim /etc/exports
# 添加如下内容(需要创建对应目录)
/data/nfs *(rw,no_root_squash)
#启动
# 启动服务
systemctl start nfs # 或者使用以下命令进行启动 service nfs-server start
systemctl enable nfs#开机自启动
执行完成后,即部署完我们的持久化服务器
然后需要在k8s集群node节点上安装nfs,这里需要在 node1 和 node2节点上安装,执行完成后,会自动帮我们挂载上
yum install -y nfs-utils
最后在k8s集群上部署应用,使用nfs持久化存储
# 创建一个pv文件
mkdir pv
# 进入
cd pv
然后创建一个yaml文件 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.10.101
path: /data/nfs
通过这个方式,就挂载到了刚刚我们的nfs数据节点下的 /data/nfs 目录
最后就变成了: /usr/share/nginx/html -> 192.168.10.101 /data/nfs 内容是对应的
我们通过这个 yaml文件,创建一个pod
kubectl apply -f nfs-nginx.yaml
创建完成后,我们也可以查看日志
kubectl describe pod nginx-dep1
下面我们就可以进行测试了,比如现在nfs服务节点上添加数据,然后在看数据是否存在 pod中
# 进入pod中查看
kubectl exec -it nginx-dep1 bash
nfs服务器上创建index.html,修改nginx默认的内容
[root@hadoop102 pv]# kubectl expose deployment nginx-dep1 --port=80 --target-port=80 --type=NodePort
service/nginx-dep1 exposed
[root@hadoop102 pv]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-dep1 NodePort 10.102.125.97 80:32738/TCP 33s
[root@hadoop102 pv]#
对于上述的方式,ip和端口是直接放在容器上的,这样管理起来可能不方便
所以这里就需要用到 pv和pvc,方便配置和管理我们的 ip 地址等元信息
PV:持久化存储,对存储的资源进行抽象,对外提供可以调用的地方【生产者】
PVC:用于调用,不需要关心内部实现细节【消费者】
PV 和 PVC 使得 K8S 集群具备了存储的逻辑抽象能力。使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置,而把这项配置的工作交给PV的配置者,即集群的管理者。存储的PV和PVC的这种关系,跟计算的Node和Pod的关系是非常类似的;PV和Node是资源的提供者,根据集群的基础设施变化而变化,由K8s集群管理员配置;而PVC和Pod是资源的使用者,根据业务服务的需求变化而变化,由K8s集群的使用者即服务的管理员来配置。
举例:
创建一个 pvc.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-dep1-pvc
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
第一部分是定义一个 deployment,做一个部署
然后定义pvc
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
nfs:
path: /data/nfs
server: 192.168.10.101
然后就可以创建pod了
kubectl apply -f pv.yaml
然后可以通过下面命令,查看我们的 pv 和 pvc之间的绑定关系
kubectl get pv, pvc
到这里为止,我们就完成了我们 pv 和 pvc的绑定操作,通过之前的方式,进入pod中查看内容
kubect exec -it nginx-dep1 bash
然后查看 /usr/share/nginx.html,也能看到刚刚的内容,这种操作和之前我们的nfs是一样的,只是多了一层pvc绑定pv的操作
学习路径:https://space.bilibili.com/302417610/,如有侵权,请联系q进行删除:3623472230