六、K8s pod相关操作（2）

实验环境：

在这里插入图片描述
接前一个笔记：pod相关操作1：https://blog.csdn.net/tushanpeipei/article/details/118444242?spm=1001.2014.3001.5502

四、初始化容器

普通容器运行必须满足前提条件，可以设置初始化容器的方式，首先执行初始化容器再执行普通容器。

如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序依次运行，每个 Init 容器必须运行成功，下一个才能够运行。

在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。对 Init 容器 spec 的修改，更改 Init 容器的 image 字段，等价于重启该 Pod。

在pod1.yaml文件中定义2个初始化容器，分别执行20s和10s：

[root@vms201 pod-practice]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  initContainers:
  - name: initc1
    image: nginx
    imagePullPolicy: IfNotPresent
    command: ["sh", "-c" , "sleep 20"]
  - name: initc2
    image: nginx
    imagePullPolicy: IfNotPresent
    command: ["sh", "-c" , "sleep 10"]
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

在20s内、20s-30s、30s以上分别查看pod1的状态：

[root@vms201 pod-practice]# kubectl get pod pod1
NAME   READY   STATUS     RESTARTS   AGE
pod1   0/1     Init:0/2   0          12s

[root@vms201 pod-practice]# kubectl get pod pod1
NAME   READY   STATUS     RESTARTS   AGE
pod1   0/1     Init:1/2   0          29s

[root@vms201 pod-practice]# kubectl get pod pod1
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          44s

可以看到整个初始化的过程。

注意：在k8s里，每个pod都会有一个隐藏的初始化容器pause。

[root@vms203 ~]# docker ps | grep pod1
e38fb27868d5   4f380adfc10f                                          "/docker-entrypoint.…"   23 minutes ago      Up 23 minutes                k8s_pod1_pod1_2-pod_979af8c8-abce-4f53-a0bf-ef28ffd0919c_0
0e0a9e630d42   registry.aliyuncs.com/google_containers/pause:3.4.1   "/pause"                 24 minutes ago      Up 24 minutes                k8s_POD_pod1_2-pod_979af8c8-abce-4f53-a0bf-ef28ffd0919c_0

起目的是维护业务容器pod1，比如共享网络空间。

五、静态POD

所谓静态pod就是，不是master上创建的，而是需要到Node的/etc/kubelet.d/里创建一个yaml文件（或者自己修改kubelet的指定位置），然后根据这个yaml文件，创建一个pod，这样创建出来的node，是不会接受master的管理的。

应用场景：例如master崩溃了，则可以用静态POD提供服务。

当然，要是想创建静态pod的话，需要对node的kubelet配置文件进行一些设置才可以。在指定目录下面创建一个yaml文件，然后改kubelet的systemd配置，reload+重启，最后再检查。

方式一：使用默认的目录

查找静态pod yaml文件默认的存放路径

[root@vms202 kubelet.d]# cat /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

可以中获取config.yaml文件的地址KUBELET_CONFIG_ARGS=–config=/var/lib/kubelet/config.yaml；然后查看此文件，获取默认静态pod地址：

[root@vms202 kubelet.d]# cat /var/lib/kubelet/config.yaml

可以看到其中的：staticPodPath: /etc/kubernetes/manifests参数，指定了静态Pod对应的地址。进入此地址：

cd  /etc/kubernetes/manifests

在此目录下创建pod的yaml文件：

[root@vms202 manifests]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

返回master上，查看pod信息：

[root@vms201 pod-practice]# kubectl get pods -n default
NAME                  READY   STATUS    RESTARTS   AGE
pod1-vms202.rhce.cc   1/1     Running   0          41s

方式二：通过手工指定路径完成静态POD的创建

在worker node上完成目录设置。编辑需要修改的文件：

vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

添加信息：在Environment属性下设置–pod-manifest-path=/etc/kubernetes/kubelet（确保目录已经被建立）。

# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/kubelet.d"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

重启服务：

 systemctl daemon-reload ;systemctl restart kubelet.service

在此目录下创建pod的yaml文件：

[root@vms202 kubelet.d]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

返回到Master上查看是否已经创建完成：yaml文件如果没有说明pod在那个命名空间创建，默认是default。

