Kubernetes Network与Pod Scheduler

m0_65060929

228人浏览 · 2026-07-14 18:35:46

m0_65060929 · 2026-07-14 18:35:46 发布

Kubernetes Network

环境准备

root@master30:~# kubectl create ns network
root@master30:~# kubectl config set-context --current --namespace network

单主机网络通信

Docker 单机网络

Docker中的网络接口默认都是虚拟的接口。虚拟接口的最大优势就是转发效率极高。这是因为Linux在内核中进行数据复制来实现虚拟接口之间的数据转发，即发送接口的发送缓存中的数据包将被直接复制到接收接口的接收缓存中，而无需通过外部物理网络设备进行交换。

Docker 服务默认会创建一个名称为docker0的Linux网桥（其上有一个docker0内部接口），利用了Linux虚拟网络技术，在本地主机和容器内分别创建一个虚拟接口，并让它们彼此连通（这样的一对接口叫做vethpair）。Docker默认指定了docker0接口的IP地址和子网掩码，让主机和容器之间可以通过网桥相互通信。

说明：brctl工具由bridge-utils提供。

外部主机要想访问容器，需要通过端口映射实现。

Containerd 单机网络

Containerd 中的网络与Docker类似，所有网络接口默认都是虚拟接口。

创建容器时，Containerd 会在本地主机和容器内分别创建一个虚拟接口，并让它们彼此连通。

跨主机网络通信

跨主机通信架构

跨主机通信方法比较多，可以使用：

docker 原生的方案：overlay 和 macvlan。
第三方提供的方案：flannel 、calico、weave等。

重点关注两点：配置难易程度和是否支持网络策略。

以下数据来源于《kubernetes 权威指南》。

方案特性	Flannel	Calico	macvlan	OpenVswitch	直接路由
方案特性	通过虚拟设备flannel0实现对docker0的管理	基于BGP协议的纯三层的网络方案	基于Linux Kernel 的macvlan技术	基于隧道的虚拟路由器技术	基于Linux Kernel 的 vRouter 技术
对底层网络的要求	三层互通	三层互通	二层互通	三层互通	二层互通
配置难易程度	简单-基于etcd	简单-基于etcd	简单-直接使用宿主机网络，需要仔细规划IP地址	复杂-需手工配置个节点的bridge	简单-使用宿主机vRoute功能，需要仔细规划每个Node的IP地址
网络性能	host-gw > VxLAN	BGP 模式性能随时小、IPIP 模式较小	性能随时可忽略	性能随时较小	性能随时较小
网络连通性限制	无	在不支持BGP的网络环境下无法使用	基于macvlan的容器无法与宿主机网络通信	无	在无法实现大二层互通的网络环境下无法使用

跨主机通信方案

我们将从如下几个方面比较，大家可以根据不同场景选择最合适的方案。

网络模型，采用何种网络模型支持 multi-host 网络？
Distributed Store，是否需要 etcd 或 consul 这类分布式 key-value 数据库存储网络信息？
IPMA，如何管理容器网络的 IP？
连通与隔离，提供怎样的网络连通性？支持容器间哪个级别和哪个类型的隔离？
性能，性能比较。

网络模型

跨主机网络意味着将不同主机上的容器用同一个虚拟网络连接起来。这个虚拟网络的拓扑结构和实现技术就是网络模型。

overlay，建立主机间 VxLAN 隧道，原始数据包在发送端被封装成 VxLAN 数据包，到达目的后在接收端解包。
Macvlan ，网络在二层上通过 VLAN 连接容器，在三层上依赖外部网关连接不同 macvlan。数据包直接发送，不需要封装，属于underlay 网络。
Flannel 支持 backend：vxlan 和 host-gw。vxlan 与 Docker overlay 类似，属于 overlay 网络。host-gw 将主机作为网关，依赖三层 IP 转发，不需要像 vxlan 那样对包进行封装，属于 underlay 网络。
Weave，是 VxLAN 实现，属于 overlay 网络。
Calico ，与Flannel使用host-gw类似，将主机作为网关，依赖三层 IP 转发，不需要像 vxlan 那样对包进行封装，属于 underlay 网络。

Distributed Store

**Docker Overlay、Flannel 和 Calico 都需要 etcd 或 consul。**Macvlan 是简单的 local 网络，不需要保存和共享网络信息。Weave 自己负责在主机间交换网络配置信息，也不需要 Distributed Store。

IPAM

Docker Overlay 网络中所有主机共享同一个 subnet，容器启动时会顺序分配 IP，可以通过 --subnet 定制此 IP 空间。

Macvlan 需要用户自己管理 subnet，为容器分配 IP，不同 subnet 通信依赖外部网关。

Flannel 为每个主机自动分配独立的 subnet，用户只需要指定一个大的 IP 池。不同 subnet 之间的路由信息也由 Flannel 自动生成和配置。

Weave 的默认配置下所有容器使用 10.32.0.0/12 subnet，如果此地址空间与现有 IP 冲突，可以通过 --ipalloc-range 分配特定的 subnet。

Calico 从 IP Pool（可定制）中为每个主机分配自己的 subnet。

连通与隔离

同一 Docker Overlay 网络中的容器可以通信，但不同网络之间无法通信，要实现跨网络访问，只有将容器加入多个网络。与外网通信可以通过 docker_gwbridge 网络。

Macvlan 网络的连通或隔离完全取决于二层 VLAN 和三层路由。

不同 Flannel 网络中的容器直接就可以通信，没有提供隔离。与外网通信可以通过 bridge 网络。

Weave 网络默认配置下所有容器在一个大的 subnet 中，可以自由通信，如果要实现隔离，需要为容器指定不同的 subnet 或 IP。与外网通信的方案是将主机加入到 weave 网络，并把主机当作网关。

Calico 默认配置下只允许位于同一网络中的容器之间通信，但通过其强大的 Policy 能够实现几乎任意场景的访问控制。

性能

性能测试是一个非常严谨和复杂的工程，这里我们只尝试从技术方案的原理上比较各方案的性能。

最朴素的判断是：Underlay 网络性能优于 Overlay 网络。

**Overlay 网络利用隧道技术，将数据包封装到 UDP 中进行传输。**因为涉及数据包的封装和解封，存在额外的 CPU 和网络开销。虽然几乎所有 Overlay 网络方案底层都采用 Linux kernel 的 vxlan 模块，这样可以尽量减少开销，但这个开销与 Underlay 网络相比还是存在的。所以 Macvlan、Flannel host-gw、Calico 的性能会优于 Docker overlay、Flannel vxlan 和 Weave。

Overlay 较 Underlay 可以支持更多的二层网段，能更好地利用已有网络，以及有避免物理交换机 MAC 表耗尽等优势，所以在方案选型的时候需要综合考虑。

跨主机网络模型

容器网络的配置是一个复杂的过程，为了应对各式各样的需求：

容器网络的解决方案也多种多样，例如有flannel，calico，kube-ovn，weave等。
容器平台/运行时也是多样的，例如有Kubernetes，Openshift，rkt等。

想要解决这个问题，我们需要一个抽象的接口层，将容器网络配置方案与容器平台方案解耦。

CNM

CNM（ Container Network Model，容器网络模型），由 Docker 公司提出，在 docker 项目下的 libnetwork 项目中被采用。按照该模型开发出的 driver 就能与 docker daemon 协同工作，实现容器网络。

docker 原生的 driver 包括 none、bridge、overlay 和 macvlan。
第三方 driver 包括 flannel、weave、calico 等。

容器网络模型对容器网络进行了抽象，由以下三类组件组成：

Sandbox 是容器的网络栈，包含容器的 interface、路由表和 DNS 设置。 Linux Network Namespace 是 Sandbox 的标准实现。Sandbox 可以包含来自不同 Network 的 Endpoint。
Endpoint 的作用是将 Sandbox 接入 Network。Endpoint 的典型实现是 veth pair，后面我们会举例。一个 Endpoint 只能属于一个网络，也只能属于一个 Sandbox。
Network 包含一组 Endpoint，同一 Network 的 Endpoint 可以直接通信。Network 的实现可以是 Linux Bridge、VLAN 等。

如图所示两个容器，一个容器一个 Sandbox，每个 Sandbox 都有一个 Endpoint 连接到 Network 1，第二个 Sandbox 还有一个 Endpoint 将其接入 Network 2.

下面我们以 docker bridge driver 为例讨论 libnetwork CNM 是如何被实现的。

两个 Network：默认网络 “bridge” 和自定义网络 “my_net2”。实现方式是 Linux Bridge：“docker0” 和 “br-5d863e9f78b6”。
三个 Enpoint，由 veth pair 实现，一端(vethxxx)挂在 Linux Bridge 上，另一端(eth0)挂在容器内。
三个 Sandbox，由 Network Namespace 实现，每个容器有自己的 Sanbox。

