kubernetes（5）Controller的一些核心概念

概述

controller主要做的事情：是在集群上管理和运行容器的对象

controller是实际存在的，而pod只是一个抽象的概念

Pod和Controller关系

pod是通过controller去实现应用的运维

如：伸缩、滚动升级等

Pod和Controller之间通过label标签建立关系，其关系的建立如下图所示

控制器（Controller）又可以称为工作负载。
pod在配置文件中定义一个标签，在controller里面定义相同的key和value，如此便使其和controller之间建立了关系

deployment应用场景

deployment是一种最常用的控制器

应用场景如下：

1. 部署无状态应用
2. 管理Pod和ReplicaSet
3. 部署、滚动升级等功能

所以，其常见的场景是：web服务、微服务

deployment部署应用

部署应用的步骤如下：

1. 首先通过下面的命令生成一个yaml文件 ，并将该文件放到web.yaml中

kubectl create deployment web --image=nginx --dry-run -o yaml > web.yaml
1

2. 查看配置文件，下面框柱的地方，便是将pod和controller通过label标签进行关联

   

3. 使用yaml文件部署应用
   

4. 暴露端口：提供对外服务的端口（因为目前只能集群内容进行网络通信）
   
   现在部署这个生成的配置文件便可以比之前部署的多了一个对外暴露端的端口的配置
   

5. 执行该配置文件
   现在便可以通过下面框住的端口号，通过任何一个node节点+端口号都能访问到nginx
   

升级回滚和弹性伸缩

升级：比如之前部署nginx，我们并没有指定版本，获取到的便是最新版本，但是当我们指定nginx的版本是1.14，后面我们需要将其升级到1,15，这样一个过程便称为应用升级

回滚：当我们想把当前的版本1.15，回滚到1.14，这个过程便成为应用回滚

弹性伸缩：比如我创建多个web副本，其满足不同的应用，这个便称为弹性伸缩

升级回滚

操作如下：

1. 在创建的yaml文件中指定nginx的版本
   
   通过下面的地方去指定版本为1.14
   

2. 部署上面的配置
   
   过一会儿，当镜像拉取完后，便可以在node节点的docker中去查看版本信息
   

3. 升级：将nginx升级到1.15，这个操作按如下的命令去执行

   
   查看docker里面的版本，其版本更新为1.15了
   
   在这一张的上一张图中，查看pod，会发现有三个。原理：

   • 其在进行升级时，会对所有pod节点进行一个一个的升级，
   • 升级时，首先会去下载1.15的镜像（下面的第三个pod），在下载的过程中node节点会继续提供服务，当下载完后，其会去进行替换
   • 如何之前下载完的会去生成一个副本，继续替换另外一个node
     
     可以发现在最终运行的还是两个
     

4. 查看升级状态：可以发现是成功的
   

5. 回滚

   • 查看历史版本：可以发现有两个版本1（1.14）、2（1.15）
     
   • 回滚到上一个版本
     
     查看状态
   • 回滚到指定版本：版本2
     

弹性伸缩

操作如下：

1. 查看当前的pod数
   
2. 创建多个服务
   
   查看pod数，会发现有多个
   

有状态和无状态的区别

无状态部署应用的特点：

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

有状态部署应用的特点：

1. 无状态的特点不需要考虑的，有状态都需要进行考虑
2. 让每一个Pod都是独立的，保证Pod启动顺序和唯一性
   • 通过唯一的网络标识符、持久存储 进行区分（有序：如mysql的主从，先启动主，再启动从）

部署有状态应用

无头service：ClusterIP的值为none

如下，如果CLUSTER-IP属性为none，这样其便不是以后面的CLUSTERIP进行约定，而是有一个唯一标识（生成一个特定规则的域名，通过域名做相关的操作，这就称为无头Service），如下面的CLUSTER-IP

StatefulSet部署有状态应用

如下准备一个yal文件：内容如下

• 建立无状态Service
  

• SatefulSet部署有状态应用：其有三个nginx副本
  

  apiVersion: v1
  kind: Service
  metadata:
    name: nginx
    labels:
      app: nginx
  spec:
    ports:
    - port: 80
      name: web
    clusterIP: None
    selector:
      app: nginx
  
  ---
  
  apiVersion: apps/v1beta1
  kind: StatefulSet
  metadata:
    name: nginx-statefulset
    namespace: default
  spec:
    serviceName: nginx
    replicas: 3
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx:latest
          ports:
          - containerPort: 80
  
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38

剩下的步骤如下：

1. 执行该yaml文件：上面的yaml文件名为sts.yaml
   
2. 查看Pod：可以发现三个Pod，其名称都是唯一的
   
3. 查看Service：可以发现CLUSTER-IP为none，是一个无头Service
   

deployment和statefulset区别

二者最大的区别是：statefulset是有身份的（唯一标识）

• 这个标识是通过：主机名 + 按照一定规则 生成域名
• 每一个Pod都会有一个唯一的域名，域名的生成规则如下
  • 格式：主机名称.service名称.名称空间.svc.cluster.local
  • 比如之前statefulset部署的有状态应用中的nginx的域名便为：nginx.statefukset-0.nginx.default.svc.cluster.local

DaemonSet部署守护进程

将所有node运行在同一个pod，新加入的node也同样运行在一个pod里面，在controller有部署守护进程，实现这个操作

使用DaemonSet部署守护进程的步骤：下面以在每个node节点安装数据采集工具为例

1. 准备一个yaml文件，生成node:

   • 如下：使用数据卷，使用filebeat采集日志

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: ds-test 
     labels:
       app: filebeat
   spec:
     selector:
       matchLabels:
         app: filebeat
     template:
       metadata:
         labels:
           app: filebeat
       spec:
         containers:
         - name: logs
           image: nginx
           ports:
           - containerPort: 80
           volumeMounts:
           - name: varlog
             mountPath: /tmp/log
         volumes:
         - name: varlog
           hostPath:
             path: /var/log
   
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28

2. 执行上面的ds.yaml文件

   查看执行前的node节点内容
   
   开始执行该yaml文件
   

3. 查看Pod
   

4. 进入某个pod，查看采集的内容
   进入pod
   
   查看文件内容
   

Job和Cronjob（一次性任务和定时任务）

Job（一次性任务）

首先，编写了一个yaml文件（文件名为job.yaml），如下所示：该文件定义了一个job，并规定了重启策略（backoffLimit），如果失败，则重启四次

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

1
2
3
4
5
6
7
8
9
10
11
12
13
14

在服务器上编写并执行文件job.yaml

查看pod

查看jobs：便可以发现这个一次性任务

再等待一会儿，当docker将镜像下载完后，如下

然后回到master节点查看

1. 查看jobs
   
2. 查看pods：下面的只是运行一次，所以当前pod已经是completed了，结束了
   
3. 查看日志：便会发现执行结果如下
   
4. 执行完后，我们可以将之前的yaml文件删除，如下，如此便将任务删除掉了
   

CronJob（定时任务）

首先，创建一个yaml文件，如下，在里面配置了一个定时任务（每隔一分钟输出hello…信息），里面设置cron表达式

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

在服务器上编写并执行上述的文件（cronjob.yaml）

查看相关内容

1. 查看pod
   
2. 等待镜像下载完成后，查看jobs
   
3. 查看日志：
   
4. 等待一会儿后，再次查看pod，便会发现又执行了一次（其是定时任务）
   

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1