pod控制器

//Pod控制器及其功用
Pod控制器，又称之为工作负载(workload)，是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

//pod控制器有多种类型:
1、ReplicaSet:也叫RS，代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。无状态应用:无数据存储
ReplicaSet主要三个组件组成:
(1)用户期望的pod副本数量
(2)标签选择器，判断哪个pod归自己管理
(3)当现存的pod数量不足，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet 不是直接使用的控制器，而是使用Deployment。

2、Deployment:工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
ReplicaSet与Deployment 这两个资源对象逐步替换之前RC的作用。

3、DaemonSet:用于确保集群中的每一v个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性:服务是无状态的
服务必须是守护进程

4、StatefulSet: 管理有状态应用

5、Job:只要完成就立即退出，不需要重启或重建

6、Cronjob: 周期性任务控制，不需要持续后台运行

//Pod与控制器之间的关系
controllers: 在集群上管理和运行容器的pod对象，pod通过label-selector 相关联。
Pod通过控制器实现应用的运维，如伸缩，升级等。

1、Deployment

部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景: web服务

写法

cat > deployment01.yaml<<-EOF
apiVersion: apps/v1   #指定api版本标签
kind: Deployment   #定义资源的类型/角色，deployment 为副本控制器，此处资源类型可以是Deployment、Job、 Ingress、 Service等
metadata:     #定义资源的元数据信息，比如资源的名称、namespace、标签等信息
  name: nginx-deployment   #定义资源的名称，在同一个namespace空间中必须是唯一的
  namespace: default     #所属命名空间
  labels:           #定义资源标签(Pod的标签)
    app: nginx      #标签
spec:        #定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
  replicas: 3     #定义资源的副本数量
  selector :      #定义标签选择器
    matchLabels:   #定义匹配标签
      app: nginx   #匹配上面的标签，需与上面的标签定义的app保持一致，才能让pod和控制器绑定
  template:       #定义pod业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
    metadata:     #设置资源名称
      labels:
        app: nginx #和标签选择器一致，pod类型不用加
    spec:
      containers:            #定义容器属性
      - name: nginx          #定义一个容器名，一个- name: 定义一个容器
        image: nginx:1.15.4   #定义容器使用的镜像以及版本
        ports:                #定义端口号
        - name: http		#端口名
          containerPort: 80   #定义容器的对外的端口,可以定义多个端口
        
        args:
        #开机策略
        - /bin/sh
        - -c
        - sleep 30; exit 3

        resources:
        #资源配置
          requests:
          #预留资源
            memory: "64Mi"
            #内存
            cpu: "250m"
            #CPU
          limits:
          #最大资源
            memory: "128Mi"
            #内存
            cpu: "500m"
            #CPU
         livenessProbe:
           exec:
             command:
             - cat
             - /tmp/healthy
           failureThreshold: 1
           initialDelaySeconds: 5
           periodSeconds: 5
      restartPolicy: Never
      #重启策略
      - name.....			#如果要加多个容器
EOF
      
      
kubectl apply -f deployment01.yaml

kubectl get deploy -n kube-public 

滚动发布

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 3
  selector :
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4   #修改这里的版本

kubectl apply -f deployment01.yaml
#然后就可以开始滚动发布了

kubectl rollout history deployment/petclinic
#查看发布历史

kubectl rollout undo deployment/petclinic
#回退一个版本
kubectl rollout undo deployment/petclinic --to-revision=2
#回退到版本2

kubectl rollout status deployment/petclinic
#可以显示回退的状态

2、SatefulSet

部署有状态应用
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service ( 即没有Cluster IP的Service) 来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现
有序收缩，有序删除(即从N-1到0)

常见的应用场景:数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

从上面的应用场景可以发现，StatefulSet由以下几个部分组成:
●HeadlessService(无头服务):用于为Pod资源标识符生成可解析的DNS记录。
●volumeClaimTemplates (存储卷申请模板) :基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
●StatefulSet:用于管控Pod资源。

为什么要有headless?
在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headlessservice解析直达到pod，还需要给pod配置一个唯一的名称。

为什么要有volumeClainTemplate?
大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod
模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

服务发现:就是应用服务之间相互定位的过程。
应用场景:
●动态性强:Pod会飘到别的node节点
●更新发布频繁:互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把idea变成产品挣到钱然后再慢慢一点一点优化
●支持自动伸缩:来大促，肯定是要扩容多个副本

K8S.里服务发现的方式---DNS，使K8s集群能够自动关联service资源的“名称"和“CLUSTER-IP"，从而达到服务被集群自动发现的目的。

实现K8S里DNS功能的插件:
●skyDNS: Kubernetes 1.3之 前的版本
●kubeDNS: Kubernetes 1.3至Kubernetes 1.11 
●CoreDNS: Kubernetes 1.11开始至今

//从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下:
(pod_name).(service_name).(namespace_name).svC.cluster.local

//总结
无状态:
1) deployment 认为所有的pod都是一样的
2)不用考虑顺序的要求
3)不用考虑在哪个node节点上运行
4)可以随意扩容和缩容

有状态
1)实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd, zookeeper
2)实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别
service:
组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service: 无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

3、DaemonSet

DaemonSet确保全部(或者一些)Node上运行一个Pod的副本。比如日志收集，当有Node加入集群时，也会为他们新增一个Pod。当有Node 从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。

使用DaemonSet的一些典型用法:
●运行集群存储daemon,例如在每个用DaemonSet 的一些典型用法: Node上运行 glusterd、ceph。
●在每个Node上运行日志收集daemon，例如fluentd、logstash。
●在每个Node上运行监控daemon， 例如Prometheus Node Exporter、 collectd、 Datadog 代理、New Relic 代理，或Ganglia gmond。
应用场景: Agent
//官方案例( 监控)
https://kubernetes. io/docs/concepts /workloads/ controllers/daemonset/

4、Job

Job分为普通任务(Job) 和定时任务(CronJob)
常用于运行那些仅需要执行一次的任务
应用场景:数据库迁移、批处理脚本、kube-bench扫描、 离线数据处理，视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/