K8s调度器Scheduler
当创建k8s pod的时候调度器会决定pod在哪个node上被创建且运行，调度器给apiserver发出了一个创建pod的api请求，apiserver首先将pod
当创建k8s pod的时候调度器会决定pod在哪个node上被创建且运行，
调度器给apiserver发出了一个创建pod的api请求，apiserver首先将pod的基本信息保存在etcd，apiserver又会把这些信息给到每个node上的kubelet进程，kubelet一直在监听这些信息，当kubelet发现这个pod的节点信息跟它当前运行的节点一致的时候，就会创建pod进程以及容器当中的docker image进程，创建相应的命名空间，使得进程之间互相隔离，这样pod就在这个节点上运行起来了。
k8s调度器会尽量的去保证所有节点上的资源是相对平衡的，判断节点资源（CPU、内存、存储、端口等）是否适合Pod的资源申请。
查看K8s资源在etcd中的信息
借助kube-etcd-helper这个工具查看etcd中的内容，
写一个操作etcd命令的脚本./etcdheloper.sh，指定etcd的地址，鉴权需要的证书等信息，
查看k8s资源列表，./etcdheloper.sh ls
这是etcd中保存的k8s资源信息，查看指定的pod信息，
跟调度器相关的是这个nodeName，
验证调度器的工作方式
有了etcd helper可以更加详细的看下调度器的工作原理，调度器一直在监听k8s中的pod的创建，通过etcd watch的功能可以去监听一个pod的创建并且看到创建的整个过程。
创建这个pod，使用etcd helper来监听下这个pod在etcd当中变动的过程，
通过这个命令可以看到在etcd中关于这个pod产生了4次变动，每次变动都是一个json，通过JSON Diff工具比较每次json都变动了哪些内容，
第一个json和第二个json比较，多了一个nodeName，
第一次给apiserver发送请求把这个信息保存在etcd当中的时候还没有nodeName，第二次就是更新nodeName，调度器通过算法决定了这个pod要在这个node上创建，
这里声明了pod已经被调度了；
第三次的json相比第二次json的变更内容：
记录了pod中container容器的启动状态和pod的ip。
Pod指定节点运行
这是集群中node的情况，
查看指定node的详情，红色部分决定了node的名称，
这个分别代表节点所在的区域和时区，
每个地域完全独立，但同一个地域的可用区中间是互通的。
地域是指电力和网络互相独立的区域；同一可用区内实例之间的网络延迟更小；
关键点是电力和网络相互独立，这个是在灾备的时候要考虑的。
数据库、k8s的节点、消息队列等常用的资源都是需要做冗余的，如果在一个可用区内做大量的冗余，
看起来比较安全，一旦这个可用区废掉了，所有的冗余信息在短时间内是不可工作的，跨可用区做冗余可用性就会得到极大的增强。
pod在指定的node上运行。
正常工作的节点
这是正常工作的节点，pod通过kubelet这个进程被创建出来。
kubectl向apiserver发送了一个请求，apiserver就把请求信息存储在etcd数据库里，调度器通过事件的监听，通过调度算法来决定pod将会被调度到哪个节点上去，确定是哪个node之后，所以就在etcd的pod信息里面增加了一个nodeName。
kubelet也进行监听，当它发现调度器分配这个pod到某一个节点信息修改的时候，来看这个节点是不是属于它当前运行的node，如果是的话，就会创建这个pod。
k8s是go语言写的，一般用glog打日志，
k8s 基于glog fork出来一个klog，k8s内核是用klog来记录日志的。
glog有个参数：-v，表示日志的详细程度，
从日志中可以看到，在创建pod的时候，先判断pod是否存在，如果不存在的话，则创建。
有2种情况不属于正常工作的节点，
pod不能被调度到节点或者pod根本不可以在节点上运行，比如这个节点的systemd后台进程有问题导致节点不能正常运行，并不代表节点所在的虚拟机崩溃了，但是作为k8s节点是不能正常运行的，这种情况下node被打上一个污点。
NoScheduler表示不能调度到指定节点上；
NoExecute表示新的pod将不可以被调度到指定node上运行，当前在上面运行的pod也将被驱逐。
参数名称可以任意起，污点一旦被创建，对节点就生效了，ubuntu这个pod状态一直pending，就表示调度不过去 ，原因就是因为这个node被打上了污点。
解除污点，pod就被调度到这个node节点上启动了。
给node打上NoExecute污点，
这个节点上面的这个pod直接就停掉了，
去掉NoExecute污点，新的pod就可以在这个节点上运行了。
给node打污点的情况实际用的比较少，除非排错，比如pod还能在node上跑，不希望新的pod被调度过来，先打一个污点，再在上面排查问题。
如果要重启node或修改配置，一般通过拉警戒线的方式，
跟打污点的效果是一样的，
去除警戒线。
打污点或拉警戒线的使用场景：
场景1，比如阿里云systemd进程因版本的问题需要升级，会用这个命令，
场景2，节点有特殊的工作用途，比如master节点，一般至少用2个node做master节点，阿里云可以去托管master节点，比如当前的集群中只有worker节点没有master节点是因为被阿里云托管了，对于这种情况也需要给master node打上污点，不将pod调度到master node上去。
打污点key有两种形式，一种是以字符串label的方式，
另外一种比如env=prod，
表示节点是测试环境还是生产环境。
除非pod有env=prod并且可以容忍NoExecute这样的标签，才能被调度在这个pod上，
node亲和性
node1 16核64G内存，node2 16核64G内存,node3 32核 64G内存，让pod向性能比较好的node上运行即pod亲和node3，
pod亲和于什么样的node去运行，在调度的时候affinity是必须的，但在实际运行的时候又用不到，只是调度的时候用到。
在调度的时候80%的概率到一个node，20%的概率到另外一个node。
pod的亲和性
details pod运行在哪个node上，ubuntu pod也运行在details pod所在的node上，
实际运用的场景比如前后端的pod运行在同一个node上。启动pod的时候去查有没有满足app:details这个条件的pod，如果有的话，就在运行在这个pod所在的node上。
pod的反亲和性
每个node有不同的hostname，如果发现这个node上已经运行了跟我一样label的pod，那我就不在这个node上运行了，再找一个新的node即同样的一个pod不在同一个node上运行这样的效果，
65这个node上已经运行了ubuntu了，
再启动一个ubuntu，就不会在65这个node上运行了，而是在124这个node上运行，
再运行ubuntu3和ubuntu4，为什么ubuntu4一直pending是因为每个node上都有ubuntu了，4没有node可以运行了。
pod亲和度使用场景比较多，node亲和度几乎用不到，因为同一个集群，尽量使用同样的ecs虚拟机，尽量不要有差异化。
就算要区分环境，比如这2台配置比较小的机器做测试环境，（生产环境的机器要比测试环境多的多，这里只是做假设），更倾向于配成2个不同的vpc（私有云）
，每个vpc有自己独立的网段，2个vpc相对安全些，让2个网段互通可以使用阿里云的cen，
这样比较好，而不是做一个大的集群（里面什么样的node都有），再通过打污点、打标签，个人感觉这样会比较累。
，
