1.什么是Controller

Controller是在集群上管理和运行容器的对象，Controller是实际存在的，Pod是虚拟的

2.Pod和Controller的关系

Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等

Pod 和 Controller之间是通过label和selector标签来建立关系，同时Controller又被称为控制器工作负载

3.Deployment控制器应用

Deployment控制器可以部署无状态应用
管理Pod和ReplicaSet
部署，滚动升级等功能
应用场景：web服务，微服务

4.Deployment部署应用

之前我们也使用Deployment部署过应用，如下代码所示

kubectrl create deployment web --image=nginx

然后输出一个yaml配置文件，配置文件如下所示

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁

使用YAML创建Pod

通过刚刚的代码，我们已经生成了YAML文件，下面我们就可以使用该配置文件快速创建Pod镜像了

kubectl apply -f nginx.yaml

但是因为这个方式创建的，我们只能在集群内部进行访问，所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

关于上述命令，有几个参数

–port：就是我们内部的端口号
–target-port：就是暴露外面访问的端口号
–name：名称
–type：类型

同理，我们一样可以导出对应的配置文件

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2021-10-31T06:59:34Z"
  labels:
    app: web
  name: web1
  namespace: default
  resourceVersion: "143753"
  uid: 5a8dc634-8e1d-4a16-b747-2d19613c2f07
spec:
  clusterIP: 10.1.90.49
  clusterIPs:
  - 10.1.90.49
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - nodePort: 30284
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

然后我们可以通过下面的命令来查看对外暴露的服务

kubectl get pods,svc

5.升级回滚和弹性伸缩

5.1升级回滚

首先我们先创建一个 1.14版本的Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.14
        name: nginx
        resources: {}
status: {}

我们先指定版本为1.14，然后开始创建我们的Pod

kubectl apply -f nginx.yaml

同时，我们使用docker images命令，就能看到我们成功拉取到了一个 1.14版本的镜像

我们使用下面的命令，可以将nginx从 1.14 升级到 1.15

kubectl set image deployment web nginx=nginx:1.15

在我们执行完命令后，能看到升级的过程

首先是开始的nginx 1.14版本的Pod在运行，然后 1.15版本的在创建
然后在1.15版本创建完成后，就会暂停1.14版本
最后把1.14版本的Pod移除，完成我们的升级

我们在下载 1.15版本，容器就处于ContainerCreating状态，然后下载完成后，就用 1.15版本去替换1.14版本了，这么做的好处就是：升级可以保证服务不中断

我们到我们的node2节点上，查看我们的 docker images;

能够看到，我们已经成功拉取到了 1.15版本的nginx了

查看升级状态
下面可以，查看升级状态

kubectl rollout status deployment web

查看历史版本
我们还可以查看历史版本

kubectl rollout history deployment web

应用回滚
我们可以使用下面命令，完成回滚操作，也就是回滚到上一个版本

kubectl rollout undo deployment web

然后我们就可以查看状态

kubectl rollout status deployment web

同时我们还可以回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

5.2弹性伸缩

弹性伸缩，也就是我们通过命令一下创建多个副本

kubectl scale deployment web --replicas=10

6.有状态应用和无状态应用

Statefulset主要是用来部署有状态应用

对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

无状态应用

我们原来使用 deployment，部署的都是无状态的应用，那什么是无状态应用？

认为Pod都是一样的
没有顺序要求
不考虑应用在哪个node上运行
能够进行随意伸缩和扩展

有状态应用

上述的因素都需要考虑到

让每个Pod独立的
让每个Pod独立的，保持Pod启动顺序和唯一性
唯一的网络标识符，持久存储
有序，比如mysql中的主从

适合StatefulSet的业务包括数据库服务MySQL 和 PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务

StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。

使用StatefulSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。

部署有状态应用

无头service， ClusterIp：none

这里就需要使用 StatefulSet部署有状态应用

然后通过查看pod，能否发现每个pod都有唯一的名称

然后我们在查看service，发现是无头的service

这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作

deployment：是有身份的，有唯一标识
statefulset：根据主机名 + 按照一定规则生成域名

每个pod有唯一的主机名，并且有唯一的域名

格式：主机名称.service名称.名称空间.svc.cluster.local
举例：nginx-statefulset-0.default.svc.cluster.local

7.DataSet

DaemonSet 即后台支撑型服务，主要是用来部署守护进程

长期伺服型和批处理型的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类的Pod运行；而后台支撑型服务的核心关注点在K8S集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点，也可能是通过 nodeSelector选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑K8S集群运行的服务。

守护进程在我们每个节点上，运行的是同一个pod，新加入的节点也同样运行在同一个pod里面

例子：在每个node节点安装数据采集工具

这里是不是一个FileBeat镜像，主要是为了做日志采集工作

进入某个 Pod里面，进入

kubectl exec -it ds-test-cbk6v bash
通过该命令后，我们就能看到我们内部收集的日志信息了

8.Job和CronJob

一次性任务和定时任务

一次性任务：一次性执行完就结束
定时任务：周期性执行
Job是K8S中用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的
spec.completions
策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功行任务保证有N个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。

Job

Job也即一次性任务

使用下面命令，能够看到目前已经存在的Job

kubectl get jobs

我们可以通过查看日志，查看到一次性任务的结果

kubectl logs pi-qpqff

CronJob

定时任务，cronjob.yaml如下所示

这里面的命令就是每个一段时间，这里是通过 cron 表达式配置的，通过 schedule字段

然后下面命令就是每个一段时间输出

我们首先用上述的配置文件，创建一个定时任务

kubectl apply -f cronjob.yaml

创建完成后，我们就可以通过下面命令查看定时任务

kubectl get cronjobs

我们可以通过日志进行查看

kubectl logs hello-1599100140-wkn79

然后每次执行，就会多出一个 pod

9.删除svc 和 statefulset

使用下面命令，可以删除我们添加的svc 和 statefulset

kubectl delete svc web

kubectl delete statefulset --all

10.Replication Controller

Replication Controller 简称 RC，是K8S中的复制控制器。RC是K8S集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。

即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有一个Pod在运行。RC是K8S中较早期的技术概念，只适用于长期伺服型的业务类型，比如控制Pod提供高可用的Web服务。

Replica Set
Replica Set 检查 RS，也就是副本集。RS是新一代的RC，提供同样高可用能力，区别主要在于RS后来居上，能够支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数来使用

K8S Controller技术详解