研发工程师玩转Kubernetes——通过PV的节点亲和性影响Pod部署

在《研发工程师玩转Kubernetes------PVC通过storageClassName进行延迟绑定》一文中，我们利用Node亲和性，让Pod部署在节点ubuntud上。因为Pod使用的PVC可以部署在节点ubuntuc或者ubuntud上，而系统为了让Pod可以部署成功，则让PVC与Pod亲和的ubuntud上的PV绑定。这样Pod在自身节点亲和性和PVC上都满足了条件。

在一些业务场景下，我们通过磁盘来保存数据，而程序通过数据设置自身状态。如果一旦一个Pod崩溃，我们希望新补充的Pod可以延续之前的状态。这个时候我们就可以使用PV的节点亲和性来完成上述调度。

PersistentVolume

下面PersistentVolume配置的节点亲和性要求资源只会在ubuntuc或者ubuntud上创建。

# default_storage_class_pv_ubuntucd.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: default-storage-class-pv-ubuntucd
  labels:
    volume: lb-default-storage-class-pv
spec:
  capacity:
    storage: 1Mi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  local:
    path: /tmp
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ubuntuc
          - ubuntud

PersistentVolumeClaim

PVC直接和上述PV绑定。

# default_storage_class_pvc_600k.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: default-storage-class-pvc-600k
spec:
  resources:
    requests:
      storage: 600Ki
  accessModes:
    - ReadWriteOnce
  selector:
    matchLabels:
      volume: lb-default-storage-class-pv

Deployment

下面这个Deployment会创建2个Pod。由于Pod的反亲和性，它们被强制要求调度到不同Node上。

# default_deployment_one_on_node.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-pv-app-one-on-node-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: default-pv-app-one-on-node
  template:
    metadata:
      labels:
        app: default-pv-app-one-on-node
    spec:
      containers:
      - name: default-pv-app-one-on-node
        image: busybox
        command: ["/bin/sh", "-c", "if [ -f /tempdir/lockfile ] && ! { set -C; 2>/dev/null >/tempdir/lockfile; }; then tail -f /tempdir/lockfile; else exec 3>/tempdir/lockfile; if [ -n \"$POD_NAME\" ]; then name=$POD_NAME; else name=\"unknown\"; fi; while true; do echo \"this is $name.$name write something to lockfile\"; echo \"$name write something to lockfile\" >&3; sleep 1; done; fi"]  
        volumeMounts:
        - name: default-pvc-volume
          mountPath: /tempdir
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
      volumes:
      - name: default-pvc-volume
        persistentVolumeClaim:
          claimName: default-storage-class-pvc-600k
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - default-pv-app-one-on-node
            topologyKey: "kubernetes.io/hostname"

实验

查看Pod状态

kubectl get pod -o wide

NAME                                                    READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
default-pv-app-one-on-node-deployment-76bf96bb5-7tzxd   1/1     Running   0          21s   10.1.202.210   ubuntud   <none>           <none>
default-pv-app-one-on-node-deployment-76bf96bb5-mtk67   1/1     Running   0          21s   10.1.43.207    ubuntuc   <none>           <none>

可以看到两个Pod分别被调度到ubuntuc和ubuntud上。

调整Pod数量

kubectl scale deployment default-pv-app-one-on-node-deployment --replicas 3

kubectl get pod -o wide

NAME                                                    READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
default-pv-app-one-on-node-deployment-76bf96bb5-7tzxd   1/1     Running   0          46s   10.1.202.210   ubuntud   <none>           <none>
default-pv-app-one-on-node-deployment-76bf96bb5-mtk67   1/1     Running   0          46s   10.1.43.207    ubuntuc   <none>           <none>
default-pv-app-one-on-node-deployment-76bf96bb5-9wvq5   0/1     Pending   0          3s    <none>         <none>    <none>           <none>

可以看到，新创建的Pod处于Pending状态。当前系统还有ubuntua、ubuntud、ubunutue三个节点，它们由于不能满足Pod对PVC的要求（实际是PVC绑定的PV的要求），而没有被调度到。

kubectl get  nodes

NAME      STATUS   ROLES    AGE     VERSION
ubuntud   Ready    <none>   2d22h   v1.27.4
ubuntuc   Ready    <none>   2d23h   v1.27.4
ubuntue   Ready    <none>   2d22h   v1.27.4
ubuntub   Ready    <none>   2d23h   v1.27.4
ubuntua   Ready    <none>   2d23h   v1.27.4

恢复Pod

kubectl scale deployment default-pv-app-one-on-node-deployment --replicas 2
kubectl delete pod default-pv-app-one-on-node-deployment-76bf96bb5-7tzxd 
kubectl get pod -o wide

NAME                                                    READY   STATUS    RESTARTS   AGE     IP             NODE      NOMINATED NODE   READINESS GATES
default-pv-app-one-on-node-deployment-76bf96bb5-mtk67   1/1     Running   0          2m12s   10.1.43.207    ubuntuc   <none>           <none>
default-pv-app-one-on-node-deployment-76bf96bb5-qqtlm   1/1     Running   0          39s     10.1.202.211   ubuntud   <none>           <none>

可以看到Pod被正确的调度到刚被删掉Pod的Node上，进而可以继续使用它的PV，从而实现服务状态恢复和衔接上的目的。