关于美食网站的问卷调查怎么做,网站模板选择,短视频培训机构排名,网站seo关键词优化今天分享如题#xff1a;
Kubernetes 本篇内容源于工作项目需要自学
但K8s确实现在十分的主流so推荐给大家
最近更新缓慢由于工作太忙惹#xff0c;忙里偷闲整理愿分享能与君共勉#x1f4aa;
大家新年快乐#x1f389;
#x1f508;言归正题#xff0c;相信很多朋友…
今天分享如题
Kubernetes 本篇内容源于工作项目需要自学
但K8s确实现在十分的主流so推荐给大家
最近更新缓慢由于工作太忙惹忙里偷闲整理愿分享能与君共勉
大家新年快乐
言归正题相信很多朋友在学习K8S的时候能够借助yaml文档把自己的应用部署到K8S集群上但是对于K8S内部的技术细节和实现原理并不了解而这恰恰正是我们作为开发者提升技术所欠缺的东西。
那么今天我们就来简单总结一下K8S的基本架构和其中的各个组件的概念和原理⚙
在开始正式介绍K8S之前我们首先要搞明白一个问题K8S是用来干什么的⚓ 一、 Kubernetes概况
首先熟悉网购的朋友可能都知道每年的双十一期间会有无数的订单传往淘宝这对阿里的服务器系统的运算能力和承受能力是一个巨大的挑战。毫无疑问哪怕是一台超级计算机面对PB级别的访问业务也会应接不暇。
云计算技术的日益成熟弥补了企业计算能力的不足。所谓云计算就是把许多台单独的计算机的计算能力集中起来承担起单台计算机无法承受的业务。实现云计算我们不得不提到“虚拟化”技术也就是使不同系统不同配置的机器能够提供相同环境的技术☁
而容器技术则是轻量化的虚拟技术。它不需要虚拟出整个操作系统只需要虚拟一个小规模的环境。2013年3月dotCloud公司的创始人之一28岁的Solomon Hykes正式决定将Docker项目开源这使得Docker容器引擎受到了广大企业和开发者青睐。 平常使用过Docker等容器技术的朋友可能会有这样的感受当我们把应用部署在一个或几个容器之中的时候我们需要完成拉取镜像、启动容器、解决不同容器的通信问题、终止容器进程等等一系列操作实在是非常不方便。也就是说怎么实现多台计算机之间的业务调度和资源管理是我们必须要解决的问题。
那么有没有一款容器集群管理工具能够帮我解决这些底层的东西让我专注于业务本身呢
答案当然是有的那就是我们今天的主角
——Kubernetes又被称作K8S。
Kubernetes源于希腊语有“舵”或“飞行员”的意思。而K8S则是由Kubernetes中间的八个字母缩写为数字8得来的。Google采用这个名字的深意就是docker把自己定位成驮着集装箱在大海上遨游的鲸鱼那么Kubernetes就是鲸鱼的掌舵者鲸鱼必须按照其设定的路线巡游。从上边图片中的土拨鼠也能看得出来Kubernetes是使用GO语言开发的。 Kubernetes是一个完备的分布式系统支撑平台具有完备的集群管理能力多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具涵盖了包括开发、部署测试、运维监控在内的各个环节。 从K8S的定义中我们可以知道所谓Kubernetes的核心特点就是能够自主地管理容器来保证云平台中的容器按照用户的期望状态运行比如用户想让apache一直运行用户不需要关心怎么去做Kubernetes会自动去监控然后去重启新建总之让apache一直提供服务同时Kubernetes也提升了工具以及人性化方面让用户能够方便的部署自己的应用。
总而言之Kubernetes的出现使得用户能够轻松地把自己的应用或业务部署在一个K8S集群上而避免了处理集群中可能存在的调度、监控、运维、网络等等诸多问题。那么K8S究竟是怎么做到这些的呢接下来我们就来正式学习一下K8S集群的基本架构。
二、 Kubernetes基本架构
在正式介绍K8S的架构之前请各位读者先思考一个问题如果让你来设计一个由50台计算机组成的集群这个集群可以提供一台超级计算机的计算能力和负载能力那么你会怎么设计
首先我们总得有几台机器是专门负责对整个集群进行管理和调度的吧如果这几台计算机能够提供对外界的接口那就太好不过了。在实际的K8S集群中我们往往会分出几台计算机专门处理这样的管理事务它们被称作“Master”节点。
其次我们必须要有大量的机器负责处理实际的业务。因此我们就可以把剩下的机器都用于提供计算能力它们应当具有正常的运算能力和通信能力。实际中这些节点被称作“Node”节点而在每一个Node节点中都运行着若干Pod进程处理实际的业务。
1. Master
K8S集群的管理节点负责管理集群提供集群的资源数据访问入口。它拥有etcd进行存储运行Api Server进程Controller Manager服务进程及Scheduler服务进程关联工作节点Node。 kube-apiserver是整个k8s集群对外提供服务的唯一接口它提供请求过滤、访问控制等机制是各组件的协调者此API是声明式的简单说就是用户想要什么规格的容器直接跟kube-apiserver说就行了过程不用你管。用户的合法请求会被API放行然后存入etcd中。 是否合法指的是etcd就好像公司领导kuber-apiserver就是门口保安领导规定必须什么样的人你能放进来。k8s将etcd所能接受的数据规格范式加以封装定义在了kube-apiserver中符合规格才能放行。 kube-scheduler资源调度器。kube-apiserver收到新建Pod的请求识别其合法并存入etcd然后kube-scheduler去watch kube-apiserver知道此需求根据预定的调度策略评估出一个最合适Node节点来运行Pod如果没有最合适那就随机最后会把调度的结果记录在etcd中。关于scheduler的更多原理请移步我的博客。 kube-controller控制器。就好比人类的大脑一样负责维护集群的状态、故障检测与恢复、自动扩展、节点状态等等。kube-controller有一个control loop的机制它会循环检测集群中Pod的状态假如Nginx启的不是预期的80端口那就由kube-controller来控制容器重启、重建直到达到预期效果为止。 etcd是一个键值对key:value格式的存储系统保存应用程序配置信息。 总而言之如果把ApiServer比作“接待大厅”的话那么Controller就是负责掌控Api对象运行周期的“控制室”Scheduler就是负责提供调度策略的“调度室”而etcd则是存储着所有资源对象信息的“存储室”。 比方说用户发送新建Nginx容器的请求给kube-apiserverkube-apiserver识别其合法后以键值对的方式存入etcdkube-scheduler和kube-controller通过watch kube-apiserver知道此需求然后kube-scheduler负责资源分配并决定容器运行在哪个Node上至于运行时所需的镜像及运行的健康状态的维护都由kube-controller来负责kube-controller会循环将当前容器的状态与watch到的用户预期的需求做对比看是否匹配。 2. Node
Node是Kubernetes集群架构中运行Pod的服务节点亦叫agent或minion。Node是Kubernetes集群操作的单元用来承载被分配Pod的运行是Pod运行的宿主机。关联Master管理节点拥有名称和IP、系统资源信息。运行docker eninge服务守护进程kunelet及负载均衡器kube-proxy。 每个Node节点都运行着以下一组关键进程。 kubelet负责对Pod对于的容器的创建、启停等任务。 kube-proxy实现Kubernetes Service的通信与负载均衡机制的重要组件。 Docker EngineDocker引擎负责本机容器的创建和管理工作。 container runtime负责pod和容器的运行即cri。
Node节点可以在运行期间动态增加到Kubernetes集群中默认情况下kubelet会想master注册自己这也是Kubernetes推荐的Node管理方式kubelet进程会定时向Master汇报自身情报如操作系统、Docker版本、CPU和内存以及有哪些Pod在运行等等这样Master可以获知每个Node节点的资源使用情况冰实现高效均衡的资源调度策略。
3. K8S部署流程
我们简单分析一下K8S集群部署业务的流程并简单看一看各个组件的作用。 准备包含应用程序的Deployment的yaml文件然后通过kubectl客户端工具发送给ApiServer。 ApiServer接收到客户端的请求并将资源内容存储到数据库(etcd)中。 Controller组件(包括scheduler、replication、endpoint)监控资源变化并作出反应。 ReplicaSet检查数据库变化创建期望数量的pod实例。 Scheduler再次检查数据库变化发现尚未被分配到具体执行节点(node)的Pod然后根据一组相关规则将pod分配到可以运行它们的节点上并更新数据库记录pod分配情况。 Kubelete监控数据库变化管理后续pod的生命周期发现被分配到它所在的节点上运行的那些pod。如果找到新pod则会在该节点上运行这个新pod。
三、 Kubernetes中的资源(API)对象
API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能引入一项新技术一定会新引入对应的API对象支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性元数据metadata、规范spec和状态status。 元数据metadata是用来标识API对象的每个对象都至少有3个元数据namespacename和uid除此以外还有各种各样的标签labels用来标识和匹配不同的对象例如用户可以用标签env来标识区分不同的服务部署环境分别用envdev、envtesting、envproduction来标识开发、测试、生产的不同服务。 规范spec描述了用户期望K8s集群中的分布式系统达到的理想状态Desired State例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3。 状态status描述了系统实际当前达到的状态Status例如系统当前实际的Pod副本数为2那么复制控制器当前的程序逻辑就是自动启动新的Pod争取达到副本数为3。
所有Kubernetes中的资源比如Pod,都通过一个叫URI的东西来区分这个URI有一个UID,URI的重要组成部分是对象的类型比如pod对象的名字对象的命名空间对于特殊的对象类型在同一个命名空间内所有的名字都是不同的在对象只提供名称不提供命名空间的情况下这种情况是假定是默认的命名空间。UID是时间和空间上的唯一。
那么总体介绍完了API对象的定义和特性之后我们就来简单了解一下几种重要的K8S集群中常见的API对象。 1. Pod
K8s有很多技术概念同时对应很多API对象最重要的也是最基础的是微服务Pod。从之前的架构图像中我们也能看出每一个Node上都运行着若干个Pod。Pod是在K8s集群中运行部署应用或服务的最小单元。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库一个Nginx容器用来发布软件另一个容器专门用来从源仓库做同步这两个容器的镜像不太可能是一个团队开发的但是他们一块儿工作才能提供一个微服务这种情况下不同的团队各自开发构建自己的容器镜像在部署的时候组合成一个微服务对外提供服务。
Pod是K8s集群中所有业务类型的基础可以看作运行在K8s集群中的小机器人不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型long-running、批处理型batch、节点后台支撑型node-daemon和有状态应用型stateful application分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet本文后面会挑重点进行介绍。
2. 复制控制器Replication ControllerRC
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个少于指定数目RC就会启动运行新的Pod副本多于指定数目RC就会杀死多余的Pod副本。即使在指定数目为1的情况下通过RC运行Pod也比直接运行Pod更明智因为RC也可以发挥它高可用的能力保证永远有1个Pod在运行。RC是K8s较早期的技术概念只适用于长期伺服型的业务类型比如控制小机器人提供高可用的Web服务。
3. 副本集Replica SetRS
RS是新一代RC提供同样的高可用能力区别主要在于RS后来居上能支持更多种类的匹配模式。副本集对象一般不单独使用而是作为Deployment的理想状态参数使用。
4. 部署(Deployment)
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象可以是创建一个新的服务更新一个新的服务也可以是滚动升级一个服务。滚动升级一个服务实际是创建一个新的RS然后逐渐将新RS中副本数增加到理想状态将旧RS中的副本数减小到0的复合操作这样一个复合操作用一个RS是不太好描述的所以用一个更通用的Deployment来描述。以K8s的发展方向未来对所有长期伺服型的的业务的管理都会通过Deployment来管理。
5. 服务Service
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例随时可能在一个节点上停止在另一个节点以一个新的IP启动一个新的Pod因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作是针对客户端访问的服务找到对应的的后端服务实例。在K8s集群中客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP集群内部通过虚拟IP访问一个服务。
6. 任务Job
Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同单Pod型任务有一个Pod成功就标志完成定数成功型任务保证有N个任务全部成功工作队列型任务根据应用确认的全局成功而标志成功。
还有很多的API对象这里就不一一介绍了。如果没个实例说得太多相信大家也是懵逼的。
六、 总结
Kubernetes作为容器集群管理工具于2015年7月22日迭代到 v 1.0并正式对外公布这意味着这个开源容器编排系统可以正式在生产环境使用。Kubernetes项目凝结了Google过去十年间在生产环境的经验和教训从Borg的多任务Alloc资源块到Kubernetes的多副本Pod在Docker等高级引擎带动容器技术兴起和大众化的同时为容器集群管理提供独了到见解和新思路。
作为开发/测试人员我们除了要能够熟练掌握Kubernetes中的各种命令行、具备部署扩容排错等运维能力还应该时刻注意对K8S各构件和底层原理的学习。只有打好K8S项目的原理基础我们才能提升个人在就业或者工作方面的竞争力而不至于对发生的问题束手无策。
本次分享内容源于CSDN感觉对于我这样的新人来说入门了解很是友好后期整理一下我学习和工作中常用的操作命令行。 以上就是我对走向自律的全部理解
希望我们都能对生活保持热爱❤
以下为之前分享的宝藏内容 我认为资料的价值在于能用、好用不是满足人的占有欲和获得感。所以也请各位擦亮双眼提高标准。得到的同时记得他的价值所在收获的同时也请做好择优标准。BTW,学长做的不好的地方欢迎你们提出来又或者如果屏幕前的你将更好的资源拿出分享那真的十分优秀也希望各位能无私互助。获取资料不强制转发。
希望学长分享的内容对你我都有帮助