[root@vms201 pod-practice]# kubectl get pods -n default
NAME                  READY   STATUS    RESTARTS   AGE
pod1-vms202.rhce.cc   1/1     Running   0          2m16s

可以在yaml文件中通过namespace属性指定对应的命名空间，再次创建时便在2-pod的命名空间下：

[root@vms202 kubelet.d]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
  namespace: 2-pod
spec:
  terminationGracePeriodSeconds: 0
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

注意点：通过此方法无法在Master上设置静态POD。其原因是master上的各种组件的yaml文件也是存放在默认的目录，并且也是以静态POD的形式存在，当修改了静态POD的目录后，kubelet无法找到Master组件的相应的yaml文件，导致失效。

六、调度POD

K8s能够决定pod在那个worker node上执行，原理如下：

调度的三个对象：
1.待调度Pod列表；
2.可用node列表；
3.调度算法（主机过滤、主机打分）。

Master将待调度Pod列表中的pod按照调度算法调度到可用node列表中去。

主机过滤：
排除掉一些不能用的主机：
1.被设置了污点的主机不可用（master上有污点，也就是在其上不会创建pod的原因），污点相关的笔记在后面补充。
2.端口冲突，当两个pod的端口是一样的时候，无法创建在同一个Node上。当需要创建的Pod无论部署到哪个worker node上都会端口冲突时，则会进入pending状态。

例如：在仅有2个worker node上创建3个端口一样的pod：

[root@vms201 pod-practice]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 pod-practice]# sed 's/pod1/pod2/' pod1.yaml | kubectl apply -f -
pod/pod2 created
[root@vms201 pod-practice]# sed 's/pod1/pod3/' pod1.yaml | kubectl apply -f -
pod/pod3 created

查看pod创建情况：

[root@vms201 pod-practice]# kubectl get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          49s   10.244.185.78   vms203.rhce.cc   <none>           <none>
pod2   1/1     Running   0          37s   10.244.58.212   vms202.rhce.cc   <none>           <none>
pod3   0/1     Pending   0          33s   <none>          <none>           <none>           <none>

可以看到，两个pod分别工作在两个worker node上，而最后创建的pod3状态则为pending。

主机打分：

当一个容器可以在多个nodes上创建时，如果判断创建在哪一个node，则需要使用主机打分功能，分数越高，pod越优先部署。当在一个node上创建了pod后，其他条件不变，分数会降低。

相关算法公式：

LeastRequestedPriority公式：
score=cpu ( ( capacity - sum ( requested ) ) * 10 / capacity) + memory
( ( capacity - sum ( requested) ) * 10 / capacity ) /2

BalanceResourceAllocation公式：
score = 10 -abs ( cpuFraction - memoryFraction ) * 10

CalculateSpreadPriority公式：
Score = 10 * （（maxCount -counts）/ （maxCount））

手工调度pod：

方式1： 通过nodeName的方式调度

查看worker node的名称：

[root@vms201 pod-practice]# kubectl get nodes
NAME             STATUS   ROLES                  AGE    VERSION
vms201.rhce.cc   Ready    control-plane,master   3d1h   v1.21.0
vms202.rhce.cc   Ready    <none>                 3d1h   v1.21.0
vms203.rhce.cc   Ready    <none>                 3d1h   v1.21.0

修改pod的yaml文件，设置nodeName为vms202.rhce.cc或者vms203.rhce.cc

[root@vms201 pod-practice]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  nodeName: vms202.rhce.cc
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
      hostPort: 80
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

查看是否运行在了指定的node上。

[root@vms201 pod-practice]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 pod-practice]# kubectl get pod pod1 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          21s   10.244.58.213   vms202.rhce.cc   <none>           <none>

注意：有污点的主机上，是不允许pod的，如果强制调度上去的话，pod的状态应该是pending的，通过nodeName是可以把一个pod调度在有污点的主机上正常运行的。

方式2： 通过标签的方式调度

在K8s里，任何的对象：node、pod、deploy、namespace等都有tag。可以在查看命令加上 --show-labels来查看。例如：

