Kubernetes Pod控制器（ReplicaSet Deployment DeamonSet)

已于 2022-07-01 22:56:07 修改
阅读量606 收藏 1
点赞数
分类专栏： 云 文章标签： kubernetes docker java
于 2021-10-23 14:19:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46690280/article/details/120919794
版权

Kubernetes Pod控制器

Kubernetes Pod控制器

概述

Pod控制器是什么

Pod控制器就是帮助我们自动的调度管理Pod，并满足期望的Pod数量。

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

​ 创建为具体的控制器对象之后，每个控制器均通过API Server提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态想期望状态迁移和逼近。

Pod和Pod控制器

Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。

通常，一个Pod控制器资源至少应该包含三个基本的组成部分：

  • 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数。
  • 期望的副本数：期望在集群中精确运行着的Pod资源的对象数量。
  • Pod模板：用于新建Pod资源对象的Pod模板资源。

控制器的必要性

​ 自主式Pod对象由调度器调度到目标工作节点后即由相应节点上的kubelet负责监控其容器的存活状态，容器主进程崩溃后，kubelet能够自动重启相应的容器。但对出现非主进程崩溃类的容器错误却无从感知，这便依赖于pod资源对象定义的存活探测，以便kubelet能够探知到此类故障。但若pod被删除或者工作节点自身发生故障（工作节点上都有kubelet，kubelet不可用，因此其健康状态便无法保证），则便需要控制器来处理相应的容器重启和配置。

常见的控制器

Pod控制器由master的kube-controller-manager组件提供，常见的此类控制器有

ReplicaSet

​ 代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能

Deployment

​ 工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。

DaemonSet

​ 用于确保集群中的每一个节点只运行特定的pod副本，常用于实现系统级后台任务。比如ELK服务

StatefulSet

​ 管理有状态应用

Job

​ 只要完成就立即退出，不需要重启或重建

CronJob

​ 周期性任务控制，不需要持续后台运行

ReplicaSet控制器

ReplicaSet概述

ReplicaSet是取代早期版本中的ReplicationController控制器，其功能基本上与ReplicationController相同

​ ReplicaSet（简称RS）是Pod控制器类型的一种实现，用于确保由其管控的Pod对象副本数在任意时刻都能精确满足期望的数量。ReplicaSet控制器资源启动后会查找集群中匹配器标签选择器的Pod资源对象，当前活动对象的数量与期望的数量不吻合时，多则删除，少则通过Pod模板创建以补足。

ReplicaSet功能

ReplicaSet能够实现以下功能：

精确反应期望值
​ 确保Pod资源对象的数量精确反映期望值：ReplicaSet需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值，否则就会自动补足所缺或终止所余。

保证高可用
​ 确保Pod健康运行：探测到由其管控的Pod对象因其所在的工作节点故障而不可用时，自动请求由调度器于其他工作节点创建缺失的Pod副本。

弹性伸缩
​ 弹性伸缩：可通过ReplicaSet控制器动态扩容或者缩容Pod资源对象的数量。必要时还可以通过HPA控制器实现Pod资源规模的自动伸缩。

创建ReplicaSet

核心属性
spec字段一般嵌套使用以下几个属性字段：
在这里插入图片描述

ReplicaSet示例
创建资源清单
vi nginx-rs.yml

apiVersion: apps/v1  #api版本定义
kind: ReplicaSet  #定义资源类型为ReplicaSet
metadata:  #元数据定义
  name: nginx-rs
  namespace: default
spec:  #ReplicaSet的规格定义
  replicas: 2  #定义副本数量为2个
  selector:  #标签选择器，定义匹配Pod的标签
    matchLabels:
      app: nginx
  template:  #Pod的模板定义
    metadata:  #Pod的元数据定义
      name: nginx-pod  #自定义Pod的名称
      labels:  #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签
        app: nginx
    spec:  #Pod的规格定义
      containers:  #容器定义
      - name: nginx  #容器名称
        image: nginx:1.12  #容器镜像
        imagePullPolicy: IfNotPresent  #拉取镜像的规则
        ports:  #暴露端口
        - name: http  #端口名称
          containerPort: 80
创建rs控制器
kubectl apply -f nginx-rs.yaml

在这里插入图片描述

查看rs控制器
kubectl get rs

在这里插入图片描述

查看pod容器

通过查看pod可以看出pod命令是规则是前面是replicaset控制器的名称加随机生成的字符串

