(三)k8s实战-资源调度

一、Label 和 Selector

1、标签(Label)

有两种设置方式:配置文件、kubectl命令

1)配置文件
在各类资源的 metadata.labels 中进行配置

2)kubectl

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

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

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

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

2、选择器(Selector)

有两种设置方式:配置文件、kubectl命令

1)配置文件
在各对象的配置 spec.selector 或其他可以写 selector 的属性中编写

2)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:用于管理无状态应用

1、配置文件样例

apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 1 # 期望副本数
  revisionHistoryLimit: 10 # 进行滚动更新后,保留的历史版本数
  selector: # 选择器,用于找到匹配的 RS
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时,更新的个数最多可以超过期望副本数的个数/比例
      maxUnavailable: 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 # 删除操作最多宽限多长时间

2、创建

1.创建一个 deployment
kubectl create deploy nginx-deploy --image=nginx:1.7.9

或执行
kubectl create -f xxx.yaml --record
# --record 会在 annotation 中记录当前命令创建或升级了资源,后续可以查看做过哪些变动操作(回滚版本中可以看到变动描述)。

2.查看部署信息
kubectl get deployments

3.查看 rs
kubectl get rs

4.查看 pod 以及展示标签,可以看到是关联的那个 rs
kubectl get pods --show-labels

3、滚动更新

# 修改deploy的yaml配置(修改后就会滚动更新)
kubectl edit deployment/nginx-deploy
# 查看滚动更新的过程
kubectl rollout status deploy <deployment_name>

案例:

#只有修改了 deployment 配置文件中的 template 中的属性后,才会触发更新操作

1.修改 nginx 版本号
kubectl set image deployment/nginx-deploy nginx=nginx:1.9.1
或者通过 kubectl edit deployment/nginx-deploy 进行修改

2.查看滚动更新的过程
kubectl rollout status deploy <deployment_name>

3.查看部署描述,最后展示发生的事件列表也可以看到滚动更新过程
kubectl describe deploy <deployment_name>

4.通过 kubectl get deployments 获取部署信息,UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目

5.通过 kubectl get rs 可以看到增加了一个新的 rs

6.通过 kubectl get pods 可以看到所有 pod 关联的 rs 变成了新的

假设当前有 5 个 nginx:1.7.9 版本,你想将版本更新为 1.9.1,当更新成功第三个以后,你马上又将期望更新的版本改为 1.9.2,那么此时会立马删除之前的三个,并且立马开启更新 1.9.2 的任务

4、回滚

有时候你可能想回退一个Deployment,例如,当Deployment不稳定时,比如一直crash looping。

默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便你可以随时会退(你可以修改revisionHistoryLimit来更改保存的revision数)。

# 查看 revison 的列表
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

案例:

更新 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 回退了。

5、扩容缩容

# 通过 kube scale 命令可以进行自动扩容/缩容,以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容
kubectl scale --replicas=6 deploy nginx-deploy

#扩容与缩容只是直接创建副本数,没有更新 pod template 因此不会创建新的 rs

6、暂停与恢复

由于每次对 pod template 中的信息发生修改后,都会触发更新 deployment 操作,那么此时如果频繁修改信息,就会产生多次更新,而实际上只需要执行最后一次更新即可,当出现此类情况时我们就可以暂停 deployment 的 rollout

# 暂停滚动更新
kubectl rollout pause deployment <name>
# 恢复滚动更新
kubectl rollout resume deploy <name>

案例:

通过 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> -oyaml,可以看到配置确实发生了修改,再通过 kubectl get po 可以看到 pod 没有被更新

那么此时我们再恢复 rollout,通过命令 kubectl rollout resume deploy <name>

恢复后,我们再次查看 rs 和 po 信息,我们可以看到就开始进行滚动更新操作了
kubectl get rs
kubectl get po

三、StatefulSet

StatefulSet:用于管理有状态应用

1、配置文件

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet # statefuelSet类型的资源
metadata: 
  name: web # StatefulSet的名字
spec:
  serviceName: "nginx" # 使用哪个service来管理dns
  replicas: 2
  selector:
    matchLabels:
      app: nginx # 配置选择器
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: arm64v8/nginx:latest
        ports: # 容器内部需要暴露的端口
        - containerPort: 80 # 暴露的端口
          name: web # 端口配置的名字
