【hcie-cloud】【23】容器编排【k8s】【Kubernetes常用工作负载、Kubernetes调度器简介、Helm简介、缩略词】【下】

文章目录

单机容器面临的问题、Kubernetes介绍与安装、Kubernetes对象的基本操作、Kubernetes YAML文件编写基础
Kubernetes常用工作负载
- Kubernetes常用工作负载简介
- 创建一个无状态nginx集群
- 无状态工作负载Deployment说明
- 无状态工作负载Deployment常见操作
- 创建一个有状态的MySQL
- 有状态工作负载StatefulSet说明
- 创建一个Zabbix客户端的进程守护集
- 创建一个普通任务
- 创建一个周期性任务
- 为无状态工作负载创建一个反向代理
- Service的代理方式
- Ingress简介
- 为Service创建一个http访问链接
- ConfigMap简介
- Secret简介
- Kubernetes的认证与授权
- Kubernetes认证机制简介
- 授权机制RBAC简介
Kubernetes调度器简介
- Kube-scheduler调度过程
- 将有GPU需求的Pod调度到特定Node上
- 将无GPU需求的Pod尽量不要调度到特定Node上
- 干预调度的机制简介
- - 污点和容忍
  - 亲和性与反亲和性
Helm简介
- Helm介绍
- Helm介绍
- Helm基本操作
- Chart目录结构
- Chart.yaml文件简介
- Values.yaml文件简介
- Templates目录简介
- Helm语法简介
缩略语

单机容器面临的问题、Kubernetes介绍与安装、Kubernetes对象的基本操作、Kubernetes YAML文件编写基础

看这篇文章
【hcie-cloud】【22】容器编排【k8s】【单机容器面临的问题、Kubernetes介绍与安装、Kubernetes对象的基本操作、Kubernetes YAML文件编写基础】【上】

Kubernetes常用工作负载

Kubernetes常用工作负载简介

在这里插入图片描述

创建一个无状态nginx集群

需求：创建一个nginx集群，其中包含3个nginx服务。集群中的服务随时可以进行更新、回滚、恢复等操作

无状态工作负载Deployment说明

Deployment可通过命令行创建，也可以使用YAML文件创建
Deployment YAML文件包含三部分：
- GVK
- 元数据信息
- 对象规格
  - 副本数
  - 标签选择器
  - 更新策略
  - Pod规格信息
GVK和元数据信息和Pod YAML文件格式及参数基本一致
Deployment的标签选择器用于根据Pod标签来判断副本数是否满足
Deployment支撑两种更新策略：
- Recreate
  - 删除所有的Pod，然后重新创建
- RollingUpdate
  - 滚动更新
    - maxSurge：滚动更新时最大更新数
    - maxUnavailable：滚动更新时不可用数
maxSurge：滚动更新时最大更新数，例如一共有3个Pod，maxSurge设置为1，在更新流程为：新创1个----》4个-----》删除1个----》3个-----》新创1个-----》4个-----》删除1个------》3个-----》新创1个----》4个-----》删除1个----》3个
maxUnavailable：滚动更新时最大不可用Pod的数量。例如一共有3个Pod，maxUnavailable设置为1，在更新流程为：删除1个----》2个-----》新创1个-----》3个—》删除-1个----》2个-----》新创1个-----》3个—》删除-1个----》2个-----》新创1个-----》3个
如果maxSruge和maxUnavailable同时存在时，更新策略选取maxSurge的值
maxSruge和maxUnavailable的值可以使用百分比表示

无状态工作负载Deployment常见操作

-修改
- 命令“kubectl edit”修改
- 直接修改YAML文件

更新
- 命令“kubectl apply”进行更新
回滚
- 更新deployment时，使用“–record”记录版本
- 使用命令“kubectl rollout history deployment/deployment名称”查询更新记录，添加“–revision”可查看对应版本的信息
- 使用命令“kubectl rollout undo deployment/deployment名称 --to-revision=版本号”可将其回滚到指定版本

创建一个有状态的MySQL

需求：创建一个包含3个副本的MySQL有状态工作负载

在这里插入图片描述

有状态工作负载StatefulSet说明

StatefulSet YAML文件包含三部分：
- GVK
- 元数据信息
- 对象规格
  - 副本数
  - 标签选择器
  - 网络标识
  - Pod规格信息
StatefulSet有以下特点：
- 有序创建、有序删除、有序更新
- 支持更新，但是不支持更新策略
- 有稳定的网络标识
- 一般都会有由PV和PVC实现的持久化存储

创建一个Zabbix客户端的进程守护集

