k8s系列（六：实例）pod控制器、replicaSet、deployment、动态更新、控制更新节奏（金丝雀、蓝绿）
pod控制器的类型：
ReplicaSet：支持滚动更新，自动扩缩容，用pod资源模板保证pod副本数量
Deployment：借助ReplicaSet来实现，还支持回退，声明式配置资源，这个服务是无状态的，必须保持一直运行，守护进程类 的
DaemonSet： 用一个节点精确保持一个特定pod副本运行，例如一些基础服务、这个服务是无状态的，必须保持一直运行，守 护进程类的
Jop： 只运行一次，任务没完成会重建，任务完成后不会重建，只能执行一次性作业，不需要持续运行
Cronjop：周期性运行，不需要持续运行，
StatefulSet: 有状态应用(redis、mysq)把手动做的操作复杂的执行逻辑定义成脚本放在pod模板当中，故障后通过脚本自动恢 复过来
TPR: Third Party Resources, 1.2-1.7
CDP: Custom Defined Resoutces,1.8+
Operator:
Helm:
定义 ReplicaSet
ReplicaSet 的spec包括副本数、标签选择器、pod模板
编辑ReplicaSet 的yaml配置文件
执行命令kubectl create -f rs-demo.yaml创建
查看pod控制器
pod名称自动生成
此时如果删除其中一个pod，rs控制器会自动创建一个，以保证副本数量为两个，如果有另外的pod的标签刚好符合rs的标签选择器的规则，那rs会自动随机剔除一个pod
动态扩容（编辑被纳入到spiserver中的文件）
金丝雀发布：通过kubectl edit rs myapp将其中container的镜像改为目标版本，此时的pod还是之前版本的pod，手动删除其中一个pod后被创建出来的新pod按照最新版本的配置文件生成，此时为新老pod并存状态，过一段时间发现访问新pod的用户正常，在手动将老pod按照一分钟一个快速删除（需要人工参与）
蓝绿发布：在创建一个rs，新的rs的标签选择器跟老的rs标签选择器不完全一样，但是符合service，先创建rs2再删除rs1，或 者让service只符合rs1，等rs2发布完了改service让service符合rs2不符合rs1
deployment 一个deploy可以管理多个rs，但是激活的只有一个，一旦rs2有问题激活rs1实现回滚，可以通过tach或post直接来实现修改，提供滚动式自定义自控制的更新，还能实现控制更新节奏（一次几个）和更新逻辑（多一个少一个pod））只需要控制节奏就可以模拟出来金丝雀、蓝绿
kubectl explain deploy.spec.strategy有
Recreate:删一个重建一个，重建更新
RollindUpdate：滚动更新
maxSurge：定义更新过程中最多能超过定义副本数量的多少
maxUnavailable：最多有几个不可用
定义deploy-demo.yaml
用apply声明式创建
查看发现创建了deploy自动的创建了rs
7f9c78c9f7为template的哈希值、摸班不同哈希值不同，用这个值追踪到特定的pod
滚动更新
一、vi deploy-demo.yaml修改replicas的值实现扩缩容
修改完之后kubectl apply -f deploy-demo.yaml
kubectl get pods -w监控pod
kubectl get pods -l app=myapp -w过滤监控
kubectl get rs -o wide可以看到又自动创建出一个rs，历史版本的rs用于回滚
kubectl rollout history deployment myapp-deploy查看历史滚动记录
二、kubectl set image更改镜像
三、kubectl patch deployment myapp-deploy -p '{"spec":{"replicas":5}}'打补丁更新
控制更新节奏
打补丁更新更新是更新策略
查看deploy
启动更新并且暂停
监控pod更新过程
此时金丝雀已经被扔出去
监视更新过程
结束暂停继续更新
此时查看rs版本已经有三个
查看deployment历史版本
回滚（如果不指--to-revision是滚回上一个版本，滚第一个版本在滚就到了当前版本的最后一版）
查看当前正在工作的rs版本
