Pod调度方式（上）

Pod调度方式

1. Pod调度之nodeName

[root@master231 scheduler]# cat 01-scheduler-nodeName.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-nodename
spec:
  replicas: 10
  selector:
    matchLabels:
      apps: xiuxian
  template:
    metadata:
      labels:
        apps: xiuxian
        version: v1
    spec:
       # 指定节点进行调度，此时scheduler是不用参与此次调度的!
       #nodeName: worker232
       nodeName: worker232
       # nodeName的字段值必须在etcd中有记录
       # nodeName: 10.0.0.232
       containers:
       - name: c1
         image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v2

使用 nodeName 进行调度可以非常精确地将 Pod 调度到指定的节点上，无需 Kubernetes 默认的调度器参与。然而，这种方式的灵活性较差，因为一旦节点不可用，Pod 就无法调度到其他节点。

2. Pod调度之hostNetwork

[root@master231 scheduler]# cat 02-scheduler-hostNetwork.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-hostnetwork
spec:
  replicas: 5
  selector:
    matchLabels:
      apps: xiuxian
  template:
    metadata:
      labels:
        apps: xiuxian
        version: v1
    spec:
       # 指定宿主机进行调度,
       # 可以调度成功，但是要注意每个worker节点和宿主机端口不能冲突，否则Pod将无法正常运行!
       hostNetwork: true
       containers:
       - name: c1
         image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v2

使用宿主机的网络命名空间可以解决一些特定的性能问题，尤其是在需要低延迟和高吞吐量的场景下。然而，它也会带来一些风险，特别是端口冲突的问题。

3. Pod调度之hostPort

[root@master231 scheduler]# cat 03-scheduler-hostPort.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-ports-hostport
spec:
  replicas: 5
  selector:
    matchLabels:
      apps: xiuxian
  template:
    metadata:
      labels:
        apps: xiuxian
        version: v1
    spec:
       containers:
       - name: c1
         image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v2
         ports:
         - containerPort: 80
           # 指定了宿主机端口，2个相同的Pod无法调度到同一个节点，否则就不知道转发到哪个pod的端口啦~
           hostPort: 8080

hostPort 适用于需要直接通过宿主机访问容器的场景。一个重要的限制是如果同一节点上有多个 Pod 使用相同的 hostPort，它们就无法并行运行，因此需要小心管理端口映射。

4. Pod调度之resources

[root@master231 scheduler]# cat 04-scheduler-resources.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-resources-requests
spec:
  replicas: 5
  selector:
    matchLabels:
      apps: xiuxian
  template:
    metadata:
      labels:
        apps: xiuxian
        version: v1
    spec:
       containers:
       - name: c1
         image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v2
         resources:
           # 指定Pod的期望资源，若不满足，则无法完成调度
           # 若不配置requests字段，则requests等效于limits。
           requests:
             cpu: 0.5
             memory: 200Mi
           # 指定Pod使用资源的上限，尽管该节点没有这些资源，我们的确可以设置一个阈值。
           # 但实际使用还是要看宿主机大小，比如宿主机仅有2core4Gi，则尽管你设置了4core8Gi，也无法真正用到4core8Gi，而是最多用2core4Gi。
           limits:
             cpu: 4
             memory: 8Gi

通过资源请求和限制，我们可以控制 Pod 调度时对计算资源的预期。它确保 Pod 不会请求超过节点资源的量，从而防止资源竞争问题。但设置不当也可能导致调度失败或资源浪费。

---

5. Pod调度之taints(污点)

5.1 污点的作用

污点作用于节点，影响 Pod 调度。语法格式为 key[=value]:effect，Kubernetes 支持以下三种 effect（影响度）：

• NoSchedule: 不允许新的 Pod 调度到该节点，也不会驱逐已经在该节点的 Pod。
• PreferNoSchedule: 优先将 Pod 调度到其他节点，只有在其他节点资源不足时才会调度到该节点。
• NoExecute: 不接受新的 Pod 调度，并且立刻驱逐已经调度到该节点的 Pod。

5.2 查看节点的污点

[root@master231 scheduler]# kubectl describe nodes  | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule
Taints:             <none>
Taints:             <none>

污点为 Kubernetes 提供了非常灵活的节点隔离机制。通过设置不同的污点，集群管理员可以对不同类型的节点进行精细控制。

5.3 节点打污点

[root@master231 scheduler]# kubectl taint node worker233 school=oldboyedu:NoSchedule
node/worker233 tainted
[root@master231 scheduler]# kubectl describe nodes  | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule
Taints:             <none>
Taints:             school=oldboyedu:NoSchedule

添加污点到节点后，只有具备相应容忍的 Pod 才能调度到这个节点。这种机制非常有用，尤其是在进行节点维护或者节点的硬件故障时。

5.4 删除污点

[root@master231 scheduler]# kubectl taint node worker233 school-
node/worker233 untainted

删除污点后，该节点将不再被标记为不可调度状态。删除污点可以恢复节点的调度能力。

5.5 修改污点

[root@master231 scheduler]# kubectl taint node worker233 school=yitiantian:NoSchedule --overwrite
node/worker233 modified
[root@master231 scheduler]# kubectl describe nodes  | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule
Taints:             <none>
Taints:             school=yitiantian:NoSchedule

使用 --overwrite 可以修改已经存在的污点，这在调整节点策略时非常有用。

---

6. 多个污点

一个节点可以拥有多个污点，这样就可以更灵活地控制 Pod 的调度。例如：

[root@master231 scheduler]# kubectl taint node worker233 school=oldboyedu:PreferNoSchedule
node/worker233 tainted
[root@master231 scheduler]# kubectl taint node worker233 class=linux92:PreferNoSchedule
node/worker233 tainted

在同一节点上设置多个污点，可以灵活调整节点的调度优先级，特别是在资源紧张的情况下，这种方式会非常有用。

---

7. 污点容忍（Tolerations）

7.1 容忍配置

Pod 需要配置容忍 (tolerations) 来允许调度到带有污点的节点。

spec:
  tolerations:
    - key: "class"
      value: "linux92"
      effect: "NoSchedule"
    - key: "school"
      value: "yitiantain"
      effect: "PreferNoSchedule"
    - key: "school"
      value: "oldboyedu"
      effect: "NoExecute"
    - key: "node-role.kubernetes.io/master"
      effect: "NoSchedule"

7.2 容忍所有污点

spec:
  tolerations:
    - operator: "Exists"

通过设置容忍策略，Pod 可以在带有污点的节点上运行。Exists 操作符可以容忍所有类型的污点，但需要谨慎使用，因为它可能导致 Pod 被调度到不适合的节点上。

---