kubernetes
一、kubernetes架构
二、工作流程![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/29656c7b682fe1d95792d036721767a9.png)
核心概念
1.包含多种类型的资源对象:pod,label,service,replication controller等
2.所有资源对象都可以通过kubernetes提供的kubectl工具进行增,删,改,查等操作,并将其保存在etcd中持久化存储。
3.是一个高度自动化的资源控制系统,通过跟踪对比etcd里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。
Pod
是k8s创建或部署的最小/最简单的基本单位,一个Pod代表集群正在运行的一个进程。可以把Pod理解成豌豆荚,而同一Pod内的每个容器是一个个豌豆。
一个Pod由一个或多个容器组成,Pod中容器共享网络、存储和计算机资源,在同一Docker主机上运行。
同一个 Pod之间的容器可以通过localhost 互相访问,并且可以挂载Pod内所有的数据卷;但是不同的 Pod之间的容器不能用localhost 访问,也不能挂载其他 Pod 的数据卷。
pod中网络通信
pod控制器
pod控制器是pod启动的一种模板,用来保证在k8s里启动的pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)
pod控制器
·Deployment:无状态应用部署。Deployment的作用是管理和控制 Pod和Replica8et,管控它们运行在用户期望的状态中。
Replicaset:确保预期的 Pod副本数量。Replicaet 的作用就是管理和控制Pod,管控他们好好干活。但是,Replicaset受控于Deployment。
可以理解成Deployment就是总包工头,主要负责监督底下的工人 Pod干活,确保每时每刻有用户要求数量的 Pod
在工作。如果一旦发现某个工人Pod不行了,就赶紧新拉一个 Pod 过来替换它。而Replicaset就是总包工头手下的小包工头。从 Kis使用者角度来看,用户会直接操作Deployment 部署服务,而当Deployment被部署的时候,KBS 会自动生成要求的ReplicaSet和 Pod。用户只需要关心Deployment 而不操心Replicaset。
资源对象Replication Controller是ReplicaSet的前身,官方推荐用neployment 取代 Replication Controller来部署服务。
Daemonset
确保所有节点运行同一类Pod,保证每个节点上都有一个此类Pod运行,通常用于实现系统级后台任务。(适用于日志收集)
statefulset
有状态应用部署
Job
一次性任务。根据用户的设置,Job管理的 Pod 把任务成功完成就自动退出了。
Cronjob
周期性计划性任务
Label
标签:是k8s特色的管理方式,便于分类管理资源对象。
Label可以附加到各种资源对象上,例如Node、Pod、Service、RC等,用于关联对象、查询和筛选。一个Label是一个key-value的键值对,其中key与value由用户自己指定。
一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除。可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多维度的资源分组管理功能。
与Label类似的,还有Annotation(注释)。
区别在于有效的标签值必须为63个字符或更少,并且必须为空或以字母数字字符(【a-z0-9A-Z】开头和结尾,中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制)
Label选择器(Label selector)
给某个资源对象定义一个Label,就相当于给他打了一个标签:随后可以通过标签选择器(Label selector)查询和筛选拥有某些label的资源对象。
标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。
Service
在k8s的集群里,虽然每个Pod会被分配一个单独的IP地址,但由于Pod是有生命周期的(他们可以被创建,而且销毁之后不会再启动),随时可能会因为业务的变更,导致这个IP地址也会随着Pod的销毁而消失
Service就是用来解决这个问题的核心概念
k8s中的Service
是网关层,可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
Service作用于哪些Pod是通过标签选择器来定义的
Service除了提供稳定的对外访问方式之外,还能起到负载均衡(Load Balance)的功能,自动把请求流量分布到后端所有的服务上,service可以做到对客户端透明的进行水平扩展(scale).而实现service这一功能关键,就是kube-proxy.kube-proxy运行在每个节点上,监听API Server中服务对象的变化,通过以下三种流量调度模式:
userspace(废弃)、iptanles(濒临废弃)、ipvs(推荐,性能最好)来实现网络的转发。
Service是k8s服务的核心,屏蔽了服务细节,统一对外暴露服务接口,真正做到了“微服务”。
service和ingress
service是通过标签选择器关联具有对有label的pod.再把相关pod的IP加入到自己的endpoints当中,service再根据endpoints里的IP进行转发
Ingress
是整个k8s的接入层,负责集群内部通讯;工作在OSI网络参考模型下,第七层的应用,对外暴露的接口,典型的访问方式是http/https.Service只能进行第四层的流量调度,表现形式是ip+port.Ingress则可以调度不同业务域、不同URL访问路径的业务流量。
Name
由于k8s内部,使用“资源”来定义每一种逻辑概念(功能),所以每种“资源”,都应该有自己的“名称”。“资源”有api版本(apiversion)、类别(kind)、元数据(metadata)、定义清单(spec)、状态(status)等配置信息。"名称"通常定义在"资源"的"元数据"信息里。在同一个namespace空间中必须是唯一的。
Namespace
随着项目增多、人员增加、集群规模的扩大,需要一种能够逻辑上隔离k8s内各种"资源"的方法,这就是Namespace。Namespace是为了把一个k8s集群划分为若干个资源不可共享的虚拟集群组而诞生的。不同的Namespace内的“资源”名称可以相同,相同Namespace内的同种“资源”,“名称”不能相同。
合理的使用k8s的Namespace,可以使得集群管理员能够更好的对交付到k8s里的服务进行分类管理和浏览。
k8s里默认存在的Namespace有:default、kube-system、kube-public等。
查询k9s里特定“资源”要带上相应Namespace
总结
控制器
节点控制器 副本控制器 端点控制器 服务账户和令牌控制器 资源配额控制器 命令空间控制器 服务控制器