#        volumeMounts: # 加载数据卷
#        - name: www # 指定加载哪个数据卷
#          mountPath: /usr/share/nginx/html # 加载到容器的哪个目录
#  volumeClaimTemplates: # 存储卷模板
#  - metadata: # 存储卷的元数据
#      name: www # 存储卷的名称
#      annotations: # 存储卷的注解
#        volume.alpha.kubernetes.io/storage-class: anything
#    spec: # 存储卷的规约
#      accessModes: [ "ReadWriteOnce" ] # 访问模式
#      resources:
#        requests:
#          storage: 1Gi # 需要1G的存储资源

2、创建

kubectl create -f web.yaml

# 查看 service(svc) 和 statefulset(sts)
kubectl get service nginx
kubectl get statefulset web

# 查看 PVC 信息
kubectl get pvc

# 查看创建的 pod,这些 pod 是有序的
kubectl get pods -l app=nginx

# 查看这些 pod 的 dns
# 运行一个 pod,基础镜像为 busybox 工具包,利用里面的 nslookup 可以看到 dns 信息
kubectl run -it --image arm64v8/busybox dns-test --restart=Never --rm /bin/sh
nslookup web-0.nginx

3、扩容缩容

# 方式一:kubectl命令
$ kubectl scale statefulset web --replicas=5

# 方式二:打补丁修改yaml
$ kubectl patch statefulset web -p '{"spec":{"replicas":3}}'

4、镜像更新

镜像更新(目前还不支持直接更新 image,需要 patch 来间接实现)

kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"arm64v8/nginx:1.9.1"}]'

两种更新策略:
RollingUpdate滚动更新、OnDelete删除更新

1)更新策略:RollingUpdate 滚动更新
StatefulSet 也可以采用滚动更新策略,同样是修改 pod template 属性后会触发更新,但是由于 pod 是有序的,在 StatefulSet 中更新时是基于 pod 的顺序倒序更新的

灰度发布:
利用滚动更新中的 partition 属性,可以实现简易的灰度发布的效果 例如我们有 5 个 pod,如果当前
partition 设置为 3,那么此时滚动更新时,只会更新那些 序号 >= 3 的 pod 利用该机制,我们可以通过控制
partition 的值,来决定只更新其中一部分 pod,确认没有问题后再主键增大更新的 pod 数量,最终实现全部 pod 更新

  updateStrategy:
    rollingUpdate:
      partition: 0
    type: RollingUpdate

2)更新策略:OnDelete 删除更新
只有在 pod 被删除时会进行更新操作

  updateStrategy:
    type: OnDelete

5、删除

需要删除 StatefulSet 、 Headless Service 和 PVC


# 1)级联删除:删除 statefulset 时会同时删除 pods
kubectl delete statefulset web

# 或 非级联删除:删除 statefulset 时不会删除 pods,删除 sts 后,pods 就没人管了,此时再删除 pod 不会重建的
kubectl deelte sts web --cascade=false

# 2)删除 service
kubectl delete service nginx

# 3)StatefulSet删除后PVC还会保留着,数据不再使用的话也需要删除
kubectl delete pvc www-web-0 www-web-1

四、DaemonSet

1、配置文件

apiVersion: apps/v1
kind: DaemonSet # 创建DaemonSet资源
metadata:
  name: fluentd # 名字
spec:
  template:
    metadata:
      labels:
        app: logging
        id: fluentd
      name: fluentd # pod的名字
    spec:
      nodeSelector: # 节点选择器
        type: microservices #匹配的节点label
      containers:
      - name: fluentd-es
        image: agilestacks/fluentd-elasticsearch:v1.3.0
        env: # 环境变量配置
         - name: FLUENTD_ARGS # 环境变量的key
           value: -qq # 环境变量的value
        volumeMounts: # 加载数据卷,避免数据丢失
         - name: containers # 数据卷的名字
           mountPath: /var/lib/docker/containers # 将数据卷挂载到容器内的哪个目录
         - name: varlog 
           mountPath: /varlog
      volumes: # 定义数据卷
         - hostPath: # 数据卷类型,主机路径的模式,也就是与node共享目录
             path: /var/lib/docker/containers # node中的共享目录
           name: containers # 定义的数据卷名称
         - hostPath:
             path: /var/log
           name: varlog
  updateStrategy:
    type: OnDelete # 建议使用OnDelete,删除后更新

