资源控制器

1 资源控制器
- 1.1 控制基础
- - 1.1.1 控制原理
  - 1.1.2 控制对象
- 1.2 标签选择器
- - 1.2.1 标签基础
  - 1.2.2 标签选择器
- 1.3 副本控制器
- - 1.3.1 RC&RS
  - 1.3.2 Deploy基础
  - 1.3.3 Deploy进阶
  - 1.3.4 DaemonSet
  - 1.3.5 任务控制器
- 1.4 监视控制器
- - 1.4.1 metrics服务
  - 1.4.2 HPA实践

1 资源控制器

1.1 控制基础

1.1.1 控制原理

学习目标

这一节，我们从基础知识、控制流程、小结三个方面来学习。

基础知识

简介

	k8s集群通过 master角色主机 和 node角色主机 实现集群的环境搭建，所有的资源对象都是以pod为单元进行管理的。pod内部都是一个个相互关联的 容器对象。这些容器对象是来源于镜像仓库的镜像文件创建出来的。也就是说，k8s主要有 控制层面和数据层面来组成：
	控制层面
		API Server - 提供数据的注册和监视各种资源对象的功能
		Scheduler - 将资源对象调度到合适的节点中。
		Controller - 大量控制功能的集合,与API Server结合起来完成控制层面操作。
	数据层面
		Etcd - 提供各种数据的存储

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KODpaxus-1688393999858)(image/image-20220720124312141.png)]

节点资源管理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pwSc70Rv-1688393999859)(image/image-20220720130853925.png)]

k8s集群中的所有资源对象都是
	- 通过 master角色主机上的各种组件进行统一管理，
	- 基于node角色上的kubelet组件实现信息的交流。
	- pod内部的应用对象
		- 基于CRI让应用本身是运行在容器内部。
		- 基于CSI实现各种持久化数据的保存。
		- 基于CNI实现多个pod应用程序之间的通信交流。

资源访问

在这里插入图片描述

对于k8s集群应用来说，所有的程序应用都是
	- 运行在 Pod资源对象里面，
	- 借助于service资源对象向外提供服务访问。
	- 借助于各种存储资源对象实现数据的可持久化
	- 借助于各种配置资源对象实现配置属性、敏感信息的管理操作
	- k8s所有资源的操作必须具备相应的资源操作权限

控制流程

数据形态

在Kubernetes集群中，一切的应用服务都是以各种资源对象来进行管理的，这些资源对象的创建流程：
    首先：根据业务应用架构的分析，确定我们要使用的资源对象(Kubernetes中的)
    其次：使用描述性语言，编写资源对象的定义文件
    再次：基于资源对象定义文件进行对象初始化，形成资源对象。

也就是说，在kubernetes中，资源对象有两种形态：
	文件形态 - 编写出来的资源对象文件，有大量属性组成。
	对象形态 - 基于资源对象文件初始化后出来的应用对象。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oIWIcMe7-1688393999859)(image/image-20220720132008586.png)]

流程解读

API Server 从某种层面上来说，它仅仅是一个数据库的接口，只不过
	- 它支持对资源数据条目的 watch/notify 的功能，
	- 它对于数据存储的格式进行了限制定制，也就是说，只能接收固定格式的数据规范。
	
	如果我们仅仅将相关对象的属性信息插入到 APIServer上，就相当于我们做企业规划的时候，准备为某个项目配置多少资源，而这个时候，这些资源是没有到位的，无法进行项目运行的。而kube-controller-manager就相当于企业的创始人，根据APIServer上的规划，通过招人、拉投资等方式，将一个个的具体对象落地。
	
示例：
	比如每一个Service，就是一个Service对象的定义，同时它还代表了每个节点上iptables或ipvs规则，而这些节点上的规则，是由kube-controller-manager结合 kube-proxy来负责进行落地

pod管理

	每一个Pod，就是一个应用程序的定义，同时它还代表了每个节点上资源的限制，而这些节点上的应用程序，是由kube-controller-manager 结合 kubelet来负责进行落地。
	资源在创建的时候，一般会由Scheduler调度到合适的Node节点上。这个时候，kubeServer在各个节点上的客户端kubelet组件，如果发现调度的节点是本地，那么会在本地节点将对应的资源进行落地，同时负责各个节点上的与APIServer相关的资源对象的监视功能。
	
	注意，kubelet只负责单个节点上的Pod管理和调度。一旦我们需要对pod进行扩容缩容，涉及到了跨节点的资源调度，kubelet是做不到的。对于这些更高层级的应用资源调度，我们只能通过构建在 k8s 核心基础资源对象之上的控制资源来实现。

小结

1.1.2 控制对象

学习目标

这一节，我们从资源管理、对象解读、小结三个方面来学习。

资源管理

资源状态

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b1Dk5CbK-1688393999860)(image/image-20220720133504886.png)]

管理流程

1 用户向 APIserver中插入一个应用资源的数据形态
	- 这个数据形态中定义了该资源对象的 "期望"状态，
	- 数据经由 APIserver 保存到 ETCD 中。
2 kube-controller-manager 中的各种控制器会监视 Apiserver上与自己相关的资源对象的变动
	比如 Service Controller只负责Service资源的控制，Pod Controller只负责Pod资源的控制等。
3 一旦APIServer中的资源对象发生变动，对应的Controller执行相关的配置代码，到对应的node节点上运行
	- 该资源对象会在当前节点上，按照用户的"期望"进行运行
	- 这些实体对象的运行状态我们称为 "实际状态"
	- 即，控制器的作用就是确保 "期望状态" 与 "实际状态" 相一致
4 Controller将这些实际的资源对象状态，通过APIServer存储到ETCD的同一个数据条目的status的字段中
5 资源对象在运行过程中，Controller 会循环的方式向 APIServer 监控 spec 和 status 的值是否一致
	- 如果两个状态不一致，那么就指挥node节点的资源进行修改，保证 两个状态一致
	- 状态一致后，通过APIServer同步更新当前资源对象在ETCD上的数据

对象解读

管理器

	对于k8s场景中的应用任务来说，这些任务彼此之间主要存在 部署、扩容、缩容、更新、回滚等。虽然我基于pod的方式实现了应用任务的部署功能操作，但是对于我们自主式的pod来说，它并不能实现其他的几种任务。
	而这显然 距 k8s的核心功能 是有一定的距离的，因此，在k8s集群的核心功能之上，有一群非常重要的组件，这些组件就是用于对pod实现所谓的任务编排功能，这些组件我们统统将其称为 -- 控制器。

控制器分类