CNI

CNI，全称 Container Network Interface，是 Google 和 **CoreOS **联合定制的网络标准，CNI 规范定义了容器和网络插件之间通信规范，实现多容器通信。各个网络厂商通过该接口实现互相通信。

一个容器可以被加入到被不同插件所驱动的多个网络之中。一个网络有自己对应的插件和唯一的名称。

CNI 模型包含2个概念:

容器: 独立的 linux 网络命名空间。
网络: 用于互联实体, 这些实体拥有各自独立且唯一的 IP 地址, 可以是容器, 物理机, 或者其他网络设备。

通过插件设置网络，包括 CNI Plugin 和 IPAM ( IP address management) Plugin 两类插件：
- CNI Plugin 负责配置容器网络。
- IPAM plugin 负责分配容器的IP 地址。
IPAM Plugin 作为 CNI plugin 的一部分, 与CNI plugin 一起工作。

CNM和CNI比较

特点	CNM	CNI
标准规范	Libnetwork	cni
最小单元	容器	POD
对守护进程的依赖	依赖 dockerd	不依赖任何守护进程
扩主机通信	依赖外部 KV 数据库	用本身的 KV 数据库
灵活程度	被 docker 绑定	插件可随意替换

网络策略

网络策略介绍

默认情况，集群网络连通性如下：

集群外部主机可以访问集群内部应用
集群内部应用也可以访问集群外部主机
各个namespace之间没有做任何的隔离策略

如果希望在 IP 地址或端口层面控制网络流量，考虑使用 Kubernetes 网络策略（NetworkPolicy）。

NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 Pod 与网络上的各类网络“实体” 通信。
NetworkPolicy 适用于一端或两端与 Pod 的连接，与其他连接无关。

**提示：**网络策略通过网络插件来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案，例如 calico。

网络策略规约

Pod 有两种隔离: 出口的隔离和入口的隔离。

默认情况下，**一个 Pod 的出口是非隔离的，即所有外向连接都是被允许的。**如果有任何的 NetworkPolicy 选择该 Pod 并在其 policyTypes 中包含 “Egress”，则该 Pod 是出口隔离的，我们称这样的策略适用于该 Pod 的出口。当一个 Pod 的出口被隔离时，唯一允许的来自 Pod 的连接是适用于出口的 Pod 的某个 NetworkPolicy 的 egress 列表所允许的连接。这些 egress 列表的效果是相加的。
默认情况下，**一个 Pod 对入口是非隔离的，即所有入站连接都是被允许的。**如果有任何的 NetworkPolicy 选择该 Pod 并在其 policyTypes 中包含 “Ingress”，则该 Pod 被隔离入口，我们称这种策略适用于该 Pod 的入口。当一个 Pod 的入口被隔离时，唯一允许进入该 Pod 的连接是来自该 Pod 节点的连接和适用于入口的 Pod 的某个 NetworkPolicy 的 ingress 列表所允许的连接。这些 ingress 列表的效果是相加的。

**网络策略是相加的，所以不会产生冲突。**如果策略适用于 Pod 某一特定方向的流量， Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。因此，评估的顺序不影响策略的结果。

**要允许从源 Pod 到目的 Pod 的连接，则源 Pod 的出口策略和目的 Pod 的入口策略都需要允许连接。**如果任何一方不允许连接，建立连接将会失败。

示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  # 使用标签过滤限制哪些pod
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  # Ingress控制外部访问内部
  - Ingress
  # Egress控制pod访问外部
  - Egress
  ingress:
  # from限制允许哪些主机可以访问pod
  - from:
    # 通过ip限制
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    # 限制namespace中pod
    - namespaceSelector:
        matchLabels:
          project: myproject
    # 限制同一namespace中pod
    - podSelector:
        matchLabels:
          role: frontend
    # 限制pod上哪些端口可以访问
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

必需字段：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 apiVersion、 kind 和 metadata 字段。
spec：NetworkPolicy 规约中包含了在一个命名空间中定义特定网络策略所需的所有信息。
spec.podSelector：每个 NetworkPolicy 都包括一个 podSelector，它对该策略所适用的一组 Pod 进行选择。示例中的策略选择带有 “role=db” 标签的 Pod。空的 podSelector 选择命名空间下的所有 Pod。
spec.policyTypes：每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。policyTypes 字段表示给定的策略是应用于进入所选 Pod 的入站流量还是来自所选 Pod 的出站流量，或两者兼有。如果 NetworkPolicy 未指定 policyTypes 则默认情况下始终设置 Ingress；如果 NetworkPolicy 有任何出口规则的话则设置 Egress。
spec.ingress：每个 NetworkPolicy 可包含一个 ingress 规则的白名单列表。每个规则都允许同时匹配 from 和 ports 部分的流量。示例策略中包含一条简单的规则：它匹配某个特定端口，来自三个来源中的一个：
- 第一个通过 ipBlock 指定
- 第二个通过 namespaceSelector 指定
- 第三个通过 podSelector 指定。
spec.egress：每个 NetworkPolicy 可包含一个 egress 规则的白名单列表。每个规则都允许匹配 to 和 port 部分的流量。该示例策略包含一条规则，该规则将指定端口上的流量匹配到 10.0.0.0/24 中的任何目的地。

to 和 from 选择器

可以在 ingress 的 from 部分或 egress 的 to 部分中指定四种选择器：

podSelector：此选择器将在与 NetworkPolicy 相同的命名空间中选择特定的 Pod，应将其允许作为入站流量来源或出站流量目的地。
namespaceSelector：此选择器将选择特定的命名空间，应将所有 Pod 用作其入站流量来源或出站流量目的地。
namespaceSelector 和 podSelector：指定 namespaceSelector 和 podSelector 的 to/from 条目选择特定命名空间中的特定 Pod。

示例：
```
  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
    - podSelector:
        matchLabels:
          role: client
  ...
```
在 from 数组中包含两个元素，允许来自本地命名空间中标有 role=client 的 Pod 的连接，或来自任何命名空间中标有 user=alice 的任何 Pod 的连接。
ipBlock：此选择器将选择特定的 IP CIDR 范围以用作入站流量来源或出站流量目的地。这些应该是集群外部 IP，因为 Pod IP 存在时间短暂的且随机产生。

集群的入站和出站机制通常需要重写数据包的源 IP 或目标 IP。在发生这种情况时，不确定在 NetworkPolicy 处理之前还是之后发生，并且对于网络插件、云提供商、Service 实现等的不同组合，其行为可能会有所不同。
- 对入站流量而言，这意味着在某些情况下，你可以根据实际的原始源 IP 过滤传入的数据包，而在其他情况下，NetworkPolicy 所作用的 源IP 则可能是 LoadBalancer 或 Pod 的节点等。
- 对于出站流量而言，这意味着从 Pod 到被重写为集群外部 IP 的 Service IP 的连接可能会或可能不会受到基于 ipBlock 的策略的约束。

实施网络策略

准备实验环境

环境说明：

namespace-web 中有3个 pod：web1、web2、test
namespace-laoma 中有1个pod：test
如没有特别说明，默认namespace是web

root@master30:~# kubectl create ns web
root@master30:~# kubens web

# 创建 web1
root@master30:~# kubectl run web1 --image=hub.laoma.cloud/library/nginx --image-pull-policy=IfNotPresent
root@master30:~# kubectl exec -it web1 -- bash -c 'echo Hello web1 > /usr/share/nginx/html/index.html'

# 创建 web2
root@master30:~# kubectl run web2 --image=hub.laoma.cloud/library/nginx --image-pull-policy=IfNotPresent
root@master30:~# kubectl exec -it web2 -- bash -c 'echo Hello web2 > /usr/share/nginx/html/index.html'

# 创建service web1和web2
root@master30:~# kubectl expose pod web1 --port=80 --target-port=80 --type=NodePort
root@master30:~# kubectl expose pod web2 --port=80 --target-port=80 --type=NodePort
root@master30:~# kubectl get service
NAME   TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
web1   NodePort   10.103.36.143    <none>        80:30790/TCP   11s
web2   NodePort   10.111.250.224   <none>        80:32686/TCP   7s

# 同一namespace中web1和web2互相访问
root@master30:~/network# kubectl run test --image=hub.laoma.cloud/library/busybox --image-pull-policy=IfNotPresent sleep 3600
root@master30:~/network# kubectl exec -it test -- sh
/ # wget web2.web -O web2-index.html
Connecting to web2.web (10.111.250.224:80)
web2-index.html      100% |*********************************************|    11   0:00:00 ETA
/ # cat web2-index.html 
Hello web2
/ # wget web1.web -O web1-index.html
Connecting to web1.web (10.103.36.143:80)
web1-index.html      100% |*********************************************|    11   0:00:00 ETA
/ # cat web1-index.html 
Hello web1
/ # exit

