二、kubernetes资源监控 Metrics-Server部署Kubernetes采用request和limit两种限制类型来对资源进行分配。
request(资源需求)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。
limit(资源限额)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。
资源类型:
CPU 的单位是核心数，内存的单位是字节。
一个容器申请0.5个CPU，就相当于申请1个CPU的一半，你也可以加个后缀m 表示千分之一的概念。比如说100m的CPU，100豪的CPU和0.1个CPU都是一样的。
内存单位：
K、M、G、T、P、E #通常是以1000为换算标准的。
Ki、Mi、Gi、Ti、Pi、Ei #通常是以1024为换算标准的。
https://github.com/kubernetes-sigs/metrics-serverhttps://github.com/kubernetes-sigs/metrics-server
Dashboard部署 GitHub - kubernetes/dashboard: General-purpose web UI for Kubernetes clustersGeneral-purpose web UI for Kubernetes clusters. Contribute to kubernetes/dashboard development by creating an account on GitHub.https://github.com/kubernetes/dashboard 三、HPA实例Horizontal Pod Autoscaler 演练 | KubernetesHorizontal Pod Autoscaler 可以根据 CPU 利用率自动扩缩 ReplicationController、 Deployment、ReplicaSet 或 StatefulSet 中的 Pod 数量 （也可以基于其他应用程序提供的度量指标，目前这一功能处于 beta 版本）。本文将引领你了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。 与 Horizontal Pod Autoscaler 相关的更多信息请参阅 Horizontal Pod Autoscaler 用户指南。准备开始 本文示例需要一个运行中的 Kubernetes 集群以及 kubectl，版本为 1.2 或更高。 Metrics 服务器 需要被部署到集群中，以便通过 Metrics API 提供度量数据。 Horizontal Pod Autoscaler 根据此 API 来获取度量数据。 要了解如何部署 metrics-server，请参考 metrics-server 文档 。如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，你的 Kubernetes 集群以及 kubectl 至少需要达到 1.6 版本。 此外，如果要使用自定义度量指标，你的 Kubernetes 集群还必须能够与提供这些自定义指标 的 API 服务器通信。 最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要 达到 1.https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
四、HelmHelm是Kubernetes 应用的包管理工具，主要用来管理 Charts，类似Linux系统的yum。
Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 metadata，以便于应用程序的分发。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
Helm V3 与 V2 最大的区别在于去掉了tiller：
官方文档：
Helm | DocsHelm - The Kubernetes Package Manager.https://helm.sh/docs/intro/ 官方镜像仓库：
Artifact HubFind, install and publish Kubernetes packageshttps://artifacthub.io/
Helm当前最新版本 v3.1.0 官网：https://helm.sh/docs/intro/
Helm安装：
下载软件包：helm-v3.1.1-linux-amd64.tar.gz
$ tar zxf helm-v3.1.1-linux-amd64.tar.gz
$ cd linux-amd64/
$ cp helm /usr/local/bin/
设置helm命令补齐：
echo "source <(helm completion bash)" >> ~/.bashrc
搜索官方helm hub chart库：
$ helm search hub wordpress Helm
添加第三方 Chart 库：
$ helm repo add stable http://mirror.azure.cn/kubernetes/charts/
$ helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
$ helm search repo redis
Helm 部署应用：
$ $ helm search repo redis //查询 NAME CHART VERSION APP VERSION stable/redis 10.5.6 5.0.7 stable/redis-ha 4.4.0 5.0.6 ...
helm search repo redis #从repo源中查询redis镜像
支持多种安装方式：(helm默认读取~/.kube/config信息连接k8s集群)
$ helm install redis-ha stable/redis-ha #从镜像源安装(自定义名称为redis-ha)
$ helm inntall redis-ha redis-ha-4.4.0.tgz #从压缩包安装
$ helm install redis-ha path/redis-ha #从指定目录中安装
$ helm install redis-ha https://example.com/charts/redis-ha-4.4.0.tgz #从URL安装
$ helm pull stable/redis-ha //拉取应用到本地
$ helm status redis-ha //查看状态
$ helm uninstall redis-ha //卸载
以一个helm中的nginx镜像为例，其中的文件“value.yaml”用于管理整个镜像的参数值，其中为参数false的项目表示该设置不生效，参数为true的项目表示该设置生效
更改默认仓库为本地镜像仓库(本地没有时才会去外部拉取)
拉取的镜像的格式
测试：做一个自动资源控制
先拉取镜像并上传到本地仓库
再更改从参数值
安装镜像，其中“webserver”表示自定义的项目名称，“.”表示当前路径
查看是否就绪
查看资源控制器
查看helm当前安装的项目、卸载项目
构建一个helm chart#创建helm chart [root@server2 helm]# helm create mychart Creating mychart [root@server2 helm]# ls helm-v3.8.0-linux-amd64.tar.gz linux-amd64 mychart nginx nginx-9.9.3.tgz #查看mychart的目录结构 [root@server2 helm]# tree mychart/ mychart/ ├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _helpers.tpl │ ├── hpa.yaml │ ├── ingress.yaml │ ├── NOTES.txt │ ├── serviceaccount.yaml │ ├── service.yaml │ └── tests │ └── test-connection.yaml └── values.yaml
#复制证书 [root@server2 ~]# cp /etc/docker/certs.d/reg.westos.org/ca.crt /etc/pki/ca-trust/source/anchors/ #更新证书 [root@server2 ~]# update-ca-trust #添加chart镜像到本地仓库 [root@server2 ~]# helm repo add local https://reg.westos.org/chartrepo/charts "local" has been added to your repositories
设置helm访问harbor仓库时的用户名和密码：(文件中设置后，否则需要在上传时指定用户名和密码)
[root@server2 helm]# vim /root/.config/helm/repositories.yaml
上传镜像：需要提前安装好插件“helm-push_0.10.2_linux_amd64.tar.gz”
#安装插件 [root@server2 ~]# mkdir /root/.local/share/helm/plugins/cm-push [root@server2 ~]# tar zxf helm-push_0.10.2_linux_amd64.tar.gz -C /root/.local/share/helm/plugins/cm-push #上传镜像 [root@server2 helm]# helm cm-push mychart-0.1.0.tgz local
注意：上传时的三个参数，<--insecure>表示跳过证书检测，<-p>表示密码，<-u>表示用户
#更新镜像库 [root@server2 helm]# helm repo update #查询镜像 [root@server2 helm]# helm search repo mychart NAME CHART VERSION APP VERSION DEscriptION local/mychart 0.1.0 v1 A Helm chart for Kubernetes #部署镜像 [root@server2 helm]# helm install demo local/mychart
Helm部署nfs-client-provisioner:
nfs-subdir-external-provisioner 4.0.16 · viceice/nfs-subdir-external-provisionernfs-subdir-external-provisioner is an automatic provisioner that used your *already configured* NFS server, automatically creating Persistent Volumes.https://artifacthub.io/packages/helm/nfs-subdir-external-provisioner/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 helm pull nfs-subdir-external-provisioner/nfs-subdir-external-provisioner tar zxf nfs-subdir-external-provisioner-4.0.16.tgz
解压后更改配置文件：
在当前目录下部署：
#从当前目录安装镜像并并指定ns helm install nfs-subdir-external-provisioner . -n nfs-client-provisioner kubectl get pod -n nfs-client-provisioner
测试：通过之前的实验文件，创建3个pvc，并查看效果
#文件中总共创建3个pvc，这里只表示出一个 [root@server2 nfs]# vim /root/volume/pvc/nfs/pvc.yml 1 kind: PersistentVolumeClaim 2 apiVersion: v1 3 metadata: 4 name: pvc1 5 spec: 6 storageClassName: nfs-client 7 accessModes: 8 - ReadWriteMany 9 resources: 10 requests: 11 storage: 1Gi *********
在共享目录中查看到已经pvc已经创建3个新的目录。删除pvc后目录也回收。
#列出镜像的历史版本 helm search repo ingress-nginx -l #拉取镜像，并指定版本俄日4.0.17 helm pull ingress-nginx/ingress-nginx --version 4.0.17helm的图形化管理：
部署kubeapps应用，为Helm提供web UI界面管理
kubeapps 7.8.7 · bitnami/bitnamiKubeapps is a web-based UI for launching and managing applications on Kubernetes. It allows users to deploy trusted applications and operators to control users access to the cluster.https://artifacthub.io/packages/helm/bitnami/kubeapps
#添加镜像源 helm repo add bitnami https://charts.bitnami.com/bitnami #默认拉取kubeapps的最新版 helm pull bitnami/kubeapps #创建新的namespace kubectl create namespace kubeapps
编辑< vim /root/helm/kubeapps/values.yaml >文件，并做如下修改
同时从< vim /root/helm/kubeapps/values.yaml >文件中寻找指定的镜像，并上传到本地harbor仓库
编辑< vim /root/helm/kubeapps/charts/postgresql/values.yaml >文件，并做如下修改
并其中用到的将镜像下载到本地
编辑
并其中用到的将镜像下载到本地
上传镜像到本地仓库
[root@server1 ~]# docker images | grep bitnami
#批量改名
[root@server1 ~]# docker images | grep bitnami| awk '{system("docker tag "$1":"$2" reg.westos.org/"$1":"$2"")}'
[root@server1 ~]# docker images |grep ^reg.westos.org/bitnami
#批量上传
[root@server1 ~]# docker images |grep ^reg.westos.org/bitnami | awk '{system("docker push "$1":"$2"")}'
上传完成后总共有8个镜像。
安装部署kubeapps
[root@server2 kubeapps]# pwd /root/helm/kubeapps [root@server2 kubeapps]# helm install kubeapps . -n kubeapps
安装完成后，kubeapps部署所需要的所有pod都已经启动
授权并获得token
#创建一个sa [root@server2 kubeapps]# kubectl create serviceaccount kubeapps-operator -n kubeapps serviceaccount/kubeapps-operator created #对sa授权，以便管理helm [root@server2 kubeapps]# kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=kubeapps:kubeapps-operator clusterrolebinding.rbac.authorization.k8s.io/kubeapps-operator created #显示token [root@server2 kubeapps]# kubectl -n kubeapps describe secrets kubeapps-operator-token-7mm2h
在浏览器测试：输入token
可以通过界面的方式部署镜像
harbor仓库与kubeapps的整合、与pod部署
第八步跳过了证书校验 ，如果需要证书的话可以将文件的内容粘贴在下边
但是这里出现一个问题，报错原因是找不到“reg.westos.org”的解析。这是因为在server2节点上虽然有解析，但是在对应的kubeapps容器中并没有解析！！！
< kubectl -n kube-system get cm>
[root@server2 ~]# kubectl -n kube-system get cm
NAME DATA AGE
calico-config 4 7d
coredns 1 15d
#向容器内添加解析
[root@server2 ~]# kubectl -n kube-system edit cm coredns
14 hosts {
15 172.25.254.1 reg.westos.org
16 fallthrough
17 }
解析添加完成后，浏览器中即可进行下一步添加设置。
pod的升级与更改：
测试：
pod版本回滚：
五、k8s高可用集群六、查看集群节点状态
#查看集群节点cpu状态 [root@server2 metrice]# kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% server2 242m 12% 1370Mi 72% server3 168m 8% 887Mi 46% server4 151m 7% 748Mi 39%