对于控制器来说，他有很多种类:
	副本控制器(Replicas Controller):
		负责在节点中对各种资源对象进行增删改查等动态管理。
    节点控制器(Node Controller): 
    	负责在节点出现故障时进行通知和响应
    任务控制器(Job controller): 
    	监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
    端点控制器(Endpoints Controller): 
    	填充端点(Endpoints)对象(即加入 Service 与 Pod)
    权限控制器(Service Account & Token Controllers): 
    	为新的命名空间创建默认帐户和 API 访问令牌
    等等

资源对象

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jkti7Yyh-1688393999860)(image/image-20220715012035435.png)]

控制器主要存在的几个部分：
	应用部署部分 - Deployment、RC、RS、DaemonSet、Statefulset、Job、CronJob、等
	服务访问部分 - Service、Ingress、Endpoint等
	数据存储部分 - PV、PVC、SC、Configmap、Secrets等
	安全管理部分 - SA、Token、Role等

控制器 vs Pod

控制器主要是通过管理pod来实现任务的编排效果，那么控制器是通过什么机制找到pod的呢？
	- 标签 或者 标签选择器

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yLIcGkcm-1688393999860)(image/image-20210930133845111.png)]

实践

小结

1.2 标签选择器

1.2.1 标签基础

学习目标

这一节，我们从标签定位、命令实践、小结三个方面来学习。

基础知识

简介

	Kubernetes通过标签来管理对应或者相关联的各种资源对象，Lable是kubernetes中的核心概念之一。

创建：	Lable通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除
本质：	lable本质上是一个key/value键值对，其中key与value由用户自己指定
注意：
	key的命名：由"字母、数字、_、.、-"这五类组成,只能以字符或数字作为开头和结尾。
	标签名称不能多于63个字符

作用：	
	一个资源对象可以定义多个Lable，同一个Lable也可以关联多个资源对象上去
	通过对Lable的管理从而达到对同Lable的资源进行分组管理(分配、调度、配置、部署等)。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N9wZSxvr-1688393999860)(image/image-20220720140102822.png)]

操作方法

方法1：资源清单方法
    在特定的属性后面按照指定方式增加内容即可，格式如下：
        labels:
          key: value
    注意：
    	labels 是 一个复数格式。

方法2： 命令行方法
    查看标签：kubectl get pods -l label_name=label_value
        参数：
            -l 就是指定标签条件，获取指定资源对象，=表示匹配，!= 表示不匹配
            如果后面的选择标签有多个的话，使用逗号隔开
            如果针对标签的值进行范围过滤的话，可以使用如下格式：
            -l "label_name in|notin (value1, value2, value3, ...)"
    增加标签：kubectl label 资源类型 资源名称 label_name=label_value
        参数：
            同时增加多个标签，只需要在后面多写几个就可以了，使用空格隔开
            默认情况下，已存在的标签是不能修改的，使用 --overwrite=true 表示强制覆盖
            label_name=label_value样式写成 label_name- ，表示删除label

简单实践

资源清单方式

	资源对象Lablel不是单独定义的，是需要依附在某些资源对象上才可以，常见的就是依附在Pod对象上。初始化Pod资源对象应用时候，在资源对象的元数据metadata属性下添加一条Labels配置：
	
[root@kubernetes-master1 ~]# kubectl  explain pod.metadata.labels
KIND:     Pod
VERSION:  v1

FIELD:    labels <map[string]string>

DESCRIPTION:
     Map of string keys and values that can be used to organize and categorize
     (scope and select) objects. May match selectors of replication controllers
     and services. More info: http://kubernetes.io/docs/user-guide/labels

创建专属管理目录
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/label -p
[root@kubernetes-master1 ~]# cd /data/kubernetes/label
[root@kubernetes-master1 /data/kubernetes/label]#

查看资源对象文件
[root@kubernetes-master1 /data/kubernetes/label]# cat 01_kubernetes_label_resource.yaml
apiVersion: v1
kind: Pod
metadata:
  name: superopsmsb-label
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-web
    image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1

应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  apply -f 01_kubernetes_label_resource.yaml
pod/superopsmsb-label created

查看标签效果
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  describe pod superopsmsb-label
Name:         superopsmsb-label
...
Labels:       app=nginx
...

查看pod的基本信息
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod --show-labels
NAME                READY   STATUS    RESTARTS   AGE    LABELS
superopsmsb-label   1/1     Running   0          101s   app=nginx

列出指定标签的pod
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod -l app
NAME                READY   STATUS    RESTARTS   AGE
superopsmsb-label   1/1     Running   0          109s

清理环境
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  delete -f 01_kubernetes_label_resource.yaml
pod "superopsmsb-label" deleted

命令行方式

查看命令帮助
[root@kubernetes-master1 /data/kubernetes/label]# kubectl run --help
  ...
  -l, --labels='': Comma separated labels to apply to the pod. Will override previous values.

使用命令创建一个pod
[root@kubernetes-master1 /data/kubernetes/label]# kubectl run nginx-web --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1 --labels="app=nginx-web,env=prod"
pod/nginx-web created

查看标签效果
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-web   1/1     Running   0          3s
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  get pod --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
nginx-web   1/1     Running   0          8s    app=nginx-web,env=prod

给pod打标签
[root@kubernetes-master1 /data/kubernetes/label]# kubectl label pod nginx-web release=1 pro=dev
pod/nginx-web labeled
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  get pod --show-labels
NAME        READY   STATUS    RESTARTS   AGE    LABELS
nginx-web   1/1     Running   0          102s   app=nginx-web,env=prod,pro=dev,release=1

强制覆盖实践
[root@kubernetes-master1 /data/kubernetes/label]# kubectl label pod nginx-web release=2
error: 'release' already has a value (1), and --overwrite is false
[root@kubernetes-master1 /data/kubernetes/label]# kubectl label pod nginx-web release=2 --overwrite=true
pod/nginx-web labeled
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod nginx-web  --show-labels
NAME        READY   STATUS    RESTARTS   AGE     LABELS
nginx-web   1/1     Running   0          2m24s   app=nginx-web,env=prod,pro=dev,release=2

小结

1.2.2 标签选择器

学习目标

这一节，我们从属性解读、简单实践、小结三个方面来学习。

基础知识

简介

	Lablel附加到Kubernetes集群中的各种资源对象上，目的就是对这些资源对象进行分组管理，而分组管理的核心就是：Lablel Selector。

	Lablel Selector跟Label一样，不能单独定义，必须附加在一些资源对象的定义文件上。一般附加在RC和Service等控制器资源对象文件中。

表达式

基础Label Selector表达式

等式：
    name = nginx 					匹配所有具有标签 name = nginx 的资源对象
    name != nginx					匹配所有不具有标签 name = nginx 的资源对象
集合：
    env in (dev, test) 				匹配所有具有标签 env = dev 或者 env = test 的资源对象
    name not in (frontend)  		匹配所有不具有标签 name = frontend 的资源对象