2、指定 Node 节点

DaemonSet 会忽略 Node 的 unschedulable 状态,有两种方式来指定 Pod 只运行在指定的 Node 节点上:

  • nodeSelector:只调度到匹配指定 label 的 Node 上
  • nodeAffinity:功能更丰富的 Node 选择器,比如支持集合操作
  • podAffinity:调度到满足条件的 Pod 所在的 Node 上

1)nodeSelector

先为 Node 打上标签

kubectl label nodes k8s-node1 svc_type=microsvc

然后再 daemonset 配置中设置 nodeSelector

spec:
  template:
    spec:
      nodeSelector:
        svc_type: microsvc

2)nodeAffinity
nodeAffinity 目前支持两种:requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution,分别代表必须满足条件和优选条件。

比如下面的例子代表调度到包含标签 wolfcode.cn/framework-name 并且值为 spring 或 springboot 的 Node 上,并且优选还带有标签 another-node-label-key=another-node-label-value 的Node。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: wolfcode.cn/framework-name
            operator: In
            values:
            - spring
            - springboot
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: pauseyyf/pause

3)podAffinity
podAffinity 基于 Pod 的标签来选择 Node,仅调度到满足条件Pod 所在的 Node 上,支持 podAffinity 和 podAntiAffinity。这个功能比较绕,以下面的例子为例:
如果一个 “Node 所在空间中包含至少一个带有 auth=oauth2 标签且运行中的 Pod”,那么可以调度到该 Node
不调度到 “包含至少一个带有 auth=jwt 标签且运行中 Pod”的 Node 上

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: auth
            operator: In
            values:
            - oauth2
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: auth
              operator: In
              values:
              - jwt
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: pauseyyf/pause

3、滚动更新

不建议使用 RollingUpdate,建议使用 OnDelete 模式,这样避免频繁更新 ds

五、HPA 自动扩/缩容

通过监测pod的cpu、内存使用率自定义 metrics 指标进行自动的扩容或缩容 pod 的数量。
可用于Deployment和StatefulSet,通常用于Deployment,不适用于无法扩/缩容的对象,如 DaemonSet
控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况

1、创建一个 HPA

实现 cpu 或内存的监控,首先有个前提条件是该对象必须配置了 resources.requests.cpu 或 resources.requests.memory 才可以,可以配置当 cpu/memory 达到上述配置的百分比后进行扩容或缩容

# 1)准备一个有做资源限制的 deployment
        resources:
          limits:
            cpu: 200m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 128Mi
           
# 2)执行命令  
kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5

# 3)查看HPA信息
kubectl get hpa

2、测试案例

1)找到对应服务的 service,编写循环测试脚本提升内存与 cpu 负载
while true; do wget -q -O- http://ip:port > /dev/null ; done
可以通过多台机器执行上述命令,增加负载

2)当超过负载后可以查看 pods 的扩容情况 kubectl get pods
查看 pods 资源使用情况 kubectl top pods

3)扩容测试完成后,再关闭循环执行的指令,让 cpu 占用率降下来,然后过 5 分钟后查看自动缩容情况

如果无法直接使用kubectl top pods命令,需要安装指标服务组件
开启指标服务:
1)下载 metrics-server 组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml
2)修改镜像地址为国内的地址
sed -i ‘s/k8s.gcr.io/metrics-server/registry.cn-hangzhou.aliyuncs.com/google_containers/g’ metrics-server-components.yaml
3)修改metrics-server-components.yaml的 tls 配置,不验证 tls
在 containers 的 args 参数中增加 --kubelet-insecure-tls 参数
4)安装组件
kubectl apply -f metrics-server-components.yaml
5)查看 pod 状态
kubectl get pods --all-namespaces | grep metrics

3、自定义 metrics

控制管理器开启–horizontal-pod-autoscaler-use-rest-clients
控制管理器的–apiserver指向API Server Aggregator
在API Server Aggregator中注册自定义的metrics API

你可能感兴趣的:(kubernetes,容器,云原生)