首页 文章 精选 留言 我的

精选列表

搜索[核心工具]，共10010篇文章
优秀的个人博客,低调大师

核心金融场景分布式事务

分布式事务是分布式系统架构设计中的一个技术难点，特别是在这几年越来越火的微服务架构中，服务拆分所带来的跨服务数据一致性问题亟待解决，本文将围绕分布式事务产生背景和蚂蚁金服的分布式事务解决方案（SOFA-DTX）向大家进行介绍。 1、分布式事务产生的背景 1.1、数据库的水平拆分 通常业务系统的数据库起初是单库，但随着业务数据规模的膨胀，单库存储受容量和性能限制，逐渐无法满足业务需求。 如下图所示，将业务数据库水平拆分成多个数据库，是业务发展的必然趋势。 数据库拆分之后，写操作一旦跨多个数据库，单数据库事务就无法保证数据一致性，需要通过分布式事务来保障跨数据库操作的数据一致性。 1.2、业务服务化拆分 在业务发展初期，“大饼一沱”的单业务系统架构，能满足基本的业务需求；但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。 如下图所示，按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，能降低各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。 业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题，需要通过分布式事务来保障多个服务的数据一致性。 2、蚂蚁金服的分布式事务解决方案 蚂蚁金服的分布式事务解决方案(SOFA-DTX), 是蚂蚁金服自主研发的分布式事务中间件，用来保障在大规模分布式环境下业务活动的最终一致性。 2.1、DTX整体架构 DTX以BASE理论的最终一致性为基础，以两阶段提交(2PC)为基本执行框架，整体架构上分为3个部分：客户端、资源管理器、事务管理器： 客户端 通过事务管理器开启、结束分布式事务，通过资源管理器编排分布式事务活动。 资源管理器 负责具体资源的准备、提交和回滚操作，并在整个执行过程中记录事务日志，向事务管理器汇报事务日志和资源执行状态。 事务协调器 负责协调分布式事务的执行：开启分布式事务、记录资源管理器提交的事务日志和资源状态、决定分布式事务最终是提交还是回滚。 DTX按照阶两段提交的方式执行分布式事务，在第一阶段，客户端首先通知事务管理器开启分布式事务；分布式事务开启之后，客户端在分布式事务内编排事务内的资源，依次执行各个资源的一阶段准备操作，每一个资源的准备操作执行情况资源管理器都会向事务管理器汇报；资源编排结束之后，客户端会通知事务管理器分布式事务一阶段结束： 在第二阶段，事务管理器会根据事务所有资源的一阶段执行情况，决定整个分布式事务最终是提交还是回滚，进而驱动所有资源二阶段的提交/回滚操作： 根据资源管理器类型的不同，DTX分为TCC模式、FMT模式和XA模式； 2.2、TCC模式 DTX的TCC（Try-Confirm-Cancel）模式下，分布式事务的资源是TCC服务，TCC服务需要用户编码实现。 如上图所示，DTX事务管理器分两阶段协调所有TCC资源，在一阶段调用所有TCC服务的prepare方法，如果所有资源均prepare成功，那么在第二阶段事务管理器会调用所有TCC资源的commit方法；如果在第一阶段任一资源prepare失败，那么在第二阶段事务管理器会调用所有资源的rollback方法；最终所有TCC资源要么全部提交，要么全部回滚。 蚂蚁金服大部分业务系统的分布式事务方案均采用TCC模式，由业务层实现两阶段的TCC服务，以确保业务数据一致性和性能达到最佳平衡； 2.3、FMT模式 TCC服务的实现及其约束条件都需要业务方提供，这无疑增加了DTX的接入门槛，所以我们在TCC模式之后继续往前推进发展，提出了FMT（Framework-managed transactions）模式来解决接入便捷性的问题。 如下图所示，FMT模式与TCC模式相同的是事务协调者也是分两阶段协调FMT资源，不同的是FMT的资源管理器；在FMT资源管理器中，用户的业务SQL作为资源的一阶段，DTX框架会自动为该业务SQL生成二阶段的提交和回滚操作。 FMT模式下，用户只需关注自身的业务SQL，DTX对业务逻辑的实现无任何侵入，用户接入更加方便快捷。 2.4、XA模式 DTX的TCC模式和FMT模式，基本解决了分布式事务的最终一致性问题，但是不能很好的支持实时一致性；为了解决分布式事务的实时一致性问题，DTX基于标准XA协议推出XA模式。 XA模式下，事务管理器通过数据库的标准XA接口，分两阶段协调所有的数据库资源，在一阶段调用所有XA事务的xa_prepare接口，在第二阶段执行所有XA事务的xa_commit/xa_rollback，最终完成分布式事务的执行。 XA模式借助数据库的XA协议协调数据库资源，借助数据库的MVCC特性达到一致性读写，实现了一致性读写的分布式解决方案。 3、总结 SOFA-DTX在10年的发展历程中，伴随着支付宝业务的飞速发展、架构的快速演进和业务量的井喷式增长，不断帮用户解决复杂场景的一致性问题，提供了高性能、高可用性的分布式事务解决方案；DTX自身演进的三种模式：TCC、FMT和XA相互之间也是功能互补，相辅相成，形成了蚂蚁金服完善的分布式事务解决方案。 分布式事务SOFA-DTX全面覆盖金融场景，金融级容灾保障、提供丰富的接入模式并且使用简洁易于接入；目前已经应用在支付宝、网上银行、蚂蚁财富、芝麻信用、南京银行等项目中。
2018-07-09
优秀的个人博客,低调大师