扩展匹配Label Selector表达式

匹配标签：
    matchLabels:
      name: nginx
匹配表达式：
    matchExpressions:
      - {key: name, operator: NotIn, values: [frontend]}

环境准备

创建携带不同标签的pod
[root@kubernetes-master1 /data/kubernetes/label]# kubectl run nginx-web2 --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1 --labels="app=nginx-web,env=prod"
pod/nginx-web2 created
[root@kubernetes-master1 /data/kubernetes/label]# kubectl run nginx-web3 --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1 --labels="app=nginx-web,env=dev"
pod/nginx-web3 created
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod
NAME         READY   STATUS    RESTARTS   AGE
nginx-web    1/1     Running   0          10m
nginx-web2   1/1     Running   0          17s
nginx-web3   1/1     Running   0          6s

简单实践

命令行简单实践

等值过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l env=prod
NAME         READY   STATUS    RESTARTS   AGE
nginx-web    1/1     Running   0          11m
nginx-web2   1/1     Running   0          60s

[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l env==dev
NAME         READY   STATUS    RESTARTS   AGE
nginx-web3   1/1     Running   0          68s

反向过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l env!=prod
NAME         READY   STATUS    RESTARTS   AGE
nginx-web3   1/1     Running   0          97s

标签名过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l app
NAME         READY   STATUS    RESTARTS   AGE
nginx-web    1/1     Running   0          12m
nginx-web2   1/1     Running   0          2m8s
nginx-web3   1/1     Running   0          117s

标签名反向过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l '!app'
No resources found in default namespace. 
注意：为了避免shell解析，这里需要添加单引号

in集合过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l "app in (nginx-web, test, en)"
NAME         READY   STATUS    RESTARTS   AGE
nginx-web    1/1     Running   0          13m
nginx-web2   1/1     Running   0          3m19s
nginx-web3   1/1     Running   0          3m8s

notin反向集合过滤
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pods -l "app notin (test, en)"
NAME         READY   STATUS    RESTARTS   AGE
nginx-web    1/1     Running   0          14m
nginx-web2   1/1     Running   0          4m4s
nginx-web3   1/1     Running   0          3m53s

删除标签
[root@kubernetes-master1 /data/kubernetes/label]# kubectl label pod nginx-web app- env-
pod/nginx-web unlabeled
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get pod nginx-web  --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
nginx-web   1/1     Running   0          15m   <none>

实践

查看当前效果
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  get pod --show-labels
NAME         READY   STATUS    RESTARTS   AGE     LABELS
nginx-web    1/1     Running   0          16m     <none>
nginx-web2   1/1     Running   0          5m48s   app=nginx-web,env=prod
nginx-web3   1/1     Running   0          5m37s   app=nginx-web,env=dev

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/label]# cat 02_kubernetes_label_service.yaml
kind: Service
apiVersion: v1
metadata:
  name: superopsmsb-service
spec:
  selector:
    env: prod
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  apply -f 02_kubernetes_label_service.yaml
service/superopsmsb-service created

查看资源匹配效果
[root@kubernetes-master1 /data/kubernetes/label]# kubectl get svc -o wide
NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
kubernetes            ClusterIP   10.96.0.1       <none>        443/TCP   21h   <none>
superopsmsb-service   ClusterIP   10.109.55.120   <none>        80/TCP    51s   env=prod

[root@kubernetes-master1 /data/kubernetes/label]# kubectl  describe svc superopsmsb-service
Name:              superopsmsb-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          env=prod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.109.55.120
IPs:               10.109.55.120
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.3.16:80
Session Affinity:  None
Events:            <none>

清理环境
[root@kubernetes-master1 /data/kubernetes/label]# kubectl  delete pod nginx-web nginx-web2 nginx-web3

小结

1.3 副本控制器

1.3.1 RC&RS

学习目标

这一节，我们从属性解读、简单实践、小结三个方面来学习。

属性解读

简介

	Replication Controller（RC），是kubernetes系统中的核心概念之一。RC是Kubernetes集群实现Pod资源对象自动化管理的基础。

简单来说，RC其实是定义了一个期望的场景，RC有以下特点：
1、组成：定义了Pod副本的期望状态：包括数量，筛选标签和模板
	Pod期待的副本数量(replicas).
	永远筛选目标Pod的标签选择器(Label Selector)
	Pod数量不满足预期值，自动创建Pod时候用到的模板(template)
2、意义：自动监控Pod运行的副本数目符合预期，保证Pod高可用的核心组件，常用于Pod的生命周期管理

	RC在kubernetes的早期kubernetes v1.2版本就被RS(ReplicaSet)替代了，但是RC目前仍然能够正常使用，因为RC的核心功能不仅仅是RS的核心，也是Deployment资源对象的核心。
	RC 和 RS 的区别仅仅是资源对象名称和标签选择器不一样而已。

属性解读

apiVersion: apps/v1
kind: ReplicaSet | ReplicationController
metadata:
  name: …
  namespace: …
spec:
  minReadySeconds <integer>  		# Pod就绪后多少秒内，Pod任一容器无crash方可视为“就绪”
  replicas <integer> 				# 期望的Pod副本数，默认为1
  selector: 						# 标签选择器，必须匹配template字段中Pod模板中的标签；
    matchExpressions <[]Object> 	# 标签选择器表达式列表，多个列表项之间为“与”关系
    matchLabels <map[string]string> # map格式的标签选择器
  template:  						# Pod模板对象
    metadata:  						# Pod对象元数据
      labels:  						# 由模板创建出的Pod对象所拥有的标签，必须要能够匹配前面定义的标签选择器
    spec:  							# Pod规范，格式同自主式Pod
      ……
注意：
    RS和RC之间selector的格式区别
    	RC 的标签匹配是 key：value
    	RS 的标签匹配是 matchExpressions | matchLabels

	当我们通过"资源定义文件"定义好了一个RC资源对象，把它提交到Kubernetes集群中以后，Master节点上的Controller Manager组件就得到通知(问：为什么？因为什么？)，定期巡检系统中当前存活的Pod，并确保Pod实例数量刚到满足RC的期望值。
	如果Pod数量大于RC定义的期望值，那么就杀死一些Pod
	如果Pod数量小于RC定义的期望值，那么就创建一些Pod
所以：通过RC资源对象，Kubernetes实现了业务应用集群的高可用性，大大减少了人工干预，提高了管理的自动化。
拓展：
	想要扩充Pod副本的数量，可以直接修改replicas的值即可

在这里插入图片描述

简单实践

准备工作

