生产k8s架构
1.apiserver:调度中心2.schedule进行pod节点调度,有时候pod创建完有panding的状态,那么这时就是schedule正在进行调度,controller manager维持pod副本数量,etcd数据库用于存储k8s信息。3.组件是有状态还是无状态APIserver是无状态服务,例如搭建三个节点,那么三个节点都会工作。
1.k8s集群中只用apiserver与etcd进行交互,别的组件不参与与etcd交互
2.所有到master的访问包括node与master的访问,请求都要经过负载均衡器(硬件F5,软件keepalived,haproxy)
3.生产环境二进制安装比kubeadm更稳定,二进制维护相对来说比较简单,搭建比较麻烦
4.kubectl不一定非要在master或者node节点上,只要这台服务器与master节点相通就可以(config文件)
5.无论master节点有几个,建议etcd节点至少是三个(奇数个,偶数会有脑裂的风险,master没有奇偶数量要求,主要是etcd有这个要求),另外,整个k8s集群只有apiserver与etcd进行通信,所以etcd最好与apiserver所在的master节点部署在一起
master节点服务介绍
1.apiserver:调度中心
2.schedule进行pod节点调度,有时候pod创建完有panding的状态,那么这时就是schedule正在进行调度,controller manager维持pod副本数量,etcd数据库用于存储k8s信息。
3.组件是有状态还是无状态
APIserver是无状态服务,例如搭建三个节点,那么三个节点都会工作。
Schedule,Controller manager是有状态服务,不论部署多少个节点,真正工作的只有一个(一对一调用)Schedule,Controller manager(如果部署三个节点,都工作,则会出现功能重复调用的问题,apiServer不会)。
node工作节点服务介绍
1.kubelet:kubelet主要负责将node节点和节点上的pod状态上报给apiserver,apiserver将状态存储到etcd中
2.kube-proxy:负责pod之间的负载均衡,例如通过svc访问到pod,涉及到的通信和负载均衡就是由kube-proxy做的
3.CoreDNS在pod内ping一个svc的名称,将svc名称解析成IP地址。
在pod内执行cat /etc/resolv.conf可以看到pod内配置了一个nameserver的ip地址,这个地址就是CoreDNS的IP地址,所以这个pod是能通过CoreDNS解析其他svc的
4.calico将每个节点充当一个路由器。
calico分配给pod的IP,在master节点直接ping是可以通的。calico给系统添加了这个路由网段,所以可以ping通 ,
例如:
随便找一个pod的IP,本地可以直接ping通,route -n发现系统添加了这条路由,路由下一跳是在10.103.236.204这个node节点上
kubectl get node就可以看到node节点上这个IP
更多推荐
所有评论(0)