企业运维实战--k8s学习笔记 HPA自动弹性伸缩 Helm之私有Helm Chart构建、使用Helm部署nfs和metrics-server监控
1 . HPA介绍HPA，全称 Horizontal Pod Autoscaler， 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 除了 CPU 利用率，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。Pod 水平自动扩缩
1 . HPA介绍
HPA，全称 Horizontal Pod Autoscaler， 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 除了 CPU 利用率，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性的调整副本控制器或 Deployment 中的副本数量，以使得 Pod 的平均 CPU 利用率与用户所设定的目标值匹配。
实际生产中，广泛使用这四类指标：
Resource metrics - CPU核内存利用率指标
Pod metrics - 例如网络利用率和流量
Object metrics - 特定对象的指标，比如Ingress, 可以按每秒使用请求数来扩展容器
Custom metrics - 自定义监控，比如通过定义服务响应时间，当响应时间达到一定指标时自动扩容
2. HPA实例
2.1. 运行php-apache 服务器
首先拉取需要的镜像，上传到私有仓库
docker pull mirrorgooglecontainers/hpa-example
docker tag mirrorgooglecontainers/hpa-example reg.westos.org/library/hpa-example
docker push reg.westos.org/library/hpa-example
我们创建一个存放hpa文件的目录
cd
mkdir hpa
cd hpa/
vim deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
spec:
selector:
matchLabels:
run: php-apache
replicas: 1
template:
metadata:
labels:
run: php-apache
spec:
containers:
- name: php-apache
image: hpa-example
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
name: php-apache
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
run: php-apache
执行hpa-apache.yaml 清单，并查看信息：
kubectl apply -f hpa-apache.yaml
kubectl get svc php-apache
kubectl get pod
访问生成的IP
curl 10.244.179.80
2.2. 创建 Horizontal Pod Autoscaler
php-apache 服务器已经运行，我们将通过 kubectl autoscale 命令创建 Horizontal Pod Autoscaler。 以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 Deployment，使 Pod 的副本数量维持在 1 到 10 之间。 大致来说，HPA 将（通过 Deployment）增加或者减少 Pod 副本的数量以保持所有 Pod 的平均 CPU 利用率在 50% 左右（由于每个 Pod 请求 200 毫核的 CPU，这意味着平均 CPU 用量为 100 毫核）。自动扩缩完成副本数量的改变可能需要几分钟的时间。Hpa会根据Pod的CPU使用率动态调节Pod的数量
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
kubectl get hpa
kubectl top pod
2.3. 增加负载
kubectl run -i --tty load-generator --rm --image=busyboxplus --restart=Never -- /bin/sh -c "while true; do wget -q -O- http://php-apache; done"
因为执行命令后，会一直在运作，所以我们需要再打开一个终端来查cpu的战用量信息：
查看pod,top,hpa的信息
Hpa会根据Pod的CPU使用率动态调节Pod的数量。
kubectl top pod
kubectl top hpa
我们不断查看他们的信息，可以看到hpa会自动扩容replicas，从开始的一个到最后八个！继续等待会开到最大程度.
top pod节点也逐渐开启，负载越来越大！
我们打断负载(ctrl + c)后
hpa会自动缩容，但是缩的速度比扩的速度慢很多，等待一段时间之后，就可以看到节点又降低了!!
kubectl get hpa
kubectl get pod
2.4. 基于多项指标的自动扩缩
HPA伸缩过程：
收集HPA控制下所有Pod最近的cpu使用情况（CPU utilization）
对比在扩容条件里记录的cpu限额（CPUUtilization）
调整实例数（必须要满足不超过最大/最小实例数）
每隔30s做一次自动扩容的判断
CPU utilization的计算方法是用cpu usage（最近一分钟的平均值，通过metrics可以直接获取到）除以cpu request（这里cpu request就是我们在创建容器时制定的cpu使用核心数）得到一个平均值，这个平均值可以理解为：平均每个Pod CPU核心的使用占比。
HPA进行伸缩算法：
计算公式：TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)
ceil()表示取大于或等于某数的最近一个整数
每次扩容后冷却3分钟才能再次进行扩容，而缩容则要等5分钟后。
当前Pod Cpu使用率与目标使用率接近时，不会触发扩容或缩容：
触发条件：avg(CurrentPodsConsumption) / Target >1.1 或 <0.9
vi hpav2.yaml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-example
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-example
metrics:
- type: Resource
resource:
name: cpu
target:
averageUtilization: 60
type: Utilization
- type: Resource
resource:
name: memory
target:
averageValue: 100Mi
type: AverageValue
kubectl apply -f hpav2.yaml
3. Helm
Helm是Kubernetes 应用的包管理工具，主要用来管理 Charts，类似Linux系统的yum。
Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
Helm V3 与 V2 最大的区别在于去掉了tiller：
创建目录用来存放helm的配置文件
设置helm的环境变量
mkdir helm
cd helm/
tar zxf helm-v3.7.1-linux-amd64.tar.gz
cd linux-amd64/
mv helm /usr/local/bin/ ##设置环境变量
设置补齐命令，这样在使用指令的时候会很方便
helm 然后按tab建可以补齐就OK
cd
echo “source <(helm completion bash)” >> ~/.bashrc ##设置补齐命令
source .bashrc
helm
添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
3.1. 实验：部署nginx
从仓库中拉取nginx文件
helm search repo redis
helm pull bitnami/nginx
拉取下来的是tar包解压它
将拉取得包移到helm/里面方便管理，将前面helm的包删掉！
mv nginx-9.5.12.tgz helm/
cd helm/
rm -fr linux-adm64/ helm-v3.7.1-linux*
tar zxf redis-cluster-6.3.2.tgz
cd nginx
编辑文件
vi values.yaml
只需要将仓库名写进去
查看sc
将之前实验的pvc都删掉！
kubectl get sc
kubectl get pvc
kubectl delete deployments.apps php-apache
kubectl delete hpa php-example
kubectl delete pvc --all
接下来我们需要将需要的镜像nginx拉取下来
首先需要在自己的私有仓库中新建项目bitnami，一定要选择公开！
server1上拉取镜像，并上传
docker pull bitnami/nginx:1.21.3-debian-10-r50
docker tag docker.io/bitnami/nginx:1.21.3-debian-10-r50 reg.westos.org/bitnami/nginx:1.21.3-debian-10-r50
docker push reg.westos.org/bitnami/nginx:1.21.3-debian-10-r50
安装测试：
查看pod节点，可以看到redis-cluster节点已经拉起了！
helm install nginx .
kubectl get pod
可以看到svc已经出现了nginx
测试：
curl 172.25.76.11
接着卸载nginx
helm uninstall nginx
3.2. 搭建Helm Chart
3.2.1创建chart
cd helm/
helm create mychart ##创建
进入刚才创建的mychart中
cd mychart/
先修改values.yaml文件，修改镜像为myapp
vi values.yaml
repository: myapp
tag: "v1"
修改打包文件Chart.yaml
vi Chart.yaml
appVersion: v1
修改之后用helm lint .查看是否正确
helm lint .
在harbor仓库公开新建项目charts
将mychart打包上传到这
cd ..
helm package mycart/
helm repo add local https://reg.westos.org/chartrepo/charts
## chartrepo是默认地址必须加
在添加的时候报错了因为没有证书，我们需要添加证书：
cd /etc/pki/ca-trust/source/anchors/
cp etc/docker/certs.d/reg.westos.org/ca.crt .
添加证书之后要更新，不然还是无法添加：
update-ca-trust
helm repo add local https://reg.westos.org/chartrepo/charts
如果还是不行并出现如下报错是因为证书本身的问题 则我们只能
helm repo add local https://reg.westos.org/chartrepo/charts --insecure-skip-tls-verify
helm repo list ##列出仓库
cd /root/helm/
接着需要上传包，所以需要安装push的插件
有两种安装方式，在线/离线安装，因为在线速度较慢，所以本人选择离线安装！
在线安装
helm plugin install https://github.com/chartmuseum/helm-push
离线安装
helm env //获取插件目录
mkdir ~/.local/share/helm/plugins/push
tar zxf helm-push_0.10.1_linux_amd64.tar.gz -C ~/.local/share/helm/plugins/push
上传helm
helm cm-push mychart-0.1.0.tgz local -u admin -p westos --insecure
上传之后更新仓库并查看
helm repo update local ##更新仓库
helm search repo mychart ##搜索
现在可以可以下载上传的仓库了！
helm install nginx local/mychart --insecure-skip-tls-verify
helm list
kubectl get svc
curl ******* #访问生成的IP
可以看到访问结果为myapp:v1代表成功
3.2.2 版本更新
设置image的tag为v2，修改打包的版本
cd mychart/
vi values.yaml ##设置image的tag为v2
tag: "v2"
vi Chart.yaml # 修改打包的版本
version: 0.2.0
appVersion: v2
打包并上传，更新仓库
cd ..
helm lint mychart #查看是否出错
helm package mychart
helm cm-push mychart-0.2.0.tgz local --insecure -u admin -p westos
helm repo update
查看仓库mychart的版本，加 -L之后可以查看到全部的版本！
helm search repo mychart
helm search repo mychart -l
更新版本,并查看svc，访问ip
helm upgrade nginx local/mychart --insecure-skip-tls-verify
kubectl get svc
curl ******
可以看到已经更新为v2版本！！
3.2.3 回滚
查看mychart的历史，回滚到第一个版本，再次访问IP
helm history nginx
helm rollback nginx 1
helm history nginx
kubectl get svc
curl ********
可以看到又回到了v1版本
3.3. Helm部署nfs
在外网hub先搜索nfs-subdir-external-provisioner，将仓库加入本地，再此查看本地仓库可以看到 nfs-subdir-external-provisioner即可
helm search hub nfs-subdir-external-provisioner ##外网搜索
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm search repo nfs-subdir-external-provisioner ##本地
新建目录用来放配置文件,拉取nfs文件
cd /root/helm
mkdir nfs-subdir-external-provisioner
cd nfs-subdir-external-provisioner/
helm pull nfs-subdir-external-provisioner/nfs-subdir-external-provisioner
tar zxf nfs-subdir-external-provisioner-4.0.14.tgz
cd nfs-subdir-external-provisioner/
仓库内需要此项目sig-storage
修改values.yaml文件
vi values.yaml
repository: sig-storage/nfs-subdir-external-provisioner
tag: v4.0.2
server: 172.25.76.5
path: /nfsdata
defaultClass: true
archiveOnDelete: false #若是true则 在删除pvc后留个备份
将之前实验的nfs记录namespace清除
cd /root/volumes/
cd nfs/
kubectl delete -f nfs-client-provisioner.yaml
kubectl get ns
kubectl -n nfs-client-provisioner get all
kubectl delete pvc --all
kubectl delete pv --all
将前面实验的mychart清除
helm list --all-namespaces
helm uninstall nginx
创建一个namespace，安装nfs
kubectl create namespace nfs-client-provisioner
cd /root/helm/nfs-subdir-external-provisioner/nfs-subdir-external-provisioner/
helm install nfs-client-provisioner . -n nfs-client-provisioner
kubectl -n nfs-client-provisioner get all
kubectl get sc
测试
之前实验有一个pvc的清单文件：
cd /root/volumes/nfs/
cat pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc1
spec:
#storageClassName: managed-nfs-storage
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
执行清单并查看pvc
kubectl apply -f pvc.yaml
kubectl get pvc
在server5中查看
kubectl delete -f pvc.yaml
kubectl get pvc
kubectl get pv
3.4.Helm部署metrics-server
首先拉取需要的文件：
cd /root/helm/
helm pull bitnami/metrics-server
tar zxf metrics-server-5.10.7.tgz
cd metrics-server/
vi values.yaml
imageRegistry: "reg.westos.org"
apiService:
create: true
在测试之前先将之前做的metrics-server清除
cd /root/metrics-server/
kubectl delete -f components.yaml
创建namespace： metrics-server
kubectl create namespace metrics-server
在server5上拉取需要的镜像,修改标签，上传到私有仓库
docker pull bitnami/metrics-server:0.5.1-debian-10-r30
docker tag docker.io/bitnami/metrics-server:0.5.1-debian-10-r30 reg.westos.org/bitnami/metrics-server:0.5.1-debian-10-r30
docker push reg.westos.org/bitnami/metrics-server:0.5.1-debian-10-r30
用helm安装metrics-server
helm install metrics-server . -n metrics-server
查看log后若出现此类报错
则需要作解析
kubectl -n kube-system edit cm coredns
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
hosts {
172.25.76.1 server1
172.25.76.2 server2
172.25.76.3 server3
fallthrough
}
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
测试:
可以看到节点的top信息
kubectl top node
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献8条内容
所有评论(0)