Pod控制器详解

目录

一、Pod控制器及其功用

二、Deployment控制器

三、StatefulSet控制器

四、DaemonSet控制器

五、Job控制器

六、CronJob 控制器

一、Pod控制器及其功用

Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

在kubernetes中，有很多类型的Pod控制器，每种都有自己的适合的场景，常见的有下面这些：

  • ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
  • Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。）
  • DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
  • StatefulSet：管理有状态应用
  • Job：只要完成就立即退出，不需要重启或重建
  • Cronjob：周期性任务控制，不需要持续后台运行

二、Deployment控制器

  • 部署无状态应用
  • 管理Pod和ReplicaSet
  • 具有上线部署、副本设定、滚动升级、回滚等功能
  • 提供声明式更新，例如只更新一个新的image
  • 应用场景：web服务
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginx-deployment
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.15.4name: nginxports:- containerPort: 80

#创建Pod
kubectl create -f nginx-deployment.yaml#查看
kubectl get pods,deploy,rs
#查看控制器配置
kubectl edit deployment/nginx-deploymentapiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"creationTimestamp: "2021-04-19T08:13:50Z"generation: 1labels:app: nginx					#Deployment资源的标签name: nginx-deploymentnamespace: defaultresourceVersion: "167208"selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deploymentuid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:progressDeadlineSeconds: 600replicas: 3					#期望的pod数量，默认是1revisionHistoryLimit: 10selector:matchLabels:app: nginxstrategy:rollingUpdate:maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值type: RollingUpdate			#滚动升级template:metadata:creationTimestamp: nulllabels:app: nginx				#Pod副本关联的标签spec:containers:- image: nginx:1.15.4				#镜像名称imagePullPolicy: IfNotPresent	#镜像拉取策略name: nginxports:- containerPort: 80				#容器暴露的监听端口protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always				#容器重启策略schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

三、StatefulSet控制器

部署有状态应用需要

  • 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
  • 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
  • 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
  • 有序收缩，有序删除（即从N-1到0）

部署有状态应用的，每个Pod 唯一且不变的，每个Pod 拥有自己专属的持久化的存储（PVC和PV）

在Deployment中，与之对应的服务是service， 而在StatefulSet中与之对应的headless service（headless service，即无头服务） 与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。

除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：

$(podname).(headless server name)
FQDN： $(podname).(headless server name).namespace.svc.cluster.local

从上面的应用场景可以发现，statefulset由以下几个部分组成：

  • Headless service： 无头服务，用于为pod资源标识符 生成可解析的DNS记录。
  • VolumeClaimTemplates： 存储卷的申请模板，基于静态或动态的pv供给方式，为pod资源提供专有的固定存储。
  • statefulset： 用于管控pod资源。

为什么要有headless service 无头服务？

  • 在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
  • 为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

为什么要有volumeClainTemplate？

  • 大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据时不一样的，每个节点都需要自己专用的存储节点。而在deployment 中的pod模板中创建的存储卷是一个共享pod是不适应的，多个pod使用同一个存储卷，而statefulset定义中的每个pod都不能使用同一个存储卷，由此基于pod模板创建pod时不适应 的。
  • 这就需要引入volume Clain Template ，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而请求绑定一个PV，从而有自己的专用的存储卷。

创建statefulset控制器

目前服务器中已经创建好了storageclass 自动创建pv的功能。下面进行创建statefulset控制器创建pod，在 volumeClaimTemplates 中定义好storageclass的名称，在创建statefulset后，它会自动创建pvc和pv。

vim statefulset.yaml

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: None     #不创建custerip，也就是无头服务的serviceselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx serviceName: "nginx"replicas: 3   #三个副本template:     #定义容器的模板metadata:labels:app: nginx spec:terminationGracePeriodSeconds: 10   #10秒内pod没关闭，就强制杀死containers:- name: nginximage: nginx:1.14.1ports:- containerPort: 80name: webvolumeMounts:   #容器内挂载- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:   #存储卷的申请模板- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]   #可读可写，仅能一个节点挂载storageClassName: "nfs-client-storageclass"  #使用动态创建的pvresources:   #设置请求的资源大小requests:storage: 2Gi

