K8s学习四（资源调度_1）

资源调度

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

Label和Selector

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

Label

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

bash 复制代码

# 创建临时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命令中：

bash 复制代码

# 匹配单个值，查找 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文件：

bash 复制代码

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 也可以实现扩容/缩容

bash 复制代码

# 通过 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>就可以实现暂停，直到你下次恢复后才会继续进行滚动更新
尝试对容器进行修改，然后查看是否发生更新操作了

bash 复制代码

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

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

bash 复制代码

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 信息，我们可以看到就开始进行滚动更新操作了

kubectl get rs
kubectl get po
修改内容

pause之后，修改不会更新
resume之后，更新。