pod可以由管理器去实现自动的创建、删除等管理操作，如ReplicationController、ReplicaSet、DaemonSet、Job、CronJob、StatefulSet、Deployment等。其中ReplicationController、ReplicaSet、DaemonSet、Job、CronJob是无状态的部署，StatefulSet是有状态的部署，而Deployment是基于ReplicaSet去管理Pod的高阶资源。有状态和无状态的区别在于新pod的状态是否和前面的pod一致，主要体现在数据卷上面，具体如下如所示：

1.ReplicationController

ReplicationController是pod的管理器，用来保证pod始终保持运行，且运行的副本数始终等于指定的副本数。使用时应该注意：
1.更改pod模板不会对现在rc中运行的pod造成影响
2.更改标签选择器会使原来rc管控的pod脱离rc的控制
3.删除rc不会删除该rc管理下的pod
4.更改pod的标签之后，若pod没有匹配rc的标签了，则该pod就脱离了rc的控制，rc会根据pod模板创建一个新的pod来保证运行的pod数量达到指定的副本数

ReplicationController的三个主要部分

1. label selector:标签选择器，用来确定rc管理的pod有哪些，常常根据label值对其进行分类
2. replica count:副本个数，用来确定该rc管理下应该运行的pod数量
3. pod template:pod模板，用来指定创建的pod模板

利用yaml文件创建一个rc管理器
yaml文件内容如下：

这里创建了一个名为nginx的rc管理器，该管理器中要运行3个Pod，用选择器去选择该nginx管理器管理的pod，标签对为app=nginx，且每个pod中运行一个容器，容器运行的镜像是nginx，且pod中的容器开放8080端口
常用操作如下：

#根据nginx-rc.yaml文件创建replicationcontroller
kubectl create -f nginx-rc.yaml
#查看所有rc的统计信息
kubectl get rc
#查看指定rc的详细信息
kubectl describe rc rcname
#修改rc的pod模板，其中rcname代表rc的name值，进入编辑模式之后进行修改，修改完成之后保存并退出即可
kubectl edit rc rcname
#扩缩pod的数量,num是副本数量
法一：kubectl scale rc rcname --replicas=num
法二：kubectl edit rc rcname进入编辑模式
#删除rc管理器，默认情况下删除rc之后其管控的pod会处于terminating状态，若想要保持pod处于running状态，则需要添加--cascade=false选项 
kubectl delete rc rcname 

因为rc会保证其管控范围内的pod数量始终等于副本个数，因此这里手动删除一个pod，可以看到rc会自动创建一个pod

2.ReplicaSet

ReplicaSet是新一代的ReplicationController，和ReplicationController相比，具有更高效的pod选择器，rc的pod选择器只能根据一组labe进行选择，但是ReplicaSet可以使用两组label进行选择，需要注意的是删除ReplicaSet的同时，其中的pod也会一并删除

利用yaml文件创建ReplicaSet资源
文件内容如下：

这里使用了更高级的选择器，每个表达式需要一个key、operator、values(当operator字段是Exists或者是DoesNotExist时不需要)；operator字段的值可以是In，NotIn，Exists，DoesNotExist

#查看rs的统计信息
kubectl get rs
#查看指定rs的详细信息
kubectl describe rs rsname
#删除rs
kubectl delete rs rsname

3.DaemonSet

daemonset是类似于rc、rs的一个管理工具，但是其能保证在特定的节点上只运行一个pod节点，注意的是：
1.若符合ds管理的node节点的标签发生变化或者是所处节点下线，则daemonset会将将该节点上部署的pod删除
2.删除ds，对应的pod也会一起删除
基于yaml文件创建DaemonSet资源
yaml文件内容如下：

这里使用了nodeseletor选择器，选择标签disk值为nginx的节点，并在其上部署nginx服务

4.Job