# 在不同namespace-laoma中创建测试pod-test，访问web1和web2
root@master30:~# kubectl create ns laoma
root@master30:~# kubectl run test -n laoma --image=hub.laoma.cloud/library/busybox --image-pull-policy=IfNotPresent sleep 3600
root@master30:~# kubectl exec -n laoma test -- wget web1.web -O /tmp/web1.html
root@master30:~# kubectl exec -n laoma test -- wget web2.web -O /tmp/web2.html

# 集群内访问service web1和web2
root@master30:~# curl 10.103.36.143
Hello web1
root@master30:~# curl 10.111.250.224
Hello web2

# 集群外节点访问web1和web2
root@client:~# curl http://10.1.8.30:30790
Hello web1
root@client:~# curl http://10.1.8.30:32686
Hello web2

根据 pod 标签限定

根据pod标签限定：

限定同一ns中pod之间访问
所有其他ns中pod或者集群外主机都无法访问ns中pod

示例1：允许同一ns中具有标签run: test的pod，访问具有标签run: web1的pod 80端口。

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          run: test
    ports:
    - protocol: TCP
      port: 80

# 创建network policy
root@master30:~# kubectl apply -f netpol.yaml
root@master30:~# kubectl get netpol
NAME                POD-SELECTOR   AGE
my-network-policy   run=web1       4s

# 同一namespace中test可以访问web1，web2不可以访问web1
root@master30:~# kubectl exec test -- sh -c 'rm index.html;wget web1'
Connecting to web1 (10.110.71.212:80)
saving to 'index.html'
index.html           100% |********************************|    11  0:00:00 ETA
'index.html' saved

# 修改现有标签
root@master30:~/network# kubectl label pod test run=web2 --overwrite
root@master30:~/network# kubectl get pods --show-labels 
NAME   READY   STATUS    RESTARTS   AGE    LABELS
test   1/1     Running   0          9m9s   run=web2
web1   1/1     Running   0          13m    run=web1
web2   1/1     Running   0          13m    run=web2

# 只能解析ip，但是流量无法到达目标pod
root@master30:~/network# kubectl exec test -- wget web1.web
Connecting to web1 (10.103.36.143:80)

# 不同 namespace 中pod，即使标签满足也不可以访问
root@master30:~# kubectl exec test -n laoma -- wget web1.web

示例2：允许同一namespace中所有pod访问具有标签run: web1的pod 80端口。

matchLabels中不使用任何标签，则允许同一ns中所有pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}
    # 或者将以上一行改为两行
    # - podSelector:
    #     matchLabels:
    ports:
    - protocol: TCP
      port: 80

# 应用策略
root@master30:~# kubectl apply -f netpol.yaml

# 同一namespace中所有pod都可以才访问web1
root@master30:~# kubectl exec test -- wget web1
Hello web1
root@master30:~# kubectl exec web2 -- curl web1
Hello web1

# 不同namespace中pod不可以访问web1
root@master30:~# kubectl exec test -n laoma -- wget web1.web

根据 pod 所属 ns 限定

用于限定，来源于其他namespace中pod。

示例1：允许具有标签project: myproject的namespace中所有pod，访问当前ns中具有标签run: web1的pod 80端口。

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: myproject
    ports:
    - protocol: TCP
      port: 80

# 应用策略
root@master30:~# kubectl apply -f netpol.yaml

# 此时namespace-web中pod和namespace-laoma中pod都无法访问web1
root@master30:~# kubectl exec test -- wget web1
root@master30:~# kubectl exec -n laoma test -- wget web1.web

# 给namespace-laoma添加标签project=myproject，此时namespace-laoma中pod可以访问web1.web
root@master30:~# kubectl label namespaces laoma project=myproject
root@master30:~# kubectl exec -n laoma test -- wget web1.web
Hello web1

示例2：允许所有namespace中所有pod，访问当前ns中具有标签run: web1的pod 80端口。

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 80

# 创建network policy
root@master30:~# kubectl apply -f netpol.yaml

# 所有namespace中所有pod都可以访问web1
root@master30:~# kubectl exec test -- wget web1
Hello web1
root@master30:~# kubectl exec -n laoma test -- wget web1.web

根据 pod IP 限定

示例1：允许网段172.17.0.0/16但不包括子网172.17.1.0/24中主机，访问具有标签run: web1的pod 80端口。

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        # 放行 网段10.1.8.0/24
        cidr: 10.1.8.0/24
        # 不放行网段
        except:
        - 10.1.8.128/26
    ports:
    - protocol: TCP
      port: 80

# 应用策略
root@master30:~# kubectl apply -f netpol.yaml

# 访问失败
root@master30:~# kubectl exec test -- wget web1
root@master30:~# kubectl exec -n laoma test -- wget web1.web

root@client:~# curl http://10.1.8.30:30251
root@client:~# curl http://10.1.8.31:30251
# 访问成功失败
root@client:~# curl http://10.1.8.32:30251
Hello web1

# 理论上：10.1.8.0/24网段中主机都可以通过集群任意节点访问web1
# 实际测试：只可以通过pod所在主机的IP访问web1 (10.1.8.32:30790)，不可以访问10.1.8.30:30790或10.1.8.31:30790

# 在worker31上也可以通过10.103.36.143访问pod-web1
root@master30:~# kubectl describe pod web1|grep Node:
Node:         worker32.laoma.cloud/10.1.8.32

从实验测试结果来看，根据网段控制来源还不完善。

如果想放行所有主机，阻止部分主机，规则如下：

    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.1.8.0/26

限定所有端口

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          run: test

# 应用策略
root@master30:~# kubectl apply -f netpol.yaml

root@master30:~# kubectl get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
test   1/1     Running   0          64m   10.224.193.70   worker32.laoma.cloud   <none>           <none>
web1   1/1     Running   0          82m   10.224.193.67   worker32.laoma.cloud   <none>           <none>
web2   1/1     Running   0          81m   10.224.41.132   worker31.laoma.cloud   <none>           <none>

# 此时满足条件的pod可以ping通pod地址
root@master30:~# kubectl run --rm -it ubuntu -l run=test --image ubuntu -- bash
root@ubuntu:/# apt update
root@ubuntu:/# apt install -y iputils-ping
root@ubuntu:/# ping -c1 10.224.193.67
PING 10.224.193.67 (10.224.193.67) 56(84) bytes of data.
64 bytes from 10.224.193.67: icmp_seq=1 ttl=62 time=0.831 ms

--- 10.224.193.67 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.831/0.831/0.831/0.000 ms

root@ubuntu:/# ping web1 -c1
PING web1.web.svc.cluster.local (10.96.144.145) 56(84) bytes of data.

--- web1.web.svc.cluster.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@ubuntu:/# exit

# 仍然 ping不通 service，因为service只开放80端口

限定端口范围

root@master30:~# vim netpol.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          run: test
    ports:
    - protocol: TCP
      port: 32000
      endPort: 32768

限定项目所有pod

设置podSelector: {}，则针对namespace中所有pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
......

多条件规则

只要有一个满足条件就可以访问pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: web
spec:
  podSelector:
    matchLabels:
      run: web1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.1.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          run: test
    ports:
    - protocol: TCP
      port: 80

# 创建network policy
root@master30:~# kubectl apply -f netpol.yaml

# namespace-web中pod-test可以访问web1
root@master30:~# kubectl exec test -- wget web1
Hello web1

默认策略

默认允许所有入站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - {}

默认拒绝所有入站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

此策略可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。此策略不会更改默认的出口隔离行为。

默认允许所有出站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - {}

默认拒绝所有出站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。此策略不会更改默认的入站流量隔离行为。

默认拒绝所有入口和所有出站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许入站或出站流量。

无法完成的工作

特定于节点的策略。
基于名字的策略。
实现适用于所有命名空间或 Pods 的默认策略。
显式地拒绝策略的能力。NetworkPolicy 的模型默认采用拒绝操作，其唯一的能力是添加允许策略。
**禁止本地回路或指向宿主的网络流量。**Pod 目前无法阻塞 localhost 访问，它们也无法禁止来自所在节点的访问请求）。

环境清理

root@master30:~# kubectl delete ns network web laoma
root@master30:~# kubectl delete ns web
root@master30:~# kubectl delete ns laoma

Kubernetes Pod Scheduler

学习参考：调度、抢占和驱逐

环境准备

root@master30:~# kubectl create ns scheduler
root@master30:~# kubectl config set-context --current --namespace scheduler

调度介绍

Kubernetes 调度是指将 Pod 放置到合适的节点上的过程。

kube-scheduler 是 Kubernetes 集群的默认调度器，通过监测（Watch）机制发现集群中未被调度到节点上的 Pod，并将这些未调度的 Pod 调度到一个合适的节点上来运行。

