K8s学习四（资源调度

资源调度

发现对Pod操作不方便，不能直接操作，而且不能直接编辑，需要对原来的配置文件进行操作，而且需要删除之后再创建Pod，不方便，更多是通过控制器来操作。

Label和Selector

通过设置标签和选择器来确定需要的资源，如果是kubectl get po，就是Pod，这里的po可以替换成其他资源，如deploy。

Label

label，标签可以在配置文件或者命令行kubectl中设置
命令行中，有下面的命令：

# 创建临时label
kubectl label po <资源名称> app=hello

# 修改已经存在的标签
kubectl label po <资源名称> app=hello2 --overwrite

# 查看label

# selector 按照 label 单值查找节点
kubectl get po -A -l app=hello

# selector 按照 label 多值查找节点，也可以不等查找
kubectl get po -A -l test=1.0.0,type=app
kubectl get po -A -l test=1.0.0,app!=hello

# selector 按照 label 选择多值查找节点，引号必须有，避免歧义
kubectl get po -A -l 'test in (1.0.0,1.0.1),type=app'


# 查看所有节点的 labels
kubectl get po --show-labels

# selector 按照 label 综合查找节点
kubectl get po -A -l app=hello --show-labels

# - 是 -- 命令的缩写，例如，-l 是 --label 的缩写，-A 是 --all-namespaces 的缩写。

Selector

进行选择对应的资源
可以在配置文件中配置，在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写
也可以在kubectl命令中：

# 匹配单个值，查找 app=hello 的 pod
kubectl get po -A -l app=hello

# 匹配多个值
kubectl get po -A -l 'k8s-app in (metrics-server, kubernetes-dashboard)'


# 查找 version!=1 and app=nginx 的 pod 信息
kubectl get po -l version!=1,app=nginx

# 不等值 + 语句
kubectl get po -A -l version!=1,'app in (busybox, nginx)'

一些命令演示如下：

Deployment(无状态)

deployment的嵌套关系如下：
这里replicationcontroller已经逐步被替代，因为replicaset可以用selector来选择。

功能

创建

先用命令行创建一个nginx的deployment，运行kubectl create deploy nginx-deploy --image=nginx:1.7.9
然后查看deploy，replicaset和Pod，会发现像上面介绍的是一层一层嵌套关系，如下：-
执行kubectl get po,rs,deploy --show-labels得到：
创建的yaml文件：

apiVersion: apps/v1 # deployment api版本
  kind: Deployment # 资源类型为deployment
  metadata: # 元信息
    labels: # deploy标签
      app: nginx-deploy
    name: nginx-deploy # deploy的名字
    namespace: default # 所在的命名空间
  spec:
    replicas: 1 # 期望的副本数
    revisionHistoryLimit: 10 # 进行滚动更新后，保留的历史版本数
    selector: # 选择器，用于找到匹配的RS
      matchLabels: # 按照标签匹配
        app: nginx-deploy # 匹配的标签
    strategy: # 更新策略
      rollingUpdate: # 滚动更新配置
        maxSurge: 25% # 进行滚动更新时，最多可以启动25%的新实例
        maxUnavailable: 25% # 进行滚动更新时，最多可以同时停止25%的旧实例
      type: RollingUpdate # 更新类型，采用滚动更新
    template: # Pod模板
      metadata: # Pod的元信息
        labels: # Pod标签
          app: nginx-deploy
      spec: # Pod期望信息
        containers: # Pod容器
        - image: nginx:1.7.9 # 镜像
          imagePullPolicy: IfNotPresent # 拉取策略
          name: nginx # 容器名称
        restartPolicy: Always # 重启策略
        terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

deploy和statefulset可能用到matchLabels

滚动更新

只有修改了 deployment 配置文件中的 template 中的属性后，才会触发更新操作
通过 kubectl edit deployment nginx-deploy 进行修改
下面先修改非template，看看是否更新
进入修改之后，在label中新加入标签：
查看是否更新,发现确实没有更新

在这里插入图片描述

