Kubernetes之标签与Pod控制器详解

一、标签

标签的主要作用:解决同类型的资源对象越来越多,为了更好的管理,按照标签分组;

常用的标签分类:
release(版本):stable(稳定版)、canary(金丝雀版本、可以理解为测试版)、beta(测试版)
environment(环境变量):dev(开发)、qa(测试)、production(生产)
application(应用):ui、as(应用软件)、pc、sc
tier(架构层级):frontend(前端)、backend(后端)、cache(缓存、隐藏)
partition(分区):customerA(客户A)、customerB(客户B)
track(品控级别):daily(每天)、weekly(每周)

K8s集群中虽然没有对有严格的要求,但是标签还是要做到:见名知意!方便自己也方便别人!

常用的命令有:

[[email protected] yaml]# kubectl get pod --show-labels    //显示pod的标签
[[email protected] yaml]# kubectl get pod -L env       //显示键对应的值
[[email protected] yaml]# kubectl get pod -l env             //通过小l查看仅包含env标签的资源
[[email protected] yaml]# kubectl get pod -l env  --show-labels      //显示对应的键值
[[email protected] yaml]# kubectl label pod labels app=pc     //给pod打标签
[[email protected] yaml]# kubectl label pod labels app-          //去除标签
[[email protected] yaml]# kubectl label pod labels env=dev --overwrite    //修改标签内容

标签与标签选择器的关系:

  • 如果标签有多个,标签选择器选择其中一个,也可以关联成功!
  • 如果选择器有多个,那么标签必须满足条件,才可关联成功!

标签选择器:标签的查询过滤条件
基于等值关系的(equality-based):”=“、”==“、”!=“前两个等于,最后一个不等于
基于集合关系(set-based):in、notin、exists三种;

selector:
  matchLables:                 //指定键值对表示的标签选择器
    app: nginx
  matchExpressions:             //基于表达式来指定的标签选择器。选择器列表间为”逻辑与“关系;使用In或NotIn操作是,其values不强制要求为空的字符串列表,而使用Exists或DostNotExists时,其values必须为空;
    - {key: name,operator: In,values: [zhangsan,lisi]}
    - {key: age,operator: Exists,values:}

使用标签选择器的逻辑:

  • 同时指定的多个选择器之间的逻辑关系为”与“操作;
  • 使用空值的标签选择器意味着每个资源对象都将被选择中;
  • 空的标签选择器无法选中任何资源;

二、常见的Pod控制器

Pod控制器基本概念:

Pod是kubernetes的最小单元,自主式创建的pod删除就没有了,但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层,并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态,pod资源出现故障首先要重启容器,如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量。

Kubernetes中内建了很多controller(控制器),这些相当于?个状态机,?来控制Pod的具体状态和?为。

Pod控制器有很多种类型,但是目前kubernetes中常用的控制器有:

  • Replication Controller(RC):是Kubernetes系统中的核心概念,用于定义Pod副本的数量。在Master内,RC进程通过RC的定义来完成Pod的创建、监控、启停等操作。根据RC定义,Kubernetes能够确保在任意时刻都能运行用于指定的Pod"副本"(Replica)数量。随着kubernetes的迭代更新,RC即将被废弃,逐渐被ReplicaSet替代;
  • ReplicaSet(RS):它的核心作用是代用户创建指定数量的Pod副本,并确定Pod副本一直处于满足用户期望数量的状态,多退少补,同时支持扩缩容机制。主要有三个组件:用户期望的Pod副本数量;标签选择器,选择属于自己管理和控制的Pod;当前Pod数量不满足用户期望数量时,根据资源模板进行新建;
  • Deployment:工作在ReplicaSet之上,用于管理无状态应用,除了ReplicaSet的机制,还增加了滚动更新和回滚功能,提供声明式配置;
  • DaemonSet:用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务。要求:服务是无状态的;服务必须是守护进程;

Pod控制器通常包含三个组成部分:

  • replicas:期望的pod对象副本数量;
  • selector:当前控制器匹配Pod对此项副本的标签选择器;
  • template:pod副本的模板;

1)Replication Controller(RC)

基本概念

Replication Controller 简称RC,它能确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods,一旦创建成功,pod 模板和创建的pods没有任何关联,可以修改pod 模板而不会对已创建pods有任何影响,也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods,Replication Controller根据label selector来关联,通过修改pods的label可以删除对应的pods。