kubectl get pods -o wide -w

在这里插入图片描述

更新控制器

修改上面创建的replicaset示例文件，将镜像nginx:1.12改为1.20版本

vi nginx-rs.yml

apiVersion: apps/v1  #api版本定义
kind: ReplicaSet  #定义资源类型为ReplicaSet
metadata:  #元数据定义
  name: nginx-rs
  namespace: default
spec:  #ReplicaSet的规格定义
  replicas: 2  #定义副本数量为2个
  selector:  #标签选择器，定义匹配Pod的标签
    matchLabels:
      app: nginx
  template:  #Pod的模板定义
    metadata:  #Pod的元数据定义
      name: nginx-pod  #自定义Pod的名称
      labels:  #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签
        app: nginx
    spec:  #Pod的规格定义
      containers:  #容器定义
      - name: nginx  #容器名称
        image: nginx:1.20  #容器镜像
        imagePullPolicy: IfNotPresent  #拉取镜像的规则
        ports:  #暴露端口
        - name: http  #端口名称
          containerPort: 80
应用更新
kubectl apply -f nginx-rs.yaml

在这里插入图片描述

查看更新流程
kubectl get pods -o wide -w

我们发现pod没有任何更新变化在这里插入图片描述
查看Pod版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

这里并没有更新pod的nginx版本号

删除pod应用

这里虽然重载了，但是已有的pod所使用的镜像仍然是1.12版本的，只是新建pod时才会使用1.20版本，这里测试先手动删除已有的pod。

kubectl delete pods -l app=nginx

在这里插入图片描述

查看版本
kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

现在我们发现pod的版本已经更新正确了在这里插入图片描述

RS扩缩容

可以直接通过vim 编辑清单文件修改replicas字段，也可以通过kubect edit 命令去编辑

​ kubectl还提供了一个专用的子命令scale用于实现应用规模的伸缩，支持从资源清单文件中获取新的目标副本数量，也可以直接在命令行通过“–replicas”选项进行读取。

scale命令扩容

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

查看容量
可看到当前是两个节点

kubectl get pods -o wide

在这里插入图片描述
执行扩容
使用scale命令可以对集群进行扩缩容

kubectl scale replicasets nginx-rs --replicas=4

在这里插入图片描述
查看扩容过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面增加了两个节点在这里插入图片描述

配置文件缩容

配置文件扩容一般用于初始容量变更，长期进行扩容

查看容量
可看到当前是四个节点

kubectl get pods -o wide

在这里插入图片描述
应用配置
因为没有变更配置文件可以直接应用配置文件

kubectl apply -f nginx-rs.yml

在这里插入图片描述
查看缩容容过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面减少了两个节点在这里插入图片描述

删除rs控制器

使用Kubectl delete命令删除ReplicaSet对象时默认会一并删除其管控的各Pod对象，有时，考虑到这些Pod资源未必由其创建，或者即便由其创建也并非自身的组成部分，这时候可以添加“–cascade=false”选项，取消级联关系。

查看集群情况
查看RS集群

kubectl get rs -o wide

在这里插入图片描述
查看POD

kubectl get pods -o wide

在这里插入图片描述
删除rs
删除rs可以通过参数cascade=false设置不删除pod

kubectl delete replicasets nginx-rs --cascade=false

在这里插入图片描述

查看集群情况

查看RS集群

kubectl get rs -o wide

在这里插入图片描述
查看POD

kubectl get pods -o wide

在这里插入图片描述
删除Pod

kubectl delete pods nginx-rs-7rzz6
kubectl delete pods nginx-rs-c5zrs

在这里插入图片描述

Deployment控制器

Deployment概述

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新

​ 只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。也可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
在这里插入图片描述
其他特性
Deployment控制器资源的主要职责是为了保证Pod资源的健康运行，其大部分功能均可通过调用ReplicaSet实现，同时还增添部分特性。

  • 事件和状态查看：必要时可以查看Deployment对象升级的详细进度和状态。
  • 回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上。
  • 版本记录：对Deployment对象的每一个操作都予以保存，以供后续可能执行的回滚操作使用。
  • 暂停和启动：对于每一次升级，都能够随时暂停和启动。
  • 多种自动更新方案：一是Recreate，即重建更新机制，全面停止、删除旧有的Pod后用新版本替代；另一个是RollingUpdate，即滚动升级机制，逐步替换旧有的Pod至新的版本。