需求：为集群中的主机安装Zabbix客户端
DaemonSet说明：
- DaemonSet YAML文件有三部分组成：
  - GVK
  - 元数据信息
  - 对象规格
    - 标签选择器
    - Pod规格信息
DaemonSet有以下特点：
- 每个节点都会运行一个且只有一个Pod副本

在这里插入图片描述

创建一个普通任务

需求：尝试ping 192.168.100.11，测试该地址是否能够被ping通
Job说明：
- Job YAML文件有三部分组成：
  - GVK
  - 元数据信息
  - 对象规格
    - backoffLimit：如果任务失败，重试的次数
    - activeDeadlineSeconds：任务的存活时长
Job有以下特点：
- Job是一个一次性任务，可以包含一个或多个Pod
- Job YAML文件中的restartPolicy用来规定Pod如果故障执行的策略

在这里插入图片描述

activeDeadlineSeconds中的时间如果到了，系统会忽略backoffLimit中的时长，即只要activeDeadlineSeconds的存活时间到了，即时backoffLimit中的次数没有到，任务也会被终止
restartPolicy针对的是Pod，而不是Pod中的任务

创建一个周期性任务

需求：将上页图片中的job设置为每天晚上3点周期性执行

Cronjob说明：
- Cronjob YAML文件有三部分组成：
  - GVK
  - 元数据信息
  - 对象规格
    - Schedule
    - JobTemplate
Cronjob有以下特点：
- Cronjob是一个周期性任务，可以理解为周期性执行job
- 对象规格中schedule规定了执行任务的周期

在这里插入图片描述

Schedule中的五个字段按照顺序分别是：分、时、日、月、周

为无状态工作负载创建一个反向代理

需求：为nginx服务创建一个反向代理服务，通过该代理，可以负载均衡的访问到由多个nginx组成的集群
Service是一个将运行在一组 Pods上的应用程序公开为网络服务的抽象方法
Service是通过kube-proxy实现的
Service可以提供负载均衡的功能，实现方式有两种：
- Iptables
- Ipvs
Service YAML文件有三部分组成：
- GVK信息
- 元数据信息
- 对象规格

在这里插入图片描述

此处的nginx集群可以借助前面创建的无状态工作负载，标签为app: web，副本数为3。

Service的代理方式

Service提供了四种代理方式：
- ClusterIP：为工作负载提供一个虚拟IP，该IP仅能被集群内部访问
- NodePort：在ClusterIP的基础上为每一个node绑定一个端口，这样可以在集群外通过 nodeIP:端口号的形式访问到该服务。可用的端口范围为30000-32767
- LoadBalancer：用在云计算场景中，通过云计算中的ELB服务将请求转发到NodePort上
- ExternalName：用于将外部的服务引入到集群内
ClusterIP会被coreDNS映射一个域名，格式为：servicename.namespace.svc.cluster.local
ClusterIP可以被设置为none，意味着不为该集群分配虚拟IP，因此，如果只采用这种方式访问业务的Pod，dnsPolicy需要设置为ClusterFirst
ClusterIP方式中的虚拟IP和NodePort总的port可以手动指定，也可以自动生成

Ingress简介

Service的NodePort代理方式有两个不足：
- 管理复杂：当服务的数量较多时，所暴露端口的管理就会变的复杂
- 影响性能：NodePort后台借助iptables进行，占用宿主机的资源
Ingress是一种基于Service的七层代理服务
Ingress有两部分组成：
- ingressController：流量的入口
- Ingress：用于描述流量转发规则

在这里插入图片描述

要想使用ingress，必须先配置SVC，因为ingress不用于发现后端的Pod ip和Pod所监控的端口
ingressController能够解析ingress资源对象生成相应转发规则，同时能够实时感知后端Pod的变化以更新负载均衡后端地址

为Service创建一个http访问链接

需求：通过创建一个ingress对象，使用户可以通过http的方式访问到前面创建的Service nginx-proxy
Ingress YAML由三部分组成：
- GVK
- 元数据信息
  -annotations：固定为“kubernetes.io/ingress.class: “nginx””
- 对象规格
  - host：暴露的外网域名，需要能够将其解析成ingress-controller地址
  - http：使用的协议
  - service：被代理的service信息
  - paths：访问路径，可以使用不同的路径对应不同的服务
  - pathType：路径的匹配模式
    - Prefix
    - Exact
      -ImplementationSpecific

在这里插入图片描述

图片中service使用的是前面创建的service
pathType有三种方式：
- Prefix：基于以 / 分隔的 URL 路径前缀匹配
- Exact：精确匹配 URL 路径，且区分大小写
- ImplementationSpecific：对于这种路径类型，匹配方法取决于 IngressClass。具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理

