k8s网络通信
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.projectcalico.org/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文件
设置调度
kubectl run testpod --image myapp:v1 --dry-run=client -o yaml > pod1.yml
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
调度设置
vim pod2.yml
apiVersion: v1
kind: Pod
metadata:labels:run: testpodname: testpod
spec:nodeSelector:lab: timingleecontainers:- image: myapp:v1name: testpod
affinity（亲和性）
官方文档 ：
https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node
亲和与反亲和
nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。
使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。
nodeAffinity节点亲和
那个节点服务指定条件就在那个节点运行
requiredDuringSchedulingIgnoredDuringExecution 必须满足，但不会影响已经调度
preferredDuringSchedulingIgnoredDuringExecution 倾向满足，在无法满足情况下也会调度pod
IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。
nodeaffinity还支持多种规则匹配条件的配置
nodeAffinity示例
vim pod3.yml
apiVersion: v1
kind: Pod
metadata:name: node-affinity
spec:containers:- name: nginximage: nginxaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: diskoperator: In | NotIn #两个结果相反values:- ssd
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: busyboxplus-deploymentlabels:app: busyboxplus
spec:replicas: 3selector:matchLabels:app: busyboxplustemplate:metadata:labels:app:busyboxplusspec:containers:- name: busyboxplusimage: busyboxplusaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- busyboxplustopologyKey: "kubernetes.io/hostname"
~ 
Podantiaffinity（pod反亲和）
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxaffinity:podAntiAffinity: #反亲和requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- nginxtopologyKey: "kubernetes.io/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示例
[root@k8s-master scheduler]# vim example6.yml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: webname: web
spec:replicas: 2selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- image: nginxname: nginx
设定污点为NoSchedule
[root@k8s-master scheduler]# kubectl taint node k8s-node1.org name=lee:NoSchedule
node/k8s-node1.org tainted[root@k8s-master scheduler]# kubectl describe nodes k8s-node1.org | grep Tain
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
污点容忍示例：
设定节点污点
vim example7.yml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: webname: web
spec:replicas: 6selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- image: nginxname: nginxtolerations: #容忍所有污点- operator: Existstolerations: #容忍effect为Noschedule的污点- operator: Existseffect: NoScheduletolerations: #容忍指定kv的NoSchedule污点- key: nodetypevalue: badeffect: NoSchedule