Deployment配置

编辑资源清单

vi nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

配置项说明
配置解释

  • 我们定义了一个Deployment，名字叫nginx-deployment；
  • 通过spec.replicas字段定义了Pod的副本数是2；
  • 通过spec.selector字段定义了被打上app: nginx的标签的Pod才会被管理；
  • tmplate字段定义了这个Deployment管理的Pod应该是怎样的，具有怎样的属性；

控制器描述
总的来说一个Deploymet控制器可以由两部分组成：
在这里插入图片描述
创建控制器

kubectl apply -f nginx-deployment.yml
kubectl get pods -o wide

在这里插入图片描述
查看replicaset
ReplicaSet是一个副本控制器，ReplicaSet可以用selector来控制Pod的数量，而Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。

kubectl get replicaset -o wide

通过查看资源对象可以看出，Deployment会自动创建相关的ReplicaSet控制器资源，并以”[DEPLOYMENT-name]-[POD-TEMPLATE-HASH-VALUE]”格式为其命名，其中的hash值由Deployment自动生成。而Pod名则是以ReplicaSet控制器的名称为前缀，后跟5位随机字符。

在这里插入图片描述

更新策略

ReplicaSet控制器的应用更新需要手动分成多步并以特定的次序进行，过程繁杂且容易出错，而Deployment却只需要由用户指定在Pod模板中要改动的内容，（如镜像文件的版本），余下的步骤便会由其自动完成。Pod副本数量也是一样。

Deployment控制器支持两种更新策略：滚动更新（rolling updata）和 重建更新（recreate），默认情况下为滚动更新

重建更新

​ 重建更新为：先删除所有的Pod再根据新的模板创建新的Pod，中间会导致服务的不可用，用户要么使用的是新版本，要么就是旧版本

滚动更新

滚动更新是默认的更新策略，它在删除一些旧版本的Pod的同时补充创建一些新的Pod，更新期间服务不会中断。

滚动更新期间，应用升级期间还要确保可用的Pod对象数量不低于某些阈值。确保可以持续处理客户端请求。变动的方式和Pod对象的数量范围将通过==spec.strategy.roollingUpdata.maxSurge和spec.strategy.roollingUpdata.maxunavailable两个属性协同进行定义。两个参数用法如下：

  • maxSurge：指定升级期间存在的总Pod对象数量最多以超出期望值的个数，其值可以为0或者正整数，也可以是一个期望值的百分比：例如如果期望值是3，当前的属性值为1，则表示Pod对象的总数不能超过4个。
  • maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望的个数、其值可以是0或者正整数。也可以是一个期望值的百分比，默认值为1；该值意味着如果期望值是3，那么在升级期间至少要有两个Pod对象处于正常提供服务的状态

maxSurge和maxUnavailable的数量不能同时为0，否则Pod对象的复本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

更新控制器

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

命令更新

查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述执行更新命令

kubectl set image deployment/nginx-deployment nginx=nginx:1.15

在这里插入图片描述
查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现更新后新建了一个RS，并且保留原来的RS但是节点数为0用来回滚
在这里插入图片描述
查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述

配置更新

查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述
编辑资源清单

vi nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.20 # 将nginx版本改为1.20
        ports:
        - containerPort: 80

应用更新

kubectl apply -f nginx-deployment.yml

在这里插入图片描述
查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现更新后新建了一个RS，并且保留原来的RS但是节点数为0用来回滚
在这里插入图片描述
查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述
回滚更新
通过rollout命令进行回滚操作

查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述
执行回滚命令

kubectl rollout undo deployment/nginx-deployment

在这里插入图片描述
查看更新过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现回滚没有创建新的rs而是将使用了原来的rs在这里插入图片描述
查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

我们发现rollout回滚只在最近的两个版本之间来回回滚，不会回滚到在上一个版本。
在这里插入图片描述

回滚指定版本

查看历史版本

通过rollout history查看版本历史

kubectl rollout history deployment/nginx-deployment

在这里插入图片描述
历史版本内容
通过指定版本号来查看变更内容，找到需要回滚的版本，这里我会回滚到最早版本nginx:1.7.9

kubectl rollout history deployment/nginx-deployment --revision=1

我们找到了需要回滚的版本是1
在这里插入图片描述
查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

在这里插入图片描述
执行回滚命令
写入我们需要回滚到的指定版本1