[root@vms201 pod-practice]# kubectl get nodes --show-labels
NAME             STATUS   ROLES                  AGE    VERSION   LABELS
vms201.rhce.cc   Ready    control-plane,master   3d2h   v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=vms201.rhce.cc,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
vms202.rhce.cc   Ready    <none>                 3d2h   v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=vms202.rhce.cc,kubernetes.io/os=linux
vms203.rhce.cc   Ready    <none>                 3d2h   v1.21.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=vms203.rhce.cc,kubernetes.io/os=linux

标签的格式：key-value的格式，例如xxxx/yyy.aaaaa=123123。

设置标签语法：

kubectl label 对象类型 对象名 key=value

删除标签语法：

kubectl label 对象类型 对象名 key-

在两个workder nodes上分别创建标签：

[root@vms201 pod-practice]# kubectl label nodes vms202.rhce.cc node1=xxx
node/vms202.rhce.cc labeled
[root@vms201 pod-practice]# kubectl label nodes vms203.rhce.cc node2=xxx
node/vms203.rhce.cc labeled
[root@vms201 pod-practice]# kubectl get nodes -l node1=xxx
NAME             STATUS   ROLES    AGE    VERSION
vms202.rhce.cc   Ready    <none>   3d2h   v1.21.0
[root@vms201 pod-practice]# kubectl get nodes -l node2=xxx
NAME             STATUS   ROLES    AGE    VERSION
vms203.rhce.cc   Ready    <none>   3d2h   v1.21.0

修改yaml文件，加入标签选择器 nodeSelector：

vim pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  nodeSelector:
    node1: xxx
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
      hostPort: 80
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

应用yaml文件，并查看应用到的node是否匹配：

[root@vms201 pod-practice]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 pod-practice]# kubectl get pod pod1 -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          53s   10.244.58.214   vms202.rhce.cc   <none>           <none>

注意：

当pod根据标签应用到的node上有污点时，pod的状态为pending；
当多个node都存在同一个标签，pod会在其上选择一个进行部署。

方式3： 通过主机亲和性的方式来部署

硬策略：
硬策略比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然我就不干的策略。

修改pod的yaml文件，设置硬策略，满足label中的key为kubernetes.io/hostname，value为vms202.rhce.cc才进行调度。

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - vms202.rhce.cc
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

在master上查看是否部署到了对应的work上：

[root@vms201 pod-practice]# kubectl get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE             NOMINATED NODE   READINESS GATES
pod1   1/1     Running   0          72s   10.244.58.218   vms202.rhce.cc   <none>           <none>

其中，operator分为如下几类In，NotIn，Exists，DoesNotExist，Gt，Lt，含义如下：

In：label 的值在某个列表中
NotIn：label 的值不在某个列表中
Gt：label 的值大于某个值
Lt：label 的值小于某个值
Exists：某个 label 存在
DoesNotExist：某个 label 不存在

软策略：
软策略就是如果你没有满足调度要求的节点的话，pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓了的策略。

举例：通过如下的yaml文件创建pod，pod会优先部署到key bb > 3的node上，如果没有的话，则依旧会部署到其他可用节点上。

[root@vms201 pod-practice]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: # 软策略
      - weight: 2
        preference:
          matchExpressions:
          - key: bb
            operator: Gt
            values:
            - "3"
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

注意：

如果nodeSelectorTerms下面有多个选项的话，满足任何一个条件就可以了；如果matchExpressions有多个选项的话，则必须同时满足这些条件才能正常调度 POD。
当设置了不同的软策略后，如果其中的多条，则依据weight的大小选择匹配哪一条策略（越大越优先）。

调度：警戒线cordon

假设某一天，我们需要对某个work进行维护，不想要行的pod分配到其上来，则可以使用cordon。如果一个node被标记为cordon，新创建的pod不会被调度到此node上。已经调度上去的不会被移走，仍然继续运行。

设置某一个node为cordon：

[root@vms201 pod-practice]# kubectl cordon vms203.rhce.cc
node/vms203.rhce.cc cordoned
[root@vms201 pod-practice]# kubectl get nodes
NAME             STATUS                     ROLES                  AGE     VERSION
vms201.rhce.cc   Ready                      control-plane,master   3d14h   v1.21.0
vms202.rhce.cc   Ready                      <none>                 3d14h   v1.21.0
vms203.rhce.cc   Ready,SchedulingDisabled   <none>                 3d14h   v1.21.0