hadoop核心组件zookeeper简介与特点

zookeeper是一个针对大型分布式系统的可靠协调系统。 1）它提供的功能包括：配置维护，名字服务，分布式同步，组服务等； 2）它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效，功能稳定的系统提供给用户； 特点： 1，最终一致性：为客户端展示同一试图 2，可靠性：如果一条消息被一台服务器接受，那么它将被所有的服务器接受。 3，实时性：zookeeper不能保证两个客户端同时得到刚刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 4，等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 5，原子性：更新操作要么成功，要么失败，没有中间状态。 6，顺序性：对于所有server，同一消息发布顺序一致。 基本原理 server很多，有主从之分，不过有一个leader,其他是follower, 每个server，在内存中存有一份数据，启动时，将选举出一个leader，根据poxos协议选举 leader负责处理数据更新操作，用到zab协议 一个更新操作成功的标志，大多数server在内存，成功修改数据（一个有5个，有3个写成功了） 本文转自 skinglzw 51CTO博客，原文链接：http://blog.51cto.com/skinglzw/1833186，如需转载请自行联系原作者
2017-11-26
优秀的个人博客,低调大师

Docker核心原理-资源隔离和限制

通常情况运行docker容器没有指定具体哪个cpu和内存的分配，其实docker官方给出了，docker容器可以运行在指定CPU上通过docker run --help可以看到: 先制作docker镜像: 编写Dockerfile 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 [root@linux-node1~] #cdstress/ [root@linux-node1stress] #catDockerfile FROMcentos ADDepel-6.repo /etc/yum .repos.d/ RUNyum-y install stress&&yumcleanall ENTRYPOINT[ "stress" ] [root@linux-node1stress] # [root@linux-node1stress] #dockerbuild-tstress. SendingbuildcontexttoDockerdaemon4.096kB Step1:FROMcentos --->970633036444 Step2:ADDepel-6.repo /etc/yum .repos.d/ --->77600d6b488e Removingintermediatecontainerf141f47cb34f Step3:RUNyum-y install stress&&yumcleanall --->Running in 0949035c73da Loadedplugins:fastestmirror,ovl http: //mirrors .aliyuncs.com /epel/6/x86_64/repodata/98697cba0d79c083725de0c38b11c15878b35f5e27262becc02cd7ed1a13ac22-updateinfo .xml.bz2:[Errno12]Timeoutonhttp: //mirrors .aliyuncs.com /epel/6/x86_64/repodata/98697cba0d79c083725de0c38b11c15878b35f5e27262becc02cd7ed1a13ac22-updateinfo .xml.bz2:(28, 'Connectiontimedoutafter30001milliseconds' ) Tryingothermirror. Determiningfastestmirrors *base:mirrors.zju.edu.cn *epel:mirrors.aliyun.com *extras:mirrors.zju.edu.cn *updates:mirrors.cqu.edu.cn ResolvingDependencies -->Runningtransactioncheck --->Packagestress.x86_640:1.0.4-4.el6willbeinstalled -->FinishedDependencyResolution DependenciesResolved ================================================================================ PackageArchVersionRepositorySize ================================================================================ Installing: stressx86_641.0.4-4.el6epel36k TransactionSummary ================================================================================ Install1Package Totaldownloadsize:36k Installedsize:89k Downloadingpackages: Runningtransactioncheck Runningtransaction test Transaction test succeeded Runningtransaction Installing:stress-1.0.4-4.el6.x86_641 /1 install -info:Nosuch file ordirectory for /usr/share/info/stress .info Verifying:stress-1.0.4-4.el6.x86_641 /1 Installed: stress.x86_640:1.0.4-4.el6 Complete! Loadedplugins:fastestmirror,ovl Cleaningrepos:baseepelextrasupdates Cleaningupeverything Cleaninguplistoffastestmirrors --->504c747b9b51 Removingintermediatecontainer0949035c73da Step4:ENTRYPOINTstress --->Running in ea8d8eb8fb87 --->7e1e0e5cf825 Removingintermediatecontainerea8d8eb8fb87 Successfullybuilt7e1e0e5cf825 [root@linux-node1stress] #dockerimages REPOSITORYTAGIMAGEIDCREATEDSIZE stresslatest7e1e0e5cf825Aboutaminuteago214MB ningx- file v01460b5af495c43daysago531.9MB nginx /ningx 1.9.3v02097c98e3cb2b3daysago534.6MB nginx1.9.3d2cfb9ed3f2b3daysago534.6MB docker.io /centos latest97063303644411daysago196.7MB [root@linux-node1stress] # 查看docker run命令帮助输出: 1 2 3 4 5 6 7 [root@linux-node1stress] #dockerrun--help|grepcpu --cpu-sharesCPUshares(relativeweight) --cpu-periodLimitCPUCFS(CompletelyFairScheduler)period --cpu- quota LimitCPUCFS(CompletelyFairScheduler) quota --cpuset-cpusCPUs in which toallowexecution(0-3,0,1) --cpuset-memsMEMs in which toallowexecution(0-3,0,1) [root@linux-node1stress] # 启动一个容器: 1 2 [root@linux-node1stress] #dockerrun-it--rm--cpuset-cpus=0stress--cpu1 stress:info:[1]dispatchinghogs:1cpu,0io,0vm,0hdd 在另外一个窗口查看使用情况cpu: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [root@linux-node1~] #top top -00:55:15up13:39,2 users ,loadaverage:0.58,0.47,0.69 Tasks:406total,2running,404sleeping,0stopped,0zombie %Cpu0:100.0us,0.0sy,0.0ni,0.0 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu1:0.3us,0.3sy,0.0ni,99.3 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu2:0.0us,0.0sy,0.0ni,100.0 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu3:0.0us,0.0sy,0.0ni,100.0 id ,0.0wa,0.0hi,0.0si,0.0st KiBMem:773004total,204488 free ,194528used,373988buff /cache KiBSwap:2098172total,2096324 free ,1848used.399644availMem PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND 5944root2007260920R100.00.00:52.46stress 335root200000S0.30.01:17.95kworker /3 :1 1569root200553044136242952S0.31.80:13.46tuned 4779root200000S0.30.00:02.25kworker /1 :1 5946root20015794825041548R0.30.30:00.18 top 同样，再开启一个窗口: 1 2 [root@linux-node1stress] #dockerrun-it--rmstress--cpu1 stress:info:[1]dispatchinghogs:1cpu,0io,0vm,0hdd 再查切换到其他窗口查看cpu使用情况 1 2 3 4 5 6 7 8 9 10 [root@linux-node1~] #top top -00:57:52up13:41,3 users ,loadaverage:1.50,0.96,0.84 Tasks:414total,2running,412sleeping,0stopped,0zombie %Cpu0:100.0us,0.0sy,0.0ni,0.0 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu1:0.0us,0.0sy,0.0ni,100.0 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu2:0.0us,0.0sy,0.0ni,100.0 id ,0.0wa,0.0hi,0.0si,0.0st %Cpu3:0.0us,2.7sy,0.0ni,97.3 id ,0.0wa,0.0hi,0.0si,0.0st KiBMem:773004total,195560 free ,199560used,377884buff /cache KiBSwap:2098172total,2096576 free ,1596used.393660availMem PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND 注意命令: docker run -it --rm stress --cpu 1 docker run -it --rm --cpuset-cpus=0 stress --cpu 1 --cpuset-cpus后面跟cpu总个数，为docker容器指定的，而--cpu是用多少个cpu来运行，只能是1、2、3、4 ...N等等 本文转自027ryan 51CTO博客，原文链接：http://blog.51cto.com/ucode/1836484，如需转载请自行联系原作者
2017-11-07
优秀的个人博客,低调大师

