一、优化命令行

yum install -y bash-completion
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

二、kubernetes带来的变革

k8s与docker的关系：
k8s是一个容器化管理平台，docker是容器

1.对于开发人员

由于公司业务多，开发环境、测试环境、预生产环境和生产环境都是隔离的，而且除了生产环境，为了节省成本，其他环境可能是没有日志收集的，在没有用 k8s 的时候，查看线下测试的日志，需要开发或者测试人员，找到对应的机器，在找到对应的容器，然后才能查看日志，在用了 k8s 之后，开发和测试可以直接在 k8s 的dashboard 到对应的 namespace，即可定位到业务的容器，然后可以直接通过控制台查看到对应的日志，大大降低了操作时间。
目前我们使用 jenkins、gitrunner 进行发版或者回滚等，从开发环境到测试环境，到生产环境，完全遵守一次构建，多集群、多环境部署，通过不同的启动参数、不同的环境变量、不同的配置文件实现区分不同的环境。目前已经实现 Python、Java、PHP、NodeJS、Go、.NET Core、Python等多种语言的一键式发版、一键式回滚，大大提高了开发人员的开发效率。

2.对于运维人员

如果你是一名运维人员，可能经常因为一些重复、繁琐的工作感觉厌倦。比如：这个需要一套新的测试环境，那个需要一套新的测试环境，之前可能需要装系统、装依赖环境、开通权限等等。而如今，可以直接用镜像直接部署一套新的测试环境，甚至全程无需自己干预，开发人员通过 jenkins 或者自动化运维平台即可一键式创建，大大降低了运维成本。
一开始，公司业务故障，可能是因为基础环境不一致、依赖不一致、端口冲突等等问题，现在实现 Docker镜像部署，k8s 编排，所有的依赖、基础都是一样的，并且环境的自动化扩容、健康检查、容灾、恢复都是全自动的，大大减少了因为这类基础问题引发的故障。也有可能公司业务是由于服务器宕机、网络等问题，造成服务不可用，此类情况均需要运维人员及时去修复，而如今，可能在你收到告警信息的时候，k8s 已经帮你恢复了。
在没有使用 k8s 时，业务应用的扩容和缩容，都需要人工去处理，从采购服务器、上架、到部署依赖环境，不仅需要大量的人力物力，而且非常容易在中间过程出现问题，又要花费大量的时间去查找问题。成功上架后，还需要在前端反代端添加或该服务器，而如今，可以利用 k8s 的弹性计算，一键式进行扩容和缩容，不仅大大提高了运维效率，而且还节省了不少的服务器资源，提高了资源利用率。

对于反代配置方面，比如可能你并不会，或者对 nginx 的配置规则并不熟悉，一些高级的功能你也不会实现，而如今，利用 k8s 的 ingress 即可简单的实现那些复杂的逻辑。并且也不会在遇到 nginx 少加一个斜杠和多加一个斜杠的问题。
对于负载均衡方面，之前负载均衡可能是 Nginx、LVS、HAProxy、F5 等，云上可能是云服务商提供的不在均衡机制。每次添加删除节点时，都需要手动去配置前端负载均衡，手动去匹配后端节点，而如今，使用 k8s内部的 service 可以动态发现实现自动管理节点，并且支持自动扩容缩容。之前遇到高峰流量时，经常服务器性能不够，需要临时加服务器面对高峰流量，而如今对于高性能 k8s 集群加上 serverless，基本实现无需管理，自动扩容。
对于高可用方面，k8s 天生的高可用功能，彻底释放了双手，无需再去创建各类高可用工具、检测检查脚本。k8s 支持进程接口级别的健康检查，如发现接口超时或者返回值不正确，会自动处理该问题。
对于中间件搭建方面，根据定义好的资源文件，可以实现秒级搭建各类中间件高可用集群，并且支持一键式扩缩容，如 Redis、RabbitMQ、Zookeeper 等，并且大大减少了出错的概率。
对于应用端口方面，传统行业中，一个服务器可能跑了很多进程，每个进程都有一个端口，需要人为的去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙，在 k8s 中，端口统一管理统一配置，每个应用的端口都可设置成一样的，之后通过 service 进行负载均衡，大大降低了端口管理的复杂度和端口冲突。