然后修改副本数为3，方便后面看滚动更新进行查看
也不是更新，发现deploy，rs都是一个，然后管理着3个Pod
注：这是因为create的模板edit后直接生效了，要是自己定义的yaml文件，记得重新apply
下面将template里面的nginx镜像版本号修改之后保存退出，发现在滚动更新
具体查看信息用kubectl rollout status deploy nginx-deploy
这次用命令行的方式进行设置，执行kkubectl set image deployment/nginx-deploy nginx=nginx:1.7.9
进入deploy查看信息kubectl describe deploy nginx-deploy
可以看出是replicaset是不断变化的，大概意思是创建一个新的replicaset，然后更新一个Pod，更新好后，停止原来rs的旧Pod，然后再更新另一个新Pod，然后再停掉原来rs的旧Pod，直至完成。如下图：
再次看信息会发现，新的Pod已经和新的RS关联，如下图：
注：可能会出现并行的状态，就是修改之后，生成一个新的RS来更新，还没完成的时候，又进行了修改，然后就会停止之前的更新，创建新的RS来进行这次更新

回滚

有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，比如一直crash looping。
默认情况下，kubernetes会在系统中保存前两次的Deploymentrollout历史记录，以便你可以随时会退（你可以修改revision history limit来更改保存的revision数）。
假如更新 deployment 时参数不小心写错，如 nginx:1.9.1 写成了 nginx:1.91
kubectl set image deployment/nginx-deploy nginx=nginx:1.91
监控滚动升级状态，由于镜像名称错误，下载镜像失败，因此更新过程会卡住
kubectl rollout status deployments nginx-deploy
结束监听后，获取 rs 信息，我们可以看到新增的 rs 副本数是 2 个
kubectl get rs
通过 kubectl get pods 获取 pods 信息，我们可以看到关联到新的 rs 的 pod，状态处于 ImagePullBackOff 状态
为了修复这个问题，我们需要找到需要回退的 revision 进行回退通过 kubectl rollout history deployment/nginx-deploy 可以获取 revison 的列表
通过 kubectl rollout history deployment/nginx-deploy --revision=2 可以查看详细信息
确认要回退的版本后，可以通过 kubectl rollout undo deployment/nginx-deploy可以回退到上一个版本
也可以回退到指定的 revision
kubectl rollout undo deployment/nginx-deploy --to-revision=2
再次通过 kubectl get deployment和 kubectl describe deployment可以看到，我们的版本已经回退到对应的 revison 上了
注：可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了。
命令结果如下：

在这里插入图片描述

下面这个是旧rs里面之前创建Pod和删除Pod

扩容缩容

扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs
通过 kube scale 命令可以进行自动扩容/缩容，以及通过 kube edit 编辑 replicas 也可以实现扩容/缩容

# 通过 kube edit 编辑，就是通过kubectl edit deploy nginx-deploy命令进去之后修改replicas


#通过 kube scale 命令可以进行自动扩容/缩容
kubectl scale --replicas=6 deploy nginx-deploy

在这里插入图片描述

缩容同理，只不过把数字变小就行

暂停与恢复

由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout
通过kubectl rollout pause deployment <name>就可以实现暂停，直到你下次恢复后才会继续进行滚动更新
尝试对容器进行修改，然后查看是否发生更新操作了

kubectl set image deploy <name> nginx=nginx:1.17.9
kubectl get po

通过以上操作可以看到实际并没有发生修改，此时我们再次进行修改一些属性，如限制 nginx 容器的最大cpu为 0.2 核，最大内存为 128M，最小内存为 64M，最小 cpu 为 0.1 核

kubectl set resources deploy <deploy_name> -c <container_name> --limits=cpu=200m,memory=128Mi --requests=cpu100m,memory=64Mi

通过格式化输出kubectl get deploy <name> -o yaml，可以看到配置确实发生了修改，再通过 kubectl get po 可以看到 pod 没有被更新
那么此时我们再恢复 rollout，通过命令 kubectl rollout resume deploy <name>
恢复后，我们再次查看 rs 和 po 信息，我们可以看到就开始进行滚动更新操作了