Android View相关核心知识问答

作者分享了自己对View相关知识的理解，有兴趣的可以学习下。如果有不同的见解欢迎留言~此外，作者并没有提供案例，如果有兴趣可以针对问题，考虑实际使用场景，并提供实际的案例，那就更好了。 1.View坐标 (1)View的坐标参数 主要有哪些?分别有什么注意的要点? 几个主要坐标参数是： 1)Left，Right，top,Bottom;它们表示的并非是距离屏幕左上方的绝对值，而是表示 view 和 他的父控件的相对坐标值，并且代表View的初始坐标，在绘制完毕后就不会再改变 。 2)X和Y 表示的是View左上角相对于父控件的坐标值，即实时相对坐标。 3)TranslationX,TranslationY 这2个值 默认都为0，表示的是相对于父控件的左上角的偏移量。 它们之间的换算关系是： x=left+translationX; y=top+translationY; width=right-left; height=bottom-top; left=getLeft(); (2)View中的几个重要方法? 1)onMeasure(widthMeasureSpec, heightMeasureSpec) onMeasure 过程决定了View的宽高，Measure完成后可以通过getMeasureWidth和getMeasureHeight方法获取到view的测量后的宽高，在几乎所有的情况下都会等于最终view的宽高 onMeasure()方法接收两个参数，widthMeasureSpec和heightMeasureSpec，这两个值分别用于确定视图的宽度和高度的规格和大小。 2)onLayout(boolean changed, int left, int top, int right, int bottom) layout 过程决定了View的四个顶点的坐标和实际的View的宽高，完成以后可以通过getTop,getBottom,getLeft,getRight来获取View的四个顶点位置，并通过getWidth,getHeight获取View的最终宽高 3)onDraw(Canvas canvas) draw过程则决定了View的显示，完成draw后view会显示在屏幕上 绘制背景(background.draw(Canvas)) 绘制自己 protected void onDraw(Canvas canvas) onDraw绘制自己，新建一个paint 在canvas上绘制自己的图形 绘制children (dispatchDraw) dispatchDraw会遍历调用所有子元素的draw方法 绘制装饰(onDrawScrollBars) 4)isEnabled() 当前视图是否可用。 可以调用setEnable()方法来改变视图的可用状态，传入true表示可用，传入false表示不可用。 它们之间最大的区别在于，不可用的视图是无法响应onTouch事件的。 5)isFocused() 当前视图是否获得焦点 通常情况下有两种方法可以让视图获得焦点，即通过键盘的上下左右键切换视图，以及调用requestFocus()方法。 而现在的Android手机几乎都没有键盘了，因此基本上只可以使用requestFocus()这个办法来让视图获得焦点了。 而requestFocus()方法也不能保证一定可以让视图获得焦点，它会有一个布尔值的返回值，如果返回true说明获得焦点成功，返回false说明获得焦点失败。一般只有视图在focusable和focusable in touch mode同时成立的情况下才能成功获取焦点，比如说EditText。 6)offsetTopAndBottom(int offset)及 offsetLeftAndRight(int offset) offsetTopAndBottom直接改变的是top, bottom, 相当于在parent中上下平移View的位置; offsetLeftAndRight直接改变的是left, right, 相当于在parent中左右平移View的位置; View的边界直接发生了变化，又因为View和他的子View的相对位置没变，所以他的子View的边界也跟着变化了。 (3)当获取View的宽高为0时怎么处理? 如果我们要获取一个view的位置坐标，可以直接子findviewbyid之后获取，也可以在view的点击事件中获取，当然也可以在其他地方获取。如果我们直接在finedviewbyid之后获取有时候就会获取失败，获取到的值是0; 分析原因可能有以下三种情况： 1)view的宽高本身就是0;2)View的visibility属性为gone;3)视图还未绘制完成，当然未绘制完成也表现在不同的方面，比如，activity所代表的界面还没显示出来没有添加到WindowPhone的DecorView上;要获取的view没有被添加到DecorView上。 我们主要要说的是第三种情况，可以怎么解决呢? 1)在View的事件回调里获取;这时候该view已经被显示即被添加到DecorView上 如点击事件 触摸事件 焦点事件等 2)在activity被显示出来时即添加到了DecorView上时获取宽和高如 onWindowFocusChanged() 回调方法 3)在onResume方法中通过post(Runnable) 4)在onCreate()或onResume()等方法中需要获取宽高时使用getViewTreeObserver().addOnGlobalLayoutListener() 来为view添加回调在回调里获得宽度或者高度获取完后让view删除该回调 5)view.measure(int widthMeasureSpec,int heightMeasureSpec) 手动对view进行measure来得到view的宽高(该方式比较特殊，需要考虑好传入的spec) 2.View滑动 1、让view滑动总共有几种方式，分别要注意什么?都适用于那些场景? 1)通过view本身提供的scrollTo和scrollBy来滑动;但是只能滑动view的内容 不可以滑动view本身。比如textview 调用这2个方法 滑动的就是显示出来的字的内容。详情查看 http://www.jianshu.com/p/2b48551d53192 2)利用补间动画将view平移 补间动画平移view，是对view的影像的操作，它不能真正改变view的位置参数。 3)利用属性动画平移view ObjectAnimator .ofFloat(view,"translationX",0,500) .setDuration(2000) .start(); ObjectAnimator .ofFloat(view,"translationY",0,500) .setDuration(2000) .start(); 属性动画平移view需要兼容3.0以下版本 4)通过改变view的LayoutParams使得view重新布局从而实现滑动 ViewGroup.MarginLayoutParamsparams =view.getLayoutParams(); params.leftMargin+=500; (2)三种滑动方式的比较 scrollTo和scrollBy这种方式使用简单操作方便，但是它只能滑动view的内容，并不能直接滑动view本身 补间动画滑动，是对view影像的操作，它同样不能真正改变view的位置参数 属性动画滑动可以改变view的位置参数，但是需要兼容3.0以下版本 LayoutParams这种方式，使用起来稍有麻烦，使用于有交互的view (3)使用动画(非属性动画)来实现view的滑动 有什么后果? 答：实际上view动画 是对view的表面ui 也就是给用户呈现出的视觉效果 来做的移动，动画本身并不能移动view的真正位置，属性动画除外。 动画播放结束以后,view最终还是会回到自己的位置的。当然了你可以设置FillAfter 属性 来让动画播放结束以后 view表象停留在变化以后的位置。 所以这会带来一个很严重的后果。比如你的button在屏幕的左边，你现在用个动画 并且设置了fillafter属性让他去了右边。 你会发现 点击右边的button 没有click事件触发，但是点击左边的 却可以触发，原因就是右边的button 只是view的表象，真正的button 还在左边没有动过。 你一定要这么做的话 可以提前在右边button移动后的位置放一个新的button，当你动画执行结束以后 把右边的visible，左边的让他gone就可以了。 (4)view的滑动渐变效果有哪些方法? 三种， 第一种是Scroller 也是使用最多的。 第二种就是动画，动画我就不多说了，不属于本文范畴。 第三种也是我们经常使用的就是用handler ，每隔一个时间间隔 来更新view的状态。 (5)onTouchEvent和GestureDetector 在什么时候用哪个比较好? 只有滑动需求的时候 就用前者，如果有双击等这种行为的时候 就用后者。 本文作者：佚名 来源：51CTO
2017-08-01
优秀的个人博客,低调大师

