k8s中的通信与调治

一 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网桥，末了到达目标容器
  

1.3 calico网络插件


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插件

删除所有节点上flannel设置文件,制止冲突

下载部署文件
下载镜像上传至仓库：

 
更改yml设置
vim calico.yaml
   4835           image: calico/cni:v3.28.1
4835           image: calico/cni:v3.28.1
4906           image: calico/node:v3.28.1
4932           image: calico/node:v3.28.1
5160           image: calico/kube-controllers:v3.28.1
5249         - image: calico/typha:v3.28.1
  4970             - name: CALICO_IPV4POOL_IPIP
4971               value: "Never"
  4999             - name: CALICO_IPV4POOL_CIDR
5000               value: "10.244.0.0/16"
5001             - name: CALICO_AUTODETECTION_METHOD
5002               value: "interface=eth0"
  
 

 
测试：

二 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文件
#建立pod

nodeName: k8s3   #找不到节点pod会出现pending，优先级最高，其他调治方式无效
2.4.2 Nodeselector(通过标签控制节点)

• nodeSelector 是节点选择约束的最简单保举情势
  
• 给选择的节点添加标签：
  
  1. kubectl label nodes k8s-node1 lab=lee

  复制代码
• 可以给多个节点设定相同标签
  

示例：  
#查看节点标签

#设定节点标签

 #调治设置

2.5 affinity（亲和性）

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示例  

不亲和 

2.5.3 Podaffinity（pod的亲和）

• 谁人节点有符合条件的POD就在谁人节点运行
  
• podAffinity 主要办理POD可以和哪些POD部署在同一个节点中的题目
  
• podAntiAffinity主要办理POD不能和哪些POD部署在同一个节点中的题目。它们处理的是Kubernetes集群内部POD和POD之间的关系。
  
• Pod 间亲和与反亲和在与更高级别的聚集（比方 ReplicaSets，StatefulSets，Deployments 等）一起使用时，
  
• Pod 间亲和与反亲和必要大量的处理，这可能会显著减慢大规模集群中的调治。
  

Podaffinity示例
   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: 2/nginx
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
  

 
2.5.4 Podantiaffinity（pod反亲和）

 Podantiaffinity示例

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示例

#建立控制器并运行

#设定污点为NoSchedule

tolerations（污点容忍）

• tolerations中界说的key、value、effect，要与node上设置的taint保持一直：
  
  
  
  • 如果 operator 是 Equal ，则key与value之间的关系必须相称。
    
  • 如果 operator 是 Exists ，value可以省略
    
  • 如果不指定operator属性，则默认值为Equal。
    
  
  
• 尚有两个特殊值：
  
  
  
  • 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。
    
  • 当不指定effect ，则匹配所有的effect
    
  
  

污点容忍示例：

#设定节点污点

 
   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: 2/nginx
        name: nginx
      
      tolerations:                #容忍所有污点
      - operator: Exists
    
      tolerations:                #容忍effect为Noschedule的污点
      - operator: Exists
        effect: NoSchedule
    
      tolerations:                #容忍指定kv的NoSchedule污点
      - key: nodetype
        value: bad
        effect: NoSchedule 
   

节点node1:由于 Deployment 的 Pod 设置了容忍所有污点（operator: Exists），所以 Pod 可以在 k8snode1 上运行，不会由于 name=lee:NoExecute 这个污点被驱逐。不过，如果后续对 Pod 进行更新，移除了这个通用的容忍设置，那么 Pod 可能会被立刻从 k8snode1 上驱逐。 
节点 node2：Deployment 的 Pod 设置了容忍 nodetype=bad:NoSchedule 这种范例的污点，所以调治器会思量将 Pod 调治到 k8snode2 上，只要该节点满足其他调治条件（如资源可用性等）。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。