Job和rc、rs、ds类似，但是不同的是Job中的pod并不会一直运行，当pod完成其任务之后，就会终止，即Job中的pod是有完成态的，phase那一列中值为successed
**1.job启动的pod在完成任务之后不会删除，还可以使用kubectl logs podname去查看其日志
2.pod会随Job的删除而删除 **
基于yaml文件创建Job资源
文件内容如下：

这里可以看到在pod的模板里面，添加了一个名为restartpolicy的字段，该字段默认是Always值，但是在kind为Job时，该字段不能为Always，因为Job中的pod不会一直运行，所以这里需要将restartPolicy字段的值修改为OnFailure或者是Never，防止容器在完成任务时启动。
其他字段：

1.在Job的spec中设置completions字段指定需要完成的任务数，即共有多少个pod完成任务，
2.在Job的spec中设置parallelism字段指定同时运行的pod数量，既并发量
3.在pod的配置中设置activeDeadlineSeconds属性可以限制pod运行的时间

5.CronJob

CronJob是K8s中的定时任务，可以设置在具体的时间执行某个操作，类似于linux中的crontab计划任务。不同的是CronJob的时间表只有5个条目：
1.分钟
2.小时
3.每月的第几天
4.每年的第几月
5.每周的第几天

利用yaml文件创建CronJob资源

使用schedule字段去设置时间表，文件中的时间表为每年的9月3号的每小时的0、15、30分中都会运行一次Job任务。

6.Statefulset

Statefulset是有状态的，而前5种管理工具都是无状态的，若statufulset管理的pod挂掉后，则会重新创建一个pod，新pod和旧pod拥有相同的名称、网络标识和状态等，且statefulset创建的每一个pod不是完全一样的，每个pod都可以拥有不同的数据卷。
statefulset在有实例不健康的情况下是不允许缩容操作，且缩容时不会删除对应的持久卷声明，因此能够做到数据的持久化
statefulset会依次启动pod，为了防止多个pod同时竞争资源

7.deployment

deployment可以同时管理多个pod版本，是一种更高阶的资源，创建一个deployment时会创建一个ReplicaSet资源，并由该ReplicaSet去管理deployment集群中的pod
deployment是用来管理rs，因为在应用的滚动升级中，会创建一个额外的rc，先在新的rc上启动新版本的pod，然后停掉旧controler中的一个Pod。再启动新的pod，停掉旧的pod，直到全部创建和停止。且在rolling-update滚动升级中，该过程是由运行在worker node上的代理kubelet执行的，若升级过程中出现网络等问题，则会导致升级失败，pod停止服务，而deployment就是为了解决该问题产生的。

deployment有两种升级策略，分别是rollingpdate和recreate。且deployment的升级是由master处理的，不再是kubectl客户端执行，由kubernetes的控制器管理升级会使升级更加可靠

1.rollingupdate是默认的升级策略，为滚动升级，即创建一个新的pod，删除一个旧的pod
2.recreate会一次性地删除所有旧的pod，然后一次性的创建所有新pod

EXPOSE方式部署服务

##对deployment部署的pod进行扩缩操作
kubectl scale deployment nginx-deployment --replicas=10
#将deployment部署的一个pod发布出去
kubectl expose deployment ngkubeinx-deployment --type=LoadBalancer --name podname 
#查看发布的pod应用
kubectl get services

可以看到，该应用已经发布出去，且对外暴露的是31607的端口，访问该虚拟机的ip地址+对外暴露的端口号：

也可以在虚拟机中通过curl ip:80来访问该服务

yaml文件方式部署服务

首先创建configmap资源，用来挂载nginx的配置文件和index.html文件
default,conf文件如下:

server {
    listen 80;
    server_name localhost;
    location / {
        root /usr/share/nginx/html;
        index index.html index.xml;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }
}
server {
    listen       80;
    server_name hxy.te.com;
    location / {
        proxy_set_header  Host $host;
        proxy_pass http://baidu.com;
    }
    error_page 500  502 504 503  /50x.html;
    location = /50x.html {
        root   html;
    }
}

html文件如下：

hello world! this is my k8s nginx

