MyLinuxOPS

更具指定的topologyKey可以将节点划分到拓扑结构中去，这种拓扑结构可以实现pod间的亲和和反亲和的关键所在，但是pod的亲和调度仅能将相关的pod分发到相关的单个拓扑中。并且其无法做到均匀的将pod分散到其他拓扑中。 如果我们要将某组pod均匀分布到多个不同的拓扑中去运行，那么我们需要让其去识别多个不同的位置。而拓扑分布式调度不经能实现将pod分散到不同的pod中去还能均匀的让其分布到所有的拓扑中去。 拓扑分布式调度资源定义规范Pod资源规范中的拓扑分布约束嵌套定义在.spec.topologySpreadConstraints字`段中，它用来指示调度器如何根据集群中现有的Pod放置待调度的该Pod规范的实例。 1234topologyKey <string>：拓扑键，用来划分拓扑结构的节点标签，在指定的键上具有相同值的节点归属为同一拓扑；必选字段。labelSelector <Object>：Pod标签选择器，用于定义该Pod需要针对哪类Pod对象的位置来确定自身可放置的位置。maxSkew <integer>：允许Pod分布不均匀的最大程 ...

无论是节点选择器，节点亲和或pod亲和都是让pod来选择节点的，节点只能被动等待。而节点污点和Pod容忍度，则是用来让节点拒绝被调度，除非pod能够容忍节点上所拥有的污点。 污点是节点级的属性，我们可以在节点上设定一组特殊的影响调度的属性，这种属性叫做污点。 一旦节点上有污点，pod将无法调度到此节点之上。除非他能容忍这些污点。如果一个pod容忍了这些污点，从而使的pod被调度到此节点上，此节点还能再次修改容忍度，使的被调度到该节点上的pod的容忍度无法被满足从而起到驱离pod的效果。 这些效果需要在节点上添加一个效用标识（effect）来达成。 污点和容忍度关系 对于Pod-A来说能够容忍有螃蟹和小强标记的污点，那么其能够调度到node01和node03之上 对于Pod-B来说，其没有容忍度，那么其只能调度到node03上。 k8s主节点上的污点k8s的主节点在部署完毕后就自动带有污点： 123root@k8s-master01:~# kubectl describe node k8s-master01 | grep TaintsTaints: node-r ...

Pod亲和调度与节点亲和很相像，所谓节点亲和是用来怕判定pod对节点的倾向性的。 Pod亲和就是Pod彼此之间运行于同一位置的倾向性；如果两个pod之间是亲和的那就意味着两个pod运行在同一位置的倾向性。 所谓同一位置可以是同一节点、同一机架、同一排机架(row)，同一个机房间(room)，同一IDC。 反亲和能实现节点级、机架级、甚至机房级别的冗余。 亲和能实现的是同一机架内的pod间通信速度能更快。 k8s中位置的定义在k8s上定义位置就是在节点上选定一个节点标签或拓扑标签，作为位置判定逻辑时，具有同一标签值的就是同一位置，具有不同标签值的就是不同位置。 上图中以hostname为位置标签，那就表示以节点来区分位置 上图以domain，区域作为标签，那么就以区域来区分位置。如果pod-a和pod-b是亲和的那么他们将分布在同一区域内，如果反亲和，那么他们将会被分布在不同的区域内。 Pod的亲和pod间也存在硬亲和和软亲和的关系，硬亲和则表示两个pod必须运行在同一个位置，而软亲和则是尽量满足运行在同一位置。 Pod亲和定义1234567891011spec: affinity ...

kubernetes的高级调度有以下几种： 节点亲和调度 Pod亲和调度 节点污点和Pod容忍度 拓扑分布式调度 节点亲和调度节点亲和的调度实现方法有以下几种： pod.spec.nodeName：人为指定Pod运行在哪个节点之上 pod.spec.nodeSelector：节点选择器 pod.spec.affinity.nodeAffinity：节点亲和性。节点的亲和中还存在四种情况 亲和：必须运行在该节点上 反亲和：老死不相往来 硬亲和：必须运行在该节点上。 软亲和：如果节点存在就运行在该节点上，如果节点不存在那就退而求其次，选择其他节点 所谓的亲和就是激活调度策略中的预选和优选函数。 nodeName亲和nodeName亲和只需要在pod模板里，pod.spec.nodeName字段内指定所要运行的节点即可。 nodeSelector亲和nodeSelector亲和是依靠Node节点上的标签来实现亲和，所以nodeSelector的亲和分为2步： 在需要运行pod的Node上打上指定的标签，如该节点上存在ssd那就打标 disktype=ssd 在pod模板中pod ...

当一个pod出现在API-Server中，且其尚未绑定到任何节点时，就需要进行调度。 1234567891011# 未绑定是指nodeName没有指定，如果定义了那么调度器就无需工作，直接在指定节点上运行起来root@k8s-master01:~# kubectl explain pod.spec.nodeNameKIND: PodVERSION: v1FIELD: nodeName <string>DESCRIPTION: NodeName is a request to schedule this pod onto a specific node. If it is non-empty, the scheduler simply schedules this pod onto that node, assuming that it fits resource requirements. 调度器基本工作逻辑Scheduler会专门监控API-Server上Pod资源中NodeName字段是否为空，若为空就会启动调度功能。为该Pod ...

Calico除了支持BGP网络之外还支持网络策略。 在默认情况下，k8s上的2个不同名称空间下的Pod是可以相互访问的。k8s的名称空间仅用于为资源名称提供隔离机制，而对于不同名称空间下的pod间相互访问并没有进行隔离。而Calico的网络策略则是用来管控Pod间的通信流量。 所谓的网络测略就是专用于调用节点内核上，能够实施流量控制的API从而定义规则来管控Pod间通信的一种机制。 k8s默认网络策略网络策略是K8S上的一种标准资源。 k8s默认网络策略定义规范12345678910111213141516171819apiVersion: networking.k8s.io/v1 # 资源隶属的API群组及版本号kind: NetworkPolicy # 资源类型的名称，名称空间级别的资源；metadata: # 资源元数据 name <string> # 资源名称标识 namespace <string> # NetworkPolicy是名称空间级别的资源spec: # 期望的状态 podSelector <Object> ...

在大规模的节点网络中如果使用BGP网格，将会产生大量的广播风暴。所以在大规模网路中使用BGP Reflect。 配置Calico工作为BGP Reflect模式在每个节点上工作的BIRD既可以作为BGP客户端，还可以作为BGP Reflect，所以只需要从众多的节点中找出1个或2个将其配置为Reflect即可。 1.在Calico中要使用Reflect需要使用专用的配置文件 12345678910111213141516171819root@k8s-master01:~/yaml/chapter08# vim reflector-node.yamlapiVersion: projectcalico.org/v3kind: Node # 节点为Node，表示为calico的node节点metadata: labels: route-reflector: true # 加label表示要从整个集群中挑选个别节点为reflect，此标签会在后续中使用到 name: k8s-master01 # 此处的名字为calicoctl get nodes中节点的名字s ...

calico默认使用IPIP网络模型，要修改将其改为BGP网格模型需要修改其地址池的详细配置，BGP网格模式一般适用于小规模的网络。 BGP网格模式启用方法1.获取地址池详细配置导出 1234567891011121314151617181920212223root@k8s-master01:~# kubectl calico get ippools -o yamlapiVersion: projectcalico.org/v3items:- apiVersion: projectcalico.org/v3 kind: IPPool metadata: creationTimestamp: "2021-08-06T06:00:24Z" name: default-ipv4-ippool resourceVersion: "6789" uid: 943b85b2-9759-49ce-8f73-78f1f3f8a111 spec: blockSize: 24 cidr: 192.168.0.0/16 i ...

calicoctl和kubectl一样它是在k8s集群之外运行的。为了避免以后在所有的节点上都安装，我们也可以将其以pod的方式运行在所有节点之上。 安装链接：https://docs.projectcalico.org/getting-started/clis/calicoctl/install calicoctl工具的安装方法有以下几种： Install calicoctl as a binary on a single host Install calicoctl as a kubectl plugin on a single host Install calicoctl as a container on a single host Install calicoctl as a Kubernetes pod 插件方式安装calicoctl工具1.下载calicoctl 1root@k8s-master01:~# curl -o kubectl-calico -O -L "https://github.com/projectcalico/calicoctl/r ...

Calico的全称为ProjectCalico。 Calico是三层虚拟网络解决方案(BGP)。每一个节点都是一个vRouter。每个节点上的pod都被当作该路由器后端的一个终端设备为其分配一个IP地址。而各节点上的vRouter都需要通过BGP协议学习生成路由规则，从而实现各节点上的pod之间互联互通。 BGP通信模型BGP通信模型有两种： BGP peer（小规模网络使用）：点对点BGP，如果一个网络中有10个BGP，那是1:9的通信模型，这样将形成n*(n-1)个通信网络。所以在次模型下如果网络规模较大BGP路由学习报文将会占据很大的网络带宽，因而在大规模网络下需要使用另外一种通信模型 BGP Reflector（大规模网络使用）：反射器模型，所有节点都将自己所有拥有的路由信息汇总给Reflector，由Reflector用1:n-1的方式向外进行反射，所以称之为BGP反射器。 小规模网络中BGP peer不存在单点问题，BGP peer宕机会有其他的进行替代。 大规模网络中BGP Reflector需要做冗余。 BGP模型要求所有节点在同一个二层网络中。不一定所有的底层网络 ...