Kubernetes核心原理（二）之Controller Manager

版权声明：本文为博主原创文章，未经博主允许不得转载。如需转载请联系本人，并标明出处和作者。 本文CSDN博客地址：http://blog.csdn.net/huwh_/article/details/75675761 1.Controller Manager简介 Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。 每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。 2.Replication Controller 为了区分，资源对象Replication Controller简称RC,而本文是指Controller Manager中的Replication Controller，称为副本控制器。副本控制器的作用即保证集群中一个RC所关联的Pod副本数始终保持预设值。 只有当Pod的重启策略是Always的时候（RestartPolicy=Always），副本控制器才会管理该Pod的操作（创建、销毁、重启等）。 RC中的Pod模板就像一个模具，模具制造出来的东西一旦离开模具，它们之间就再没关系了。一旦Pod被创建，无论模板如何变化，也不会影响到已经创建的Pod。 Pod可以通过修改label来脱离RC的管控，该方法可以用于将Pod从集群中迁移，数据修复等调试。 删除一个RC不会影响它所创建的Pod，如果要删除Pod需要将RC的副本数属性设置为0。 不要越过RC创建Pod，因为RC可以实现自动化控制Pod，提高容灾能力。 2.1.Replication Controller的职责 确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量。 通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。 通过改变RC中的Pod模板来实现系统的滚动升级。 2.2.Replication Controller使用场景 使用场景 说明 使用命令 重新调度 当发生节点故障或Pod被意外终止运行时，可以重新调度保证集群中仍然运行指定的副本数。 弹性伸缩 通过手动或自动扩容代理修复副本控制器的spec.replicas属性，可以实现弹性伸缩。 kubectl scale 滚动更新 创建一个新的RC文件，通过kubectl 命令或API执行，则会新增一个新的副本同时删除旧的副本，当旧副本为0时，删除旧的RC。 kubectl rolling-update 滚动升级，具体可参考kubectl rolling-update --help,官方文档：https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ [root@node5 ~] # kubectl rolling-update --help Perform a rolling update of the given ReplicationController. Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector. Usage: kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags] Aliases: rolling-update, rollingupdate Examples: # Update pods of frontend-v1 using new replication controller data in frontend-v2.json. $ kubectl rolling-update frontend-v1 -f frontend-v2.json # Update pods of frontend-v1 using JSON data passed into stdin. $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f - # Update the pods of frontend-v1 to frontend-v2 by just changing the image, and switching the # name of the replication controller. $ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # Update the pods of frontend by just changing the image, and keeping the old name $ kubectl rolling-update frontend --image=image:v2 3.Node Controller kubelet在启动时会通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server接收到信息后将信息更新到etcd中。 Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能。流程如下 1、Controller Manager在启动时如果设置了--cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node节点生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，防止不同的节点的CIDR地址发生冲突。 2、具体流程见以上流程图。 3、逐个读取节点信息，如果节点状态变成非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列删除。 4.ResourceQuota Controller 资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。 支持三个层次的资源配置管理： 1）容器级别：对CPU和Memory进行限制 2）Pod级别：对一个Pod内所有容器的可用资源进行限制 3）Namespace级别：包括 Pod数量 Replication Controller数量 Service数量 ResourceQuota数量 Secret数量 可持有的PV（Persistent Volume）数量 说明： k8s配额管理是通过Admission Control（准入控制）来控制的； Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota； LimitRanger作用于Pod和Container； ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。 ResourceQuota Controller流程图： 5.Namespace Controller 用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息。 如果Namespace被API标记为优雅删除（即设置删除期限，DeletionTimestamp）,则将该Namespace状态设置为“Terminating”,并保存到etcd中。同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。 6.Endpoint Controller Service、Endpoint、Pod的关系： Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。 如果监测到Service被删除，则删除和该Service同名的Endpoints对象； 如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。 如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。 kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。 7.Service Controller Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service变化，如果是一个LoadBalancer类型的Service，则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。 参考《Kubernetes权威指南》
2017-07-28

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册