创建资源目录
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/controller -p
[root@kubernetes-master1 ~]# cd /data/kubernetes/controller/
[root@kubernetes-master1 /data/kubernetes/controller]#

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 01_kubernetes_rc_test.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: superopsmsb-rc
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:   
      containers:
      - name: nginx-web
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  apply -f 01_kubernetes_rc_test.yaml
replicationcontroller/superopsmsb-rc created

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get rc
NAME             DESIRED   CURRENT   READY   AGE
superopsmsb-rc   2         2         2       34s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
superopsmsb-rc-pxblj   1/1     Running   0          3s
superopsmsb-rc-qtv4f   1/1     Running   0          3s

RS实践

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 02_kubernetes_rs_test.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: superopsmsb-rs
spec:
  minReadySeconds: 0
  replicas: 3
  selector:
    matchLabels:
      app: rs-test
  template:
    metadata:
      labels:
        app: rs-test
    spec:
      containers:
      - name: nginx-web
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  apply -f 02_kubernetes_rs_test.yaml
replicaset.apps/superopsmsb-rs created

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get rs
NAME             DESIRED   CURRENT   READY   AGE
superopsmsb-rs   3         3         3       2s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get pod -l app=rs-test
NAME                   READY   STATUS    RESTARTS   AGE
superopsmsb-rs-csjs5   1/1     Running   0          23s
superopsmsb-rs-d6wb7   1/1     Running   0          23s
superopsmsb-rs-n7k6w   1/1     Running   0          23s

控制实践

删除pod
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  delete pod -l app=nginx
pod "superopsmsb-rc-pxblj" deleted
pod "superopsmsb-rc-qtv4f" deleted
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  delete pod -l app=rs-test
pod "superopsmsb-rs-csjs5" deleted
pod "superopsmsb-rs-d6wb7" deleted
pod "superopsmsb-rs-n7k6w" deleted

查看删除后效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get rc
NAME             DESIRED   CURRENT   READY   AGE
superopsmsb-rc   2         2         2       5m4s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get rs
NAME             DESIRED   CURRENT   READY   AGE
superopsmsb-rs   3         3         3       3m33s

检查pod效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
superopsmsb-rc-bsmqg   1/1     Running   0          99s
superopsmsb-rc-mzv9s   1/1     Running   0          99s
superopsmsb-rs-7fgr8   1/1     Running   0          46s
superopsmsb-rs-8k9kd   1/1     Running   0          46s
superopsmsb-rs-gnxp8   1/1     Running   0          46s

环境清理

[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  delete -f 01_kubernetes_rc_test.yaml -f 02_kubernetes_rs_test.yaml
replicationcontroller "superopsmsb-rc" deleted
replicaset.apps "superopsmsb-rs" deleted

1.3.2 Deploy基础

学习目标

这一节，我们从属性解读、简单实践、小结三个方面来学习。

基础知识

简介

	Deployment资源对象在内部使用Replica Set来实现Pod的自动化编排。Deployment资源对象不管是在作用、文件定义格式、具体操作等方面都可以看做RS的一次升级，两者的相似度达90%。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EmoAjjfS-1688393999868)(image/image-20220720143435219.png)]

相对于RC的一个最大的升级是:	
	1 我们可以随时知道当前Pod的"部署"进度
		即Pod创建--调度--绑定Node--在目标Node上启动容器，整个流程都是自动化的。
	2 Deployment的更新是滚动式更新。
		RC 和 RS 是手动式更新

资源对象属性

apiVersion: apps/v1  			# API群组及版本
kind: Deployment  				# 资源类型特有标识
metadata:
  name <string>  				# 资源名称，在作用域中要唯一
  namespace <string>  			# 名称空间；Deployment隶属名称空间级别
spec:
  minReadySeconds <integer>  	# Pod就绪后多少秒内任一容器无crash方可视为“就绪”
  replicas <integer> 			# 期望的Pod副本数，默认为1
  selector <object> 			# 标签选择器，必须匹配template字段中Pod模板中的标签
  template <object>  			# Pod模板对象

  revisionHistoryLimit <integer> # 滚动更新历史记录数量，默认为10
  strategy <Object> 			# 滚动更新策略
    type <string>  				# 滚动更新类型，可用值有Recreate和RollingUpdate；
    rollingUpdate <Object>  	# 滚动更新参数，专用于RollingUpdate类型
      maxSurge <string>  		# 更新期间可比期望的Pod数量多出的数量或比例；
      maxUnavailable <string>  	# 更新期间可比期望的Pod数量缺少的数量或比例，10， 
  progressDeadlineSeconds <integer> # 滚动更新故障超时时长，默认为600秒
  paused <boolean>  			# 是否暂停部署过程

简单实践

手工命令实践

创建资源对象
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl create deployment nginx-test --image=kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1 --replicas=3
deployment.apps/nginx-test created

查看资源的体系结构
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get deployments.apps
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-test   3/3     3            3           9s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get rs
NAME                   DESIRED   CURRENT   READY   AGE
nginx-test-657b8889c   3         3         3       13s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx-test-657b8889c-k264w   1/1     Running   0          15s
nginx-test-657b8889c-l65gh   1/1     Running   0          15s
nginx-test-657b8889c-txfhr   1/1     Running   0          15s

清理资源对象
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl delete deployments.apps nginx-test
deployment.apps "nginx-test" deleted

资源清单实践

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 03_kubernetes_deploy_test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: superopsmsb-deployment
spec:
  minReadySeconds: 0
  replicas: 3
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      containers:
      - name: nginx-web
        image: kubernetes-register.superopsmsb.com/superopsmsb/nginx_web:v0.1
    
应用资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl apply -f 03_kubernetes_deploy_test.yaml
deployment.apps/superopsmsb-deployment created

查看资源结构
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
superopsmsb-deployment   3/3     3            3           65s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get rs
NAME                               DESIRED   CURRENT   READY   AGE
superopsmsb-deployment-677cc5798   3         3         3       69s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get pod
NAME                                     READY   STATUS    RESTARTS   AGE
superopsmsb-deployment-677cc5798-dzq9b   1/1     Running   0          72s
superopsmsb-deployment-677cc5798-q2zbk   1/1     Running   0          72s
superopsmsb-deployment-677cc5798-tnqrm   1/1     Running   0          72s

小结

1.3.3 Deploy进阶

学习目标

这一节，我们从扩容缩容、动态更新、小结三个方面来学习。

扩容缩容

简介

基于资源对象调整：
	kubectl scale <--current-replicas=3> --replicas=5 deployment/deploy_name
基于资源文件调整:
	kubectl scale --replicas=4 -f deploy_name.yaml

简单实践

资源扩容
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
superopsmsb-deployment   3/3     3            3           3m24s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  scale deployment superopsmsb-deployment --replicas=10
deployment.apps/superopsmsb-deployment scaled
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps                                NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
superopsmsb-deployment   10/10   10           10          3m40s

