kubernetes的deployment运用部署

一、deployment

         Deployment是新一代用于Pod管理的对象，与Replication Controller相比，它提供了更加完善的功能，使用起来更加简单方便。

      kubernetes开发了deployment，replicaset、daemonset、statefuleset、job等多种controller。

例子：

kubectl run nginx-deployment --image=nginx --replicas=2

  1.查看状态：

kubectl describe deployments.apps nginx-deployment

     告诉我们创建一个replica set nginx-deployment-6c94df7599 to 2，events是deployment是日志，记录了replicaset的启动过程。

  2.查看详细信息：

kubectl describe replicasets.apps nginx-deployment-6c94df7599

 3.查看更详细信息

kubectl describe pod nginx-deployment-6c94df7599-vv5xx

events记录了pod的启动过程，如果操作失败，也能在这里查看到原因

     过程：

          1.用户通过kubectl创建deployment。

          2.deployment创建replicaset

          3.replicaset创建pod

二、k8s创建资源的两种方式

            1.直接用命令创建，

            2.通过配置文件和kubectl apply创建，要完成前面同样的工作，可以执行命令：

        1.命令

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

 2.配置文件

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

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx
        name: nginx

kubectl apply -f web.yml

    资源的属性写在配置文件中，文件格式为YAML

三、两种方式的比较

       1、基于命令的方式：

           1.简单直观快捷，上手快。

           2.适合临时测试和实验

       2、基于配置文件方式：

            1.配置文件描述了what，即应用最终要达到的状态。

            2.配置文件提供了创建资源的模板，能够重复部署。

            3.可以像管理代码一样管理部署。

           4.适合正式的、跨环境的、规模化部署。

          5.这种方式要求熟悉配置文件的语法、有一定难度。

 四、deployment YAML

       1.配置格式

apiVersion: apps/v1                      当前配置格式的版本
kind: Deployment                         创建资源的类型，这里是deployment
metadata:                                该资源的源数据 name是必须的源数据项
  labels:                                
    app: nginx-deployment
  name: nginx-deployment                 Deployment名称
spec:                                    是该deployment的规格说明
  replicas: 2                            指明副本数量，默认为1
  selector:
    matchLabels:
      app: nginx-deployment
  template:                              定义pod模板
    metadata:               定义pod的元数据，至少要定义一个label，label的key和value可以任意制定
      creationTimestamp: null
      labels:                            定义pod标签
        app: nginx-deployment
    spec:                 描述pod的规格，此部分定义pod中每一个ring器的属性，name和image是必需品
      containers:
      - image: nginx                     指定容器的名称
        name: nginx                      指定基于哪个镜像运行容器
 

五、删除资源

kubectl  delete  deployments.apps  nginx-deployment
kubectl  delete  -f web.yml 

     

六、scale up/down

            伸缩是指在线增加或减少pod的副本数。

        修改web.yml文件

          

再次执行
kubectl apply -f web.yml

  出于安全考虑，默认配置下kubernetes不会pod调度到master节点，如果希望k8s-master也当做node节点使用

   执行命令：

kubectl taint node k8s-master  node-role.kubernetes.io/master-

   恢复master不充作节点，执行如下命令：

kubectl taint node k8s-master  node-role.kubernetes.io/master="":NoSchedule

七、k8s如何failover

       当k8s出现故障时候，等待一段时间，kubernetes会检查到k8s-node1不可用，，将k8s-node1上的pod标记为unknown状态，并在k8s-node1上新创建两个pod，维持总副本数为3个

     当k8s-node1恢复后，unknown的pod会被删除，不过已经运行的pod不会重新调度回k8s-node1

 

八、用label控制pod位置

        默认配置下，scheduler会将pod调度到所有可用的node。不过有些情况我们希望将pod部署到指定的node节点上， 比如将有大量的磁盘i/o的pod部署到配置了ssd的node上，或者pod需要GPU，需要运行在配置了GPU的节点上。

  1.设置节点的label

kubectl label nodes k8s-node1 disktype=ssd
kubectl get nodes --show-labels

disktype=ssd 已经成功添加到k8s-node1，除了disktype，node还有几个kubernetes自己维护的label

 2.修改配置文件

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx
        name: nginx
      nodeSelector:
        disktype: ssd

kubectl apply -f web.yml

三个副本都运行在了k8s-node1上

3.删除labeldisktype

kubectl  label nodes k8s-node1 disktype-

 不过此时的pod不会重新部署，依然在k8s-node1上运行

 除非在web.yml中删除node selector设置，然后通过kubectl apply重新部署

kubernetes会删除之前的pod并调度和运行新的pod。