调度过程

Kube-scheduler 选择一个最佳节点来运行新创建的或尚未调度（unscheduled）的 Pod。由于 Pod 中的容器和 Pod 本身可能有不同的要求，调度程序会过滤掉任何不满足 Pod 特定调度需求的节点。

调度术语：

满足 Pod 调度请求的所有节点称之为 可调度节点。
调度器将 pod 调度到特定节点的这个过程叫做绑定。

Kubernetes 调度过程：

过滤，将满足 Pod 调度需求的所有节点选出来。 例如，PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下，这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。
打分，根据当前启用的打分规则，调度器会给每一个可调度节点进行打分，调度器将 Pod 调度到得分最高的节点上。 如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。

在做调度决定时需要考虑的因素包括：

单独和整体的资源请求
硬件/软件/策略限制
亲和以及反亲和要求
数据局部性
负载间的干扰
等等。

kubernetes 使用以下两种方式配置调度器的过滤和打分行为：

调度策略，配置过滤所用的 断言（Predicates） 和打分所用的 优先级（Priorities）。
调度配置，允许配置实现不同调度阶段的插件，包括：QueueSort、Filter、Score、Bind、Reserve、Permit 等等。

过滤

以下**断言（Predicates）**用于主机过滤：

PodFitsHostPorts：检查节点是否有空闲端口（网络协议类型）用于 Pod 请求的 Pod 端口。
PodFitsHost：检查 Pod 是否通过其主机名指定特定节点。
PodFitsResources: 检查 Node 是否有空闲资源（例如 CPU 和内存）来满足 Pod 的要求。
MatchNodeSelector: 检查 Pod 的 Node Selector匹配节点的标签.
NoVolumeZoneConflict: 评估是否卷考虑到该存储的故障区域限制，Pod 请求在节点上可用。
NoDiskConflict：评估 Pod 是否可以根据它请求的卷以及已经挂载的卷安装在节点上。
MaxCSIVolumeCount: 决定多少 CSI 应附加卷，以及是否超过配置的限制。
PodToleratesNodeTaints: 检查Pod 的 toleration 可以容忍节点的 taints。
CheckVolumeBinding：评估 Pod 是否因它请求的卷而适合。这适用于绑定和未绑定 PVCs.

计分

以下 **优先级 **Priorities 用于主机评分：

SelectorSpreadPriority: 跨主机传播 Pod，考虑属于相同的 Pod 服务, 状态集或者副本集。
InterPodAffinityPriority：实现首选的 pod 间亲和性和反亲和性。
LeastRequestedPriority：支持请求资源较少的节点。换句话说，节点上放置的 Pod 越多，这些 Pod 使用的资源越多，该策略给出的排名就越低。
MostRequestedPriority：支持请求资源最多的节点。此策略将使计划的 Pod 适合运行整个工作负载集所需的最少数量的节点。
RequestedToCapacityRatioPriority：使用默认资源评分函数形状创建基于 requestsToCapacity 的 ResourceAllocationPriority。
BalancedResourceAllocation：支持资源使用均衡的节点。
NodePreferAvoidPodsPriority：根据节点注释对节点进行优先级排序 scheduler.alpha.kubernetes.io/preferAvoidPods。您可以使用它来暗示两个不同的 Pod 不应在同一个节点上运行。
NodeAffinityPriority：根据PreferredDuringSchedulingIgnoredDuringExecution 中指示的节点关联性调度首选项对节点进行优先级排序。您可以在将 Pod 分配给节点中阅读更多相关信息。
TaintTolerationPriority：根据节点上不可容忍污点的数量，为所有节点准备优先级列表。此策略会在考虑该列表的情况下调整节点的等级。
ImageLocalityPriority: 优先选择已经拥有容器镜像对于本地缓存的 Pod。
ServiceSpreadingPriority：对于给定的 Service，此策略旨在确保 Service 的 Pod 运行在不同的节点上。它倾向于调度到没有已分配服务的 Pod 的节点上。总体结果是服务对单个节点故障变得更有弹性。
EqualPriority：给所有节点一个相等的权重。
EvenPodsSpreadPriority：实现首选 pod 拓扑扩展约束。

控制 pod 运行位置

参考学习：将 Pod 指派给节点

你可以约束一个 Pod 只能在特定的节点上运行。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，而不是将 Pod 放置在可用资源不足的节点上等等）。不过有些情况我们希望将Pod部署到指定的Node，比如将有大量磁盘I/O的Pod部署到配置了SSD的Node；或者Pod需要GPU，需要运行在配置了GPU的节点上。

你可以使用下列方法中的任何一种来选择 Kubernetes 对特定 Pod 的调度：

nodeName

nodeName 是 PodSpec 的一个字段，其值是节点名称，调度器将Pod调度到给定节点上运行。

nodeName 是节点选择约束的最简单方法，也是优先级最高的方法，通常不使用。

使用 nodeName 选择节点的一些限制：

如果指定的节点不存在，Pod 将不会运行，甚至会被自动删除。
如果指定的节点没有资源来容纳 Pod，Pod 将会调度失败，并且显示实际原因。

例如：OutOfmemory 或 OutOfcpu。
云环境中的节点名称并非总是可预测或稳定的。

示例：

root@master30:~# kubectl create deployment webapp --image nginx --replicas 5 -o yaml --dry-run=client > deploy-webapp.yaml
root@master30:~# vim deploy-webapp.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: webapp
  name: webapp
spec:
  replicas: 5
  selector:
    matchLabels:
      app: webapp
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: webapp
    spec:
      # 添加nodeName配置
      nodeName: worker32.laoma.cloud
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

root@master30:~# kubectl apply -f deploy-webapp.yam
root@master30:~# kubectl get pods -o wide | awk '{print $1,$7}'
NAME NODE
webapp-55c6b896bc-kdrcp worker32.laoma.cloud
webapp-55c6b896bc-l6kpt worker32.laoma.cloud
webapp-55c6b896bc-l8pld worker32.laoma.cloud
webapp-55c6b896bc-qrzqt worker32.laoma.cloud
webapp-55c6b896bc-tdr5h worker32.laoma.cloud

nodeSelector

nodeSelector 是 PodSpec 的一个字段。它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中必须包含这里的每个键值对（它也可以具有其他标签）。

**最常见的用法的是使用label。**label是key-value对，各种资源都可以设置label，灵活添加各种自定义属性。

提示：nodeSelector 是节点选择约束的推荐形式。

# 查看node标签
root@master30:~# kubectl get node --show-labels 
NAME                  STATUS   ROLES           AGE    VERSION   LABELS
master30.laoma.cloud   Ready    control-plane   7d8h   v1.30.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master30.laoma.cloud,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=
worker31.laoma.cloud   Ready    <none>          7d8h   v1.30.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker31.laoma.cloud,kubernetes.io/os=linux
worker32.laoma.cloud   Ready    <none>          7d8h   v1.30.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker32.laoma.cloud,kubernetes.io/os=linux

# 标注worker31 disktype是ssd
root@master30:~# kubectl label node worker31.laoma.cloud disktype=ssd
root@master30:~# kubectl get node -L disktype
NAME                   STATUS   ROLES           AGE   VERSION   DISKTYPE
master30.laoma.cloud   Ready    control-plane   11d   v1.30.2   
worker31.laoma.cloud   Ready    <none>          11d   v1.30.2   ssd
worker32.laoma.cloud   Ready    <none>          11d   v1.30.2

在Pod模板的spec里通过nodeSelector指定将此Pod部署到具有label为 disktype=ssd 的Node上。

root@master30:~# vim deploy-webapp.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webapp
  name: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      # 添加 nodeSelector
      nodeSelector:
        disktype: ssd
      containers:
      - image: nginx
        name: nginx

root@master30:~# kubectl apply -f deploy-webapp.yaml
root@master30:~# kubectl get pods -o wide | awk '{print $1,$7}'
NAME NODE
webapp-7d675f9d9c-gm824 worker31.laoma.cloud
webapp-7d675f9d9c-rxds2 worker31.laoma.cloud
webapp-7d675f9d9c-v7b6c worker31.laoma.cloud

# 删除worker31标签，并不会在新的node上部署pod
root@master30:~# kubectl label node worker31.laoma.cloud disktype-
root@master30:~# kubectl get node -L disktype
NAME                   STATUS   ROLES           AGE   VERSION   DISKTYPE
master30.laoma.cloud   Ready    control-plane   11d   v1.30.2   
worker31.laoma.cloud   Ready    <none>          11d   v1.30.2   
worker32.laoma.cloud   Ready    <none>          11d   v1.30.2   

# 删除模版中nodeSelector属性，会自动触发重新部署。

Affinity and AntiAffinity