kubectl rollout undo deployment/nginx-deployment --to-revision=1

在这里插入图片描述
查看版本
通过命令查看pod的版本号

kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

到此我们已经回滚到了指定版本

Deployment扩缩容
scale命令扩容

命令扩容一般用于短期的临时性扩容，应付完成后要记得缩容到原来水平

查看当前容量
当前是两个节点

kubectl get pods -o wide

在这里插入图片描述
执行扩容
使用scale命令可以对集群进行扩缩容，扩充到4个节点

kubectl scale deployment nginx-deployment --replicas=4

在这里插入图片描述
查看扩容过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面增加了两个节点在这里插入图片描述

配置文件缩容

配置文件扩缩容一般用于初始容量变更，长期进行扩缩容

查看当前容量
当前是4个节点

kubectl get pods -o wide

在这里插入图片描述
应用配置文件
因为我们没有更改配置文件，直接应用配置文件即可

kubectl apply -f nginx-deployment.yml

在这里插入图片描述
查看扩容过程
在更新前打开新窗口，监控pod的更新变化

kubectl get pods -o wide -w

在这里插入图片描述
在更新前打开新窗口，监控RS的更新变化

kubectl get rs -o wide -w

我们发现扩容后只是在原来的RS集群上面减少了两个节点
在这里插入图片描述

删除Deployment

查看集群情况
查看Deployment

kubectl get deployments -o wide

在这里插入图片描述
查看POD

kubectl get pods -o wide

在这里插入图片描述
删除Deployment
执行删除命令删除Deployment

kubectl delete deployment nginx-deployment

在这里插入图片描述查看Deployment

kubectl get deployments -o wide

在这里插入图片描述
查看POD

kubectl get pods -o wide

在这里插入图片描述

DaemonSet控制器

DaemonSet概述

DaemonSet用于在集群中的全部节点上同时运行一份指定Pod资源副本，后续新加入集群的工作节点也会自动创建一个相关的Pod对象，当从集群移除借点时，此类Pod对象也将被自动回收而无需重建。管理员也可以使用节点选择器及节点标签指定仅在具有特定特征的节点上运行指定的Pod对象。

应用场景
  • 运行集群存储的守护进程，如在各个节点上运行glusterd或ceph。
  • 在各个节点上运行日志收集守护进程，如fluentd和logstash。
  • 在各个节点上运行监控系统的代理守护进程，如Prometheus Node Exporter、collectd、Datadog agent、New Relic agent和Ganglia gmond等。 创建DaemonSet
创建DaemonSet

DaemonSet控制器的spec字段中嵌套使用的相同字段selector、template和minReadySeconds，并且功能和用法基本相同，但它不支持replicas，因为毕竟不能通过期望值来确定Pod资源的数量，而是基于节点数量。

编辑资源清单
vi nginx-daemonset.yml

apiVersion: apps/v1    #api版本定义
kind: DaemonSet    #定义资源类型为DaemonSet
metadata:    #元数据定义
  name: nginx-daemon-set    #daemonset控制器名称
  namespace: default    #名称空间
  labels:    #设置daemonset的标签
    app: daem-nginx
spec:    #DaemonSet控制器的规格定义
  selector:    #指定匹配pod的标签
    matchLabels:    #指定匹配pod的标签
      app: daem-nginx    #注意：这里需要和template中定义的标签一样
  template:    #Pod的模板定义
    metadata:    #Pod的元数据定义
      name: nginx
      labels:    #定义Pod的标签，需要和上面的标签选择器内匹配规则中定义的标签一致，可以多出其他标签
        app: daem-nginx
    spec:    #Pod的规格定义
      containers:    #容器定义
      - name: nginx-pod    #容器名字
        image: nginx:1.12    #容器镜像
        ports:    #暴露端口
        - name: http    #端口名称
          containerPort: 80    #暴露的端口

创建应用

kubectl apply -f nginx-daemonset.yml

在这里插入图片描述
查看pod情况
我们发现只有node节点上创建了pod

kubectl get pods -o wide

在这里插入图片描述
通过上面验证查看，Node-Selector字段的值为空，表示它需要运行在集群中的每个节点之上。而当前的节点数是2个，所以其期望的Pod副本数（Desired Number of Nodes Scheduled）为2，而当前也已经创建了2个相关的Pod对象。