解析上面： 由于StatefulSet资源依赖于一个实现存在的Headless类型的Service资源，所以需要先定义一个名为nginx的Headless Service资源，用于为关联到每个Pod资源创建DNS资源记录。接着定义了一个名为web的StatefulSet资源，它通过Pod模板创建了3个Pod资源副本，并基于volumeClaimTemplates向存储类进行了请求大小为2Gi的专用存储卷。

下面开始创建

kubectl apply -f statefulset.yaml
#创建service和statefulset。kubectl get pods -w kubectl get pvc -w kubectl get pv -w

滚动更新

kubectl set image statefulset web nginx=nginx:1.17.1 
#升级版本

在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的

#从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local

总结：

无状态：

  • deployment 认为所有的pod都是一样的
  • 不用考虑顺序的要求
  • 不用考虑在哪个node节点上运行
  • 可以随意扩容和缩容

有状态

  • 实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
  • 实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别

  • service： 一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
  • Headless service： 无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

四、DaemonSet控制器

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

使用 DaemonSet 的一些典型用法：

  • 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
  • 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
  • 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

应用场景：Agent
//官方案例（监控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

示例：

vim ds.yaml 
apiVersion: apps/v1
kind: DaemonSet 
metadata:name: nginx-daemonSetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80
kubectl apply -f ds.yaml//DaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h   1/1     Running     0          35s
nginx-deployment-8jrg5   1/1     Running     0          35s

五、Job控制器

Job分为普通任务（Job）和定时任务（CronJob），常用于运行那些仅需要执行一次的任务

应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务

官方案例：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/    

vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:name: busybox
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh", "-c", "sleep 10;date;exit 1"]restartPolicy: NeverbackoffLimit: 2
  • .spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。
  • .spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。
kubectl apply -f job-limit.yamlkubectl get job,pods
NAME                COMPLETIONS   DURATION   AGE
job.batch/busybox   0/1           4m34s      4m34sNAME                READY   STATUS   RESTARTS   AGE
pod/busybox-dhrkt   0/1     Error    0          4m34s
pod/busybox-kcx46   0/1     Error    0          4m
pod/busybox-tlk48   0/1     Error    0          4m21skubectl describe job busybox
......
Warning  BackoffLimitExceeded  43s    job-controller  Job has reached the specified backoff limit

六、CronJob 控制器

周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份

官方案例：https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:name: hello
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: helloimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure#cronjob其它可用参数的配置
spec:concurrencyPolicy: Allow			#要保留的失败的完成作业数（默认为1）schedule: '*/1 * * * *'			#作业时间表。在此示例中，作业将每分钟运行一次startingDeadlineSeconds: 15		#pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败successfulJobsHistoryLimit: 3		#要保留的成功完成的作业数（默认为3）terminationGracePeriodSeconds: 30	#job存活时间 默认不设置为永久jobTemplate:						#作业模板。这类似于工作示例

kubectl create -f cronjob.yaml kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          25skubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1621587180-mffj6   0/1     Completed   0          3m
hello-1621587240-g68w4   0/1     Completed   0          2m
hello-1621587300-vmkqg   0/1     Completed   0          60s

kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/134683.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

flink状态和检查点

flink状态和检查点

检查点和状态后端的区别 检查点 就是某个时间点下的所有算子的状态快照。这个时间点就是等所有任务将“同一个数据”处理完毕的时候。 状态后端&#xff1a;是一个管理状态的组件&#xff0c;还负责将本地状态&#xff08;检查点&#xff09;持久化到远程文件存储系统中。 分…
阅读更多...
解析找不到msvcr100.dll文件的解决方法，4个方法修复msvcr100.dll

解析找不到msvcr100.dll文件的解决方法，4个方法修复msvcr100.dll

msvcr100.dll是Microsoft Visual C 2010运行库的组成部分&#xff0c;一些基于Visual C开发的软件运行时会依赖这个dll文件。出现“找不到msvcr100.dll”的错误提示&#xff0c;往往意味着这个文件在你的计算机系统中丢失或损坏&#xff0c;导致相关程序无法正常运行。以下是找…
阅读更多...
大数据之LibrA数据库系统告警处理（ALM-12028 主机D状态进程数超过阈值）