资源缩容
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
superopsmsb-deployment   10/10   10           10          5m6s
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  scale -f 03_kubernetes_deploy_test.yaml --replicas=1
deployment.apps/superopsmsb-deployment scaled
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps   NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
superopsmsb-deployment   1/1     1            1           5m15s

动态更新

简介

更新命令1：kubectl set SUBCOMMAND [options] 资源类型 资源名称
    子命令：常用的子命令就是image
    参数详解：
        --record=true		更改的时候，将信息增加到历史记录中

回滚命令： kubectl rollout SUBCOMMAND [options] 资源类型 资源名称
    子命令：
    history   	显示 rollout 历史
    status    	显示 rollout 的状态
    undo     	撤销上一次的 rollout

更新软件版本

更新软件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl set image -f 03_kubernetes_deploy_test.yaml nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0
deployment.apps/superopsmsb-deployment image updated

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get deployments.apps -o wide
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES                                                         SELECTOR
superopsmsb-deployment   1/1     1            1           7m19s   nginx-web    kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0   app=deploy-test

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  exec -it superopsmsb-deployment-cc6444576-ngvt4 -- env | grep VERSION
NGINX_VERSION=1.16.0
结果显示：
	软件版本更新完毕

查看历史记录

查看更新状态
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout status deployment superopsmsb-deployment
deployment "superopsmsb-deployment" successfully rolled out

查看更新历史
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout history deployment superopsmsb-deployment
deployment.apps/superopsmsb-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
结果显示：
	更新时候没有显示记录，我们可以借助于 已经被废弃的--record=true 的方式，增加更新记录

携带记录式更新
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl set image -f 03_kubernetes_deploy_test.yaml nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.23.0 --record=true
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/superopsmsb-deployment image updated
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout history deployment superopsmsb-deployment   deployment.apps/superopsmsb-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl set image nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.23.0 --filename=03_kubernetes_deploy_test.yaml --record=true

携带记录式更新
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl set image -f 03_kubernetes_deploy_test.yaml nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0 --record=true
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/superopsmsb-deployment image updated
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout history deployment superopsmsb-deployment   deployment.apps/superopsmsb-deployment
REVISION  CHANGE-CAUSE
1         <none>
3         kubectl set image nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.23.0 --filename=03_kubernetes_deploy_test.yaml --record=true
4         kubectl set image nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0 --filename=03_kubernetes_deploy_test.yaml --record=true

资源回滚操作
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout undo deployment superopsmsb-deployment
deployment.apps/superopsmsb-deployment rolled back
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl rollout history deployment superopsmsb-deployment
deployment.apps/superopsmsb-deployment
REVISION  CHANGE-CAUSE
1         <none>
4         kubectl set image nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.16.0 --filename=03_kubernetes_deploy_test.yaml --record=true
5         kubectl set image nginx-web=kubernetes-register.superopsmsb.com/superopsmsb/nginx:1.23.0 --filename=03_kubernetes_deploy_test.yaml --record=true
结果显示：
	将1.23.0版本拿回来了

小结

1.3.4 DaemonSet

学习目标

这一节，我们从属性解读、简单实践、小结三个方面来学习。

基础知识

简介

	DaemonSet能够让所有（或者特定）的节点"精确的"运行同一个pod，它一般应用在集群环境中所有节点都必须运行的守护进程的场景。
	我们在部署k8s环境的时候，网络的部署样式就是基于这种DaemonSet的方式，因为对于网络来说，是所有节点都必须具备的基本能力。

信息查看