最初Replication Controller 是用于复制和在异常时重新调度节点的唯一kubernetes组件,后来逐渐被replicaSet代替了。现在基本上很少见到Replication Controller,它即将被废弃。但是有的kubernates容器环境还是有可能会有RC,所以还是有必要知道它的用法。

根据Replication Controller的定义,Kubernetes能够确保在任意时刻都能运行用于指定的Pod"副本"(Replica)数量。如果有过多的Pod副本在运行,系统就会停掉一些Pod;如果运行的Pod副本数量太少,系统就会再启动一些Pod,总之,通过RC的定义,Kubernetes总是保证集群中运行着用户期望的副本数量。

Replication Controller(RC)的特点:

  • 确保Pod数量;
  • 确保Pod健康;
  • 弹性伸缩;
  • 滚动更新;

应用示例

[[email protected] yaml]# vim rc.yaml
kind:  ReplicationController
apiVersion: v1
metadata:
  name: http-rc
spec:
  replicas: 2
    selector:
      name: http-rc
  template:
    metadata:
      labels:
        name: http-rc
    spec:
      containers:
      - name: http-rc
        image: httpd
[[email protected] yaml]# kubectl apply -f rc.yaml
[[email protected] yaml]# kubectl get rc http-rc
NAME      DESIRED   CURRENT   READY   AGE
http-rc   2         2         2       103s
[[email protected] yaml]# kubectl get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-rc-l2sp6   1/1     Running   0          98s   10.244.1.5   node01   <none>           <none>
http-rc-xghkm   1/1     Running   0          98s   10.244.2.5   node02   <none>           <none>
[[email protected] yaml]# kubectl delete -f rc.yaml 

2)ReplicaSet (RS)

基本概念

ReplicaSet是Replication Controller的替代者,确保Pod副本数在任一时刻都精确满足期望值。用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。虽然ReplicaSet可以独立使用,但一般还是建议使用 Deployment 来自动管理ReplicaSet,这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持rolling-update但Deployment支持)。也就是说Replicaset通常不会直接创建,而是在创建最高层级的deployment资源时自动创建。

RS与RC相比,RS不仅支持等值的标签器,而且还支持基于集合的标签选择器;

ReplicaSet(RS)主要功能:

  • 确保Pod数量;
  • 确保Pod健康;
  • 弹性伸缩;
  • 滚动更新;

应用示例

[[email protected] yaml]# cat rs.yaml
kind:  ReplicaSet
apiVersion: apps/v1
metadata:
  name: http-rs
spec:
  replicas: 2
  selector:
    matchLabels:
      name: http-rs
  template:
    metadata:
      labels:
        name: http-rs
    spec:
      containers:
      - name: http-rs
        image: httpd
[[email protected] yaml]# kubectl apply -f rs.yaml
[[email protected] yaml]# kubectl get rs http-rs
NAME      DESIRED   CURRENT   READY   AGE
http-rs   2         2         2       11s
[[email protected] yaml]# kubectl get pod -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-rs-2sstf   1/1     Running   0          19s   10.244.1.6   node01   <none>           <none>
http-rs-jm8ph   1/1     Running   0          19s   10.244.2.6   node02   <none>           <none>
[[email protected] yaml]# kubectl delete -f rs.yaml 

根据上面的yaml文件可以看出,ReplicaSet和Replication Controller的template部分是一样的,但是selector处不一样。Replication Controller用selector , ReplicaSet用 selector.matchLables选择器 ,这样更简单,更具有表达力!

RS支持的spec.selector 支持matchLabels和matchExpressions两种匹配机制!

ReplicaSet 与 Replication Controller 的区别

  • ReplicaSet 标签选择器的能力更强;
  • Replication Controller只能指定标签名:标签值;
  • Replicaset 可以指定env=pro,env=devel ,也可以指定只要包含env标签就行,理解为env=*;

总之,目前来说,RS可以代替RC的所有的功能,而且RC已经处于快被淘汰的边缘!

3)Deployment

基本概念

