第十二章、Kubernetes核心技术Helm

Helm就是一个包管理工具【类似于npm】

为什么引入Helm

首先在原来项目中都是基于yaml文件来进行部署发布的,而目前项目大部分微服务化或者模块化,会分成很多个组件来部署,每个组件可能对应一个deployment.yaml,一个service.yaml,一个Ingress.yaml还可能存在各种依赖关系,这样一个项目如果有5个组件,很可能就有15个不同的yaml文件,这些yaml分散存放,如果某天进行项目恢复的话,很难知道部署顺序,依赖关系等,而所有这些包括

  • 基于yaml配置的集中存放
  • 基于项目的打包
  • 组件间的依赖

但是这种方式部署,会有什么问题呢?

  • 如果使用之前部署单一应用,少数服务的应用,比较合适
  • 但如果部署微服务项目,可能有几十个服务,每个服务都有一套yaml文件,需要维护大量的yaml文件,版本管理特别不方便

Helm的引入,就是为了解决这个问题

  • 使用Helm可以把这些YAML文件作为整体管理
  • 实现YAML文件高效复用
  • 使用helm应用级别的版本管理

Helm介绍

Helm是一个Kubernetes的包管理工具,就像Linux下的包管理器,如yum/apt等,可以很方便的将之前打包好的yaml文件部署到kubernetes上。

Helm有三个重要概念

  • helm:一个命令行客户端工具,主要用于Kubernetes应用chart的创建、打包、发布和管理
  • Chart:应用描述,一系列用于描述k8s资源相关文件的集合
  • Release:基于Chart的部署实体,一个chart被Helm运行后将会生成对应的release,将在K8S中创建出真实的运行资源对象。也就是应用级别的版本管理
  • Repository:用于发布和存储Chart的仓库

Helm组件及架构

Helm采用客户端/服务端架构,有如下组件组成

  • Helm CLI是Helm客户端,可以在本地执行
  • Tiller是服务器端组件,在Kubernetes集群上运行,并管理Kubernetes应用程序
  • Repository是Chart仓库,Helm客户端通过HTTP协议来访问仓库中Chart索引文件和压缩包

Helm v3变化

2019年11月13日,Helm团队发布了Helm v3的第一个稳定版本

该版本主要变化如下

架构变化

  • 最明显的变化是Tiller的删除
  • V3版本删除Tiller
  • relesase可以在不同命名空间重用

V3之前

V3版本

helm配置

首先我们需要去 官网下载

  • 第一步,下载helm
  • 第二步,解压helm压缩文件,把解压后的helm目录复制到 usr/bin 目录中
  • 使用命令:helm

我们都知道yum需要配置yum源,那么helm就就要配置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

helm基本命令

  • chart install
  • chart upgrade
  • chart rollback

使用helm快速部署应用

使用命令搜索应用

首先我们使用命令,搜索我们需要安装的应用

# 搜索 weave仓库

helm search repo weave

根据搜索内容选择安装

搜索完成后,使用命令进行安装

helm install ui aliyun/weave-scope

可以通过下面命令,来下载yaml文件【如果】

kubectl apply -f weave-scope.yaml

安装完成后,通过下面命令即可查看

helm list

同时可以通过下面命令,查看更新具体的信息

helm status ui

但是我们通过查看 svc状态,发现没有对象暴露端口

所以我们需要修改service的yaml文件,添加NodePort

kubectl edit svc ui-weave-scope

这样就可以对外暴露端口了

然后我们通过 ip + 32185 即可访问

如果自己创建Chart

使用命令,自己创建Chart

helm create mychart

创建完成后,我们就能看到在当前文件夹下,创建了一个 mychart目录

目录格式
  • templates:编写yaml文件存放到这个目录
  • values.yaml:存放的是全局的yaml文件
  • chart.yaml:当前chart属性配置信息

在templates文件夹创建两个文件

我们创建以下两个

  • deployment.yaml
  • service.yaml

我们可以通过下面命令创建出yaml文件

# 导出deployment.yaml

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

安装mychart

执行命令创建

helm install web1 mychart

应用升级