ConfigMap简介

需求：在某应用开发时，需要对接MySQL，用户名为user1，密码为Huawei@123，为了避免密码直接在YAML文件中体现而导致泄露，因此需要将该应用的YAML文件和密码相关的配置分开存放
ConfigMap是一种用于存储应用所需配置信息的资源类型，用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件
通过ConfigMap可以方便的做到配置解耦，使得不同环境有不同的配置
ConfigMap最为常见的使用方式就是在环境变量和Volume中引用

在这里插入图片描述

Secret简介

需求：（接上页）密码以明文的方式放在configMap中，仍然存在泄露的风险，因此kubernetes提供了一种用于保存敏感信息的方式——Secret
Secret是一种加密存储的资源对象，可以将认证信息、证书、私钥等保存在Secret中，而不需要把这些敏感数据暴露到镜像或者Pod定义中，从而更加安全和灵活
Secret与ConfigMap非常像，都是key-value键值对形式，使用方式也相同，不同的是Secret会加密存储，所以适用于存储敏感信息。

在这里插入图片描述

Kubernetes的认证与授权

需求：为某部门创建名称为“business”的命名空间，保证该命名空间中的Pod仅能被用户yftyxa使用
需求中的“对命名空间Pod的使用”可以细化为具体的权限，在kubernetes中使用Role进行定义
需求中的用户为被赋权者，可以看做被作用的对象，在kubernetes中使用Subject进行定义
在kubernetes中，将Role的权限赋给Subject使用RoleBinding完成

在这里插入图片描述

Kubernetes认证机制简介

Kubernetes中的用户分为两种：
- 普通用户（User）
  普通用户一般是指由独立于Kubernetes之外的其它服务管理的用户账号，Kubernetes中不存在表示此类用户账号的对象，作用于系统全局，名称必须全局唯一
- 服务账户（ServiceAccount）
  服务账户为Pod中的进程调用Kubernetes API设计，通常需要绑定于特定的名称空间，作用仅局限在他们所在的Namespace，他们由API Server创建，或者通过API调用手动创建，附带着一组存储为Secret的用于访问API Server的凭据
Kubernetes支持多种认证方式，例如：
- LS双向认证
- 静态令牌文件
- 启动引导令牌
- 服务账号令牌
- OpenID Connect（OIDC）令牌
- Webhook 令牌身份认证
- 身份认证代理

授权机制RBAC简介

RBAC全称Role-Based Access Control，是Kubernetes集群基于角色的访问控制，实现授权决策，允许通过Kubernetes API动态配置策略
RBAC中的重要概念：
- Role：一组权限的集合，例如Role可以包含列出Pod权限及列出Deployment权限，Role用于给某个NameSpace中的资源进行鉴权
- ClusterRole：一组权限的集合，但与Role不同的是，ClusterRole可以在包括所有NameSpace和集群级别的资源或非资源类型进行鉴权
- Subject：被授权的对象，包括Service Account、User Account、Groups
- RoleBinding与ClusterRoleBindin：将Subject绑定到Role或ClusterRole。RoleBinding将使规则在命名空间内生效，而ClusterRoleBinding将使规则在集群中的所有命名空间中生效

Kubernetes调度器简介

Kube-scheduler调度过程

节点过滤（Predicate）
- 用于排除不满足条件的节点
- 人为设置的调度策略，在此阶段生效
节点打分（Priority）
- 对满足条件的节点进行打分
打分完成后，调度器会将Pod调度到分数最高的节点上。如果最高分的Node有多个，调度器会将Pod调度到随机的其中一台Node上

将有GPU需求的Pod调度到特定Node上

需求：某公司有图像处理业务，承载这些业务的Pod在进行计算时需要使用node节点上的GPU，因此需将Pod固定到指定的Node节点上
- 实施说明：
- 为node添加固定标签，例如针对以上需求可以为其添加“GPU”的标签，具体命令格式为：
  - kubectl label node 节点名称 key=value
- 在对应的YAML文件中，添加“nodeSelector”

[root@k8s01 ~]# kubectl label node k8s02 type=GPU
node/k8s02 labeled  
[root@k8s01 yaml]# cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  namespace: test
……..
  nodeSelector:
    type: GPU
[root@k8s01 yaml]# kubectl describe pod nodelabel -n test
……
Events:
  Type        Reason         Age     From                   Message
  ----           ------          ----        ----                      -------
  Normal  Scheduled      17s   default-scheduler  Successfully assigned test/nodelabel to k8s02