亲和性功能包含两种类型的亲和性，即“节点亲和性”和“Pod 间亲和性/反亲和性”。

nodeAffinity

概念上节点亲和性类似于 nodeSelector，它使你可以根据节点上的标签来约束 Pod 可以调度到哪些节点。

节点亲和性有两种：

requiredDuringSchedulingIgnoredDuringExecution ，指定必须将 Pod 调度到满足规则的节点上，就像 nodeSelector 。
preferredDuringSchedulingIgnoredDuringExecution，指定优先将 Pod 调度到满足规则的节点上，但不会强制执行调度。

注意：如果节点的标签在运行时发生变更，那么 Pod 将仍然继续在该节点上运行。

使用 Pod 规约中的 .spec.affinity.nodeAffinity 字段来设置节点亲和性。

示例：

root@master30:~# vim deploy-nodeaffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: CPU
                operator: In
                values:
                - L1
                - L2
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: MEM
                operator: In
                values:
                - L1
                - L2
      containers:
      - image: hub.laoma.cloud/library/nginx
        name: nginx

示例说明：

此节点亲和性规则表示：Pod 只能放置在具有标签键 CPU 且标签值为 L1 或 L2 的节点上。另外，在满足这些标准的节点中，具有标签键为 MEM 且标签值为 L1 或 L2 的节点应该优先使用。
preferredDuringSchedulingIgnoredDuringExecution 中的 weight 字段值的范围是 1-100。对于每个符合所有调度要求（资源请求、RequiredDuringScheduling 亲和性表达式等）的节点，调度器将遍历该字段的元素来计算总和，并且如果节点匹配对应的 MatchExpressions，则添加“权重”到总和。然后将这个评分与该节点的其他优先级函数的评分进行组合。总分最高的节点是最优选的。
你可以使用 operator 字段来为 Kubernetes 设置在解释规则时要使用的逻辑操作符。operator（操作符）支持： In，NotIn，Exists，DoesNotExist，Gt，Lt。
你可以使用 NotIn 和 DoesNotExist 来实现节点反亲和性行为，或者使用节点污点将 Pod 从特定节点中驱逐。
如果你同时指定了 nodeSelector 和 nodeAffinity，两者必须都要满足，才能将 Pod 调度到候选节点上。
如果你指定了多个与 nodeAffinity 类型关联的 nodeSelectorTerms，则 如果其中一个 nodeSelectorTerms 满足的话，pod将可以调度到节点上。
如果你指定了多个与 nodeSelectorTerms 关联的 matchExpressions，则 只有当所有 matchExpressions 满足的话，Pod 才会可以调度到节点上。

如果你修改或删除了 pod 所调度到的节点的标签，Pod 不会被删除。 换句话说，亲和性选择只在 Pod 调度期间有效。

验证1：节点未打标签

root@master30:~# kubectl apply -f deploy-nodeaffinity.yaml
root@master30:~# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
web-8496b6959f-gphmk   0/1     Pending   0          3s
web-8496b6959f-rfc5h   0/1     Pending   0          3s

验证2：节点打标签CPU

root@master30:~# kubectl label nodes worker31.laoma.cloud CPU=L1
root@master30:~# kubectl label nodes worker32.laoma.cloud CPU=L2


root@master30:~# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
web-8496b6959f-gphmk   1/1     Running   0          13s
web-8496b6959f-rfc5h   1/1     Running   0          13s

# 节点平均分布
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
web-8496b6959f-4lfb8 Running worker32.laoma.cloud
web-8496b6959f-qhfmv Running worker31.laoma.cloud

验证3：worker32节点打标签MEM

root@master30:~# kubectl label nodes worker32.laoma.cloud MEM=L2

# 重新部署
root@master30:~# kubectl rollout restart deployments.apps web

# 只在worker32上运行
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
web-8496b6959f-dwcbl ContainerCreating worker32.laoma.cloud
web-8496b6959f-t4r5b ContainerCreating worker32.laoma.cloud

清理环境

root@master30:~# kubectl delete deployments.apps web
root@master30:~# kubectl label nodes worker31.laoma.cloud CPU-
root@master30:~# kubectl label nodes worker32.laoma.cloud CPU-
root@master30:~# kubectl label nodes worker32.laoma.cloud MEM-

节点亲和性权重

用户可以为 preferredDuringSchedulingIgnoredDuringExecution 亲和性类型的每个实例设置 weight 字段，其取值范围是 1 到 100。当调度器找到能够满足 Pod 的其他调度请求的节点时，调度器会遍历节点满足的所有的偏好性规则，并将对应表达式的 weight 值加和。

最终的加和值会添加到该节点的其他优先级函数的评分之上。在调度器为 Pod 作出调度决定时，总分最高的节点的优先级也最高。

例如，考虑下面的 Pod 规约：

apiVersion: v1
kind: Pod
metadata:
  name: with-affinity-anti-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2
  containers:
  - name: with-node-affinity
    image: hub.laoma.cloud/library/nginx

如果存在两个候选节点，都满足 preferredDuringSchedulingIgnoredDuringExecution 规则，其中一个节点具有标签 label-1: key-1，另一个节点具有标签 label-2: key-2，调度器会考察各个节点的 weight 取值，并将该权重值添加到节点的其他得分值之上。

Inter-pod affinity and anti-affinity

Pod 间 亲和性 和 反亲和性 提供基于已经在节点上运行的 Pod 的标签来约束 Pod 可以调度到的节点，而不是基于节点上的标签。

Pod 间亲和性与反亲和性规则的格式为，如果 X 节点上已经运行了一个或多个满足规则 Y 的 Pod：

在亲和性的情况下，Pod 应该运行在 X 节点。
在反亲和性的情况下，Pod 不应该运行在 X 节点。

说明：

这里的 X 可以是节点、机架、云提供商可用区或地理区域或类似的拓扑域。你可以使用 topologyKey 来表示它，topologyKey 是节点标签的键以便系统用来表示这样的拓扑域。
Y 则是 Kubernetes 尝试满足的规则，通过标签选择算符的形式来表达规则（Y）。

注意：

Pod 间亲和性与反亲和性会消耗大量计算资源，可能会显著减慢大规模集群中的调度。我们不建议在超过数百个节点的集群中使用它们。
Pod 反亲和性需要对节点进行一致的标记，即集群中的每个节点必须具有适当的标签匹配 topologyKey。如果某些或所有节点缺少指定的 topologyKey 标签，可能会导致意外行为。

Pod 间亲和性与反亲和性的类型

requiredDuringSchedulingIgnoredDuringExecution，例如将两个通信非常频繁的 Pod 调度到同一个可用区内。
preferredDuringSchedulingIgnoredDuringExecution，例如将同一服务的多个 Pod 调度到不同可用区中。

使用 Pod 规约中的 .affinity.podAffinity 字段设置Pod 间亲和性。

使用 Pod 规约中的 .affinity.podAntiAffinity 字段设置Pod 间反亲和性。

语法说明

本示例定义了一条 Pod 亲和性规则和一条 Pod 反亲和性规则。

root@master30:~# vim pod-with-podaffinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-podaffinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: pod-with-podaffinity
    image: docker.io/library/nginx

亲和性规则规定，只有节点属于特定的区域且该区域中的其他 Pod 已打上 security=S1 标签时，调度器才可以将示例 Pod 调度到此节点上。例如，如果我们有一个具有指定区域（称之为 “Zone V”）的集群，此区域由带有 topology.kubernetes.io/zone=V 标签的节点组成，那么只要 Zone V 内已经至少有一个 Pod 打了 security=S1 标签， **调度器就可以将此 Pod 调度到 Zone V 内的任何节点。**相反，如果 Zone V 中没有带有 security=S1 标签的 Pod，则调度器不会将示例 Pod 调度给该区域中的任何节点。
反亲和性规则规定，如果节点属于特定的区域且该区域中的其他 Pod 已打上 security=S2 标签，则调度器应尝试避免将 Pod 调度到此节点上。例如，如果我们有一个具有指定区域（我们称之为 “Zone R”）的集群，此区域由带有 topology.kubernetes.io/zone=R 标签的节点组成，只要 Zone R 内已经至少有一个 Pod 打了 security=S2 标签，调度器应避免将 Pod 分配给 Zone R 内的任何节点。相反，如果 Zone R 中没有带有 security=S2 标签的 Pod，则反亲和性规则不会影响将 Pod 调度到 Zone R。

补充说明：

Pod 亲和性与反亲和性的合法操作符有 In，NotIn，Exists，DoesNotExist。
原则上，topologyKey 可以是任何合法的标签键。出于性能和安全考虑，topologyKey 受到一些限制：
1. 对于 Pod 亲和性而言，在 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 中，topologyKey 不允许为空。
2. 对于 Pod 反亲和性而言，requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 中，topologyKey 不允许为空。
3. 除上述情况外，topologyKey 可以是任何合法的标签键。