大数据之LibrA数据库系统告警处理（ALM-12028 主机D状态进程数超过阈值）

告警解释 系统每30秒周期性检测主机中omm用户D状态进程数&#xff0c;并把实际进程数和阈值相比较。主机D状态进程数默认提供一个阈值范围。当检测到进程数超出阈值范围时产生该告警。 平滑次数为1&#xff0c;主机中omm用户D状态进程数小于或等于阈值时&#xff0c;告警恢复…
阅读更多...
MSQL系列(十四) Mysql实战-SQL语句 left join inner join On和Where语句的区别

MSQL系列(十四) Mysql实战-SQL语句 left join inner join On和Where语句的区别

Mysql实战-SQL语句On和Where语句的区别 前面我们讲解了Join的底层驱动表 选择原理&#xff0c;也知道了基本的内连接外连接两种SQL查询表连接方式 但是我们再查询多表的时候on和where语句到底有什么区别? where是过滤条件 ,不满足where的一定不会出现在结果中on是连接条件, …
阅读更多...
[MICROSAR Adaptive] --- Hello Adaptive World

[MICROSAR Adaptive] --- Hello Adaptive World

Automotive E/E Architecture and AUTOSAR Adaptive Platform Vector Solution: MICROSAR Adaptive First project: Hello Adaptive World Summary 1 引言 1.1 AP诞生的历史背景 新一代电子电器架构通常将车内的节点分为三类。计算平台，预控制器和传感器执行器相关的节点，…
阅读更多...
怎样选择文件外发控制系统，让数据实现高效安全交换？

怎样选择文件外发控制系统，让数据实现高效安全交换？

制造型企业都非常重视其知识产权&#xff08;IP&#xff09;的安全性&#xff0c;尤其是其最有价值的产品设计数据的安全问题。基于复杂的供应链生态&#xff0c;每天可能要与几十家甚至上百家供应商及合作伙伴进行数据交换。不管是一级还是二级供应商&#xff0c;合作伙伴还是…
阅读更多...
【黑马程序员】SpringCloud——微服务

【黑马程序员】SpringCloud——微服务

文章目录 前言一、服务架构演变1. 单体架构2. 分布式架构2.1 服务治理 3. 微服务3.1 微服务结构3.2 微服务技术对比3.3 企业需求 二、SpringCloud兼容性 三、服务拆分及远程调用1. 服务拆分1.1 服务拆分注意事项1.2 导入服务拆分 Demo 2. 远程调用2.1 根据订单 id 查询订单功能…
阅读更多...
Synthetic Data Generation with Large Language Models for Text Classification

Synthetic Data Generation with Large Language Models for Text Classification

本文是LLM系列文章&#xff0c;针对《Synthetic Data Generation with Large Language Models for Text Classification: Potential and Limitations》的翻译。 基于大型语言模型的文本分类合成数据生成&#xff1a;潜力和局限性 摘要1 引言2 相关工作3 方法4 评估1&#xff1…
阅读更多...
软考 系统架构设计师系列知识点之边缘计算（2）

软考 系统架构设计师系列知识点之边缘计算（2）

接前一篇文章&#xff1a;软考 系统架构设计师系列知识点之边缘计算&#xff08;1&#xff09; 所属章节&#xff1a; 第11章. 未来信息综合技术 第4节. 边缘计算概述 3. 边缘计算的特点 边缘计算是在靠近物或数据源头的网络边缘侧&#xff0c;融合网络、计算、存储、应用核心…
阅读更多...
JAVA客户端使用账号密码调用influxdb2报错：{“code“:“unauthorized“,“message“:“Unauthorized“}

JAVA客户端使用账号密码调用influxdb2报错：{“code“:“unauthorized“,“message“:“Unauthorized“}

问题&#xff1a;JAVA客户端访问influxdb2报错 说明&#xff1a;当前influxdb版本&#xff1a;2.6.1 使用依赖&#xff1a; <dependency><groupId>org.influxdb</groupId><artifactId>influxdb-java</artifactId><version>2.10</vers…
阅读更多...
IDEA插件分享：代码零入侵，后端神器

IDEA插件分享：代码零入侵，后端神器

