Kubernetes之标签与Pod控制器详解

标签：ken   根据   监控   current   进程   软件   修改   ber   base   一、标签 标签的主要作用：解决同类型的资源对象越来越多，为了更好的管理，按照标签分组； 常用的标签分类：release（版本）：stable（稳定版）、canary（金丝雀版本、可以理解为测试版）、beta（测试版）environment（环境变量）：dev（开发）、qa（测试）、production（生产）application（应用）：ui、as（应用软件）、pc、sctier（架构层级）：frontend（前端）、backend（后端）、cache（缓存、隐藏）partition（分区）：customerA（客户A）、customerB（客户B）track（品控级别）：daily（每天）、weekly（每周） K8s集群中虽然没有对有严格的要求，但是标签还是要做到：见名知意！方便自己也方便别人！ 常用的命令有： [root@master yaml]# kubectl get pod --show-labels //显示pod的标签 [root@master yaml]# kubectl get pod -L env //显示键对应的值 [root@master yaml]# kubectl get pod -l env //通过小l查看仅包含env标签的资源 [root@master yaml]# kubectl get pod -l env --show-labels //显示对应的键值 [root@master yaml]# kubectl label pod labels app=pc //给pod打标签 [root@master yaml]# kubectl label pod labels app- //去除标签 [root@master 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健康； 弹性伸缩； 滚动更新； 应用示例 [root@master 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 [root@master yaml]# kubectl apply -f rc.yaml [root@master yaml]# kubectl get rc http-rc NAME DESIRED CURRENT READY AGE http-rc 2 2 2 103s [root@master 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 http-rc-xghkm 1/1 Running 0 98s 10.244.2.5 node02 [root@master 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健康； 弹性伸缩； 滚动更新； 应用示例 [root@master 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 [root@master yaml]# kubectl apply -f rs.yaml [root@master yaml]# kubectl get rs http-rs NAME DESIRED CURRENT READY AGE http-rs 2 2 2 11s [root@master 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 http-rs-jm8ph 1/1 Running 0 19s 10.244.2.6 node02 [root@master 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！ 应用示例 [root@master 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 [root@master yaml]# kubectl apply -f deployment.yaml [root@master yaml]# kubectl get deployments. http-deployment NAME READY UP-TO-DATE AVAILABLE AGE http-deployment 2/2 2 2 9s [root@master 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 http-deployment-548ddf7b65-hdczk 1/1 Running 0 18s 10.244.2.7 node02 [root@master 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要求。 应用示例 [root@master 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 [root@master yaml]# kubectl apply -f ds.yaml daemonset.extensions/http-ds created [root@master yaml]# kubectl get ds http-ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE http-ds 2 2 2 2 2 17s [root@master 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 [root@master yaml]# kubectl delete -f ds.yaml 注意：DaemonSet中不可写replicas（副本）数量。它会根据当前k8s集群中的node自动生成！ ——————————本文到此结束，感谢阅读——————————————Kubernetes之标签与Pod控制器详解标签：ken   根据   监控   current   进程   软件   修改   ber   base   原文地址：https://blog.51cto.com/14157628/2466694