示例 1：根据节点拓扑–亲和性调度

# node节点打标签
root@master30:~# kubectl label node worker31.laoma.cloud \
topology.kubernetes.io/zone=v
root@master30:~# kubectl label node worker32.laoma.cloud \
topology.kubernetes.io/zone=v

# 创建两个pod
root@master30:~# vim pod-with-podaffinity.yaml

---
apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: docker.io/library/nginx
    imagePullPolicy: IfNotPresent
  nodeName: worker31.laoma.cloud
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-podaffinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - web
        topologyKey: topology.kubernetes.io/zone
  containers:
  - name: web
    image: docker.io/library/nginx

root@master30:~# kubectl apply -f pod-with-podaffinity.yaml 
root@master30:~# kubectl describe pod pod-with-podaffinity |grep Node:
Node:             worker32.laoma.cloud/10.1.8.32

**实验结果：**pod-with-podaffinity 调度到 worker32节点。

如果此时将work32节点的 topology.kubernetes.io/zone 标签删除，重新创建pod pod-with-podaffinity，会调度到哪个节点呢?

root@master30:~# kubectl delete -f pod-with-podaffinity.yaml --force
root@master30:~# kubectl label nodes worker32.laoma.cloud \
topology.kubernetes.io/zone-
root@master30:~# kubectl apply -f pod-with-podaffinity.yaml 

root@master30:~# kubectl describe pod pod-with-podaffinity |grep Node:
Node:             worker31.laoma.cloud/10.1.8.31

# 清理环境
root@master30:~# kubectl delete -f pod-with-podaffinity.yaml
root@master30:~# kubectl label nodes worker31.laoma.cloud \
topology.kubernetes.io/zone-

**结论：**pod 亲和性调度必须满足两个条件。

node 必须具有相应标签。这些node根据标签定义，既可以属于同一个机架，也可以属于同一个房间等物理区域。
在具有相应标签的 node上至少运行一个具有相应标签的pod。

Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSets、StatefulSets、 Deployments 等）一起使用时，更加有用。可以轻松配置一组应位于相同定义拓扑（例如，节点）中的工作负载。

示例 2：根据节点主机名–反亲和性调度

下面是一个简单 redis Deployment 的 YAML 代码段，它有三个副本和选择器标签 app=store。 Deployment 配置了 PodAntiAffinity，用来确保调度器不会将多个副本调度到单个节点上。

# 准备deployment
root@master30:~# vim deploy-with-podAntiAffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: store
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-server
        image: docker.io/library/nginx

# 查看pod调度情况
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
store-5596cf4c84-9z5ch Pending <none>
store-5596cf4c84-dswkq Running worker32.laoma.cloud
store-5596cf4c84-ww2l4 Running worker31.laoma.cloud

结果：在 topologyKey: "kubernetes.io/hostname作用下，**每个节点只能运行一个pod。**因为每个节点的hostname都是自己的主机名，是唯一的。最后一个pod，找不到可用节点。

示例 3：多个应用亲和性和反亲和性调度

下面 webserver Deployment 的 YAML 代码段中配置了 podAntiAffinity 和 podAffinity，确保每个 web 服务器副本不会调度到单个节点上，同时所有副本与具有 app=store 选择器标签的 Pod 放置在一起。

# 缩容 deployment
root@master30:~# kubectl scale deployment store --replicas 1
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
store-5596cf4c84-dswkq Running worker32.laoma.cloud

# 准备新deployment
root@master30:~# vim deploy-with-multi-Affinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-store
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 1
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: docker.io/library/nginx

root@master30:~# kubectl apply -f deploy-with-multi-Affinity.yaml
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
store-5596cf4c84-f4dfb Running worker32.laoma.cloud
web-store-7b4779c958-vpl58 Running worker32.laoma.cloud

# 扩容：验证新副本位置
root@master30:~# kubectl get pods -o wide --no-headers |awk '{print $1,$3,$7}'
store-5596cf4c84-f4dfb Running worker32.laoma.cloud
web-store-7b4779c958-bswws Pending <none>
web-store-7b4779c958-vpl58 Running worker32.laoma.cloud
# 在亲和性作用下，只有worker32节点具备满足条件的pod
# 在反亲和性作用下，worker32节点上已经运行了一个副本
# 最终结果：第二个 pod 调度 挂起。

Taint 和 Toleration

学习参考：污点和容忍度

node 使用 Taint（污点），允许特定Pod在本机运行，未匹配的Pod则不能在该节点运行。
pod 使用 Toleration（容忍度），允许被调度到带有与之匹配的污点的节点上。

污点和容忍度相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。

思考：nodeAffinity 和 Taint 区别？

nodeAffinity，Pod 选 Node 的必要条件。
Taint，Node 选 Pod 的必要条件。

两者关系就像男女相亲。例如:

女选男，首选挣钱多多，类似于 nodeAffinity；长得丑没关系，类似于Taint。
男选女，首选长的漂亮，类似于 nodeAffinity；挣钱少没关系，类似于Taint。

设置 Node Taints

使用命令 kubectl taint 给节点增加一个污点。

示例：给节点 worker31.laoma.cloud 增加一个污点，键名 CPU，键值 L1，效果 NoSchedule。

root@master30:~# kubectl taint nodes worker31.laoma.cloud \
CPU=L1:NoSchedule

表示拥有和这个污点相匹配的tolerations的 Pod 才能够被分配到 worker31.laoma.cloud 这个节点。

若要移除worker污点，执行以下命令：

root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU:NoSchedule-

设置 Pod tolerations

在 Pod.Spec 中定义 Pod 的 tolerations。

示例：

tolerations:
- key: "CPU"
  operator: "Equal"
  value: "L1"
  effect: "NoSchedule"

operator 可选值：

Equal，默认值，容忍度和污点的键值对相同，则“匹配”。
Exists，此时容忍度不能指定 value，只要污点中存在 key ，则容忍度和污点相“匹配”。
```
  tolerations:
  - key: "CPU"
    operator: "Exists"
    effect: "NoSchedule"
```

effect 可选值：

NoSchedule，除非具有匹配的容忍度规约，否则新的 Pod 不会被调度到带有污点的节点上。当前正在节点上运行的 Pod 不会被驱逐。
PreferNoSchedule，是“偏好”或“软性”的 NoSchedule。控制平面将尝试避免将不能容忍污点的 Pod 调度到的节点上，但不能保证完全避免。
NoExecute 影响已在节点上运行的 Pod，具体影响如下：
- 如果 Pod 不能容忍这类污点，会马上被驱逐。
- 如果 Pod 能够容忍这类污点，但是在容忍度定义中没有指定 tolerationSeconds，则 Pod 还会一直在这个节点上运行。
- 如果 Pod 能够容忍这类污点，而且指定了 tolerationSeconds，则 Pod 还能在这个节点上继续运行这个指定的时间长度。这段时间过去后，节点生命周期控制器从节点驱除这些 Pod。
- 如果 Pod 还未在节点上运行，系统不会将 Pod 分配到该节点。
空，则可以与所有键名 CPU 的效果相匹配。

**注意：**如果容忍度的 key 为空且 operator 为 Exists，表示这个容忍度与任意的 key 、value 和 effect 都匹配，即这个容忍度能容忍任意 taint。

一个容忍度和一个污点匹配

示例：

设置 node 污点：

root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoSchedule
root@master30:~# kubectl taint nodes worker32.laoma.cloud CPU=L2:NoSchedule

创建 pod ：

root@master30:~# vim deploy-with-tolerations.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      tolerations:
      - key: "CPU"
        operator: "Equal"
        value: "L3"
        effect: "NoSchedule"
      containers:
      - name: nginx
        image: hub.laoma.cloud/library/nginx
        imagePullPolicy: IfNotPresent

# 创建上述pod示例
root@master30:~# kubectl apply -f deploy-with-tolerations.yaml
root@master30:~# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
web-5bf7b7b98f-kh7hv   0/1     Pending   0          2s
web-5bf7b7b98f-km7w5   0/1     Pending   0          2s
# pod状态为Pending

# 事件表明3个节点上的污点与pod不匹配，所以无法创建pod
root@master30:~# kubectl describe pod web-5bf7b7b98f-kh7hv
......
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  29s   default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {CPU: L1}, 1 node(s) had untolerated taint {CPU: L2}, 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.


# 删除 deployments，将容忍度改为CPU=L1
root@master30:~# kubectl delete deployments.apps web
root@master30:~# vim deploy-with-tolerations.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      tolerations:
      - key: "CPU"
        operator: "Equal"
        value: "L1"
        effect: "NoSchedule"
      containers:
      - name: nginx
        image: hub.laoma.cloud/library/nginx
        imagePullPolicy: IfNotPresent