Deployment构建于ReplicaSet之上,支持事件和状态查看、回滚、版本记录、暂停和启动升级;Deployment有多种自动更新方案:Recreate,先删除再新建;RollingUpdate,滚动升级,逐步替换。Deployment为Pod和Replica Set(下一代Replication Controller)提供声明式更新,它可以更加方便的管理Pod和Replica Set。只需要在 Deployment 中描述想要的目标状态是什么,Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。此外,也可以定义一个全新的 Deployment 来创建 ReplicaSet 或删除已有Deployment 并创建一个新的来替换。

Deployment控制器典型的应用如下:

  • 使用Deployment来创建ReplicaSet (即RS)。RS在后台创建pod。检查启动状态,看它是成功还是失败;
  • 接着通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态;这会创建一个新的RS,Deployment会按照控制的速率将pod从旧的RS移动到新的RS中;
  • 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision;
  • 扩容Deployment以满足更高的负载;
  • 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线;
  • 根据Deployment 的状态判断上线是否hang住了;
  • 清除旧的不必要的 ReplicaSet;

Deployment和RC、RS一样都是Kubernetes的一个核心内容,主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Controller之外的新特性:

  • RC的全部功能;
  • 事件和状态查看;
  • 回滚;
  • 版本记录;
  • 暂停和启动;
  • 多种升级方案;

一般情况下,个人推荐使用Deployment!

应用示例

[[email protected] yaml]# cat deployment.yaml
kind:  Deployment
apiVersion: extensions/v1beta1
metadata:
  name: http-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      name: http-deployment
  template:
    metadata:
      labels:
        name: http-deployment
    spec:
      containers:
      - name: http-deployment
        image: httpd
[[email protected] yaml]# kubectl apply -f deployment.yaml
[[email protected] yaml]# kubectl get deployments. http-deployment
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
http-deployment   2/2     2            2           9s
[[email protected] yaml]# kubectl get pod -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
http-deployment-548ddf7b65-77vfk   1/1     Running   0          18s   10.244.1.7   node01   <none>           <none>
http-deployment-548ddf7b65-hdczk   1/1     Running   0          18s   10.244.2.7   node02   <none>           <none>
[[email protected] yaml]# kubectl delete -f deployment.yaml 

4)DaemonSet(DS)

基本概念

DaemonSet确保全部(或者一些)Node节点上运行一个Pod 的副本,可使用节点选择器及节点标签指定Pod仅在部分Node节点运行。当有Node加入集群时,会为他们新增一个Pod;当有Node从集群移除时,这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod。DaemonSet常用于存储、日志、监控类守护进程。

DeamonSet简单的用法是,在所有的 Node 上都存在一个 DaemonSet,将被作为每种类型的 daemon 使用。 一个稍微复杂的用法可能是,对单独的每种类型的 daemon 使用多个 DaemonSet,但具有不同的标志,和/或对不同硬件类型具有不同的内存、CPU要求。

应用示例

[[email protected] yaml]# cat ds.yaml
kind:  DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: http-ds
spec:
  selector:
    matchLabels:
      name: http-ds
  template:
    metadata:
      labels:
        name: http-ds
    spec:
      containers:
      - name: http-ds
        image: httpd
[[email protected] yaml]# kubectl apply -f ds.yaml
daemonset.extensions/http-ds created
[[email protected] yaml]# kubectl get ds http-ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
http-ds   2         2         2       2            2           <none>          17s
[[email protected] yaml]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
http-ds-gkscx   1/1     Running   0          39s
http-ds-nbq69   1/1     Running   0          39s
[[email protected] yaml]# kubectl delete -f ds.yaml 

注意:DaemonSet中不可写replicas(副本)数量。它会根据当前k8s集群中的node自动生成!

——————————本文到此结束,感谢阅读——————————————

原文地址:https://blog.51cto.com/14157628/2466694

时间: 2024-10-04 21:53:07

Kubernetes之标签与Pod控制器详解的相关文章

Docker Kubernetes Service 网络服务代理模式详解

Docker Kubernetes  Service 网络服务代理模式详解 Service service是实现kubernetes网络通信的一个服务 主要功能:负载均衡.网络规则分布到具体pod 注:kubernetes deployment服务分配服务器负载均衡VIP只能NODE节点单独访问,这里需要外网用户可以放问到容器内,这里就需要用到service. 网络代理模式 kube-proxy v1.0中只支持userspace模式,在v1.1中,添加了iptables代理,在v1.2开始ip