3.Pod

Pod是在集群中运行部署应用或服务的最小单元，他是可以支持很多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

比如：你运行一个操作系统发行版的软件仓库，一个nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块工作才能提供一个微服务，这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。这就是k8s中的Pod。

目前k8s中业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet 和 StatefulSet。

1>Pod生命周期

在这里插入图片描述

2>Pod是如何管理多个容器的

Pod中可以同时运行多个进程（作为容器运行）协同工作。。同一个 Pod 中的容器会自动的分配到同一个 node上。同一个 Pod 中的容器共享资源、网络环境和依赖，所以它们总是被同时调度。在一个 Pod 中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。

3>Pod中数据持久性

Pod 在设计⽀持就不是作为持久化实体的。在调度失败、节点故障、缺少资源或者节点维护的状态下都会死
掉会被驱逐。通常，我们是需要借助类似于 Docker 存储卷这样的资源来做 Pod 的数据持久

4>Pod的状态

挂起（Pending）：API Server 创建了 pod 资源对象已存入 etcd 中，但它尚未被调度完成，或者仍处于从仓库下载镜像的过程中。
运行中（Running）：Pod 已经被调度至某节点，并且所有容器都已经被 kubelet 创建完成
成功（Succeeded）：Pod 中的所有容器都已经成功终止并且不会被重启。
失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。即容器以非 0 状态退出或者被系统禁止。
未知（Unknown）：Api Server 无法正常获取到 Pod 对象的状态信息，通常是由于无法与所在工作节点的kubelet 通信所致。
ImgPullErr : 镜像拉取失败
ContainerCreating ：容器创建中

5>Pod的资源清单详解

apiVersion：v1  #必选，API的版本号
kind:Pod   #必选，类型Pod
metadata: # 必选，元数据
  name: nginx # 必选，符合 RFC 1035 规范的 Pod 名称
  namespace: web-testing # 可选，不指定默认为 default，Pod 所在的命名空间
  labels: # 可选，标签选择器，一般用于 Selector
    - app: nginx
  annotations: # 可选，注释列表
    - app: nginx
spec: # 必选，用于定义容器的详细信息
  containers: # 必选，容器列表
  - name: nginx # 必选，符合 RFC 1035 规范的容器名称
    image: nginx:v1 # 必选，容器所用的镜像的地址
    imagePullPolicy: Always # 可选，镜像拉取策略
    workingDir: /usr/share/nginx/html # 可选，容器的工作目录
    volumeMounts: # 可选，存储卷配置
    - name: webroot # 存储卷名称
      mountPath: /usr/share/nginx/html # 挂载目录
      readOnly: true # 只读
    ports: # 可选，容器需要暴露的端口号列表
    - name: http # 端口名称
      containerPort: 80 # 端口号
      protocol: TCP # 端口协议，默认 TCP
    env: # 可选，环境变量配置
    - name: TZ # 变量名
      value: Asia/Shanghai
    - name: LANG
      value: en_US.utf8
    resources: # 可选，资源限制和资源请求限制
      limits: # 最大限制设置
        cpu: 1000m
        memory: 1024MiB
      requests: # 启动所需的资源
        cpu: 100m
        memory: 512MiB
     readinessProbe: # 可选，容器状态检查
       httpGet: # 检测方式
         path: / # 检查路径
         port: 80 # 监控端口
       timeoutSeconds: 2 # 超时时间
       initialDelaySeconds: 60 # 初始化时间
     livenessProbe: # 可选，监控状态检查
       exec: # 检测方式
         command:
         - cat
         - /health
       httpGet: # 检测方式
         path: /_health
         port: 8080
         httpHeaders:
         - name: end-user
           value: jason
        tcpSocket: # 检测方式
          port: 80
        initialDelaySeconds: 60 # 初始化时间
        timeoutSeconds: 2 # 超时时间
        periodSeconds: 5 # 检测间隔
        successThreshold: 2 # 检查成功为 2 次表示就绪
        failureThreshold: 1 # 检测失败 1 次表示未就绪
      securityContext: # 可选，限制容器不可信的行为
        provoleged: false
     restartPolicy: Always # 可选，默认为 Always
     nodeSelector: # 可选，指定 Node 节点
       region: subnet7
     imagePullSecrets: # 可选，拉取镜像使用的 secret
     - name: default-dockercfg-86258
     hostNetwork: false # 可选，是否为主机模式，如是，会占用主机端口
     volumes: # 共享存储卷列表
     - name: webroot # 名称，与上述对应
       emptyDir: {
    
    } # 共享卷类型，空
       hostPath: # 共享卷类型，本机目录
         path: /etc/hosts
       secret: # 共享卷类型，secret 模式，一般用于密码
         secretName: default-token-tf2jp # 名称
         defaultMode: 420 # 权限
         configMap: # 一般用于配置文件
         name: nginx-conf
         defaultMode: 420

