其他分享
首页 > 其他分享> > 散记

散记

作者:互联网

service
	提供相同服务的一组pod可以抽象成一个service,
	固定IP - 对外提供服务的统一入口,每个service都有一个虚拟IP地址(VIP, clusterIP)和端口号供客户端访问。由于Pod重建等原因导致的pod ip地址变化, service始终保持对外ip端口不变
	负载分发策略有两种: RoundRobin(轮询), SessionAffinity (基于客户端IP地址, 第一次客户端访问后端某个pod,之后的请求都转发到这个pod上)
	CoreDNS附件会为集群中的每个Service对象生成唯一的DNS名称标识
	service -> endpoint -> pod
	
endpoint
	endpoint 维护了 service name到 一组[pod ip和端口号]的映射
	endpoint controller
		生成和维护endpoint对象
		监听service和对应pod的变化
			service被创建/更新/删除,创建/更新/删除和该service同名的endpoint对象
			监听到pod事件,将podIp记录到endpoint中
	kubectl get endpoints
	
kube-proxy
	kube-proxy组件负责管理各Pod与Service之间的网络连接
	kube-proxy监听service和endpoint的变化,将需要新增的规则添加到iptables中。
	为Service提供cluster内部的服务发现和负载均衡
	每台机器上都运行一个 kube-proxy 服务
	kube-proxy 目前仅支持 4层 TCP 和 UDP,不支持 HTTP 路由,HTTP由Ingress解决。
	访问Service的请求,不论是Cluster IP+TargetPort;还是IP+NodePort的方式,都被Node节点的Iptables规则重定向到Kube-proxy监听Service服务代理端口。kube-proxy接收到Service的访问请求后,根据负载策略,转发到后端的Pod。
	Client ==> NodeIP:NodePort ==> Service Ip:ServicePort ==> PodIP:ContainerPort
	IPVS(virtual server)
		iptables 线性查找匹配、全量更新,随着Service 数量的增大,其性能会显著下降。
		ipvs 采用哈希表而且运行在内核态.
		当Service 数量达到一定规模时,哈希表的查询速度优势就会显现出来,从而提高Service 的服务性能。
		IPVS 是建立于 Netfilter之上的高效四层负载均衡器,支持 TCP 和 UDP 协议
		
kubelet
	服务注册

容器编排 
	1. 集群管理与基础设施抽象:将多个虚拟机或物理机构建成协同运行的集群,并将这些硬件基础设施抽象为一个统一的资源池。
	2. 资源分配和优化:基于配置清单中指定的资源需求与现实可用的资源量,利用成熟的调度算法合理调度工作负载。
	3. 应用部署:跨主机自动部署容器化应用,支持多版本并存、滚动更新和回滚等机制。
	4. 应用伸缩:应用实例规模的自动或手动伸缩。
	5. 应用隔离:租户、项目或应用进行访问隔离。
    6. 服务可用性:利用状态监测和应用重构等机制确保服务始终健康运行。
master
	客户端访问集群的唯一入口
	1. API Server: 提供RESTful API对k8s集群发送指令、获取信息。结果存在etcd中。
	2. ControllerManager(控制器管理器): 根据API Server接收到的请求,驱动对应资源逼近或者达到预期的状态。Node、Pod、Server、Endpoint、ServiceAccount和Token等数十种类型API对象的控制器。这些控制器被封装到一个kube-controller-manager二进制文件,每一个控制器单独启一个进程。
	3. Scheduler: 将API Server接收到的创建pod请求,根据软硬件、策略约束、亲和力等特性,调度到合适的节点上。
	4. etcd: 只有api server 能和etcd通讯。提供监听(watch)机制, 监听和推送变更。
worker
	接收来自Master的指令如管理Pod对象、调整网络规则以合理完成路由和转发流量等任务
	1. kubelet: 
		接收并执行Master发来的指令
		监视当前节点上Pod的健康状态,并在任何Pod出问题时重建新实例
	2. kube-proxy: 
		1. 把API Server上的Service资源对象转换为当前节点上的ipvs规则,这些规则将发往Service对象ClusterIP
的流量分发至后端的Pod端点
		2. 确保集群中Node、Service和Pod对象之间的有效通信
	3. runtime: 
		kubelet通过CRI(容器运行时接口)支持多种类型的OCI容器运行时,如docker、containerd

3种网络
	1.    节点网络: 常规网络,主机之间的通信
	2.     pod网络: 的CNI网络插件实现,如calico
	3. Service网络: kube-proxy配置为节点的ipvs规则

标签:散记,Service,service,proxy,pod,kube,Pod
来源: https://www.cnblogs.com/abc608088/p/16593662.html