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)

flannel网络插件

插件组成

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网桥,最后到达目标容器。

#默认网络通信路由

桥接转发数据库

arp列表

flannel支持的后端模式

更改flannel的默认模式

kubectl -n kube-flannel edit cm kube-flannel-cfg

重启pod

kubectl -n kube-flannel delete pod --all

calico网络插件

官网:

https://docs./getting-started/kubernetes/self-managed-onprem/onpremises

简介

纯三层的转发,中间没有任何的NAT和overlay,转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

calico网络架构

Felix:监听ECTD中心的存储获取事件,用户创建pod后,Felix负责将其网卡、IP、MAC都设置好,然后在内核的路由表里面写一条,注明这个IP应该到这张网卡。同样如果用户制定了隔离策略,Felix同样会将该策略创建到ACL中,以实现隔离。
BIRD:一个标准的路由程序,它会从内核里面获取哪一些IP的路由发生了变化,然后通过标准BGP的路由协议扩散到整个其他的宿主机上,让外界都知道这个IP在这里,路由的时候到这里

部署

删除flannel插件

kubectl delete  -f kube-flannel.yml

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

rm -rf /etc/cni/net.d/10-flannel.conflist

下载部署文件

下载镜像上传至仓库:

更改yml设置

vim calico.yaml

测试

k8s调度

调度在Kubernetes中的作用

调度是指将未调度的Pod自动分配到集群中的节点的过程
调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod
调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运

调度原理:

创建Pod
用户通过Kubernetes API创建Pod对象,并在其中指定Pod的资源需求、容器镜像等信息。
调度器监视Pod
Kubernetes调度器监视集群中的未调度Pod对象,并为其选择最佳的节点。
选择节点
调度器通过算法选择最佳的节点,并将Pod绑定到该节点上。调度器选择节点的依据包括节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等。
绑定Pod到节点
调度器将Pod和节点之间的绑定信息保存在etcd数据库中,以便节点可以获取Pod的调度信息。
节点启动Pod
节点定期检查etcd数据库中的Pod调度信息,并启动相应的Pod。如果节点故障或资源不足,调度器会重新调度Pod,并将其绑定到其他节点上运行。

调度器种类

默认调度器(Default Scheduler):
 是Kubernetes中的默认调度器,负责对新创建的Pod进行调度,并将Pod调度到合适的节点上。
自定义调度器(Custom Scheduler):
是一种自定义的调度器实现,可以根据实际需求来定义调度策略和规则,以实现更灵活和多样化的调度功能。
扩展调度器(Extended Scheduler):
 是一种支持调度器扩展器的调度器实现,可以通过调度器扩展器来添加自定义的调度规则和策略,以实现更灵活和多样化的调度功能。
 kube-scheduler是kubernetes中的默认调度器,在kubernetes运行后会自动在控制节点运行

常用调度方法

 nodename

nodeName 是节点选择约束的最简单方法,但一般不推荐
如果 nodeName 在 PodSpec 中指定了,则它优先于其他的节点选择方法
 使用 nodeName 来选择节点的一些限制
 如果指定的节点不存在。
如果指定的节点没有资源来容纳 pod,则pod 调度失败。
云环境中的节点名称并非总是可预测或稳定的 

 示例

建立pod文件

设置调度

  1. kubectl run testpod --image myapp:v1 --dry-run=client -o yaml > pod1.yml
  2. vim pod1.yml

建立pod

注意:找不到节点pod时会出现pending,优先级最高,其他调度方式无效

Nodeselector(通过标签控制节点)

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

 给选择的节点添加标签:
 

[root@k8s-master scheduler]#  kubectl label nodes k8s-node1.org  lab=lee

查看节点标签

设定节点标签

[root@k8s-master scheduler]#  kubectl label nodes k8s-node1.org  lab=lee

调度设置

  1. vim pod2.yml
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5. labels:
  6. run: testpod
  7. name: testpod
  8. spec:
  9. nodeSelector:
  10. lab: timinglee
  11. containers:
  12. - image: myapp:v1
  13. name: testpod

 affinity(亲和性)

官方文档 :

https:///zh/docs/concepts/scheduling-eviction/assign-pod-node

亲和与反亲和

nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。
 使用节点上的 pod 的标签来约束,而不是使用节点本身的标签,来允许哪些 pod 可以或者不可以被放置在一起。

