目录
核心资源对象：
namespace: kubectl get ns kubectl create ns bdqn kubectl delete ns bdqn kubectl create deployment deploy1 -n bdqn kubectl get ns bdqn deployment:容器控制器，实现容器高可靠 service：服务，发布pod到外部接口 pod：容器，最小的管理单位，用来容纳一个或多个底层container
Pod的分类
自主式Pod：pod退出，不会自动被创建
控制器管理pod：在控制器的生命周期内，始终维持pod的副本数
镜像获取策略：
imagePullPolicy: Always IfNotPresent Never
容器的重启策略：
restartPolicy: Always OnFailure Never
pod的探针：
LivenessProbe 生存探测 ReadinessProbe 就绪探测
deployment滚动更新和回滚：
kubectl apply -f update2.yaml --record kubectl rollout undo deployment update --to-revision=1 ===================================
ReplicaSet
前边，我们说过Deployment是一种高级的Pod控制器，然后，这种高级Pod控制器，并不是像想象中直接管理后端的Pod，而是又创建了RS这种Pod控制器，然后由RS控制后端的Pod，那么为什么这么做？因为：RS资源并不支持滚动更新策略。
RC: ReplicationController （老一代的Pod控制器）
用于确保由其管控的Pod对象副本数量，能够满足用户期望，多则删除，少则通过模板创建。
特点：
确保Pod资源的对象的数量精准
确保Pod健康运行
弹性伸缩。
同样，它也可以通过yaml或json格式的资源清单来创建。其中spec字段一般嵌套以下字段
replicas: 期望的Pod对象副本数量
selector: 当前控制器匹配Pod对象副本的标签选择器
template: Pod副本的模板
与RC相比而言，RS不仅支持基于等值的标签选择器，而且还支持基于集合的标签选择器。
Labels与selector的关系：举例：
1） 现在有一个Pod资源，且是拥有2个标签。还有svc资源，selector选择器，仅有一个符合，问：svc资源是否能成功的关联到上述的Pod资源？
```yaml kind: Pod apiVersion: v1 metadata: name: pod1 labels: test: web app: httpd spec: containers: - name: pod1 image: httpd imagePullPolicy: IfNotPresent --- kind: Service apiVersion: v1 metadata: name: test-svc1 spec: selector: app: httpd ports: - port: 80 ```
查看服务是否关联成功：
kubectl describe svc test-svc1
Endpoints: 10.244.1.49:80
2） 现在有一个Pod资源，且是拥有1个标签。还有svc资源，selector选择器，需要2个满足条件，问：svc资源是否能成功的关联到上述的Pod资源？
```yaml kind: Pod apiVersion: v1 metadata: name: pod1 labels: test: web spec: containers: - name: pod1 image: httpd imagePullPolicy: IfNotPresent --- kind: Service apiVersion: v1 metadata: name: test-svc1 spec: selector: app: httpd test: web ports: - port: 80
通过以上实验，可以得到的结论：
selector我们可以是拥有选择权的，而labels只能够被动的“被选择”。所以，labels必须全部满足selector的要求，才能被匹配。
如果标签有多个，标签选择器选择其中一个，也可以关联成功。相反，如果选择器有多个，那么标签必须完全满足条件，才可以关联成功！
#### 常用标签
标签：解决同类型的资源对象越来越多，为了更好的管理，按照标签分组。
常用标签分类：
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（每周）
标签要做到：见名知意。
举例：写一个Pod的yaml文件，
```yaml kind: Pod apiVersion: v1 metadata: name: pod-labels labels: env: qa tier: frontend spec: containers: - name: myapp image: httpd imagePullPolicy: IfNotPresent ```
//通过--show-labels显示资源对象的标签。
[root@master labels]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-labels 1/1 Running 0 3m58s env=qa,tier=frontend
//通过-l 查看仅包含某个标签的资源。
[root@master labels]# kubectl get pod -l env NAME READY STATUS RESTARTS AGE pod-labels 1/1 Running 0 5m39s
//给Pod资源添加标签
[root@master labels]# kubectl label pod pod-labels release=v1 pod/pod-labels labeled [root@master labels]# kubectl get pod pod-labels --show-labels NAME READY STATUS RESTARTS AGE LABELS pod-labels 1/1 Running 0 8m33s env=qa,release=v1,tier=frontend
//删除标签
[root@master labels]# kubectl label pod pod-labels release- pod/pod-labels labeled
//修改标签
[root@master labels]# kubectl label pod pod-labels env=dev --overwrite
标签选择器：标签的查询过滤条件。
基于等值关系的（equality-based）："="，"==","！="前边两个都是相等，最后是不等。
基于集合关系(set-based)："in"、"notin"、"exists"三种。
例子：
PodA: app:nginx name:zhangsan age:18 PodB: app:nginx name:lisi age:45 PodC: name:wangwu age:45 ```yaml ...selector: matchLabels: app: nginx matchExpressions:
//Pod中有name这个关键字的，并且对应的值是:zhangsan，或者lisi，那么此处会关联到PodA、PodB
- {key: name,operator: In,values: [zhangsan,lisi]}
//所有关键字是age的，并且忽略它的值，都会被选中，此处会关联到PodA、PodB、PodC
- {key: age,operator: Exists,values:}
...
# matchLabels: 指定键值对表示的标签选择器。
# matchExpressions： 基于表达式来指定的标签选择器。选择器列表间为“逻辑与”关系；使用In或者NotIn操作时，其values不强制要求为非空的字符串列表，而使用Exists或DostNotExist时，其values必须为空。
PS: 如果同时设置了matchLabels和matchExpressions，则两组条件为 AND关系，即需要同时满足所有条件才能完成Selector的筛选。
Job,Deployment,Replica Set 和 Daemon Set，也支持基于集合要求.
使用selector标签选择器的逻辑：***
1. 同时指定的多个选择器之间的逻辑关系为“与“操作。
2. 使用空值的标签选择器意味着每个资源对象都将被选择中。
3. 空的标签选择器无法选中任何资源。
RS的资源清单和RC和Deployment并无二致，所以在此不再过多介绍。
------------------------------------------
DaemonSet
它也是一种Pod控制器。
特点：它会在每一个Node节点上都会生成并且只能生成一个Pod资源。
使用场景：如果必须将Pod运行在固定的某个或某几个节点，且要优先于其他Pod的启动。通常情况下，默认会每一个节点都会运行，并且只能运行一个Pod。这种情况推荐使用DaemonSet资源对象。
监控程序：
日志收集程序；
运行一个web服务，在每一个节点都运行一个Pod，查看语法是否正确。
旧版本：
kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: test-ds spec: template: metadata: labels: name: test-ds spec: containers: - name: test-ds image: httpd imagePullPolicy: IfNotPresent ``` RC、RS、Deployment、DaemonSet。 Pod控制器。--> Controller-manager(维护集群状态，保证Pod处于期望的状态。)
新版本：
[root@master ~]cat ds.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: ds spec: selector: matchLabels: name: test-web template: metadata: labels: name: test-web spec: containers: - name: ds image: nginx imagePullPolicy: IfNotPresent ```
需要注意的是：ds也支持滚动更新，它此时的默认更新策略是rollingUpdate。
# kubectl explain ds.spec.updateStrategy.
- OnDelete：这是用于向后兼容的默认更新策略。 使用OnDelete更新策略，在更新DaemonSet模板之后，只有在手动删除旧的DaemonSet窗格时才会创建新的DaemonSet Pod。 这与Kubernetes版本1.5或更早版本中的DaemonSet是一致的。
- RollingUpdate：通过RollingUpdate更新策略，在更新DaemonSet模板后，旧的DaemonSet窗格将被终止，并且将以受控的方式自动创建新的DaemonSet。
更改ds更新策略：
旧版本：
```yaml kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: ds spec: updateStrategy: type: RollingUpdate template: metadata: labels: name: test-web spec: containers: - name: ds image: nginx imagePullPolicy: IfNotPresent ```
新版本：
自己写
滚动升级，并回滚
综合练习作业：
创建一个新的namespace资源（名称test），且要求以下资源都在此名称空间内运行。
1） 创建一个DaemonSet资源，要求使用自定义镜像v1版本，标签为： test-web，app: httpd两个。
2） 创建svc资源，与上述DS资源关联，并验证关联成功。
3） 上述DS资源，镜像更新为v2版本。
4）创建一个Deployment资源，镜像使用自定义镜像v1版本，replicas：8.问，能否与上述SVC资源关联成功？并用实验的方式验证。
5） 将上述Deployment资源更新为v2版本的镜像，且要求更新过程中最大不可用Pod数量为: 2. 更新过程中Pod总数为12个。