root@master30:~# kubectl apply -f deploy-with-tolerations.yaml
root@master30:~# kubectl get pods -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP               NODE                   NOMINATED NODE   READINESS GATES
web-7c99d767-w9rzt   1/1     Running   0          5s    10.224.162.142   worker31.laoma.cloud   <none>           <none>
web-7c99d767-wwjhk   1/1     Running   0          5s    10.224.19.13     worker31.laoma.cloud   <none>           <none>

# Pod调度成功，而且分配到了worker31

# 清理环境
root@master30:~# kubectl taint node worker31.laoma.cloud CPU:NoSchedule-
root@master30:~# kubectl taint node worker32.laoma.cloud CPU:NoSchedule-
root@master30:~# kubectl delete deployments.apps web

多个容忍度和多个污点匹配

Kubernetes 可以给一个节点添加多个污点，也可以给一个 Pod 添加多个容忍度设置。

Kubernetes 处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历，过滤掉那些 Pod 中存在与之相匹配的容忍度的污点。余下未被过滤的污点的 effect 值决定了 Pod 是否会被分配到该节点，特别是以下情况：

如果未被过滤的污点中存在至少一个 effect 值为 NoSchedule 的污点，则 Kubernetes 不会将 Pod 分配到该节点。
如果未被过滤的污点中不存在 effect 值为 NoSchedule 的污点，但存在 effect 值为 PreferNoSchedule 的污点，则 Kubernetes 尝试不将 Pod 分配到该节点。
如果未被过滤的污点中存在至少一个 effect 值为 NoExecute 的污点，则 Kubernetes 不会将 Pod 分配到该节点（如果 Pod 还未在节点上运行），或者将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。

例如，某个节点添加了如下污点：

root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoSchedule
root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoExecute
root@master30:~# kubectl taint nodes worker31.laoma.cloud MEM=L2:NoSchedule

假定某个 Pod 有两个容忍度：

tolerations:
- key: "CPU"
  operator: "Equal"
  value: "L1"
  effect: "NoSchedule"
- key: "CPU"
  operator: "Equal"
  value: "L1"
  effect: "NoExecute"

在这种情况下，上述 Pod 不会被调度到上述节点，因为其没有容忍度和第三个污点相匹配。但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行，那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。

示例：

设置 node 多个污点

root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoSchedule
root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoExecute
root@master30:~# kubectl taint nodes worker31.laoma.cloud MEM=L2:NoSchedule
root@master30:~# kubectl taint nodes worker32.laoma.cloud CPU=L2:NoSchedule

创建 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      tolerations:
      - key: "CPU"
        operator: "Equal"
        value: "L1"
        effect: "NoSchedule"
      - key: "CPU"
        operator: "Equal"
        value: "L1"
        effect: "NoExecute"
      containers:
      - name: nginx
        image: hub.laoma.cloud/library/nginx
        imagePullPolicy: IfNotPresent

# 创建上述pod示例
root@master30:~# kubectl apply -f deploy-with-tolerations.yaml
root@master30:~# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
web-6844d698c4-b8cz7   0/1     Pending   0          4s
web-6844d698c4-wrpkj   0/1     Pending   0          4s
# pod状态为Pending

# 事件表明节点上的3个污点与pod不匹配，所以无法创建pod
root@master30:~# kubectl describe pod web-6844d698c4-b8cz7 
......
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  50s   default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {CPU: L2}, 1 node(s) had untolerated taint {MEM: L2}, 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

# 删除deployments，添加容忍度MEM=L2
root@master30:~# kubectl delete deployments.apps web
root@master30:~# vim deploy-with-tolerations.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      tolerations:
      - key: "CPU"
        operator: "Equal"
        value: "L1"
        effect: "NoSchedule"
      - key: "CPU"
        operator: "Equal"
        value: "L1"
        effect: "NoExecute"
      - key: "MEM"
        operator: "Equal"
        value: "L2"
        effect: "NoSchedule"
      containers:
      - name: nginx
        image: hub.laoma.cloud/library/nginx
        imagePullPolicy: IfNotPresent

root@master30:~# kubectl apply -f deploy-with-tolerations.yaml
root@master30:~# kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP             NODE                   NOMINATED NODE   READINESS GATES
web-77d5464ccf-656fd   1/1     Running   0          5s    10.224.19.18   worker31.laoma.cloud   <none>           <none>
web-77d5464ccf-wjk6m   1/1     Running   0          5s    10.224.19.27   worker31.laoma.cloud   <none>           <none>
# Pod 调度成功，而且分配到了worker31

# 清理环境
root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoSchedule-
root@master30:~# kubectl taint nodes worker31.laoma.cloud CPU=L1:NoExecute-
root@master30:~# kubectl taint nodes worker31.laoma.cloud MEM=L2:NoSchedule-
root@master30:~# kubectl taint nodes worker32.laoma.cloud CPU=L2:NoSchedule-
root@master30:~# kubectl delete deployments.apps web

Taint 和 Toleration 用例

通过污点和容忍度，可以灵活地让 Pod 避开某些节点或者将 Pod 从某些节点驱逐。

下面是几个使用例子：

用户专用节点：如果想将某些节点专门分配给特定的一组用户使用，可以给这些节点添加一个污点，例如 dedicated=groupName:NoSchedule 。然后给这组用户的 Pod 添加一个相对应的 toleration。拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。

如果希望这些 Pod 只能被分配到上述专用节点，那么还需要给这些专用节点添加一个和上述污点类似的 label ，例如 dedicated=groupName ，同时还要给 Pod 增加节点亲和性，要求上述 Pod 只能被分配到添加了 dedicated=groupName 标签的节点上。
配备了特殊硬件的节点：在部分节点配备了特殊硬件（比如 GPU）的集群中，我们希望不需要这类硬件的 Pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。要达到这个目的，可以先给配备了特殊硬件的节点添加 taint ，例如 special=true:NoSchedule，然后给使用这类特殊硬件的 Pod 添加一个相匹配的 toleration。

基于污点的驱逐

前文提到过污点 effect 值 NoExecute 会影响已经在节点上运行的 Pod：

如果 Pod 不能忍受 effect 值为 NoExecute 的污点，那么 Pod 将马上被驱逐。
如果 Pod 能够忍受 effect 值为 NoExecute 的污点，但是在容忍度定义中没有指定 tolerationSeconds，则 Pod 还会一直在这个节点上运行。
如果 Pod 能够忍受 effect 值为 NoExecute 的污点，而且指定了 tolerationSeconds，则 Pod 还能在这个节点上继续运行这个指定的时间长度。

当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括：

node.kubernetes.io/not-ready：节点未准备好。这相当于节点状态 Ready 的值为 “False”。
node.kubernetes.io/unreachable：节点控制器访问不到节点. 这相当于节点状态 Ready 的值为 “Unknown”。
node.kubernetes.io/memory-pressure：节点存在内存压力。
node.kubernetes.io/disk-pressure：节点存在磁盘压力。
node.kubernetes.io/pid-pressure: 节点的 PID 压力。
node.kubernetes.io/network-unavailable：节点网络不可用。
node.kubernetes.io/unschedulable: 节点不可调度。
node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 启动时指定了一个 “外部” 云平台驱动，它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。

节点被驱逐时，节点控制器或者 kubelet 会添加带有 NoExecute 效应的相关污点。如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。

说明： 为了保证由于节点问题引起的 Pod 驱逐速率限制行为正常，系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下，这样做可以避免 Pod 被大量驱逐。

使用这个功能特性，结合 tolerationSeconds，Pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。

比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间，愿意等待网络恢复以避免被驱逐。在这种情况下，Pod 的容忍度可能是下面这样的：

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

说明：

Kubernetes 会自动给 Pod 添加一个 key 为 node.kubernetes.io/not-ready 的容忍度，并配置 tolerationSeconds=300，除非用户提供的 Pod 配置中已经已存在了 key 为 node.kubernetes.io/not-ready 的容忍度。

同样，Kubernetes 会给 Pod 添加一个 key 为 node.kubernetes.io/unreachable 的容忍度并配置 tolerationSeconds=300，除非用户提供的 Pod 配置中已经已存在了 key 为 node.kubernetes.io/unreachable 的容忍度。

这种自动添加的容忍度意味着在其中一种问题被检测到时 Pod 默认能够继续停留在当前节点运行 5 分钟。

DaemonSet 中的 Pod 被创建时，针对以下污点自动添加的 NoExecute 的容忍度将不会指定 tolerationSeconds：

node.kubernetes.io/unreachable
node.kubernetes.io/not-ready

这保证了出现上述问题时 DaemonSet 中的 Pod 永远不会被驱逐。

cordon 和 uncordon

kubectl cordon 命令，标记node为不可调度，将无法在node上创建新的pod。