注意
​ 对于特殊的硬件的节点来说，可能有的运行程序只需要在某一些节点上运行，那么通过Pod模板的spec字段中嵌套使用nodeSelector字段，并确保其值定义的标签选择器与部分特定工作节点的标签匹配即可。

更新DaemonSe

DaemonSet自Kubernetes1.6版本起也开始支持更新机制，相关配置嵌套在kubectl explain daemonset.spec.updateStrategy字段中。其支持RollingUpdate（滚动更新）和OnDelete（删除时更新）两种策略，滚动更新为默认的更新策略。

查看镜像版本

kubectl get pods -l app=daem-nginx -o custom-columns=NAME:metadata.name,NODE:spec.nodeName,Image:spec.containers[0].image

在这里插入图片描述
更新版本

kubectl set image daemonset/nginx-daemon-set nginx-pod=nginx:1.20

在这里插入图片描述
查看镜像版本

kubectl get pods -l app=daem-nginx -o custom-columns=NAME:metadata.name,NODE:spec.nodeName,Image:spec.containers[0].image

在这里插入图片描述
查看更新详情

kubectl describe daemonset nginx-daemon-set

在这里插入图片描述

​ 通过上面查看可以看出，默认的滚动更新策略是一次删除一个工作节点上的Pod资源，待其最新版本Pod重建完成后再开始操作另一个工作节点上的Pod资源。

​ DaemonSet控制器的滚动更新机制也可以借助于minReadySeconds字段控制滚动节奏；必要时也可以执行暂停和继续操作。其也可以进行回滚操作。