将无GPU需求的Pod尽量不要调度到特定Node上

需求：（接上页）该公司的其他非图像处理需使用非GPU Node，当此业务偶尔需求量较大时，也可将其调度到GPU节点上
实施说明：
- 为node添加污点（taint），并对该污点设置指定类型（PreferNoSchedule）例如针对以上需求可以为其添加“GPU”的污点
- 在对应的YAML文件中，添加对污点相关的容忍度

[root@k8s01 ~]# kubectl taint nodes k8s02 type=GPU:PreferNoSchedule
node/k8s02 tainted  
[root@k8s01 yaml]# cat deploy-taint.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: test
……..
      tolerations:
         - key: "type"
           effect: "PreferNoSchedule“
[root@k8s01 yaml]# kubectl get pod -n test -o wide 
NAME                                    READY   STATUS    RESTARTS   AGE       IP                    NODE
nodelabel3-868b59d4b5-ghsdj    1/1      Running     0            2m8s    10.244.235.137   k8s03   nodelabel3-868b59d4b5-v5mkd   1/1     Running     0            2m8s    10.244.236.176   k8s02   nodelabel3-868b59d4b5-wjmkx   1/1     Running     0            2m8s    10.244.235.136   k8s03

干预调度的机制简介

污点和容忍

干预调度有多种方式，推荐使用标签选择器及污点和容忍
标签选择器
- 即为指定的Node添加特定标签，使匹配标签的Pod可以调度到指定节点
- 如果为Node添加了多个标签，必须全部匹配才能将Pod调度到该节点上
污点和容忍
- Taint（污点）：
  - 为Node添加污点后，默认情况下，Pod不会被调度至该节点上，如果没有合适的节点，Pod会pending
  - 一个节点可以被打上多个污点标签，污点类型分为：
  - preferNoSchedule
    尽可能的不调度到该节点上
  - NoSchedule
    新创建的Pod不调度到该节点，已经运行在上面的Pod不会受影响
  - NoExecute
    完全不调度到该节点
- Tolerations（容忍）：
  - 一个Pod能都容忍节点上的污点时，表示其将该节点视为没有污点
  - 如果一个Node有多个污点，Pod需要容忍其全部后，才能和其他节点一样

亲和性与反亲和性

干预调度的方式除了标签选择器及污点和容忍，还包括：
- 亲和性与反亲和性
  - requiredDuringSchedulingIgnoredDuringExecution
    - 表示必须满足标签匹配才会将Pod调度在该节点
  - preferredDuringSchedulingIgnoredDuringExecution
    - 表示优先将Pod调度到标签匹配的节点，如果不匹配，也是可以进行调度
- 指定节点名称
  - 调度Pod时，将Node的名称作为匹配条件
亲和性和反亲和性需要配合operator进行，例如如果operator的值为In，表示亲和性，如果是NotIn，则表示反亲和性

Helm简介

Helm介绍

Kubernetes在部署有多个服务组成的应用时，有以下问题：
- 无法对所涉服务进行整体管理
- 无法对所涉服务脚本进行有效复用
- 无法对应用进行版本管理
Helm是kubernetes的包管理工具，是查找、分享和使用软件构建kubernetes的最优方式
Helm有以下功能：
- 从头开始创建新的chart
- 将chart打包成归档（tgz）文件
- 与存储chart的仓库进行交互
- 在现有的Kubernetes集群中安装和卸载chart
- 管理与Helm一起安装的chart的发布周期

Helm介绍

Helm有以下基本概念
- Chart
  - 创建Kubernetes应用程序所必需的一组信息
- Config
  - Config 包含了可以合并到打包的chart中的配置信息，用于创建一个可发布的对象
- Release
  - Release是chart的部署实例，一个chart在一个Kubernetes集群上可以有多个release
Helm包含以下组件：
- Helm客户端
- Helm库
Helm客户端是终端用户的命令行客户端。负责以下内容：
- 本地chart开发
- 管理仓库
- 管理发布
- 与Helm库建立接口
  - 发送安装的chart
  - 发送升级或卸载现有发布的请求
Helm库提供执行所有Helm操作的逻辑。与Kubernetes API服务交互并提供以下功能：
- 结合chart和配置来构建版本
- 将chart安装到Kubernetes中，并提供后续发布对象
- 与Kubernetes交互升级和卸载chart

Helm基本操作