root@master30:~# kubectl cordon -h
Mark node as unschedulable.

Usage:
  kubectl cordon NODE [options]

root@master30:~# kubectl get nodes
NAME                  STATUS   ROLES           AGE   VERSION
master30.laoma.cloud   Ready    control-plane   9d    v1.30.2
worker31.laoma.cloud   Ready    <none>          9d    v1.30.2
worker32.laoma.cloud   Ready    <none>          9d    v1.30.2

# 标记worker31.laoma.cloud为SchedulingDisabled
root@master30:~# kubectl cordon worker31.laoma.cloud 
root@master30:~# kubectl get nodes
NAME                  STATUS                     ROLES           AGE   VERSION
master30.laoma.cloud   Ready                      control-plane   9d    v1.30.2
worker31.laoma.cloud   Ready,SchedulingDisabled   <none>          9d    v1.30.2
worker32.laoma.cloud   Ready                      <none>          9d    v1.30.2


# 创建一个deployment
root@master30:~# kubectl create deployment web --image=hub.laoma.cloud/library/nginx --replicas=2
root@master30:~# kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP              NODE               NOMINATED NODE   READINESS GATES
web-59b9bb7664-flhvx   1/1     Running   0          10s   10.224.225.69   worker32.laoma.cloud   <none>           <none>
web-59b9bb7664-ss586   1/1     Running   0          10s   10.224.225.68   worker32.laoma.cloud   <none>           <none>

# 取消worker31.laoma.cloud标记SchedulingDisabled
root@master30:~# kubectl uncordon worker31.laoma.cloud 
root@master30:~# kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
master.laoma.cloud   Ready    control-plane   36d   v1.30.2
worker31.laoma.cloud    Ready    <none>   36d   v1.30.2
worker32.laoma.cloud    Ready    <none>   36d   v1.30.2

root@master30:~# kubectl scale deployment web --replicas=4
root@master30:~# kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE    IP              NODE               NOMINATED NODE   READINESS GATES
web-59b9bb7664-flhvx   1/1     Running   0          2m6s   10.224.225.69   worker32.laoma.cloud   <none>           <none>
web-59b9bb7664-jkb5q   1/1     Running   0          5s     10.224.51.133   worker31.laoma.cloud   <none>           <none>
web-59b9bb7664-ss586   1/1     Running   0          2m6s   10.224.225.68   worker32.laoma.cloud   <none>           <none>
web-59b9bb7664-w6mbs   1/1     Running   0          5s     10.224.51.132   worker31.laoma.cloud   <none>           <none>

drain

学习参考：安全地清空一个节点

在对节点执行维护（例如内核升级、硬件维护等）之前，可以使用 kubectl drain 从节点安全地逐出所有 Pod。安全的驱逐过程允许 Pod 的容器体面地终止，并确保满足指定的 PodDisruptionBudgets。

准备开始

此任务假定你已经满足了以下先决条件：

在节点清空期间，确保应用具有高可用性。
你已经了解了 PodDisruptionBudget 的概念，并为需要它的应用配置了 PodDisruptionBudget。

为了确保负载在维护期间仍然可用，可以配置一个 PodDisruptionBudget。如果可用性对于正在清空的该节点上运行或可能在该节点上运行的任何应用程序很重要，首先配置一个 PodDisruptionBudgets 并继续遵循本指南。

建议为你的 PodDisruptionBudgets 设置 AlwaysAllow 不健康 Pod 驱逐策略，以在节点清空期间支持驱逐异常的应用程序。默认行为是等待应用程序的 Pod 变为健康后，才能进行清空操作。

kubectl drain 实践

kubectl drain 命令，驱逐 node 上所有 pod，同时标记 node 为不可调度。默认情况下，该命令忽略节点上不能驱逐的 Pod。有关更多细节，请参阅 kubectl drain 文档。

root@master30:~# kubectl drain -h
Drain node in preparation for maintenance.

 The given node will be marked unschedulable to prevent new pods from arriving.
'drain' evicts the pods if the APIServer supports.

Usage:
  kubectl drain NODE [options]
  
# 默认不驱逐 DaemonSet 控制的pod
root@master30:~# kubectl drain worker31.laoma.cloud 
node/worker31.laoma.cloud cordoned
error: unable to drain node "worker31.laoma.cloud", aborting command...

There are pending nodes to be drained:
 worker31.laoma.cloud
error: cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): kube-system/calico-node-jwdzx, kube-system/kube-proxy-98qkl

# 使用--ignore-daemonsets驱逐DaemonSet控制的pod
root@master30:~# kubectl drain worker31.laoma.cloud --ignore-daemonsets 
node/worker31.laoma.cloud already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/calico-node-jwdzx, kube-system/kube-proxy-98qkl
evicting pod kube-system/kuboard-74c645f5df-ljk98
evicting pod laoma/web-59b9bb7664-jkb5q
evicting pod laoma/web-59b9bb7664-w6mbs
pod/web-59b9bb7664-w6mbs evicted
pod/web-59b9bb7664-jkb5q evicted
pod/kuboard-74c645f5df-ljk98 evicted
node/worker31.laoma.cloud evicted

# 还可以使用以下选项驱逐特定pod:
  --pod-selector='': Label selector to filter pods on the node
  -l, --selector='': Selector (label query) to filter on，supports '=', '==', and '!='.(e.g. -l CPU=L1,MEM=L2). Matching objects must satisfy all of the specified label constraints.

root@master30:~# kubectl get node
NAME                   STATUS                        ROLES        AGE   VERSION
master30.laoma.cloud   Ready                         control-plane   36d   v1.30.2
worker31.laoma.cloud   Ready,SchedulingDisabled   <none>       36d   v1.30.2
worker32.laoma.cloud   Ready                      <none>       36d   v1.30.2

# 删除worker31上SchedulingDisabled标记
root@master30:~# kubectl uncordon worker31.laoma.cloud

并行清空多个节点

kubectl drain 命令一次只能发送给一个节点，可以在不同的终端或后台为不同的节点并行地运行多个 kubectl drain 命令。同时运行的多个 drain 命令仍然遵循你指定的 PodDisruptionBudget。

例如，一个三副本的 Deployments，设置了一个PodDisruptionBudget，指定 minAvailable: 2。如果所有的三个 Pod 处于健康（healthy）状态，并且你并行地发出多个 drain 命令，那么 kubectl drain 只会从 Deployments中逐出一个 Pod，因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用（最多不可用 Pod 个数的计算方法：replicas - minAvailable）。任何会导致处于健康（healthy）状态的副本数量低于指定预算的清空操作都将被阻止。

环境清理

root@master30:~# kubectl delete ns scheduler

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

AI写小说用什么模型最好？DeepSeek、Claude、豆包实测对比，别只盯着一个用

AI编程社区

[论文学习]ToolEmu:用语言模型模拟沙盒识别语言模型智能体的风险

AI编程社区

【生产力】Claude Opus 5 新特性与行为变化：完整更新与迁移指南

AI编程社区

所有评论(0)

查看更多评论

m0_65060929

@m0_65060929

已为社区贡献3条内容

Kubernetes Network与Pod Scheduler

m0_65060929

Kubernetes Network

环境准备

单主机网络通信

Docker 单机网络

Containerd 单机网络

跨主机网络通信

跨主机通信架构

跨主机通信方案

网络模型

Distributed Store

IPAM

连通与隔离

性能

跨主机网络模型

CNM

CNI

CNM和CNI比较

网络策略

网络策略介绍

网络策略规约

to 和 from 选择器

实施网络策略

准备实验环境

根据 pod 标签限定

根据 pod 所属 ns 限定

根据 pod IP 限定

限定所有端口

限定端口范围

限定项目所有pod

多条件规则

默认策略

默认允许所有入站流量

默认拒绝所有入站流量

默认允许所有出站流量

默认拒绝所有出站流量

默认拒绝所有入口和所有出站流量

无法完成的工作

环境清理

Kubernetes Pod Scheduler

环境准备

调度介绍

调度过程

过滤

计分

控制 pod 运行位置

nodeName

nodeSelector

Affinity and AntiAffinity

nodeAffinity

Inter-pod affinity and anti-affinity

语法说明

示例 1：根据节点拓扑–亲和性调度

示例 2：根据节点主机名–反亲和性调度

示例 3：多个应用亲和性和反亲和性调度

Taint 和 Toleration

设置 Node Taints

设置 Pod tolerations

一个容忍度和一个污点 匹配

多个容忍度和多个污点 匹配

Taint 和 Toleration 用例

基于污点的驱逐

cordon 和 uncordon

drain

准备开始

kubectl drain 实践

并行清空多个节点

环境清理

所有评论(0)

温馨提示：您尚未绑定手机号

m0_65060929

一个容忍度和一个污点匹配

多个容忍度和多个污点匹配