#实例1：部署nginx、tomcat容器
# kubectl explain Pod  #查apiVersion版本号 v1
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: nginx
      image: nginx
    - name: tomcat
      image: tomcat


# k8s部署一个yaml的应用：kubectl apply -f [配置清单]

ImgPullErr : 镜像拉取失败
ContainerCreating ： 容器创建中

6>Pod的重启策略

Pod 重启策略（ RestartPolicy ）应用于 Pod 内的所有容器，井且仅在 Pod 所处的 Node 上由 kubelet
进行判断和重启操作。当某个容器异常退出或者健康检查失败时， kubelet 将根据 RestartPolicy 设置来进行相应的操作。Pod 的重启策略包括：Always、OnFailure 和 Never，默认值为 Always

Always：当容器失效时，由 kubelet 自动重启该容器。
OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器
Never：不论容器运行状态如何，kubelet 都不会重启该容器。
kubelet 重启失效容器的时间间隔以 sync-frequency 乘以 2n 来计算；例如 1、2、4、8 倍等，最长延时5min ，并且在成功重启后的 10 min 后重置该时间。
Pod 的重启策略与控制方式息息相关，当前可用于管理 Pod 的控制器包括 ReplicationController、Job、DaemonSet 及直接通过 kubelet 管理（静态 Pod）。每种控制器对 Pod 的重启策略要求如下：
1．RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行。
2．Job 和 CronJob：OnFailure 或 Never，确保容器执行完成后不再重启。
3．kubelet：在 Pod 失效时自动重启它，不论将 RestartPolicy 设置为什么值，也不会对 Pod 进行健康检查。

三、名词介绍

1.k8s中的名称空间

#k8s中名称空间是用来隔离集群资源，而k8s中的资源也分为名称空间级资源以及集群级资源。
# kubectl是k8s客户端，它跟k8s没有任何关系。

## kubectl get [资源名称] 获取集群资源的命令