[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get ds -n kube-system
NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE ...
kube-proxy   6         6         6       6            6         ...
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get ds -n kube-flannel
NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE ...
kube-flannel-ds   6         6         6       6            6         ...

应用场景

    当节点加入到K8S集群中，pod会被（DaemonSet）调度到该节点上运行，当节点从K8S集群中被移除，被DaemonSet调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
    在某种程度上，DaemonSet承担了RC的部分功能，它也能保证相关pods持续运行，如果一个DaemonSet的Pod被杀死、停止、或者崩溃，那么DaemonSet将会重新创建一个新的副本在这台计算节点上。
    
常用于后台支撑服务
	集群存储守护进程、日志收集服务、监控服务

资源属性

apiVersion: apps/v1  				# API群组及版本
kind: DaemonSet  					# 资源类型特有标识
metadata:
  name <string>  					# 资源名称，在作用域中要唯一
  namespace <string>  				# 名称空间；DaemonSet资源隶属名称空间级别
spec:
  minReadySeconds <integer>  		# Pod就绪后多少秒内任一容器无crash方可视为“就绪”
  selector <object> 				# 标签选择器，必须匹配template字段中Pod模板中的标签
  template <object>  				# Pod模板对象；

  revisionHistoryLimit <integer> 	# 滚动更新历史记录数量，默认为10；
  updateStrategy <Object> 			# 滚动更新策略
    type <string>  					# 滚动更新类型，可用值有OnDelete和RollingUpdate；
    rollingUpdate <Object>  		# 滚动更新参数，专用于RollingUpdate类型
      maxUnavailable <string>  		# 更新期间可比期望的Pod数量缺少的数量或比例

简单实践

准备工作

获取镜像到本地，然后改名后提交到本地仓库
[root@kubernetes-master1 ~]# docker pull prom/node-exporter
[root@kubernetes-master1 ~]# docker tag prom/node-exporter:latest kubernetes-register.superopsmsb.com/superopsmsb/node-exporter
[root@kubernetes-master1 ~]# docker push kubernetes-register.superopsmsb.com/superopsmsb/node-exporter
[root@kubernetes-master1 ~]# docker rmi prom/node-exporter:latest

监控实践

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 04_kubernetes_daemonset_test.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: superopsmsb-daemonset
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      name: prometheus-node-exporter
      labels:
        app: prometheus
    spec:
      containers:
      - image: kubernetes-register.superopsmsb.com/superopsmsb/node-exporter
        name: prometheus-node-exporter
        ports:
        - name: prom-node-exp
          containerPort: 9100
          hostPort: 9100
      hostNetwork: true
      hostPID: true
  属性解析：
  	hostNetwork 和 hostPID 容器共享宿主机的 网络和PID
  	
应用配置文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl apply -f 04_kubernetes_daemonset_test.yaml
daemonset.apps/superopsmsb-daemonset created

检查效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get ds
NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE  ...
superopsmsb-daemonset   3         3         3       3            3          ...

[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  get pod -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP          NODE               NOMINATED NODE   READINESS GATES
superopsmsb-daemonset-7v4z2   1/1     Running   0          20s   10.0.0.15   kubernetes-node1   <none>           <none>
superopsmsb-daemonset-8sznt   1/1     Running   0          20s   10.0.0.17   kubernetes-node3   <none>           <none>
superopsmsb-daemonset-q72bj   1/1     Running   0          20s   10.0.0.16   kubernetes-node2   <none>           <none>

访问监控数据
[root@kubernetes-master1 /data/kubernetes/controller]# curl -s 10.0.0.15:9100/metrics | head -n2
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
[root@kubernetes-master1 /data/kubernetes/controller]# curl -s 10.0.0.16:9100/metrics | head -n2
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
[root@kubernetes-master1 /data/kubernetes/controller]# curl -s 10.0.0.17:9100/metrics | head -n2
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary

小结

1.3.5 任务控制器

学习目标

这一节，我们从 Job实践、CronJob实践、小结三个方面来学习。

Job实践

简介

	在我们日常的工作中，经常会遇到临时执行一个动作，但是这个动作必须在某个时间点执行才可以，而我们又不想一直这么傻傻的等待，即使等待到了，由于特殊原因，我们执行的时候，已经不是准确的时间点了。针对于这种场景，我们一般使用job的方式来帮助我们定制化的完成任务。

属性解析

apiVersion: batch/v1  					# API群组及版本
kind: Job  								# 资源类型特有标识
metadata:
  name <string>  						# 资源名称，在作用域中要唯一
  namespace <string>  					# 名称空间；Job资源隶属名称空间级别
spec:
  selector <object> 					# 标签选择器，必须匹配template字段中Pod模板中的标签
  template <object>  					# Pod模板对象
  completions <integer> 				# 期望的成功完成的作业次数，成功运行结束的Pod数量
  ttlSecondsAfterFinished  <integer> 	# 终止状态作业的生存时长，超期将被删除
  parallelism  <integer>  				# 作业的最大并行度，默认为1
  backoffLimit <integer>  				# 将作业标记为Failed之前的重试次数，默认为6
  activeDeadlineSeconds  <integer> 		# 作业启动后可处于活动状态的时长

简单实践

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 05_kubernetes_job_test.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: superopsmsb-job
spec:
  completions: 5
  parallelism: 1
  template:
    spec:
      containers:
      - name: job-test
        image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
        command: ["/bin/sh","-c","echo job-test; sleep 1"]
  	  restartPolicy: OnFailure
  	  
应用配置文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  apply -f 05_kubernetes_job_test.yaml
job.batch/superopsmsb-job created

效果查看
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get job
NAME              COMPLETIONS   DURATION   AGE
superopsmsb-job   5/5           20s        58s

查看所有的任务日志
[root@kubernetes-master1 /data/kubernetes/controller]# job_list=$(kubectl get pod | grep job | sort -k 5 | awk '{print $1}')
[root@kubernetes-master1 /data/kubernetes/controller]# for i in $job_list; do kubectl logs $i --timestamps=true; done
2062-17-20T07:10:52.090455777Z job-test
2062-17-20T07:10:48.000080414Z job-test
2062-17-20T07:10:43.951750054Z job-test
2062-17-20T07:10:39.926175031Z job-test
2062-17-20T07:10:35.797860595Z job-test
结果显示：	
	这些任务，确实是串行的方式来执行，由于涉及到任务本身是启动和删除，所以时间间隔要大于3s

CronJob实践

简介

	CronJob其实就是在Job的基础上加上了时间调度，我们可以：在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。其效果与linux中的crontab效果非常类似，一个CronJob对象其实就对应中crontab文件中的一行，它根据配置的时间格式周期性地运行一个Job，格式和crontab也是一样的。

crontab的格式如下：
   分       时       日       月      周     命令 
 (0～59)  (0～23)  (1～31)  (1～12)  (0～7)

属性解析

apiVersion: batch/v1  					# API群组及版本
kind: CronJob  							# 资源类型特有标识
metadata:
  name <string>  						# 资源名称，在作用域中要唯一
  namespace <string>  					# 名称空间；CronJob资源隶属名称空间级别
spec:
  jobTemplate  <Object>  				# job作业模板，必选字段
    metadata <object>  					# 模板元数据
    spec <object> 						# 作业的期望状态
  schedule <string>  					# 调度时间设定，必选字段
  concurrencyPolicy  <string> 			# 并发策略，可用值有Allow、Forbid和Replace
  failedJobsHistoryLimit <integer> 		# 失败作业的历史记录数，默认为1
  successfulJobsHistoryLimit  <integer> # 成功作业的历史记录数，默认为3
  startingDeadlineSeconds  <integer> 	# 因错过时间点而未执行的作业的可超期时长
  suspend  <boolean> 					# 是否挂起后续的作业，不影响当前作业，默认为false

简单实践

创建资源清单文件
[root@kubernetes-master1 /data/kubernetes/controller]# cat 06_kubernetes_cronjob_test.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: superopsmsb-cronjob
spec:
  schedule: "* * * * *"
  successfulJobsHistoryLimit: 100
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: cronjob
            image: kubernetes-register.superopsmsb.com/superopsmsb/busybox:1.28
            command: ["/bin/sh","-c","echo cronjob-test"]
  	  
应用配置文件
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  apply -f 06_kubernetes_cronjob_test.yaml
cronjob.batch/superopsmsb-cronjob created

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get cronjobs.batch
NAME                  SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
superopsmsb-cronjob   * * * * *   False     0        38s             50s

等待8分钟后查看job任务执行效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get jobs.batch
NAME                           COMPLETIONS   DURATION   AGE
superopsmsb-cronjob-27638376   1/1           4s         7m55s
superopsmsb-cronjob-27638377   1/1           3s         6m55s
superopsmsb-cronjob-27638378   1/1           3s         5m55s
superopsmsb-cronjob-27638379   1/1           3s         4m55s
superopsmsb-cronjob-27638380   1/1           3s         3m55s
superopsmsb-cronjob-27638381   1/1           4s         2m55s
superopsmsb-cronjob-27638382   1/1           3s         115s
superopsmsb-cronjob-27638383   1/1           3s         55s
注意：
	这是6分钟过后才进行查看的效果
	
查看日志效果
[root@kubernetes-master1 /data/kubernetes/controller]# cornjob_list=$(kubectl get pod | grep cronjob | awk '{print $1}')
[root@kubernetes-master1 /data/kubernetes/controller]# for i in $cornjob_list ;do kubectl logs $i --timestamps=true; done
2022-07-20T07:36:00.998466094Z cronjob-test
2022-07-20T07:37:00.992842042Z cronjob-test
2022-07-20T07:38:00.996314468Z cronjob-test
2022-07-20T07:39:01.039271449Z cronjob-test
2022-07-20T07:40:00.999991261Z cronjob-test
2022-07-20T07:41:01.032948311Z cronjob-test
2022-07-20T07:42:01.073678317Z cronjob-test
2022-07-20T07:43:01.076927560Z cronjob-test
2022-07-20T07:44:01.082994524Z cronjob-test

1.4 监视控制器

1.4.1 metrics服务

学习目标

这一节，我们从监控指标、环境部署、小结三个方面来学习。

基础知识

简介

	k8s管理平台为了保证所有的资源对象能够在用户负载的情况下稳定运行，需要获取资源对象的实际运行状态，然后根据实际情况进行容量的扩容和缩容操作，从而保证整个业务集群环境是正常运行的。
	在k8s中他们主要是以指标的样式来获取的，这些指标包括核心指标和自定义指标。在k8s的系统上包含了各种各样的指标数据，早期的k8s系统，为kubelet集成了一个CAdvsior工具可以获取kubelet所在节点上的相关指标，包括容器指标。但是CAdvsior的缺陷在于，我们仅能够获取，指定节点上的指标信息，而无法获取集群管理的统一指标。

	比如，在k8s集群中，提供了一些监控用的命令，比如top，通过它可以汇总节点上的相关统计信息。由于没有默认情况下，k8s没有提供专用的metrics接口，所以这个命令无法正常使用。
    [root@kubernetes-master1 ~]# kubectl top nodes
    error: Metrics API not available
    [root@kubernetes-master1 ~]# kubectl top pod
    error: Metrics API not available
	
	虽然k8s已经内嵌了CAdvsior，但是没有集群级别的资源对象能够汇总这些所有的指标数据，并通过相关资源对象的api接口暴露出去。
	kubectl api-resources | grep metrics

数据采集汇总

方式	解析
监控代理程序	如node_exporter，收集标准的主机指标数据，包括平均负载、CPU、Memory、Disk、Network及诸多其他维度的数据
kubelet	收集容器指标数据，它们也是Kubernetes“核心指标”，每个容器的相关指标数据主要有CPU利用率（user和system）及限额、文件系统读/写/限额、内存利用率及限额、网络报文发送/接收/丢弃速率等。
API Server	收集API Server的性能指标数据，包括控制工作队列的性能、请求速率与延迟时长、etcd缓存工作队列及缓存性能、普通进程状态（文件描述符、内存、CPU等）、Golang状态（GC、内存和线程等）
etcd	收集etcd存储集群的相关指标数据，包括领导节点及领域变动速率、提交/应用/挂起/错误的提案次数、磁盘写入性能、网络与gRPC计数器等
kube-state-metrics	该组件用于根据Kubernetes API Server中的资源派生出多种资源指标，它们主要是资源类型相关的计数器和元数据信息，包括指定类型的对象总数、资源限额、容器状态（ready/restart/running/terminated/waiting）以及Pod资源的标签系列等

简单实践

软件安装

获取文件
[root@kubernetes-master1 ~]# mkdir /data/kubernetes/pod/metrics -p
[root@kubernetes-master1 ~]# cd /data/kubernetes/pod/metrics
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# mv components.yaml metrics-server.yaml
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# cp metrics-server.yaml{,.bak}

查看镜像文件
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# grep 'image:'  metrics-server.yaml
        image: k8s.gcr.io/metrics-server/metrics-server:v0.6.1

获取镜像文件
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# docker pull registry.aliyuncs.com/google_containers/metrics-server:v0.6.1
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# docker tag registry.aliyuncs.com/google_containers/metrics-server:v0.6.1 kubernetes-register.superopsmsb.com/google_containers/metrics-server:v0.6.1
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# docker push kubernetes-register.superopsmsb.com/google_containers/metrics-server:v0.6.1

修改配置文件
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# vim metrics-server.yaml
      ... 
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls     # 添加这一条配置属性
        image: kubernetes-register.superopsmsb.com/google_containers/metrics-server:v0.5.1

注意：
	默认情况下，该服务会因为无法与k8s进行认证，导致服务无法正常运行。
	所以需要在pod启动的时候，添加一条属性 --kubelet-insecure-tls

创建资源对象
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl apply -f metrics-server.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

确认效果
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl  get deploy metrics-server -n kube-system
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           2m32s
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl  get svc metrics-server -n kube-system
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
metrics-server   ClusterIP   10.107.209.27   <none>        443/TCP   2m37s

检查效果

资源创建完毕后，可以看到多出来了两个资源
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl api-resources | egrep 'metr|NAME'
NAME         SHORTNAMES   APIVERSION                NAMESPACED   KIND
nodes                     metrics.k8s.io/v1beta1    false        NodeMetrics
pods                      metrics.k8s.io/v1beta1    true         PodMetrics

查看node节点资源利用
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl top node
NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
kubernetes-master1   127m         6%     2121Mi          57%
kubernetes-master2   138m         6%     1090Mi          29%
kubernetes-master3   146m         7%     1045Mi          28%
kubernetes-node1     33m          1%     723Mi           19%
kubernetes-node2     49m          2%     785Mi           21%
kubernetes-node3     51m          2%     779Mi           21%

查看namespace的pod资源利用
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl top pod
NAME                 CPU(cores)   MEMORY(bytes)
superopsmsb-django   13m          48Mi
[root@kubernetes-master1 /data/kubernetes/pod/metrics]# kubectl top pod -n kube-system | head -n3
NAME                                         CPU(cores)   MEMORY(bytes)
coredns-5d555c984-fmrht                      1m           16Mi
coredns-5d555c984-scvjh                      2m           16Mi

小结

1.4.2 HPA实践

学习目标

这一节，我们从属性解读、简单实践、小结三个方面来学习。

基础知识

简介

	对于 Kubernetes，Metrics API 提供了一组基本的指标，以支持自动伸缩和类似的用例。 该 API 提供有关节点和 Pod 的资源使用情况的信息， 包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中， 那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。

	HorizontalPodAutoscaler (HPA) 和 VerticalPodAutoscaler (VPA) 使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。水平(Horizontal)扩缩意味着对增加的负载的响应是部署更多的 Pods。 垂直(Vertical)扩缩扩缩意味着将更多资源分配给已经为工作负载运行的 Pod。

资源属性

apiVersion: autoscaling/v2 				# API群组及版本
kind: HorizontalPodAutoscaler				# 资源类型特有标识
metadata:
  name <string>  						# 资源名称，在作用域中要唯一
  namespace <string>  					# 名称空间；资源隶属名称空间级别
spec:
  scaleTargetRef  <Object>  				# 带扩展的资源对象，必选字段
  maxReplicas <integer>					# 必选字段，扩容最大值
  minReplicas <integer>					# 可选字段，缩容最小值
  metrics      <[]Object> 				# 以什么指标监控
  - type: Resource						# 监控的类型
    resource:  <Object>						# 资源对象的属性
      name: <string>					# 必选字段，监视资源名称，可以是cpu和mem
      target:	<Object>				# 必选字段，资源目标值
        type: <string>					# 必选字段，值的类型，
        averageValue: <string>				# 普通目标数据值
	averageUtilization  <integer>			# 百分比目标数据值
  behavior:
    scaleDown:  <Object>				# 缩容行为
      stabilizationWindowSeconds: 90			# 扩缩容的基本时间范围，0-3600，默认300

环境准备

定制基础的应用对象
[root@kubernetes-master1 /data/kubernetes/controller]# cat 07_kubernetes_pod_hpa_1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: superopsmsb-django-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: django-web
  template:
    metadata:
      labels:
        app: django-web
    spec:
      containers:
      - name: django-web
        image: kubernetes-register.superopsmsb.com/superopsmsb/django_web:v0.1
---
apiVersion: v1
kind: Service
metadata:
  name: superopsmsb-django-service
spec:
  selector:
    app: django-web
  ports:
  - name: http
    port: 8000

创建资源对象
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl  apply -f 07_kubernetes_pod_hpa_1.yaml
deployment.apps/superopsmsb-django-web created
service/superopsmsb-django-service created

检查效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get pod,deployment,svc
NAME                                          READY   STATUS    RESTARTS   AGE
pod/superopsmsb-django-web-7b5c7886b5-s624f   1/1     Running   0          47s
pod/superopsmsb-django-web-7b5c7886b5-txt56   1/1     Running   0          47s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/superopsmsb-django-web   2/2     2            2           47s

NAME                                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/kubernetes                   ClusterIP   10.96.0.1        <none>        443/TCP   30h
service/superopsmsb-django-service   ClusterIP   10.106.219.128   <none>        80/TCP    47s

简单实践

手工hpa实践

在k8s中有一个自动的扩缩容命令 autoscale,可以创建hpa对象
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl autoscale deployment superopsmsb-django-web --min=2 --max=5 --cpu-percent=40
horizontalpodautoscaler.autoscaling/superopsmsb-django-web autoscaled
    属性解析：
        --min=2				最少的pod数量
        --max=5				最多的pod数量
        --cpu-percent=40	调整的标准，以cpu为例

查看效果
[root@kubernetes-master1 /data/kubernetes/controller]# kubectl get hpa
NAME                     REFERENCE                           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
superopsmsb-django-web   Deployment/superopsmsb-django-web   23%/40%   2         5         2          35s
注意：
	由于这里查询的是核心指标，所以它是从metrics-server中获取到的

创建测试pod
[root@kubernetes-master1 ~]# kubectl run flask-web --image=kubernetes-register.superopsmsb.com/superopsmsb/flask_web:v0.1
pod/flask-web created
[root@kubernetes-master1 ~]# kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
flask-web                                 1/1     Running   0          3s

进入容器环境
[root@kubernetes-master1 ~]# kubectl  exec -it flask-web -- /bin/bash
root@flask-web:/# while true; do curl -s http://superopsmsb-django-service:8000; sleep 0.001; done
...

查看hpa的效果
[root@kubernetes-master1 ~]# kubectl get hpa -w
NAME                     REFERENCE                           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
superopsmsb-django-web   Deployment/superopsmsb-django-web   32%/40%   2         5         2          26m
superopsmsb-django-web   Deployment/superopsmsb-django-web   81%/40%   2         5         4          27m
superopsmsb-django-web   Deployment/superopsmsb-django-web   62%/40%   2         5         5          27m
结果显示：
	hpa设定的cpu阈值超过 40%的时候，资源会自动扩容
	这里会有一个缓冲时间，默认是1分钟

进入容器环境停止测试过程
[root@kubernetes-master1 ~]# kubectl  exec -it flask-web -- /bin/bash
root@flask-web:/# while true; do curl -s http://superopsmsb-django-service:8000; sleep 0.001; done
^C

再次查看hpa的效果
[root@kubernetes-master1 ~]# kubectl get hpa -w
NAME                     REFERENCE                           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
...
superopsmsb-django-web   Deployment/superopsmsb-django-web   81%/40%   2         5         4          27m
...
superopsmsb-django-web   Deployment/superopsmsb-django-web   23%/40%   2         5         5          32m
superopsmsb-django-web   Deployment/superopsmsb-django-web   22%/40%   2         5         3          33m
...
superopsmsb-django-web   Deployment/superopsmsb-django-web   22%/40%   2         5         2          40m
结果显示：
	hpa设定的cpu阈值低于 40%的时候，资源会自动缩容，
	但是为了防止过载反复，这里的缩容会有一个缓冲时间，默认为5分钟左右

清理资源对象
[root@kubernetes-master1 ~]# kubectl delete hpa superopsmsb-django-web
horizontalpodautoscaler.autoscaling "superopsmsb-django-web" deleted

资源清单hpa实践

[root@kubernetes-master1 /data/kubernetes/controller]# cat 08_kubernetes_pod_hpa_2.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: superopsmsb-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: django-web
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 90
      
创建资源对象
[root@kubernetes-master1 /data/backup/controller]# kubectl  apply -f 08_kubernetes_pod_hpa_2.yaml
horizontalpodautoscaler.autoscaling/superopsmsb-hpa created

查看效果
[root@kubernetes-master1 /data/backup/controller]# kubectl get hpa
NAME              REFERENCE                           TARGETS                   MINPODS   MAXPODS   REPLICAS   AGE
superopsmsb-hpa   Deployment/superopsmsb-django-web   49086464/500Mi, 23%/50%   2         5         2          75s
注意：	
	这里获取的数据内容是需要等待几秒才会出现
	]# echo $((49086464 /1024/1024))
	46  M
	
在测试终端执行测试
while true; do curl -s http://superopsmsb-django-service:8000; sleep 0.001; done

在控制端确认hpa效果
[root@kubernetes-master1 ~]# kubectl  get hpa -w
NAME            REFERENCE                         TARGETS                 MINPODS MAXPODS RE PLICAS  AGE
superopsmsb-hpa Deployment/superopsmsb-django-web 49086464/500Mi, 23%/50% 2       5       2          6m33s
superopsmsb-hpa Deployment/superopsmsb-django-web 49362944/500Mi, 35%/50% 2       5       2          6m46s
superopsmsb-hpa Deployment/superopsmsb-django-web 49412096/500Mi, 83%/50% 2       5       2          7m1s
superopsmsb-hpa Deployment/superopsmsb-django-web 49551360/500Mi, 79%/50% 2       5       5          7m16s
superopsmsb-hpa   Deployment/superopsmsb-django-web 49135616/500Mi, 24%/50% 2     5       5          11m
superopsmsb-hpa Deployment/superopsmsb-django-web 49623040/500Mi, 23%/50% 2       5       2          14m