配置repo
- 添加helm源：helm repo add 名称 helm库链接
- 查看helm源：helm repo list
- 搜索chart：helm search 名称
操控chart
- 创建chart：helm create 名称
- 安装chart：helm install 名称 release
- 下载并解压chart： helm pull 名称
- 推送chart：helm push 名称
- 升级chart：help upgrade 选项
- 回滚chart：help rollback release
- 卸载chart： helm uninstall 名称
Helm v2和Helm v3有很大的区别，以上列出的为v3版本的命令

Chart目录结构

使用命令helm create用于创建一个chart，系统会自动创建固定结构的目录

[root@k8s01 mytest]# tree mytest
mytest                                            ####chart包目录名              
├── charts                                     ####应用运行的依赖存放目录
├── Chart.yaml                              ####chart定义文件，包含chart的名称版本等信息
├── templates                               ####应用模板目录
│   ├── deployment.yaml
│   ├── _helpers.tpl                        ####存放模板信息
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt                          ####存放提示信息
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests                                  ####用于测试
│       └── test-connection.yaml
└── values.yaml                            ####chart包的参数配置文件，在模板文件中会调用定义的变量

Chart.yaml文件简介

Chart.yaml 中主要是放一些概要信息，比如 chart 的名称、版本、维护者、依赖（即子 chart）

apiVersion: v1
appVersion: 5.7.30
deprecated: true
description: DEPRECATED - Fast, reliable, scalable, and easy to use open-source relational
  database system.
home: https://www.mysql.com/
icon: https://www.mysql.com/common/logos/logo-mysql-170x115.png
keywords:
- mysql
- database
- sql
name: mysql
sources:
- https://github.com/kubernetes/charts
- https://github.com/docker-library/mysql
version: 1.6.9

上面内容来自http://mirror.azure.cn/kubernetes/charts/mysql/Chart.yaml
- appVersion：chart的版本
- Deprecated：表示当前chart已弃用
- keywords：关键字列表，便于检索
- Name：chart名称
- Source：下载列表
- Version：release版本

Values.yaml文件简介

在values.yaml文件中定义的值通过 Values 对象传递到templates下的YAML模板清单中
使用{{ .Values.key }}格式来引用values.yaml中定义好的参数

在这里插入图片描述

Templates目录简介

各类Kubernetes资源的配置模板都放置在templates目录下

[root@k8s01 helm]# ll mysql/templates/
total 48
-rw-r--r-- 1 root root  292 Nov 13  2020 configurationFiles-configmap.yaml
-rw-r--r-- 1 root root 8930 Nov 13  2020 deployment.yaml
-rw-r--r-- 1 root root 1290 Nov 13  2020 _helpers.tpl
-rw-r--r-- 1 root root  295 Nov 13  2020 initializationFiles-configmap.yaml
-rw-r--r-- 1 root root 2036 Nov 13  2020 NOTES.txt
-rw-r--r-- 1 root root  868 Nov 13  2020 pvc.yaml
-rw-r--r-- 1 root root 1475 Nov 13  2020 secrets.yaml
-rw-r--r-- 1 root root  328 Nov 13  2020 serviceaccount.yaml
-rw-r--r-- 1 root root  800 Nov 13  2020 servicemonitor.yaml
-rw-r--r-- 1 root root 1231 Nov 13  2020 svc.yaml
drwxr-xr-x 2 root root   50 May  9 05:24 tests

Helm语法简介

helm在全局作用域中有两个重要的全局对象：
- Values
- release
Value传入chart的值有四个来源
- chart中的values.yaml文件
- 若这是个子chart，来自父chart的values.yaml文件
- 执行 install 或 upgrade 时通过 -f或–values 指定
- 执行 install 或 upgrade 时通过 --set 选项传入
Release代表应用发布时带有的属性：
- {{ .Release.Name }} # release的名字
- {{ .Release.Time }} # release部署时间
- {{ .Release.Namespace }} # kubernetes命名空间
- {{ .Release.Revision }} # release版本号，是递增值，每次更新都加一
- {{ .Release.IsUpgrade }} # 若值为true则代表该release是一次更新
- {{ .Release.IsInstall }} # 若值为true则代表该release是一次安装

缩略语

缩略语	英文全称	解释
API	Application Programming Interface	应用编程接口，指的是应用程序之间为了保证互相通讯所提供的一系列特殊规则和要求
K8s	Kubernetes	Kubernetes的缩写
CLI	Command-line Interface	命令行视图
LB	Load Balance	负载均衡
AI	Artificial Intelligence	人工智能
OA	Office Automation	办公自动化
OTT	Over The Top	通过互联网向用户提供各种应用服务
CSI	Container Storage Interface	容器存储接口
CCE	Cloud Container Engine	华为云容器引擎
HCS	HUAWEI CLOUD Stack	华为云解决方案名称