# 获取名称空间
[root@k8s-m-01 ~]# kubectl get namespace
NAME              STATUS   AGE
default           Active   5d16h
kube-node-lease   Active   5d16h
kube-public       Active   5d16h
kube-system       Active   5d16h
[root@k8s-m-01 ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   5d16h
kube-node-lease   Active   5d16h
kube-public       Active   5d16h
kube-system       Active   5d16h

# 注：部署应用一般是部署在自己的名称空间之内

[root@k8s-m-01 ~]# kubectl create namespace wordpress  #创建命名空间
namespace/wordpress created

#k8s中的命名规范
1、必须小写
2、必须以字母开头
3、名称当中只能够包含字母、数字和中划线(-)

2.Label标签

一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以附加到各种资源对象上，例如Node、Pod、Service、RC 等，一个资源对象可以定义任意数量的 Label，同一个 Label 也可以被添加到任意数量的资源对象上去，Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

扫描二维码关注公众号，回复： 13106866 查看本文章

版本标签：“release” : “stable” , “release” : “canary”
环境标签：“environment” : “dev” , “environment” : “production”
架构标签：“tier” : “frontend” , “tier” : “backend” , “tier” : “middleware”
分区标签：“partition” : “customerA” , “partition” : “customerB”
质量管控标签：“track” : “daily” , “track” : “weekly”

# docker中的TAG = 仓库URL/名称空间/仓库名称:版本号

#k8s当做标签是用来管理（识别一系列）容器，方便与管理和监控拥有同一标签的所有容器

apiVersion: v1
kind: Pod
metadata:
  name: test-tag
  labels:
    release: stable
spec:
  containers:
    - name: nginx
      image: nginx
      
      
# 查看label
[root@k8s-master1 ~]# kubectl get pod --show-labels
NAME   READY   STATUS    RESTARTS   AGE     LABELS
test   1/1     Running   1          5d23h   run=test


# 增加标签
kubectl label pod（资源类型） test-tag app=tag

[root@k8s-m-01 ~]# kubectl label pod test-tag app=tag
pod/test-tag labeled
[root@k8s-m-01 ~]# kubectl get pod --show-labels 
NAME                     READY   STATUS             RESTARTS   AGE     LABELS
test-tag                 0/1     ImagePullBackOff   0          2m15s   app=tag,release=stable

# 删除标签
[root@k8s-m-01 ~]# kubectl label pod test-tag app-
pod/test-tag labeled

# 修改标签
## 先删除后增加
kubectl label pod test-tag app=tag release-
kubectl label pod test-tag app=tag release=bate

3.k8s中常用命令

#1.获取资源
kubectl get [资源名称]

[root@k8s-master1 ~]# kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
test   1/1     Running   1          6d

#2.创建资源
kubectl apply [资源类型] [资源名称]
kubectl apply -f [资源清单的路径]

[root@k8s-master1 ~]# vim tag.yaml
[root@k8s-master1 ~]# kubectl apply -f tag.yaml

4.控制器

k8s中控制器分为：deployment、DaemonSet、Statufluset
控制器是用来管理Pod

1）deployment

#1.deployment:在deployment对象中描述所需状态，然后deployment控制器将实际状态以受控的速率更改为所需的状态（自愈）
一般用来部署长期运行的，无状态的应用（对启动顺序没有要求的（php nginx））
总结：主要功能是保证有足够的Pod正常对外提供服务
特点：集群之中，随机部署

#2.创建deployment.yaml
[root@k8s-master1 ~]# vim deployment.yaml
apiVersion: apps/v1  #kubectl explain deployment查看deployment版本号：apps/v1
kind: Deployment  #类型
metadata:  #元数据
  name: deployment  #deployment的名称
spec:  #定义容器的详细信息
  replicas: 1  #创建Pod的副本数
  selector:  #标签选择器：定义Deployment 如何找到要管理的 Pod，与 template 的 label（标签）对应
    matchLabels: #精确匹配
      release: stable  #对应Pod标签
  template:  #创建Pod的模板---------以下是Pod信息
    metadata:  #Pod元数据
      name: test-tag  #Pod名称（可不定义，随机生成）
      labels:  #标签
        release: stable 
    spec:  #定义容器详细信息
      containers:  #容器列表
        - name: nginx
          image: nginx

#3.创建deployment
[root@k8s-master1 ~]# kubectl apply -f deployment.yaml   #创建deployment
deployment.apps/deployment created
[root@k8s-master1 ~]# kubectl get deployment   #查看deployment
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
deployment   1/1     1            1           51s

#4.查看部署详情
[root@k8s-master1 ~]# kubectl describe deployments.apps 
Name:                   deployment
Namespace:              default
CreationTimestamp:      Thu, 01 Apr 2021 12:34:09 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               release=stable
Replicas:               10 desired | 10 updated | 10 total | 10 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  release=stable
  Containers:
   nginx:
    Image:        nginx
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   deployment-5849786498 (10/10 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  24m   deployment-controller  Scaled up replica set deployment-5849786498 to 10

1>弹性扩容的3种方法

#1.修改配置清单
[root@k8s-master1 ~]# kubectl edit deployments deployment
spec:
  progressDeadlineSeconds: 600
  replicas: 10  #修改这个参数
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      release: stable


[root@k8s-master1 ~]# kubectl get pods -w  #监控pod状态（自动创建10个）
NAME                          READY   STATUS    RESTARTS   AGE
deployment-5849786498-whrht   1/1     Running   0          38m
test                          1/1     Running   1          6d1h
test-tag                      1/1     Running   0          59m

deployment-5849786498-stwbz   0/1     Pending   0          0s
deployment-5849786498-stwbz   0/1     Pending   0          0s
deployment-5849786498-6zpws   0/1     Pending   0          0s
deployment-5849786498-r9q4w   0/1     Pending   0          0s
deployment-5849786498-6zpws   0/1     Pending   0          0s
deployment-5849786498-n7qbv   0/1     Pending   0          1s
deployment-5849786498-cb52r   0/1     Pending   0          1s
deployment-5849786498-krspr   0/1     Pending   0          1s
deployment-5849786498-r9q4w   0/1     Pending   0          1s
deployment-5849786498-xc4z2   0/1     Pending   0          1s
deployment-5849786498-cb52r   0/1     Pending   0          1s


#2.命令行打标签
[root@k8s-master1 ~]# kubectl patch deployments.apps deployment -p '{"spec":{"replicas":4}}'   #自动缩容到4台
deployment.apps/deployment patched
[root@k8s-master1 ~]# kubectl patch deployments.apps deployment -p '{"spec":{"replicas":40}}'   #自动扩容到40台
deployment.apps/deployment patched

#3.scale
[root@k8s-master1 ~]# kubectl scale deployment/deployment --replicas=4
deployment.apps/deployment scaled

2>更新(首先要存在低版本才可以更新)

#1.编辑django.yaml（基础版本）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: django
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stable
  template:
    metadata:
      labels:
        app: stable
    spec:
      containers:
        - name: nginx1
          image: nginx:1.17.10

#2.创建Pod
[root@k8s-master1 ~]# kubectl apply -f django.yaml 
deployment.apps/django created

#监控中 （获取podid）
[root@k8s-master1 ~]# kubectl get pods -w
django-5b8b5bd7f7-79qs6       0/2     Pending   0          0s
django-5b8b5bd7f7-79qs6       0/2     Pending   0          0s
django-5b8b5bd7f7-79qs6       0/2     ContainerCreating   0          0s
django-5b8b5bd7f7-79qs6       2/2     Running             0          15s
django-5b8b5bd7f7-79qs6       1/2     Error               0          17s
django-5b8b5bd7f7-79qs6       2/2     Running             1          18s

#进入容器查看版本号
[root@k8s-master1 ~]# kubectl exec -it django-5b8b5bd7f7-79qs6  -- bash
Defaulting container name to nginx2.
Use 'kubectl describe pod/django-5b8b5bd7f7-79qs6 -n default' to see all of the containers in this pod.
root@django-5b8b5bd7f7-79qs6:/# nginx -v
nginx version: nginx/1.17.10


#3.更新镜像
## 打标签
[root@k8s-master1 ~]# kubectl patch deployments.apps django -p '{"spec":{"template":{"spec":{"containers":[{"image":"nginx:1.18.0", "name":"nginx"}]}}}}'
deployment.apps/django patched
##验证
[root@k8s-master1 ~]# kubectl exec -it django-79d65d8758-wlqv8 -- bash
Defaulting container name to nginx.
Use 'kubectl describe pod/django-79d65d8758-wlqv8 -n default' to see all of the containers in this pod.
root@django-79d65d8758-wlqv8:/# nginx -v
nginx version: nginx/1.18.0


##修改配置清单
[root@k8s-master1 ~]# vim django.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: django
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stable
  template:
    metadata:
      labels:
        app: stable
    spec:
      containers:
        - name: nginx
          image: nginx:1.19.9
##验证         
[root@k8s-master1 ~]# kubectl exec -it deployment-5849786498-6zpws -- bash
root@deployment-5849786498-6zpws:/# nginx -v
nginx version: nginx/1.19.9


##设置镜像（重点）
[root@k8s-master1 ~]# kubectl set image deployment/django nginx=nginx:1.16.0
##验证
[root@k8s-master1 ~]# kubectl exec -it django-66fd455d7f-rpflf -- bash
root@django-66fd455d7f-rpflf:/# nginx -v
nginx version: nginx/1.16.0


##edit
[root@k8s-master1 ~]# kubectl edit deployment.apps django
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: stable
    spec:
      containers:
      - image: nginx:1.19.0  #修改版本号
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {
    
    }
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
##验证
[root@k8s-master1 ~]# kubectl exec -it django-57f7d86d66-rdss6 -- bash
root@django-57f7d86d66-rdss6:/# nginx -v
nginx version: nginx/1.19.0

3>回滚

#查看资源历史
[root@k8s-master1 ~]# kubectl rollout history deployment django
deployment.apps/django 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>
5         <none>


#2.回滚到上一级
[root@k8s-master1 ~]# kubectl rollout history deployment django
deployment.apps/django 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
5         <none>
6         <none>
注：目前是到第5级，回滚是回滚到4，回滚后4不显示，显示成6，6与4内容一样

#3.回滚指定版本
[root@k8s-master1 ~]# kubectl rollout undo deployment django --to-revision=1
deployment.apps/django rolled back
[root@k8s-master1 ~]# kubectl rollout history deployment django
deployment.apps/django 
REVISION  CHANGE-CAUSE
2         <none>
3         <none>
5         <none>
6         <none>
7         <none>
注：回滚到1版本，1不展示，变成7

2）DaemonSet

# 在集群中所有的节点上部署只部署一个Pod,删除节点自动删除对应得Pod
#特点：每台上有且只有一个

apiVersion: apps/v1  #kubectl explain DaemonSet 查看版本号
kind: DaemonSet
metadata:
  name: zabbix-agent
spec:
  selector:
    matchLabels:
      app: zabbix-agent
  template:
    metadata:
      labels:
        app: zabbix-agent
    spec:
      containers:
        - name: zabbix-agent
          image: zabbix/zabbix-agent:5.2.6-centos

# 更新
1、修改配置文件
[root@k8s-m-01 ~]# kubectl edit daemonsets.apps zabbix-agent 
daemonset.apps/zabbix-agent edited

2、打标签的方式
[root@k8s-m-01 ~]# kubectl patch daemonsets.apps zabbix-agent  -p '{"spec":{"template":{"spec":{"containers":[{"image":"zabbix/zabbix-agent:centos-5.2.4", "name":"zabbix-agent"}]}}}}'
daemonset.apps/zabbix-agent patched

3、设置镜像
[root@k8s-m-01 ~]# kubectl set image daemonset/zabbix-agent zabbix-agent=zabbix/zabbix-agent:centos-5.2.3
daemonset.apps/zabbix-agent image updated



## 回滚到上一个版本
[root@k8s-m-01 ~]# kubectl rollout undo daemonset zabbix-agent 
daemonset.apps/zabbix-agent rolled back

## 回滚到指定版本
[root@k8s-m-01 ~]# kubectl rollout undo daemonset zabbix-agent --to-revision=1
daemonset.apps/zabbix-agent rolled back

kubernrtes===》Pod介绍、label标签、控制器