可以看到STATUS一栏的状态为SchedulingDisabled。取消cordon命令如下：

[root@vms201 pod-practice]# kubectl uncordon vms203.rhce.cc
node/vms203.rhce.cc uncordoned

调度：节点的drain
和cordon功能相似，不同点是如果一个节点被设置为drain，则此节点不再被调度pod，且此节点上已经运行的pod会被驱逐(evicted)到其他节点：

设置某一个node为cordon：

[root@vms201 pod-practice]# kubectl drain vms203.rhce.cc --ignore-daemonsets --force --delete-emptydir-data
node/vms203.rhce.cc already cordoned
WARNING: deleting Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet: 2-pod/pod1; ignoring DaemonSet-managed Pods: kube-system/calico-node-ldfhc, kube-system/kube-proxy-m9c2c
evicting pod kube-system/metrics-server-bcfb98c76-x8c77
evicting pod 2-pod/pod1
pod/pod1 evicted
pod/metrics-server-bcfb98c76-x8c77 evicted
node/vms203.rhce.cc evicted

可以看到，vms203.rhce.cc其上相关的pod已经被驱逐（删除）：

[root@vms201 pod-practice]# kubectl get pods
No resources found in 2-pod namespace.

取消node的drain，以uncordon的方式进行操作：

[root@vms201 pod-practice]# kubectl uncordon vms203.rhce.cc
node/vms203.rhce.cc uncordoned

调度: 节点taint（污点）及pod的tolerations（容忍）

节点亲和性(affinity)，是节点的一种属性,让符合条件的pod亲附于它(倾向于或者硬性要求)。污点是一种相反的行为，它会使pod抗拒此节点(即pod调度的时候不被调度到此节点)。

污点和容忍结合在一起以确保pod不会被调度到不适合的节点上。当一个或者多个污点添加到某个节点上，则意味着此节点不会接受任何不容忍这些污点的pod。Tolerations作用于pod上，允许(但不是必须)pod被调度到有符合的污点(taint)的节点上。

查看master上的污点：

[root@vms201 pod-practice]# kubectl describe nodes vms201.rhce.cc | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

在一个worker node上设置污点：以key-values：effect的形式出现，effect一般是NoSchedule

 [root@vms201 pod-practice]# kubectl taint node vms202.rhce.cc disk=ssd:NoSchedule
node/vms202.rhce.cc tainted

修改pod的yaml文件，让其通过标签的方式部署在设置了污点的node上：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  nodeSelector:
    node1: xxx
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
      hostPort: 80
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

查看pod的部署状态：为pending。

[root@vms201 pod-practice]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 pod-practice]# kubectl get pod pod1
NAME   READY   STATUS    RESTARTS   AGE
pod1   0/1     Pending   0          17s

在pod的yaml文件中设置tolerations属性，设置能够容忍此污点：

[root@vms201 pod-practice]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod1
  name: pod1
spec:
  terminationGracePeriodSeconds: 0
  tolerations:
  - key: "disk"
    operator: "Equal"
    value: "ssd"
    effect: "NoSchedule"
  nodeSelector:
    node1: xxx
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod1
    resources: {}
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
      hostPort: 80
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

然后在查看节点是否已经运行起来：状态为running。operator的值可以设置为equal、Exists（不用写value，完全通过是否有这个key来判断）

[root@vms201 pod-practice]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@vms201 pod-practice]# kubectl get pod pod1
NAME   READY   STATUS    RESTARTS   AGE
pod1   1/1     Running   0          70s

污点和drain/cordon有什么不同：

污点可以通过容忍在此节点运行；
drain和coradon操作后便无法分配节点了。

删除污点：

[root@vms201 pod-practice]# kubectl taint nodes vms202.rhce.cc disk:NoSchedule-
node/vms202.rhce.cc untainted

如果一个node有多个污点，但是pod的yaml文件中仅容忍了其中部分的污点，也是无法在此node上调度的。

参考资料：
《老段CKA课程》

原文链接：https://blog.csdn.net/tushanpeipei/article/details/118459673