当我们修改了mychart中的东西后,就可以进行升级操作

helm upgrade web1 mychart

chart模板使用

通过传递参数,动态渲染模板,yaml内容动态从传入参数生成

刚刚我们创建mychart的时候,看到有values.yaml文件,这个文件就是一些全局的变量,然后在templates中能取到变量的值,下面我们可以利用这个,来完成动态模板

  • 在values.yaml定义变量和值
  • 具体yaml文件,获取定义变量值
  • yaml文件中大题有几个地方不同
    • image
    • tag
    • label
    • port
    • replicas

定义变量和值

在values.yaml定义变量和值

获取变量和值

我们通过表达式形式 使用全局变量 {{.Values.变量名称}}

例如: {{.Release.Name}}

安装应用

在我们修改完上述的信息后,就可以尝试的创建应用了

helm install --dry-run web2 mychart

第十三章Kubernetes持久化存储

前言

之前我们有提到数据卷:emptydir ,是本地存储,pod重启,数据就不存在了,需要对数据持久化存储

对于数据持久化存储【pod重启,数据还存在】,有两种方式

  • nfs:网络存储【通过一台服务器来存储】

步骤

持久化服务器上操作

  • 找一台新的服务器nfs服务端,安装nfs
  • 设置挂载路径

使用命令安装nfs

yum install -y nfs-utils

首先创建存放数据的目录

mkdir -p /data/nfs

设置挂载路径

# 打开文件

vim /etc/exports

# 添加如下内容

/data/nfs *(rw,no_root_squash)

执行完成后,即部署完我们的持久化服务器

Node节点上操作

然后需要在k8s集群node节点上安装nfs,这里需要在 node1 和 node2节点上安装

yum install -y nfs-utils

执行完成后,会自动帮我们挂载上

启动nfs服务端

下面我们回到nfs服务端,启动我们的nfs服务

# 启动服务

systemctl start nfs

# 或者使用以下命令进行启动

service nfs-server start

K8s集群部署应用

最后我们在k8s集群上部署应用,使用nfs持久化存储

# 创建一个pv文件

mkdir pv

# 进入

cd pv

然后创建一个yaml文件 nfs-nginx.yaml

通过这个方式,就挂载到了刚刚我们的nfs数据节点下的 /data/nfs 目录

最后就变成了: /usr/share/nginx/html -> 192.168.44.134/data/nfs 内容是对应的

我们通过这个 yaml文件,创建一个pod

kubectl apply -f nfs-nginx.yaml

创建完成后,我们也可以查看日志

kubectl describe pod nginx-dep1

可以看到,我们的pod已经成功创建出来了,同时下图也是出于Running状态

下面我们就可以进行测试了,比如现在nfs服务节点上添加数据,然后在看数据是否存在 pod中

# 进入pod中查看 kubectl exec -it nginx-dep1 bash

PV和PVC

对于上述的方式,我们都知道,我们的ip 和端口是直接放在我们的容器上的,这样管理起来可能不方便

所以这里就需要用到 pv 和 pvc的概念了,方便我们配置和管理我们的 ip 地址等元信息

PV:持久化存储,对存储的资源进行抽象,对外提供可以调用的地方【生产者】

PVC:用于调用,不需要关心内部实现细节【消费者】

PV 和 PVC 使得 K8S 集群具备了存储的逻辑抽象能力。使得在配置Pod的逻辑里可以忽略对实际后台存储 技术的配置,而把这项配置的工作交给PV的配置者,即集群的管理者。存储的PV和PVC的这种关系,跟 计算的Node和Pod的关系是非常类似的;PV和Node是资源的提供者,根据集群的基础设施变化而变 化,由K8s集群管理员配置;而PVC和Pod是资源的使用者,根据业务服务的需求变化而变化,由K8s集 群的使用者即服务的管理员来配置。

实现流程

  • PVC绑定PV
  • 定义PVC
  • 定义PV【数据卷定义,指定数据存储服务器的ip、路径、容量和匹配模式】

举例

创建一个 pvc.yaml

第一部分是定义一个 deployment,做一个部署

  • 副本数:3
  • 挂载路径
  • 调用:是通过pvc的模式

