转载于网络
pod是kubernetes的最小单元，自主式创建的pod删除就没有了，但是通过资源控制器创建的pod如果删除还会重建。pod控制器就是用于实现代替我们去管理pod的中间层，并帮我们确保每一个pod资源处于我们所定义或者所期望的目标状态，pod资源出现故障首先要重启容器，如果一直重启有问题的话会基于某种策略重新编排。自动适应期望pod数量
pod控制器类型简介：
1.ReplicaSet:
代用户创建指定数量的pod副本数量，确保pod副本数量符合用户期望的数量状态，如果少了多退少补，并且支持滚动式自动扩容和缩容机制。
ReplicaSet主要三个组件组成：
（1）用户期望的pod副本数量
（2）标签选择器，判断哪个pod归自己管理
（3）pod资源模板（当现存的pod数量不足，会根据pod资源模板进行新建帮助用户管理无状态的pod资源，精确反应用户定义的目标数量。不直接使用）
Deployment：（无状态，守护进程类，只关注群体不关注个体）
工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。（pod数量和node没有精确的配比，没有一对一的关系）
DaemonSet：（无状态，守护进程类，只关注群体不关注个体）
确保集群中的每一个节点上只运行一个特定的pod副本，系统级的后台任务。新增节点他都会自动添加pod。也可以是满足条件的节点上运行特定的副本。比如ELK服务特性：服务是无状态的服务必须是守护进程（pod资源模板，标签选择器）有hostnetwork直接爆露node
Job：（有状态，一次性任务）
只要完成就立即退出，不需要重启或重建，没有完成重构job。只能执行一次性任务
Cronjob：（有状态，周期性任务）
周期性任务控制，不需要持续后台运行
StatefulSet：（管理有状态应用）
管理有状态应用（redis cluster）针对管理的应用器配置管理是不一样的，没有什么共通的规律，需要人为的封装在脚本中实行，相当之大的逻辑处理。（运维技能封装到运维脚本中）
TPR：（third party resource）1.7以后就不支持了
第三方资源
CDR：（custom defined resource） 1.8+以后
用户自定义资源
控制器ReplicaSet应用：
获取replica的字段命令===>kubectl explain rs
实例yaml：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: web-server
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: web-nginx
release: canary
template:
metadata:
name: web-nginx-pod
labels:
app: web-nginx
release: canary
environment: qa
spec:
containers:
- name: web-nginx-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
~template中创建的container必须包含控制器中标签选择器中要选择的标签，如果不包含控制器就发现不了他已经存在pod，会一直创建下去
动态修改replicaset的副本数量 1. kubectl edit rs web-server 或者 kubectl edit -f replicaSet_demo.yaml
2.kubectl scale --replicas=5 rs/web-server 或者 kubectl scale -f replicaSet_demo.yaml
通过kubectl edit可以修改pod资源的镜像，但是只有是重建的pod才会使用修改过得镜像
控制器deployment应用：
deployment是建构在rs之上的，可以控制多个rs滚动式自定义，自控制的更新。
同时在实现自动更新时还能实现控制更新节奏和更新逻辑
获取deployment的字段命令===>kubectl explain deploy
实例deployment：
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
namespace: default
spec:
replicas: 5
selector:
matchLabels:
app: myapp
release: canary
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: myapp
release: canary
spec:
containers:
- name: myapp-container
image: ikubernetes/myapp:v2
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
红色部分是更新策略，可以多出一个，不能少于replica定义的5个
deployment启动可以用kubectl apply -f deploy_demo.yaml
可以用打补丁的方式进行修改：kubectl patch deployment myapp-deploy -p '{"spec":{"replicas":5}}' 相对来说要对文件的嵌套关系了解清楚
kubectl rollout pause deployment myapp-deploy 暂停一个deployment
kubectl rollout resume deployment myapp-deploy 重新启动一个暂停的deployment
kubectl rollout history deployment myapp-deploy 查看历史版本
kubectl rollout undo deployment myapp-deploy --to-revision=1 回滚到以前版本
控制器daemonset应用：
获取daemonset的字段：kubectl explain ds
实例daemonset
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: redis
role: logstor
template:
metadata:
labels:
app: redis
role: logstor
spec:
containers:
- name: redis
image: redis:4.0-alpine
ports:
- name: redis
containerPort: 6379
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeta-ds
namespace: default
spec:
selector:
matchLabels:
app: filebeat
release: stable
template:
metadata:
labels:
app: filebeat
release: stable
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.5-alpine
imagePullPolicy: IfNotPresent
env:
- name: REDIS_HOST
value: redis.default.svc.cluster.local
- name: REDIS_LOG_LEVEL
value: info
通过kubectl get pod -o wide 可以看出一个节点上只有一个filebeat的pod
daemonset也支持滚动式更新，有两个选项1.OnDelete 在删除时更新
2.RollingUpdate 只有做多不可用，最多有几个不工作，根据节点数量
通过修改containers的image镜像来测试滚动更新 ,先删除一个pod，再新建一个，滚动式更新。一次滚动几个根据maxUnavailable的值是多大（kubectl explain ds.spec.updateStrategy.rollingUpdate）
kubectl set image ds filebeta-ds filebeta=ikubernetes/filebeta:5.6.6-alpine kubectl get pod -w