创建configmap资源：

##创建一个名为nginx-config的configmap资源
kubectl create configmap nginx-config --from-file=./default.conf
#创建一个名为nginx-html的configmap资源
kubectl create configmap nginx-html --from-file=./index.html
##查看nginx-config资源
kubectl get configmap nginx-config -o yaml

部署服务的yaml文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginxsvcdp
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  minReadySeconds: 1 #指定最小的成功运行时间
  strategy:     #设置滚动升级的策略
      rollingUpdate:
          maxSurge: 1   #设置允许超过副本运行的pod数，默认是25%，即若dp中的副本数为4，那么dp中最多允许5个pod同时运行
          maxUnavailable: 0   #设置允许副本最多不可用的pod数，默认为25%，即若dp中的副本数为4，那么dp中最多有1个pod处于不可用的状态
      type: RollingUpdate    #设置滚动升级策略的类型
  template:   #指定创建pod的模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        readinessProbe:  #设置就绪探针的时间,可以避免服务发布但是不能正常提供应用的情况
            exec:    ##指定使用exec类型的就绪探针
                command:
                -  curl
                -  http://localhost:80
        volumeMounts:
        -  mountPath: /etc/nginx/conf.d
           name: config
        -  mountPath: /usr/share/nginx/html
           name: data
      volumes:
        -  name: data
           configMap:
              name: nginx-html
              items:
              -  key: index.html
                 path: ./index.html
        -  name: config
           configMap:
              name: nginx-config
              items:
              -  key: default.conf
                 path: ./default.conf
 
---   #资源类型分隔符，用于在一个文件中定义多种类型的资源
apiVersion: v1
kind: Service
metadata:
    name: nginxdpsvc
spec:
    type: NodePort
    selector:
        app: nginx
    ports:
    -  port: 80
       targetPort: 80

deployment中的其余操作

#查看deployment的部署状态
kubectl rollout status deployment dpname
#修改dp的某个属性,若修改dp的自由属性，可以通过kubectl patch命令,minreadysecond属性表示至少在pod成功运行多久之后才将其视为可用
kubectl patch dp dpname -p '{"spec": {"minReadySeconds": 10}}'
#修改dp中pod的模板，使用ubectl set或者是kubectl edit
kubectl set image dp dpname imagename=newimage
#版本回滚，回到上一个应用版本
kubectl rollout undo dp dpname
#显示所有的应用版本
kubectl rollout history dp dpname
#回滚到指定的历史版本，其中revision是对应历史版本中的版本号，能回到指定的历史版本是因为deploymnet创建的每个rs都会被保留，且一个版本就对应一个rs，若手动删除了某个rs，则会丢失该版本的信息，导致不嫩回滚到该版本，但是rs过多会比较混乱，所以deployment中设置了revisionHistoryLimit值限制rs的个数，在apps/v1beta2中的默认值为10，所以只能保留近10次的rs，之前的都会被删除
kubectl rollout undo dp dpname --to-revision=revision
#暂定滚动升级
kubectl rollout pause dp dpname
#回复滚动升级
kubectl rollout resume dp dpname

使用deployment时需要注意“
1.若deployment中的po的模板引用了一个configMap或者是secret资源，那么更改configmap或者是secret资源不会出发升级操作，若想要修改应用程序的配置并触发更新的话，则应该创建一个新的configmap或者是secret，并且修改pod模板引用新的configmap或者secret来出发滚动升级
2.可以通过设置maxSurge和maxUnavailable字段去修改一次替换pod的个数。maxSurge是允许dp中运行pod超出replicas值的数量，默认是25%，即若dp中的副本数为4，那么dp中最多允许5个pod同时运行；maxUnavailable决定在滚动升级中，最多有多少个pod处于不能使用的状态，默认为25%，即若dp中的副本数为4，那么dp中最多有1个pod处于不可用的状态
3.可以通过设置processDeadlineSeconds的值来定义滚动升级失败的时间，默认为10分钟