环境介绍

基于[ https://www.geek-share.com/detail/2789293776.html]() 的实验继续进行

ReplicaSet简单介绍

1. RC：ReplicationController（老一代的pod控制器）

用来确保由其管控的Pod对象副本数量，能够满足用户期望，多则删除，少则通过模本创建

特点：

• ​ 确保Pod资源对象的数量精准。
• ​ 确保pod健康运行。
• ​ 弹性伸缩

同样，它也可以通过yaml或json格式的资源清单来创建。其中spec字段一般嵌套以下字段：

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

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

2. 标签：解决同类型的资源对象，为了更好的管理，按照标签分组。

常用的标签分类：

• ​ release（版本）：stable（稳定版）、canary（金丝雀版本）、beta（测试版本）
• ​ environment（环境变量）：dev（开发）、qa（测试）、production（生产）
• ​ application（应用）：ui、as（application software应用软件）、pc、sc
• ​ tier（架构层级）：frontend（前端）、backend（后端）、cache（缓存）
• ​ partition（分区）：customerA（客户A）、customerB（客户B）
• ​ track（品控级别）：daily（每天）、weekly（每周）

标签要做到：见名知意。

3.测试

（1）编写一个pod的yaml文件

[root@master ~]# vim label.yaml

kind: Pod
apiVersion: v1
metadata:
name: labels
labels:
env: qa
tier: frontend
spec:
containers:
- name: myapp
image: httpd

<1>执行一下

[root@master ~]# kubectl apply -f label.yaml  --record

<2>查看一下

[root@master ~]# kubectl get pod  --show-labels
//通过--show-labels显示资源对象的

[root@master ~]# kubectl get po -L env,tier
//显示某个键对应的值

[root@master ~]# kubectl get po -l env,tier
//通过-l 查看仅包含某个标签的资源。

（2）添加标签

[root@master ~]# kubectl label pod  labels app=pc
//给pod资源添加标签

（3）修改标签

[root@master ~]# kubectl label pod labels env=dev --overwrite
//修改标签

[root@master ~]# kubectl get pod -l tier --show-labels
//查看标签

（4）编写一个service的yaml文件

[root@master ~]# vim service.yaml
kind: Service
apiVersion: v1
metadata:
name: service
spec:
type: NodePort
selector:
env: qa
ports:
- protocol: TCP
port: 90
targetPort: 80
nodePort: 30123

<1>执行一下

[root@master ~]# kubectl apply -f service.yaml

<2>查看一下

[root@master ~]# kubectl describe svc

<3>访问一下

[root@master ~]# curl 127.0.0.1:30123

如果标签有多个，标签选择器选择其中一个，也可以关联成功。相反，如果选择器有多个，那么标签必须完全满足条件，才可以关联成功。

4. 标签选择器：标签的查询过滤条件。

[基于等值关系的（equality-based）]()：“=”，“==”，“！ =”前面两个都是相等，最后一个是不等于。

[基于集合关系（set-based）]():in、notin、exists三种。选择器列表间为“逻辑与”关系，使用ln或者NotIn操作时，其valuas不强制要求为非空的字符串列表，而使用Exists或DostNotExist时，其values必须为空

使用标签选择器的逻辑：

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

（1）例子

编写一个selector的yaml'文件

[root@master ~]# vim selector.yaml
selector:
matchLabels:
app: nginx
mathExpressions:
- {key: name,operator: In,values: [zhangsan,lisi]}
- {key: age,operator: Exists,values:}

• selector：当前控制器匹配Pod对此项副本的标签选择器
• matchLabels: 指定键值对表示的标签选择器。
• mathExpressions:：基于表达式来指定的标签选择器。

DaemonSet

它也是一种pod控制器。

RC，RS , deployment , daemonset.都是pod控制器。statfukSet，RBAC

1. 使用场景：

如果必须将pod运行在固定的某个或某几个节点，且要优先于其他的pod的启动。通常情况下，默认会将每一个节点都运行，并且只能运行一个pod。这种情况推荐使用DeamonSet资源对象。

• 监控程序；
• 日志收集程序；
• 集群存储程序；

[root@master ~]# kubectl get ds -n kube-system
//查看一下DaemonSet

2. DaemonSet 与 Deployment 的区别

• Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。
• DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。

3. 运行一个web服务，在每一个节点运行一个pod。

[root@master ~]# vim daemonset.yaml

kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: test-ds
spec:
template:
metadata:
labels:
name: test-ds
spec:
containers:
- name: test-ds
image: httpd

<1>执行一下

[root@master ~]# kubectl apply -f daemonset.yaml

<2>查看一下

[root@master ~]# kubectl get ds

总结

1）总结RC、RS、Deplyment、DaemonSet控制器的特点及使用场景。

<1>Replication Controller（RC）

介绍及使用场景

Replication Controller

RC

RC

Kubernetes

RC

Pod

Pod

Pod

Pod

Pod

RC

Pod

Pod

RC

Pod

主要功能

• 确保pod数量：RC用来管理正常运行Pod数量，一个RC可以由一个或多个Pod组成，在RC被创建后，系统会根据定义好的副本数来创建Pod数量。在运行过程中，如果Pod数量小于定义的，就会重启停止的或重新分配Pod，反之则杀死多余的。
• 确保pod健康：当pod不健康，运行出错或者无法提供服务时，RC也会杀死不健康的pod，重新创建新的。
• 弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过RC动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取RC关联pod的整体资源使用情况，做到自动伸缩。
• 滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

<2>Replication Set（RS）

被认为 是“升级版”的RC。RS也是用于保证与label selector匹配的pod数量维持在期望状态。

实际上

RS

和

RC

的功能基本一致，目前唯一的一个区别就是

RC

只支持基于等式的

selector

（env=dev或app=nginx），但

RS

还支持基于集合的

selector

（version in (v1, v2)），这对复杂的运维管理就非常方便了。

kubectl

命令行工具中关于

RC

的大部分命令同样适用于我们的

RS

资源对象。不过我们也很少会去单独使用

RS

，它主要被

Deployment

这个更加高层的资源对象使用，除非用户需要自定义升级功能或根本不需要升级

Pod

，在一般情况下，我们推荐使用

Deployment

而不直接使用

Replica Set

。

区别在于

1、RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），这对复杂的运维管理很方便。

2、升级方式

• RS不能使用kubectlrolling-update进行升级
• kubectl rolling-update专用于rc
• RS升级使用deployment或者kubectl replace命令
• 社区引入这一API的初衷是用于取代vl中的RC，也就是说当v1版本被废弃时，RC就完成了它的历史使命，而由RS来接管其工作

<3>DaemonSet

1. 特点：

如果必须将pod运行在固定的某个或某几个节点，且要优先于其他的pod的启动。通常情况下，默认会将每一个节点都运行，并且只能运行一个pod。这种情况推荐使用DeamonSet资源对象。

一个DaemonSet对象能确保其创建的Pod在集群中的每一台（或指定）Node上都运行一个副本。如果集群中动态加入了新的Node，DaemonSet中的Pod也会被添加在新加入Node上运行。删除一个DaemonSet也会级联删除所有其创建的Pod。

2. 使用环境

• 监控程序；
• 日志收集程序；
• 集群存储程序；

<4>Deployment

1. 什么是Deployment

Kubernetes Deployment提供了官方的用于更新Pod和Replica Set（下一代的Replication Controller）的方法，您可以在Deployment对象中只描述您所期望的理想状态（预期的运行状态），Deployment控制器为您将现在的实际状态转换成您期望的状态，例如，您想将所有的webapp:v1.0.9升级成webapp:v1.1.0，您只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。现在，您可以通过Deployment来创建新的资源（pod，rs，rc），替换已经存在的资源等。

你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

2. 典型的用例

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

3. 使用环境

Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前某一版本（成功/稳定）的Deployment等功能，在某种程度上，Deployment可以帮我们实现无人值守的上线，大大降低我们的上线过程的复杂沟通、操作风险。

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续Deployment

3. DaemonSet 与 Deployment 的区别

• Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。
• DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。

2）使用DaemonSet控制器运行httpd服务，要求名称以自己的名称命名。标签为：tier=backend,env=dev.

[root@master ~]# vim daemonset.yaml
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: xgp-ds
spec:
template:
metadata:
labels:
tier: backend
env: dev
spec:
containers:
- name: xgp-ds
image: httpd

查看一下

[root@master ~]# kubectl get pod  --show-labels

[root@master ~]# kubectl get pod -L env,tier

3) 创建service资源对象与上述资源进行关联，要有验证。

[root@master ~]# vim service.yaml
kind: Service
apiVersion: v1
metadata:
name: service
spec:
type: NodePort
selector:
env: dev
ports:
- protocol: TCP
port: 90
targetPort: 80
nodePort: 30123

执行一下

[root@master ~]# kubectl apply -f service.yaml

查看一下

[root@master ~]# kubectl describe svc

访问一下

[root@master ~]# curl 127.0.0.1:30123

4）整理关于标签和标签选择器都有什么作用？

<1>标签：解决同类型的资源对象，为了更好的管理，按照标签分组。

<2>标签选择器：标签的查询过滤条件。