nodeAffinity节点亲和

那个节点服务指定条件就在那个节点运行
requiredDuringSchedulingIgnoredDuringExecution   必须满足,但不会影响已经调度
 preferredDuringSchedulingIgnoredDuringExecution 倾向满足,在无法满足情况下也会调度pod
 IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化,导致亲和性策略不能满足,则继续运行当前的Pod。
nodeaffinity还支持多种规则匹配条件的配置

nodeAffinity示例

  1. vim pod3.yml
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5. name: node-affinity
  6. spec:
  7. containers:
  8. - name: nginx
  9. image: nginx
  10. affinity:
  11. nodeAffinity:
  12. requiredDuringSchedulingIgnoredDuringExecution:
  13. nodeSelectorTerms:
  14. - matchExpressions:
  15. - key: disk
  16. operator: In | NotIn #两个结果相反
  17. values:
  18. - ssd

Podaffinity(pod的亲和)

那个节点有符合条件的POD就在那个节点运行
podAffinity 主要解决POD可以和哪些POD部署在同一个节点中的问题
 podAntiAffinity主要解决POD不能和哪些POD部署在同一个节点中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
 Pod 间亲和与反亲和在与更高级别的集合(例如 ReplicaSets,StatefulSets,Deployments 等)一起使用时,
 Pod 间亲和与反亲和需要大量的处理,这可能会显著减慢大规模集群中的调度。
 

Podaffinity示例

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: busyboxplus-deployment
  5. labels:
  6. app: busyboxplus
  7. spec:
  8. replicas: 3
  9. selector:
  10. matchLabels:
  11. app: busyboxplus
  12. template:
  13. metadata:
  14. labels:
  15. app:busyboxplus
  16. spec:
  17. containers:
  18. - name: busyboxplus
  19. image: busyboxplus
  20. affinity:
  21. podAffinity:
  22. requiredDuringSchedulingIgnoredDuringExecution:
  23. - labelSelector:
  24. matchExpressions:
  25. - key: app
  26. operator: In
  27. values:
  28. - busyboxplus
  29. topologyKey: "/hostname"
  30. ~

Podantiaffinity(pod反亲和)

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: nginx-deployment
  5. labels:
  6. app: nginx
  7. spec:
  8. replicas: 3
  9. selector:
  10. matchLabels:
  11. app: nginx
  12. template:
  13. metadata:
  14. labels:
  15. app: nginx
  16. spec:
  17. containers:
  18. - name: nginx
  19. image: nginx
  20. affinity:
  21. podAntiAffinity: #反亲和
  22. requiredDuringSchedulingIgnoredDuringExecution:
  23. - labelSelector:
  24. matchExpressions:
  25. - key: app
  26. operator: In
  27. values:
  28. - nginx
  29. topologyKey: "/hostname"

 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] 可取值:

Taints示例

  1. [root@k8s-master scheduler]# vim example6.yml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5. labels:
  6. app: web
  7. name: web
  8. spec:
  9. replicas: 2
  10. selector:
  11. matchLabels:
  12. app: web
  13. template:
  14. metadata:
  15. labels:
  16. app: web
  17. spec:
  18. containers:
  19. - image: nginx
  20. name: nginx

设定污点为NoSchedule

  1. [root@k8s-master scheduler]# kubectl taint node k8s-node1.org name=lee:NoSchedule
  2. node/k8s-node1.org tainted
  1. [root@k8s-master scheduler]# kubectl describe nodes k8s-node1.org | grep Tain
  2. Taints: name=lee:NoSchedule
删除污点

tolerations(污点容忍)

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

污点容忍示例:
设定节点污点

  1. vim example7.yml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5. labels:
  6. app: web
  7. name: web
  8. spec:
  9. replicas: 6
  10. selector:
  11. matchLabels:
  12. app: web
  13. template:
  14. metadata:
  15. labels:
  16. app: web
  17. spec:
  18. containers:
  19. - image: nginx
  20. name: nginx
  21. tolerations: #容忍所有污点
  22. - operator: Exists
  23. tolerations: #容忍effect为Noschedule的污点
  24. - operator: Exists
  25. effect: NoSchedule
  26. tolerations: #容忍指定kv的NoSchedule污点
  27. - key: nodetype
  28. value: bad
  29. effect: NoSchedule