然后定义pvc

然后在创建一个 pv.yaml

然后就可以创建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的操作

第十四章、Kubernetes集群资源监控

概述

监控指标

一个好的系统,主要监控以下内容

  • 集群监控
    • 节点资源利用率
    • 节点数
    • 运行Pods
  • Pod监控
    • 容器指标
    • 应用程序【程序占用多少CPU、内存】

监控平台

使用普罗米修斯【prometheus】 + Grafana 搭建监控平台

  • prometheus【定时搜索被监控服务的状态】
    • 开源的
    • 监控、报警、数据库
    • 以HTTP协议周期性抓取被监控组件状态
    • 不需要复杂的集成过程,使用http接口接入即可
  • Grafana
    • 开源的数据分析和可视化工具
    • 支持多种数据源

部署prometheus

首先需要部署一个守护进程

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-system
  labels:
    k8s-app: node-exporter
spec:
  selector:
    matchLabels:
      k8s-app: node-exporter
  template:
    metadata:
      labels:
        k8s-app: node-exporter
    spec:
      containers:
      - image: prom/node-exporter
        name: node-exporter
        ports:
        - containerPort: 9100
          protocol: TCP
          name: http
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: node-exporter
  name: node-exporter
  namespace: kube-system
spec:
  ports:
  - name: http
    port: 9100
    nodePort: 31672
    protocol: TCP
  type: NodePort
  selector:
    k8s-app: node-exporter

然后执行下面命令

kubectl create -f node-exporter.yaml

执行完,发现会报错

这是因为版本不一致的问题,因为发布的正式版本,而这个属于测试版本

所以我们找到第一行,然后把内容修改为如下所示

# 修改前 apiVersion: extensions/v1beta1 # 修改后 【正式版本发布后,测试版本不能使用】 apiVersion: apps/v1

创建完成后的效果

然后通过yaml的方式部署prometheus

  • configmap:定义一个configmap:存储一些配置文件【不加密】
  • prometheus.deploy.yaml:部署一个deployment【包括端口号,资源限制】
  • prometheus.svc.yaml:对外暴露的端口
  • rbac-setup.yaml:分配一些角色的权限

下面我们进入目录下,首先部署 rbac-setup.yaml

kubectl create -f rbac-setup.yaml

然后分别部署

# 部署configmap kubectl create -f configmap.yaml # 部署deployment kubectl create -f prometheus.deploy.yml # 部署svc kubectl create -f prometheus.svc.yml

部署完成后,我们使用下面命令查看

kubectl get pods -n kube-system

在我们部署完成后,即可看到 prometheus 的 pod了,然后通过下面命令,能够看到对应的端口

kubectl get svc -n kube-system

通过这个,我们可以看到 prometheus 对外暴露的端口为 30003,访问页面即可对应的图形化界面

http://192.168.177.130:30003

在上面我们部署完prometheus后,我们还需要来部署grafana

kubectl create -f grafana-deploy.yaml

然后执行完后,发现下面的问题

error: unable to recognize "grafana-deploy.yaml": no matches for kind "Deployment" in version "extensions/v1beta1"

我们需要修改如下内容

# 修改

apiVersion: apps/v1

# 添加selector

spec:

    replicas: 1

    selector:

        matchLabels:

            app: grafana

            component: core

修改完成后,我们继续执行上述代码

# 创建deployment

kubectl create -f grafana-deploy.yaml

# 创建svc

kubectl create -f grafana-svc.yaml

# 创建 ing

kubectl create -f grafana-ing.yaml

我们能看到,我们的grafana正在

配置数据源

下面我们需要开始打开 Grafana,然后配置数据源,导入数据显示模板

kubectl get svc -n kube-system

我们可以通过 ip + 30431 访问我们的 grafana 图形化页面

然后输入账号和密码:admin admin

进入后,我们就需要配置 prometheus 的数据源

和 对应的IP【这里IP是我们的ClusterIP】

设置显示数据的模板

选择Dashboard,导入我们的模板

然后输入 315 号模板

然后选择 prometheus数据源 mydb,导入即可

导入后的效果如下所示

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