K8S资源控制器管理

最新推荐文章于 2024-05-06 21:46:58 发布
最新推荐文章于 2024-05-06 21:46:58 发布
阅读量673 收藏
点赞数
分类专栏： 云 文章标签： kubernetes 容器 云原生 标签选择器 副本控制器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46690280/article/details/131524808
版权

资源控制器

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

小结
Ybb_studyRecord
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s中控制器使用详解
congge
01-24 6828
k8s控制器
k8s资源清单
01-07
kind: Pod #文件自定义的资源类型和角色，控制器类型 metadata: #元数据对象 name: demo #命名空间 labels: #标签 app: demo #标签的类型室键值方式 spec: #固定对象容器的控制 containers: - name:...
k8s的资源管理
2301_76288258的博客
02-28 9954
假设期望副本数是3，那么滚动更新时能够创建的副本数是 3 * 25% = 0.75 再向上取整为 1，能够销毁的副本数向下取整为 0 假设期望副本数是10，10 * 25% = 2.5 向上取整为 3 向上取整为 2 整个滚动更新过程中Pod副本数始终处在 （10-2）<= Pod副本数 <= （10+3）之间。--force --grace-period=0 #grace-period表示过渡存活期，默认30s，在删除pod之前允许pod慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod。
k8s资源篇：资源控制手段
风一样的少年
08-23 559
胡扯一下 今天是周末，捋一捋k8s资源方面的一些事情，最近也在面试，k8s的问题是真的多。 根据目前我的知识储备，感觉k8s的资源管理分为两大类：预防和应急。预防就是提供给用户手段，让你尽可能的控制资源的使用。应急可以理解为兜底，也是最后的屏障了，当预防的手段没有预防好，就要使用应急手段了。 预防手段 在k8s中资源的使用对象是pod。k8s为pod提供了request和limit的手段来限制资源的使用情况。 request表示pod启动时，要申请的资源数 limit表示pod最终能使用的资源数 举个例
k8s 资源管理
m0_64735681的博客
11-20 475
k8s 资源管理
K8S 资源控制器
elihe2011的专栏
12-23 2127
1. 概述 kubernetes 控制器会监听资源的 创建/更新/删除 事件，并触发 Reconcile 函数作为响应。整个调整过程被称作 “Reconcile Loop”（调谐循环） 或者 “Sync Loop“（同步循环） Reconcile 是一个使用资源对象的命名空间和资源对象名称来调用的函数，使得资源对象的实际状态与 资源清单中定义的状态保持一致。调用完成后，Reconcile 会将资源对象的状态更新为当前实际状态。 for { desired := getDesiredState() c
k8s快速入门视频教程
10-18
免费的k8s 快速入门视频教程。 ---------------------------------------------------------------------------------...--k8s极速入门 k8s集群核心概念 Controller(控制器)； --k8s极速入门 k8s集群核心概念 Service；
K8s调度器Kube-scheduler
01-07
 调度是容器编排的重要环节，需要经过严格的监控和控制，现实生产通常对调度有各类限制，譬如某些服务必须在业务独享的机器上运行，或者从灾备的角度考虑尽量把服务调度到不同机器，这些需求在Kubernetes集群依靠...
k8s培训视频.zip
05-09
06-Kubernetes Pod控制器应用进阶 07-Kubernetes Pod控制器应用进阶 08-Kubernetes Pod控制器 09-Kubernetes Pod控制器 10-kubernetes Service资源 11-kubernetes ingress及Ingress Controller 12-存储卷 13-...
Kubernetes(K8S)超快速入门视频教程
11-05
手把手视频详细讲解项目开发全过程，需要的小伙伴自行百度网盘下载，链接见附件，永久有效。... 4、K8S资源清单YAML 5、K8S集群NameSpace（命名空间）、Pod、Controller（控制器）、Service 6、K8S课程总结
K8S哲学 - 资源调度 DaemonSet
gu2022_3_5_21_23的博客
05-03 421
默认是滚动更新，结果是，一旦修改 yaml文件 template 里面的 内容，那么所有节点的 ds 都会更新，所以 修改为 OnDelete 模式、当 某一个 节点的 ds需要更新，就删除 改 ds ，会自动按照新的 yaml文件创建一个 ds。正常情况下，每个服务都会进行 各自的日志收集、但是因为他们不在 同一台 Node 上，导致一旦查日志就需要 调动各个 机器进行切换，不方便也不高效。所以只要 节点在 改集群内，只要 在需要的节点加上 nodeSelector 就会在该节点创建 ds。
k8s：精通 Pod 操作的关键命令
weixin_43784341的博客
04-29 985
这些命令可以帮助你在 Kubernetes 中管理和操作 Pod，使你能够轻松地创建、查看、删除和调试 Pod，并进行其他相关操作。
K8S controller编写之Informer的原理+使用[drift]
斯是陋室，惟汝德馨
04-30 759
Watch 操作的实现机制使用 HTTP 协议的分块传输编码——当 client-go 调用 Kubernetes API Server 时，Kubernetes API Server 在 Response 的 HTTP Header 中设置 Transfer-Encoding 的值为 chunked，表示采用分块传输编码，客户端收到消息后，与服务端进行连接，并等待下一个数据块。图来源（CloudNativeCommunity）client-go 中informer的概括图.
k8s笔记 | Ingress
weixin_41104307的博客
05-03 440
将 文件helm 放到 /usr/local/bin/这里需要配合之前创建的 deploy+service。k8s笔记 | Service 服务。
9.2.k8s的控制器资源(rs控制器replicasets)
qq_22321199的专栏
05-04 329
replicaset副本控制器，简称：rs控制器；
k8s的架构组成
最新发布
健康平安的活着的专栏
05-06 173
k8s可以实现容器化的自动部署和管理，以及扩缩容。k8s可以创建多个容器，每个容器运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问。k8s是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务，通过k8s能够进行应用的自动化部署和扩缩容。
k8s ReplicaSet
2401_82869454的博客
05-06 143
ReplicaSet 是替代 ReplicationController 的，ReplicaSet 的行为与 ReplicationController 完全相同， 但pod 选择器的表达能力更强。ReplicationController 的标签选择器只允许包含某个标签的匹配 pod，但 ReplicaSet 的选择器还允许匹配缺少某个标签的 pod, 或包含特定标签名的 pod。ReplicaSet 相对于 ReplicationController 的主要改进是它更具表达力的标签选择器。
云原生周刊：K8s 中的服务和网络 ｜ 2024.4.29
KubeSphere
04-30 1129
通过示例和命令，文章演示了如何在 Kubernetes 集群中启用和使用 In-Place Resizing 功能，并展示了如何调整 CPU 和内存资源，以及观察调整操作的状态和结果。通过阅读这篇文章，读者可以更好地理解 Kubernetes 中的服务和网络组件，以及它们如何为容器化应用程序的部署和通信提供支持。KubeIP v2 不仅扩展了对 Google Cloud（v1 版本支持的云平台）的支持，还增加了对 AWS 的支持，并且旨在可扩展到其他允许为虚拟机分配静态公共 IP 的云提供商。
k8s pod控制器
08-30
K8s中的Pod控制器是用来管理和控制Pod的一种机制。Pod控制器负责创建、启动、停止、重启和删除Pod，以及监控和调节Pod的状态。Pod和Controller之间是通过label标签来建立关系，Controller又被称为控制器工作负载。Pod控制器可以根据需要创建多个Pod实例，以满足应用程序的需求。 常见的Pod控制器包括Deployment、ReplicaSet、StatefulSet和DaemonSet等。Deployment控制器是K8s中最常用和最重要的Pod控制器之一。它通过创建和管理ReplicaSet来实现对Pod的控制。Deployment控制器可以定义应用的副本数、升级和回滚策略，以及弹性伸缩等功能。通过使用Deployment控制器，可以方便地部署和管理应用程序。 在使用K8s时，可以使用yaml文件来定义Pod控制器的配置和参数。通过指定不同的字段和数值，可以实现对Pod控制器的定制化配置。例如，可以在yaml文件中指定应用程序的镜像、资源需求、副本数等信息。 总结来说，K8s中的Pod控制器是用来管理和控制Pod的机制，通过label标签与Pod建立关系。常见的Pod控制器包括Deployment、ReplicaSet、StatefulSet和DaemonSet。使用yaml文件可以对Pod控制器进行配置和定制化。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [k8s技术交流，包括Pod概念和特点Pod种类Pod镜像拉取策略Pod重启策略Pod控制器Pod探针、Pod调度](https://download.csdn.net/download/lingmeng447/85358750)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* *3* [【k8s】6、pod控制器](https://blog.csdn.net/hancoder/article/details/118064163)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值