k8s网络通信与调度

已于 2024-09-17 12:55:41 修改
阅读量1.2k 收藏 14
点赞数 16
文章标签： kubernetes 容器 云原生
于 2024-09-16 20:27:23 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/howewww/article/details/142306512
版权

目录

一 k8s网络通信

1.1 k8s通信整体架构

1.2 flannel网络插件

1.2.1 flannel跨主机通信原理

1.2.2 flannel支持的后端模式

1.3 calico网络插件

1.3.1 calico简介：

1.3.2 calico网络架构

1.3.3 部署calico

二 k8s调度（Scheduling）

2.1 调度在Kubernetes中的作用

2.2 调度原理：

2.3 调度器种类

2.4 常用调度方法

2.4.1 nodename

2.4.2 Nodeselector(通过标签控制节点)

2.5 affinity（亲和性）

2.5.1 亲和与反亲和

2.5.2 nodeAffinity节点亲和

2.5.3 Podaffinity（pod的亲和）

2.5.4 Podantiaffinity（pod反亲和）

2.6 Taints（污点模式，禁止调度）

tolerations（污点容忍）

污点容忍示例：

一 k8s网络通信

1.1 k8s通信整体架构

  • k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等

  • CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist

  • 插件使用的解决方案如下

    • 虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。

    • 多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。

    • 硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

  • 容器间通信：

    • 同一个pod内的多个容器间的通信，通过lo即可实现pod之间的通信

    • 同一节点的pod之间通过cni网桥转发数据包。

    • 不同节点的pod之间的通信需要网络插件支持

  • pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换

  • pod和外网通信：iptables的MASQUERADE

  • Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

1.2 flannel网络插件

插件组成：

插件功能
VXLAN即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）
VTEPVXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因
Cni0网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）
Flannel.1TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端
Flanneldflannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息

1.2.1 flannel跨主机通信原理

  • 当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。

  • VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。

  • 内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。

  • Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。

  • flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。

  • linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。

  • 此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

#默认网络通信路由
[root@k8s-master ~]# ip r
default via 172.25.250.2 dev eth0 proto static metric 100 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.25.250.0/24 dev eth0 proto kernel scope link src 172.25.250.100 metric 100 

#桥接转发数据库
[root@k8s-master ~]# bridge fdb

#arp列表
[root@k8s-master ~]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
172.25.250.1             ether   00:50:56:c0:00:08   C                     eth0
172.25.250.2             ether   00:50:56:e3:df:10   C                     eth0
172.25.250.250           ether   00:0c:29:a1:e3:aa   C                     eth0
10.244.1.0               ether   7a:9e:17:cc:15:d7   CM                    flannel.1
172.25.250.10            ether   00:0c:29:56:91:53   C                     eth0
172.25.250.20            ether   00:0c:29:69:a7:a7   C                     eth0
10.244.2.0               ether   ee:76:8c:81:e2:0c   CM                    flannel.1
10.244.0.2               ether   76:ed:07:63:08:96   C                     cni0
10.244.0.3               ether   ea:a5:9f:1d:b4:a9   C                     cni0

1.2.2 flannel支持的后端模式

网络模式功能
vxlan报文封装，默认模式
Directrouting直接路由，跨网段使用vxlan，同网段使用host-gw模式
host-gw主机网关，性能好，但只能在二层网络中，不支持跨网络 如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP性能差，不推荐

更改flannel的默认模式

[root@k8s-master ~]# kubectl -n kube-flannel edit cm kube-flannel-cfg 
32         "Type": "host-gw"

#重启pod
[root@k8s-master ~]# kubectl -n kube-flannel delete pod --all
pod "kube-flannel-ds-65v85" deleted
pod "kube-flannel-ds-6vtqt" deleted
pod "kube-flannel-ds-8lzpx" deleted