今天给大家介绍一款好用的IDEA插件&#xff1a;Apipost-Helper-2.0。非常好用&#xff01;主要包含以下功能&#xff1a; 1、无侵入生成API文档 编写完代码后&#xff0c;只需右键upload同步接口即可快速将源码中包含的API以及注解自动生成API文档&#xff0c;并生成可以访问…
阅读更多...
Django ORM：数据库操作的Python化艺术

Django ORM：数据库操作的Python化艺术

Django的对象关系映射器&#xff08;ORM&#xff09;是其核心功能之一&#xff0c;允许开发者使用Python代码来定义、操作和查询数据库。这篇文章将带你深入了解Django ORM的强大之处&#xff0c;从基本概念到高级查询技巧&#xff0c;提供丰富的示例帮助你掌握使用Django ORM进…
阅读更多...
说说你在React项目是如何捕获错误的？

说说你在React项目是如何捕获错误的？

一、是什么 错误在我们日常编写代码是非常常见的 举个例子&#xff0c;在react项目中去编写组件内JavaScript代码错误会导致 React 的内部状态被破坏&#xff0c;导致整个应用崩溃&#xff0c;这是不应该出现的现象 作为一个框架&#xff0c;react也有自身对于错误的处理的解…
阅读更多...
vuecli3 批量打印二维码

vuecli3 批量打印二维码

安装以个命令: npm install qrcode --save npm install print-js --save 页面使用: import qrcode from qrcode import printJS from print-js <el-button type"primary" click"handleBulkPrint">批量打印</el-button>methods: {// 批量打印…
阅读更多...
c++ 信奥赛编程 2049：【例5.19】字符串判等

c++ 信奥赛编程 2049：【例5.19】字符串判等

#include <iostream> using namespace std; string strlwr(string s) { for(int i0;i<s.size();i){if(s[i]>A && s[i]<Z)s[i]s[i]-Aa;}return s; } int main() {string str1,str2; //定义两个字符串变量 getline(cin,str1); //通过函数输入字符串 getl…
阅读更多...
JavaWeb 学习路线

JavaWeb 学习路线

JavaWeb 学习路线 基础知识 1. Java基础 数据类型、循环、条件语句等基本概念面向对象编程&#xff08;OOP&#xff09;的概念和实践 2. Java核心 集合框架、异常处理、多线程等I/O流、网络编程基础 3. Servlet基础 Servlet生命周期HTTP协议和请求/响应概念 Web开发 1…
阅读更多...
集成运算放大电路

集成运算放大电路

引用原文链接&#xff1a; 集成运放及其经典电路详解 - 知乎 (zhihu.com) 1、 反比例运算放大器 输入负电压则输出正电压&#xff0c;输入正电压则输出负电压 2、同相放大电路&#xff08;同相指输入电压与输出电压的位相相同&#xff09; 输入负电压则输出负电压&#xf…
阅读更多...
LeetCode----188. 买卖股票的最佳时机 IV

LeetCode----188. 买卖股票的最佳时机 IV

 题目 给你一个整数数组 prices 和一个整数 k &#xff0c;其中 prices[i] 是某支给定的股票在第 i 天的价格。 设计一个算法来计算你所能获取的最大利润。你最多可以完成 k 笔交易。也就是说&#xff0c;你最多可以买 k 次&#xff0c;卖 k 次。 注意&#xff1a;你不能同…
阅读更多...
网络测试工具—— iperf2 安卓APK 下载 及简单使用

网络测试工具—— iperf2 安卓APK 下载 及简单使用

网络测试工具—— iperf2 安卓APK 下载 及简单使用 前言一、iperf2是什么&#xff1f;二、使用步骤附上help中命令截图翻译总结 前言 项目上有一款安卓车机加载局域网图片加载非常慢&#xff0c;所以需要测试一个安卓车机设备的带宽&#xff0c;经过调研后使用到了iperf2。 一…
阅读更多...
elementUI 常遇问题

elementUI 常遇问题

一.解决element-ui中下拉菜单子选项click事件不触发的问题 将click改为click.nativelogoutHandle;即可监听选项的点击事件。 (原因&#xff1a; click.native 可以监听 DOM 元素的原生 click 事件)
阅读更多...
最新文章

Copyright @ 2022~2023