k8s之pod调度详解

通常情况下,使用的都是k8s默认的调度调度方式,但是在有些情况下,我们需要将pod运行在具有特点的标签的node上才能都运行,这个时候,pod的调度策略就不能使用k8s默认的调度策略了,这个时候,就需要指定调度策略,告诉k8s需要将pod调度到那些node(节点)上. nodeSelector常规情况下,会直接使用nodeSelector这种调度策略.labels(标签) 是k8s里面用来编标记资源的一种常用的方式,我们可以给node标记特殊的标签,然后nodeSelector会将pod调度到带

基于kubernetes构建Docker集群管理详解-转

http://blog.liuts.com/post/247/ 一.前言        Kubernetes 是Google开源的容器集群管理系统,基于Docker构建一个容器的调度服务,提供资源调度.均衡容灾.服务注册.动态扩缩容等功能套件,目前最新版本为0.6.2.本文介绍如何基于Centos7.0构建Kubernetes平台,在正式介绍之前,大家有必要先理解Kubernetes几个核心概念及其承担的功能.以下为Kubernetes的架构设计图:1. Pods        在Kuberne

UISegmentedControl 分段控制器 详解

SegmentedControl又被称作分段控制器,是IOS开发中经常用到的一个UI控件. 初始化方法:传入的数组可以是字符串也可以是UIImage对象的图片数组 - (instancetype)initWithItems:(NSArray *)items; 设置控件风格: @property(nonatomic) UISegmentedControlStyle segmentedControlStyle 注意:这个属性已经废弃,不再起任何作用,它的枚举如下: typedef NS_ENUM(N

MVC 控制器详解

Controller: Controllers 文件夹包含负责处理用户输入和响应的控制器类. MVC 要求所有控制器的名称必须以 "Controller" 结尾. 控制器的职责: 处理跟用户的交互 处理业务逻辑的调用 指定具体的视图显示数据,并且把数据传递给视图 约定: 必须是非静态类    必须实现IController接口            必须是以Controller结尾命名 Action: 在Action中,可以访问任何的当前请求的数据,以及干涉响应的内容,几乎可以将Act

MVC 5 + EF6 完整教程16 -- 控制器详解

Controller作为持久层和展现层的桥梁, 封装了应用程序的逻辑,是MVC中的核心组件之一. 本篇文章我们就来谈谈 Controller, 主要讨论两个方面: Controller运行机制简介 Controller数据传递方式 Controller运行机制简介 实现自定义的Controller 我们自己要实现一个控制器有两种方法:一种是继承IController接口,一种是继承Controller或ControllerBase.Controller继承了ControllerBase, 另外C

MVC控制器详解

原文地址:http://www.cnblogs.com/SeeYouBug/p/6441934.html#3628606 目录 一.理解控制器 1.1.什么是控制器 1.2.控制器的作用 1.3.创建实现IController接口的控制器 1.4.创建继承于Controller类的控制器 二.控制器对数据的接收 2.1.数据来源 2.2.通过上下文对象获取数据 2.3.使用动作(Action)方法参数 2.3.1.使用Action方法参数 2.3.2.理解参数对象实例化 2.3.3.理解可选参数

S5PV210的LCD控制器详解

1.FIMD结构框图 (1)Samsung的s5pv210的LCD控制器叫做FIMD(也叫显示控制器).Display controller(显示控制器)包括用于将图像数据从相机接口控制器的本 地总线或位于系统存储器(例如:显存)中的视频缓冲器传送到外部LCD驱动器接口的逻辑. LCD驱动接口支持三种接口,即RGB接口,I80接口和YUV 接口.显示控制器使用多达五个覆盖图像窗口(也就是虚拟窗口win0-win4),其支持各种颜色格式,如RGB.YUV. FIMD在内部与AHB总线等相连接,在外

&lt;link&gt;标签的rel属性详解

<link>标签定义了当前文档与 Web 集合中其他文档的关系.link 元素是一个空元素,它仅包含属性.此元素只能存在于 head 部分,不过它可出现任何次数.在 HTML 中,<link> 标签没有结束标签.在 XHTML 中,<link> 标签必须被正确的关闭. 除了HTML的标准通用属性之外,link元素还包括很多可选属性: charset, href, hreflang, media, rel, rev, target, title和type.这些属性中,ta