[root@k8s-master ~]# ip r
default via 172.25.250.2 dev eth0 proto static metric 100 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
10.244.1.0/24 via 172.25.250.10 dev eth0 
10.244.2.0/24 via 172.25.250.20 dev eth0 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.25.250.0/24 dev eth0 proto kernel scope link src 172.25.250.100 metric 100

1.3 calico网络插件

官网：Install Calico networking and network policy for on-premises deployments | Calico Documentation

1.3.1 calico简介：

  • 纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。

  • Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

1.3.2 calico网络架构

  • Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。

  • BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里

1.3.3 部署calico

删除flannel插件

[root@k8s-master ~]# kubectl delete -f kube-flannel.yml 
namespace "kube-flannel" deleted
serviceaccount "flannel" deleted
clusterrole.rbac.authorization.k8s.io "flannel" deleted
clusterrolebinding.rbac.authorization.k8s.io "flannel" deleted
configmap "kube-flannel-cfg" deleted
daemonset.apps "kube-flannel-ds" deleted

删除所有节点上flannel配置文件,避免冲突

[root@k8s-master ~]# rm -rf /etc/cni/net.d/10-flannel.conflist
[root@k8s-node1 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist
[root@k8s-node2 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist

下载部署文件

[root@k8s-master ~]# mkdir calico
[root@k8s-master calico]# curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico-typha.yaml -o calico.yaml

下载镜像上传至仓库

[root@k8s-master ~]# docker load -i calico-3.28.1.tar

[root@k8s-master ~]# docker tag calico/cni:v3.28.1 reg.exam.com/calico/cni:v3.28.1
[root@k8s-master ~]# docker tag calico/node:v3.28.1 reg.exam.com/calico/node:v3.28.1
[root@k8s-master ~]# docker tag calico/kube-controllers:v3.28.1 reg.exam.com/calico/kube-controllers:v3.28.1
[root@k8s-master calico]# docker tag calico/typha:v3.28.1 reg.exam.com/calico/typha:v3.28.1


[root@k8s-master ~]# docker push reg.exam.com/calico/cni:v3.28.1
[root@k8s-master ~]# docker push reg.exam.com/calico/node:v3.28.1
[root@k8s-master ~]# docker push reg.exam.com/calico/kube-controllers:v3.28.1
[root@k8s-master calico]# docker push reg.exam.com/calico/typha:v3.28.1

更改yml设置

[root@k8s-master calico]# vim calico.yaml
4835           image: calico/cni:v3.28.1
4906           image: calico/node:v3.28.1
4932           image: calico/node:v3.28.1
5158           image: calico/kube-controllers:v3.28.1
5247       - image: calico/typha:v3.28.1

4973             - name: CALICO_IPV4POOL_VXLAN
4974               value: "Never"

4999             - name: CALICO_IPV4POOL_CIDR
5000               value: "10.244.0.0/16"
5001             - name: CALICO_AUTODETECTION_METHOD
5002               value: "interface=eth0"


[root@k8s-master calico]# kubectl apply -f calico.yaml 

[root@k8s-master calico]# kubectl -n kube-system get pods 
NAME                                          READY   STATUS    RESTARTS         AGE
calico-kube-controllers-6849cb478c-5p67d      1/1     Running   0                6m5s
calico-node-57vcg                             1/1     Running   5 (14s ago)      6m5s
calico-node-f8v72                             1/1     Running   5 (13s ago)      6m5s
calico-node-snx85                             1/1     Running   1 (25s ago)      6m5s
calico-typha-fff9df85f-2zvz7                  1/1     Running   0                6m5s
coredns-846454f5f7-p89pl                      1/1     Running   10 (6h17m ago)   6d3h
coredns-846454f5f7-sqtwj                      1/1     Running   10 (6h17m ago)   6d3h
etcd-k8s-master.exam.com                      1/1     Running   10 (6h17m ago)   6d3h
kube-apiserver-k8s-master.exam.com            1/1     Running   10 (6h17m ago)   6d3h
kube-controller-manager-k8s-master.exam.com   1/1     Running   10 (6h17m ago)   6d3h
kube-proxy-7zpq9                              1/1     Running   4 (6h17m ago)    3d4h
kube-proxy-mm6zd                              1/1     Running   4 (6h17m ago)    3d4h
kube-proxy-q4sjf                              1/1     Running   4 (6h17m ago)    3d4h
kube-scheduler-k8s-master.exam.com            1/1     Running   10 (6h17m ago)   6d3h

#服务起不来 试试重启
[root@k8s-master calico]# systemctl restart cri-docker
[root@k8s-master calico]# systemctl restart kubelet.service

测试：

[root@k8s-master calico]# kubectl run  web --image myapp:v1
pod/web created

web                         1/1     Running     0               40s     10.244.57.193   k8s-node1.exam.com   <none>           <none>

[root@k8s-master calico]# curl 10.244.57.193
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

二 k8s调度（Scheduling）

2.1 调度在Kubernetes中的作用

  • 调度是指将未调度的Pod自动分配到集群中的节点的过程

  • 调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod

  • 调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行

2.2 调度原理：

  • 创建Pod

    • 用户通过Kubernetes API创建Pod对象，并在其中指定Pod的资源需求、容器镜像等信息。

  • 调度器监视Pod

    • Kubernetes调度器监视集群中的未调度Pod对象，并为其选择最佳的节点。

  • 选择节点

    • 调度器通过算法选择最佳的节点，并将Pod绑定到该节点上。调度器选择节点的依据包括节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等。

  • 绑定Pod到节点

    • 调度器将Pod和节点之间的绑定信息保存在etcd数据库中，以便节点可以获取Pod的调度信息。

  • 节点启动Pod

    • 节点定期检查etcd数据库中的Pod调度信息，并启动相应的Pod。如果节点故障或资源不足，调度器会重新调度Pod，并将其绑定到其他节点上运行。

2.3 调度器种类

  • 默认调度器（Default Scheduler）：

    • 是Kubernetes中的默认调度器，负责对新创建的Pod进行调度，并将Pod调度到合适的节点上。

  • 自定义调度器（Custom Scheduler）：

    • 是一种自定义的调度器实现，可以根据实际需求来定义调度策略和规则，以实现更灵活和多样化的调度功能。

  • 扩展调度器（Extended Scheduler）：

    • 是一种支持调度器扩展器的调度器实现，可以通过调度器扩展器来添加自定义的调度规则和策略，以实现更灵活和多样化的调度功能。

  • kube-scheduler是kubernetes中的默认调度器，在kubernetes运行后会自动在控制节点运行

2.4 常用调度方法

2.4.1 nodename

  • nodeName 是节点选择约束的最简单方法，但一般不推荐

  • 如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法

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

    • 如果指定的节点不存在。

    • 如果指定的节点没有资源来容纳 pod，则pod 调度失败。

    • 云环境中的节点名称并非总是可预测或稳定的

实例：

#建立pod文件
[root@k8s-master scheduler]# kubectl run testpod --image myapp:v1 --dry-run=client -o yaml > pod1.yml

#设置调度
[root@k8s-master scheduler]# vim pod1.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  nodeName: k8s-node2
  containers:
  - image: myapp:v1
    name: testpod
    
#建立pod
[root@k8s-master scheduler]# kubectl apply -f pod1.yml 
pod/testpod created

[root@k8s-master scheduler]# kubectl get pods -o wide

Note：nodeName: k8s3 #找不到节点pod会出现pending，优先级最高，其他调度方式无效

[root@k8s-master scheduler]# kubectl get pods 
NAME		READY   STATUS    RESTARTS       AGE
testpod		0/1     Pending   0              58s

2.4.2 Nodeselector(通过标签控制节点)

  • nodeSelector 是节点选择约束的最简单推荐形式

  • 给选择的节点添加标签：

kubectl label nodes k8s-node1 lab=haha

  • 可以给多个节点设定相同标签

示例：

查看节点标签

[root@k8s-master scheduler]# kubectl get nodes --show-labels
NAME         STATUS   ROLES           AGE    VERSION   LABELS
k8s-master   Ready    control-plane   5d3h   v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-node1    Ready    <none>          5d3h   v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux
k8s-node2    Ready    <none>          5d3h   v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux

设定节点标签

[root@k8s-master scheduler]# kubectl label nodes k8s-node1.exam.com lab=imNo.1
node/k8s-node1.exam.com labeled

[root@k8s-master scheduler]# kubectl get nodes k8s-node1.exam.com --show-labels 
NAME                 STATUS   ROLES    AGE    VERSION   LABELS
k8s-node1.exam.com   Ready    <none>   6d9h   v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1.exam.com,kubernetes.io/os=linux,lab=imNo.1

调度设置

[root@k8s-master scheduler]# vim pod2.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  nodeSelector:
    lab: imNo.1
  containers:
  - image: myapp:v1
    name: testpod
    
[root@k8s-master scheduler]# kubectl apply -f pod2.yml 
pod/testpod created

[root@k8s-master scheduler]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS       AGE   IP              NODE                 NOMINATED NODE   READINESS GATES
testpod                     1/1     Running   0              32s   10.244.57.210   k8s-node1.exam.com   <none>           <none>

Note：节点标签可以给N个节点加

2.5 affinity（亲和性）

官方文档 ：

将 Pod 指派给节点 | Kubernetes

2.5.1 亲和与反亲和

  • nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。

  • 使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

2.5.2 nodeAffinity节点亲和

  • 那个节点服务指定条件就在那个节点运行

  • requiredDuringSchedulingIgnoredDuringExecution 必须满足，但不会影响已经调度

  • preferredDuringSchedulingIgnoredDuringExecution 倾向满足，在无法满足情况下也会调度pod

    • IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

  • nodeaffinity还支持多种规则匹配条件的配置如

匹配规则功能
lnlabel 的值在列表内
Notlnlabel 的值不在列表内
Gtlabel 的值大于设置的值，不支持Pod亲和性
Ltlabel 的值小于设置的值，不支持pod亲和性
Exists设置的label 存在
DoesNotExist设置的 label 不存在

 nodeAffinity示例

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk				   #node上面带的标签
            operator: In | NotIn    	#两个结果相反,但是不能这么写       
            values:
              - ssd					#标签设定的值

[root@k8s-master scheduler]# vim pod3.yml
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk				   
            operator: In    	     
            values:
              - ssd

[root@k8s-master scheduler]# kubectl get pods -o wide 
NAME                        READY   STATUS    RESTARTS        AGE   IP              NODE                 NOMINATED NODE   READINESS GATES
node-affinity               0/1     Pending   0               37s   <none>          <none>               <none>           <none>


#解决pending问题
检查是否设定的标签和标签的值在yml中一致 如果不是一致 就匹配不到 显示为pending
[root@k8s-master scheduler]# kubectl get nodes k8s-node1.exam.com --show-labels 
NAME                 STATUS   ROLES    AGE    VERSION   LABELS
k8s-node1.exam.com   Ready    <none>   7d8h   v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1.exam.com,kubernetes.io/os=linux,lab=imNo.1

#此处key为lab 值为imNo.1
[root@k8s-master scheduler]# vim pod3.yml
...
14           - key: lab
15             operator: In
16             values:
17               - imNo.1


[root@k8s-master scheduler]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS        AGE     IP               NODE                  NOMINATED NODE   READINESS GATES
node-affinity               1/1     Running   0               25s     10.244.57.235    k8s-node1.exam.com    <none>           <none>


------------------------------------------------------------------------
#NotIn
[root@k8s-master scheduler]# kubectl apply -f pod3.yml 
pod/node-affinity created

[root@k8s-master scheduler]# vim pod3.yml
            operator: NotIn
            
[root@k8s-master scheduler]# kubectl get pods -o wide 
node-affinity               1/1     Running   0               3s    10.244.57.211   k8s-node1.exam.com   <none>           <none>
testpod                     1/1     Running   0               16m   10.244.57.210   k8s-node1.exam.com   <none>           <none>

##Pod 的调度状态取决于节点的标签与Pod的调度要求（亲和性或反亲和性规则）是否匹配。如果没有匹配的节点，Pod就会处于Pending状态等待合适的节点出现；如果找到了匹配的节点，Pod 就可以被调度并启动，进入Running状态

2.5.3 Podaffinity（pod的亲和）

  • 那个节点有符合条件的POD就在那个节点运行

  • podAffinity 主要解决POD可以和哪些POD部署在同一个节点中的问题

  • podAntiAffinity主要解决POD不能和哪些POD部署在同一个节点中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。

  • Pod 间亲和与反亲和在与更高级别的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用时，

  • Pod 间亲和与反亲和需要大量的处理，这可能会显著减慢大规模集群中的调度。

Podaffinity示例

[root@k8s-master scheduler]# vim pod4.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
            
[root@k8s-master scheduler]# kubectl apply -f pod4.yml 
deployment.apps/nginx-deployment created

[root@k8s-master scheduler]# kubectl get pods -o wide 
NAME                               READY   STATUS    RESTARTS        AGE     IP              NODE                 NOMINATED NODE   READINESS GATES
nginx-deployment-658496fff-5prc7   1/1     Running   0               32s     10.244.165.81   k8s-node2.exam.com   <none>           <none>
nginx-deployment-658496fff-jc7fz   1/1     Running   0               32s     10.244.165.83   k8s-node2.exam.com   <none>           <none>
nginx-deployment-658496fff-xxd7l   1/1     Running   0               32s     10.244.165.82   k8s-node2.exam.com   <none>           <none>

2.5.4 Podantiaffinity（pod反亲和）

Podantiaffinity示例

[root@k8s-master scheduler]# vim pod5.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        podAntiAffinity:			#反亲和
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"

[root@k8s-master scheduler]# kubectl apply -f pod5.yml 
deployment.apps/nginx-deployment created

[root@k8s-master scheduler]# kubectl get pods -o wide 
NAME                                READY   STATUS    RESTARTS       AGE   IP              NODE                 NOMINATED NODE   READINESS GATES
nginx-deployment-5f5fc7b8b9-62cqb   0/1     Pending   0              29s   <none>          <none>               <none>           <none>
nginx-deployment-5f5fc7b8b9-l5sqj   0/1     Pending   0              29s   <none>          <none>               <none>           <none>
nginx-deployment-5f5fc7b8b9-nbdpr   1/1     Running   0              29s   10.244.57.212   k8s-node1.exam.com   <none>           <none>

2.6 Taints（污点模式，禁止调度）

  • Taints(污点)是Node的一个属性，设置了Taints后，默认Kubernetes是不会将Pod调度到这个Node上

  • Kubernetes如果为Pod设置Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去

  • 可以使用命令 kubectl taint 给节点增加一个 taint：

$ kubectl taint nodes <nodename> key=string:effect   #命令执行方法
$ kubectl taint nodes node1 key=value:NoSchedule     #创建
$ kubectl describe nodes server1 | grep Taints       #查询
$ kubectl taint nodes node1 key-                     #删除

其中[effect] 可取值：

effect值解释
NoSchedulePOD 不会被调度到标记为 taints 节点
PreferNoScheduleNoSchedule 的软策略版本，尽量不调度到此节点
NoExecute如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出

Taints示例

#建立控制器并运行
[root@k8s-master scheduler]# vim pod6.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        
[root@k8s-master scheduler]# kubectl apply -f pod6.yml 
deployment.apps/web created

[root@k8s-master scheduler]# kubectl get pod 
NAME                        READY   STATUS    RESTARTS       AGE   
web-6765dc77b-6gq4c         1/1     Running   2 (32m ago)   22h
web-6765dc77b-8kb6f         1/1     Running   2 (33m ago)   22h
web-6765dc77b-d6ck2         1/1     Running   2 (33m ago)   22h
web-6765dc77b-hv8n8         1/1     Running   2 (33m ago)   22h
web-6765dc77b-j9wgt         1/1     Running   2 (32m ago)   22h
web-6765dc77b-zp4p5         1/1     Running   2 (33m ago)   22h


#设定污点为NoSchedule
[root@k8s-master scheduler]# kubectl taint node k8s-node1.exam.com name=howe:NoSchedule
node/k8s-node1.exam.com tainted

[root@k8s-master scheduler]# kubectl describe nodes k8s-node1.exam.com | grep Tain
Taints:             name=howe:NoSchedule

#控制器增加pod
[root@k8s-master scheduler]# kubectl get pod -o wide

web-7c56dcdb9b-2n69r        1/1     Running   0               66s   10.244.165.85   k8s-node2.exam.com   <none>           <none>
web-7c56dcdb9b-mvg4m        1/1     Running   0               66s   10.244.165.86   k8s-node2.exam.com   <none>           <none>

#设定污点为NoExecute
[root@k8s-master scheduler]# kubectl taint node k8s-node1.exam.com name=howe:NoExecute
node/k8s-node1.exam.com tainted

[root@k8s-master scheduler]# kubectl describe nodes k8s-node1.exam.com | grep Tain
Taints:             name=howe:NoExecute

[root@k8s-master scheduler]# kubectl get pod -o wide
web-7c56dcdb9b-2n69r        1/1     Running   0               3m9s   10.244.165.85   k8s-node2.exam.com   <none>           <none>
web-7c56dcdb9b-mvg4m        1/1     Running   0               3m9s   10.244.165.86   k8s-node2.exam.com   <none>           <none>

#删除污点
[root@k8s-master scheduler]# kubectl taint node k8s-node1.exam.com name-
node/k8s-node1.exam.com untainted

[root@k8s-master scheduler]# kubectl describe nodes k8s-node1.exam.com | grep Tain
Taints:             <none>

tolerations（污点容忍）

  • tolerations中定义的key、value、effect，要与node上设置的taint保持一直：

    • 如果 operator 是 Equal ，则key与value之间的关系必须相等。

    • 如果 operator 是 Exists ，value可以省略

    • 如果不指定operator属性，则默认值为Equal。

  • 还有两个特殊值：

    • 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。

    • 当不指定effect ，则匹配所有的effect

污点容忍示例：
[root@k8s-master scheduler]# kubectl taint node k8s-node1.exam.com name=howe:NoExecute
node/k8s-node1.exam.com tainted

[root@k8s-master scheduler]# kubectl taint node k8s-node2.exam.com nodetype=bad:NoSchedule
node/k8s-node2.exam.com tainted

#示例：   
      tolerations:				#容忍所有污点
      - operator: Exists
    
	  tolerations:				#容忍effect为Noschedule的污点
      - operator: Exists
        effect: NoSchedule
	
	  tolerations:				#容忍指定kv的NoSchedule污点
      - key: nodetype
        value: bad
        effect: NoSchedule
 
[root@k8s-master scheduler]# vim pod7.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web 
  name: web 
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web 
  template:
    metadata:
      labels:
        app: web 
    spec:
      containers:
      - image: nginx
        name: nginx
      tolerations:
      - operator: Exists
      - operator: Exists
        effect: NoSchedule
      - key: nodetype
        value: bad 
        effect: NoSchedule
        
[root@k8s-master scheduler]# kubectl apply -f pod7.yml 
deployment.apps/web created

[root@k8s-master scheduler]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS        AGE     IP              NODE                  NOMINATED NODE   READINESS GATES
web-6765dc77b-6gq4c         1/1     Running   0               70s     10.244.165.92   k8s-node2.exam.com    <none>           <none>
web-6765dc77b-8kb6f         1/1     Running   0               70s     10.244.57.215   k8s-node1.exam.com    <none>           <none>
web-6765dc77b-d6ck2         1/1     Running   0               70s     10.244.104.3    k8s-master.exam.com   <none>           <none>
web-6765dc77b-hv8n8         1/1     Running   0               70s     10.244.57.214   k8s-node1.exam.com    <none>           <none>
web-6765dc77b-j9wgt         1/1     Running   0               70s     10.244.165.93   k8s-node2.exam.com    <none>           <none>
web-6765dc77b-zp4p5         1/1     Running   0               70s     10.244.57.216   k8s-node1.exam.com    <none>           <none>

Note：三种容忍方式每次测试写一个即可

HoweWWW
关注
【K8S系列】深入解析k8s网络插件—Weave Net
颜淡慕潇
08-13 5万+
总体而言，Weave Net 是一个功能强大且易于使用的 Kubernetes 网络插件，它提供了简单的网络配置和管理方式，并具有跨主机容器通信、动态网络拓扑和安全性等优点。然而，它也存在一些性能开销和单点故障的缺点，需要用户在使用之前了解和权衡。
K8s（六）：网络插件之Calico安装与详解
热门推荐
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
04-02 2万+
🔴 K8s（六）：网络插件之Calico安装与详解
K8S网络通信 ---- Kubernetes
NiuXL的编程技术网络日志
06-12 434
文章目录1. K8S网络模型2. K8S网络解决方案3. K8S网络通信方式 图解Python数据结构与算法-实战篇 1. K8S网络模型        Kubernetes 的网络模型假定了所有Pod 都在一个可以直接连通的扁平的网络空间中，Kubernetes的扁平化是指所有的 Pod 都可以通过对方的 IP .
运维实战 kubernetes(k8s) 之 service
weixin_54720351的博客
06-14 1万+
@[TOC]( 运维实战 kubernetes(k8s) 之 service ) 1. service Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。 service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现） service的类型： ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。 NodePort：将Service通过指定的Node上的端口暴露给外部，访
k8s网络通信
lingshengxiyou的博客
04-06 96
到这里我们就会发现，这其实就是对单个容器的 bridge 网络模型的扩展。今天的数据中心包含多个集群以及海量的物理机，Overlay 网络是虚拟机和底层网络设备之间的中间层，通过 Overlay 网络这一个中间层，我们可以解决虚拟机的迁移问题、降低二层核心网络设备的压力并提供更大规模的虚拟网络数量： 在使用 VxLAN 构成二层网络中，虚拟机在不同集群、不同可用区和不同数据中心迁移后，仍然可以保证二层网络的可达性，这能够帮助我们保证线上业务的可用性、提升集群的资源利用率、容忍虚拟机和节点的故障；
k8s网络模型与集群通信
qigeminghao的博客
11-16 1224
在k8s中，我们的应用会以pod的形式被调度到各个node节点上，在设计集群如何处理容器之间的网络时是一个不小的挑战，今天我们会从pod（应用）通信来展开关于k8s网络的讨论。 小作文包含如下内容： k8s网络模型与实现方案 pod内容器通信 pod与pod通信 pod与service通信 外网与service通信 k8s网络模型与实现方案 k8s集群中的每一个Pod（最小调度单位）都有自己的IP地址，即ip-per-pod模型。 在ip-per-pod模型中每一个pod在集群中保持唯一性，
k8s+k8s+pod介绍与网络通讯+配合博文
03-30
k8s网络模型基于每个Pod都拥有独立IP地址的设计，这意味着Pod之间可以直接通过IP通信。此外，Service作为Pod的抽象，提供了一个稳定的网络接口，即使Pod实例变化，Service的IP保持不变。Service通过Label Selector来...
k8s-Pod编排与调度
qq_16803227的博客
01-19 507
Pod是K8s调度的最小单元，但是Pod可能因为资源不足、集群崩溃等被驱逐。Controller Manage会管理Pod，完成Pod自愈、滚动升级等操作，通过Deployment这种资源完成Pod维护。一个Deployment可以包含一个或多个Pod副本，每个Pod副本的角色相同，所以系统会自动为Deployment的多个Pod副本分发请求。
k8s 网络通信详解
11-12
不同的网络命名空间中，协议栈是独立的，完全隔离，彼此之间无法通信。同一个网络命名空间有独立的路由表和独立的Iptables/Netfilter来提供包的转发、NAT、IP包过滤等功能。
k8s中网络通讯简单介绍
爪哇人的博客
07-11 512
Kubernetes的网络模型假定了所有的pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假设这定这个网络已经存在。但是在私有云里搭建Kubernetes集群，就不能够假定这个网络已经存在了。我们需要自己去实现这个网络假设，将不同节点的Docker容器之间的访问互相打通，然后运行Kubernetes。
Kubernetes基础(十五)-k8s网络通信
sre救赎之路
02-07 1789
Pod是Kubernetes中最小的可部署单元，它是一个或多个紧密关联的容器的组合，这些容器共享同一个网络命名空间和存储卷，因此Pod中的，所以在同一个Pod内的容器间通信可以。k8s创建Pod时永远都是首先创建Infra 容器，也可以被称为pause容器。这个容器为其他容器提供了一个共享的基础设施，包括网络和存储功能，其他业务容器共享pause容器的网络栈和Volume挂载卷。
k8s：组件网络通讯方式
学亮编程手记
06-13 507
网络通讯模式 Flannel 不同情况下的网络通信方式 外网访问Pod是通过Service的Nodeport进行映射来实现的。 pod1和pod2在同一台机器 组件通讯示意图
Kubernetes精讲之网络通信与调度
最新发布
m2282475145的博客
09-12 1128
纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。
K8S知识点记录—网络通信
qq_40494873的博客
04-09 3710
前言 对于刚接触K8s的新人来说，K8S的网络通信太复杂了，每个点都可以深入很多很多，这篇文章记录自己网络通信的一个整体认识，帮助快速上手。 一、K8S的网络通信汇总 根据自己的梳理画了一个图（从用户到pod的一个网络通信图，目的是快速打通网络流） 图中的概念介绍： K8S中三类IP，NodeIP，PodIP，ClusterIP Node IP：Node节点的IP地址，即物理网卡的IP地址 Pod IP：Pod的IP地址，即docker容器的IP地址，此为虚拟IP地址 Cluster IP：Ser
k8s-kubernetes--网络策略、flannel网络插件和calico网络插件
Gong_yz的博客
03-12 5717
网络策略通过网络插件来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。(Flannel不支持 NetworkPolicy，所以使用Flannei网络插件是不会隔离pod的)
k8s网络详解
weixin_43539320的博客
04-10 3930
cni0：他同docker网络模式不同的是，docker默认会创建一个名为docker0的网桥，而flannel会通过一个cni0来替换docker0。overlay：（覆盖网络），在现有的三层网络之下，“覆盖一层”虚拟的，由内核VXLAN模块负责维护的二层网络，使得在连接在这个VXLAN二层网络的pod之间，可以像在同一个局域网里一样，自由通讯。VXLAN：（虚拟可扩展局域网），是linux内核本身就支持的一种网络虚拟化技术。VXLAN完全就可以在内核实现封装和解封装的行为。架构图。
谈谈k8s网络、调度、资源隔离
05-24
Kubernetes（k8s）是一个容器编排平台，它提供了网络、调度和资源隔离等功能来管理和运行容器化应用程序。 1. 网络 在Kubernetes中，每个容器都有自己的IP地址，而Pod则有一个共享的IP地址。Kubernetes提供了多种...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值