Ybb_studyRecord
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
k8s-docker详解——deployment部署工作负载、暴露服务，以及flannel网络插件的作用
qq_53980494的博客
08-27 935
本文主要介绍了k8s集群中如何使用自制镜像对外发布服务，以及集群中flannel网络如何实现pod之间的通信，还有对外服务时service四层负载均衡和ingress七层负载均衡。
kubernetes资源控制器【一】- ReplicaSet控制器
yuan_jiaoyoung的博客
11-12 569
Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。
常见的Kubernetes命令之kubectl命令详解
weixin_42492572的博客
05-22 1万+
常见的Kubernetes命令之kubectl命令详解，包括资源查看、资源详细信息、日志、资源创建和删除、资源更新和扩缩容等相关命令
Pod控制器详解
Yosigo_的博客
08-09 1081
Pod控制器详解 Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类： 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建 什么是Pod控制器 Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个
Kubernetes Pod控制器详解
axibazZ的博客
08-27 689
一、Pod控制器介绍 在kubernetes中，按照pod的创建方式可以将其分为两类： 自动式pod：kubernetes直接创建出来的pod，这种pod删除之后就没有了，也不会重建。 控制器创建的pod：通过控制器创建的pod，这种pod删除之后还会自动重建。 二、什么是Pod控制器 Pod控制器是管理pod的中间层，使用了pod控制器之后，我们只需要告诉pod控制器，想要多少个什么样的pod就可以了，他就会创建出满足条件的pod并确保每一个pod处于用户期望的状态，如果pod在运...
1、Kubernetes Pod 控制器有哪些1
08-04
本文将详细讲解Kubernetes中的一些主要控制器，包括ReplicationController、ReplicaSet、Deployment、DaemonSet、StatefulSet以及Job和CronJob，并探讨Horizontal Pod Autoscaling（HPA）的概念。 首先，...
2、Kubernetes Deployment 控制器1
08-04
典型的应用场景包括：定义Deployment来创建Pod和ReplicaSet滚动升级和回滚应用扩容和缩容暂停和继续DeploymentⅠ、部署一个简单的 Ng
部署Kubernetes Pod？教你五招！
01-07
虽然部署和运行一个容器镜像（作为一个通用pod）是很有诱惑力的，但是你应该根据工作负载特性选择正确的控制器类型。Kubernetes有一个称为controller的原语，它与工作负载的关键特性相一致。Deployment、
controller-rs:kubernetes示例控制器
05-15
控制器 使用的rust kubernetes控制器。 所述Controller对象调和Foo实例中检测到它的变化时，和写入到其.STATUS对象。要求kube集群/ minikube。 将CRD及其实例安装到集群中： cargo run --bin crdgen > yaml/foo-crd....
kanarini：Kubernetes的Canary部署控制器
02-05
Kanarini，Kubernetes的Canary部署控制器 总览 Kanarini是CRD控制器，它通过创建两个部署对象（“ canary”和“ stable”）并通过调用Custom Metrics API（ ）来验证部署的运行状况，从而实现金丝雀部署策略。 ...
Docker&Kubernetes ❀ Kubernetes集群Pod控制器 - Deployment (Deploy)
无糖可乐没有灵魂
02-21 297
文章目录1、资源配置清单2、创建控制器3、副本扩缩容4、镜像更新4.1 重建更新4.2 滚动更新5、版本回退5.1 案例演示6、金丝雀发布7、删除控制器 1、资源配置清单 为了更好的解决服务编排的问题，Kubernetes在V 1.2版本开始，引入了Deployment控制器，这种控制器并不会直接管理Pod，而是通过管理ReplicaSet来间接管理Pod，所以Deployment的功能比ReplicaSet更强大； 参数查询方法： [root@master ~]# kubectl explain de
Kubernetes服务发现之Service
RtxTitanV的博客
07-23 1495
Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了Service资源——一种将运行在一组Pod上的应用公开为网络服务的抽象方法。使用Kubernetes，我们无需修改应用程序即可使用不熟悉的服务发现机制。Kubernetes为Pod提供自己的IP地址和一组Pod的单个DNS名称，并且可以在它们之间进行负载平衡。
deployment标签（labels）匹配相关知识：spec.selector.matchLables与spec.template.metadata.lables
热门推荐
梦想起飞的地方.........
06-11 1万+
deployment标签（labels）匹配相关知识：spec.selector.matchLables与spec.template.metadata.lables 1. spec.selector.matchLables实验 1.1 正确的Deployment书写方式，是要让spec.selector.matchLabels值和spec.template.metadata.lables值完全匹配，这样才不会报错。 apiVersion: apps/v1 kind: Deployment me.
k8s学习(五)ReplicaSet的使用
码易的博客
12-21 485
ReplicaSet     ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合，可确保指定数量的pod在任何设定的时间运行。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。 示例 1、nginx-replicaset.yaml [root@k8s-master k8s]# cat nginx-replicaset.yaml apiVersion: apps/v1 kind: ReplicaSet metadata
副本机制和其他控制器
github_38730134的博客
03-05 301
每个节点上运行一个pod pod执行系统级别的与基础结构相关的操作，比如希望在每个节点上运行日志收集器和资源监控器时需要每个节点上都运行一个这样的pod 使用DaemonSet在每个节点上运行一个pod DaemonSet对象没有期望副本数的概念，它的工作是确保一个pod匹配它的选择器并在每个节点上运行，DaemonSet创建的pod，已经有一个指定的目标节点并跳过Kubernetes调度器，不是随机分配在集群上。 使用DaemonSet在特定节点上运行pod DaemonSet可以通过在pod模板中的no
kubernetes 每个node上只能运行一个副本DaemonSet
dlm520947的博客
06-14 959
每个node上只能运行一个副本: apiVersion: extensions/v1beta1 kind: DaemonSet #使用DaemonSet的方式运行 metadata: name: kube-flannel namespace: kube-system labels: tier: node app: ...
【kubernetes详解08】-Pod控制器
桂安俊@KylinOS
05-08 800
一、Pod控制器介绍 Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类： 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建 什么是Pod控制器？ Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod
K8s中Pod控制器
MansonRi
02-17 3606
关于Pod控制器     kubelet是K8s集群节点代理程序，它在每个工作节点上都运行着一个实例。当工作节点发生故障时，kubelet也将不可用，pod无法再由kubelet重启。此时Pod的存活性一般由工作节点之外的Pod控制器来保证。     Pod控制器由master的kube-contriller-manager组件提供，常见的有Deployment、DaemonSet、Job等，...
kubernetes DaemonSet资源对象
虾米的博客
05-02 9577
What is a DaemonSet? DaemonSet能够让所有（或者一些特定）的Node节点运行同一个pod。当节点加入到kubernetes集群中，pod会被（DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，被（DaemonSet）调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。 在使用
kubernetes中 deployment与replicaset的区别
最新发布
06-08
在 Kubernetes 中，Deployment 和 ReplicaSet 都是用来管理 Pod 副本的控制器，但是它们有一些不同： 1. ReplicaSet 是 Kubernetes 早期版本中的控制器，而 Deployment 是在 ReplicaSet 之上的抽象层，用于更方便地...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值