首页 文章 精选 留言 我的

精选列表

搜索[计算机组成原理]，共10000篇文章
优秀的个人博客,低调大师

Spark shell的原理深入研究

Spark shell是一个特别适合快速开发Spark原型程序的工具，可以帮助我们熟悉Scala语言。即使你对Scala不熟悉，仍然可以使用这个工具。Spark shell使得用户可以和Spark集群交互，提交查询，这便于调试，也便于初学者使用Spark。 感受到Spark shell是如此的方便，因为它很大程度上基于Scala REPL(Scala 交互式shell，即Scala解释器)，并继承了Scala REPL(读取-求值-打印-循环)(Read-Evaluate-Print-Loop)的所有功能。 Sprk Shell虽然强大，但多数时候你还是会运行编译后的代码，而不是使用REPL环境，即API。 这里啊，首次使用spark一般都是从执行spark-shell开始的。当在键盘上敲入spark-shell并回车时，我用源码来分析。 这里是个知识点。若没有对spark进行安装集群部署，直接将spark的压缩包，解压，然后执行spark-shell，默认是local模式。 关于spark的安装部署方式，我这里不多赘述。请移步 Spark运行模式概述 而，我们这一句将spark进行了集群安装（Jdk、Scala、Hadoop、Spark）等。 执行spark-shell，则是，集群模式。 想清晰的学习，请移步 Spark Standalone与Spark on YARN的几种提交方式 spark-shell的脚本 export SPARK_SUBMIT_OPTS "$FWDIR"/bin/spark-submit --class org.apache.spark.repl.Main --name "Spark shell" "$@" spark-submit的脚本 exec "$SPARK_HOME"/bin/spark-class org.apache.spark.deploy.SparkSubmit "$@" spark-class的脚本 # Find the java binary if [ -n "${JAVA_HOME}" ]; then RUNNER="${JAVA_HOME}/bin/java" else if [ `command -v java` ]; then RUNNER="java" else echo "JAVA_HOME is not set" >&2 exit 1 fi fi exec "$RUNNER" -cp "$LAUNCH_CLASSPATH" org.apache.spark.launcher.Main "$@" 总结: 1、运行spark-shell，则会运行spark-submit。 2、spark-shell其实是对spark-submit的一层封装!!! 3、在某些情况下，可能需要对环境变量及JVM启动参数做修改，还可能涉及ulimit中的某些配置项，那么可以将这些指令添加到sparl-class中。 4、SparkSbumit当中定义了mian函数，在它的处理中会将Spark Repl运行起来，Spark Repl能够接收用户的输入，通过编译与运行，返回结果给用户。 这就是Spark具有交互处理能力的原因所在。 调用顺序： SparkSbumit -> repl.Main -> SparkILoop 本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/5717800.html，如需转载请自行联系原作者
2017-11-13
优秀的个人博客,低调大师

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
优秀的个人博客,低调大师

ArangoDB介绍——未知架构和底层原理

ArangoDB介绍 ArangoDB是一个开源NoSQL数据库，官网：https://www.ArangoDB.org/ ArangoDB支持灵活的数据模型，比如文档Document、图Graph以及键值对Key-Value存储。ArangoDB同时也是一个高性能的数据库，它使用类SQL查询或JavaScript扩展来构建高性能应用。 ArangoDB值得称赞的一点，可以在树莓派上运行ArangoDB 1.4版。 ArangoDB的特性： 1）多模型数据库 可以灵活的使用键值对、文档、图及其组合构建你的数据模型。 2）查询便利 ArangoDB有类SQL的AQL查询语言，还可以通过REST方式进行查询。 3）可通过JavaScript进行扩展 无语言范围的限制，可以从前端到后端都使用同一种语言。 4）高性能 ArangoDB速度极快 5）Foxx - 构建自己的API 用JavaScript和ArangoDB构建应用，Foxx运行在DB内部，可快速访问数据。 6）空间利用率高 跟其它文档型数据库相比，ArangoDB占用的存储空间更少，因为ArangoDB是模式自由的元数据模式。 7）简单易用 ArangoDB可以在几秒内启动运行，同时可使用图形界面来管理你的ArangoDB。 8）多OS支持 ArangoDB支持Windows、Linux和OSX等操作系统，还支持树莓派。 9）开源且免费 ArangoDB开源免费，它采用了Apache 2许可证协议。 10）复制 ArangoDB支持主从集群 简单说下Aerospike的安装，我这边有个服务器是Ubuntu的，那就用它了。 如果有Docker的话，那敢情好了。直接下载image，run一下就好了。 wget -O aerospike.tgz 'http://aerospike.com/download/server/latest/artifact/ubuntu12' tar -xvf aerospike.tgz cd aerospike-server-community-*-ubuntu12 sudo ./asinstall # will install the .rpm packages sudo service aerospike start && \ sudo tail -f /var/log/aerospike/aerospike.log | grep cake 有时候自己手动启动。 sudo /etc/init.d/aerospike start 另外大家可以学习下python的aerospike库。Python # import the module import aerospike # Configuration for the client config = { 'hosts': [ ('127.0.0.1', 3000) ] } # Create a client and connect to the database client = aerospike.client(config).connect() # Records are addressable via a tuple of (namespace, set, key) key = ('test', 'demo', 'foo') # Write a record client.put(key, { 'name': 'John Doe', 'age': 32 }) # Read a record (key, metadata, record) = client.get(key) # Close Connection to Cluster client.close() 性能比较见http://www.infoq.com/cn/news/2013/04/NoSQL-Benchmark 整体看来 如果是充分利用内存提速的话 要比mongodb好！ 本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/6244006.html，如需转载请自行联系原作者
2017-11-07
优秀的个人博客,低调大师

InstantRun原理（1）——初始化逻辑

Android Studio 2.0开始支持 Instant Run 特性， 使得在开发过程中能快速将代码变化更新到设备上。之前，更新代码之后需要先编译一个完整的新Apk，卸载设备上已安装的这个 Apk （若有），再 push 到设备安装，再启动。有了 Instant Run 特性之后，只需要 push 一些增量到设备上，直接执行，可以为开发人员节省大量时间。当然 Instant Run 特征只在 debug 时有效，对发布 release 版没有任何影响。 对于InstantRun不了解的同学可以去查看官方文档 Instant Run 通过 hot swap， warm swap， code swap 三种 swap 来实现。Android Studio 会根据代码的改变自动决定 push 哪种 swap 到设备上，并根据不同的 s
2017-09-10
优秀的个人博客,低调大师

Android面试，IntentService的原理及使用

在Android开发中，我们或许会碰到这么一种业务需求，一项任务分成几个子任务，子任务按顺序先后执行，子任务全部执行完后，这项任务才算成功。那么，利用几个子线程顺序执行是可以达到这个目的的，但是每个线程必须去手动控制，而且得在一个子线程执行完后，再开启另一个子线程。或者，全部放到一个线程中让其顺序执行。这样都可以做到，但是，如果这是一个后台任务，就得放到Service里面，由于Service和Activity是同级的，所以，要执行耗时任务，就得在Service里面开子线程来执行。那么，有没有一种简单的方法来处理这个过程呢，答案就是IntentService。 什么是IntentService，IntentService是继承于Service并处理异步请求的一个类，在IntentService内有一个工作线程来处理耗时操作，启动IntentService的方式和启动传统Service一样，同时，当任务执行完后，IntentService会自动停止，而不需要我们去手动控制。另外，可以启动IntentService多次，而每一个耗时操作会以工作队列的方式在IntentService的onHandleIntent回调方法中执行，并且，每次只会执行一个工作线程，执行完第一个再执行第二个，以此类推。 所有请求都在一个单线程中，不会阻塞应用程序的主线程（UI Thread），同一时间只处理一个请求。 那么，用IntentService有什么好处呢？首先，我们省去了在Service中手动开线程的麻烦，第二，当操作完成时，我们不用手动停止Service。 Code 接下来让我们来看看如何使用，我写了一个Demo来模拟两个耗时操作，Operation1与Operation2，先执行1，2必须等1执行完才能执行： 新建工程，新建一个继承IntentService的类，我这里是IntentServiceDemo.java public class IntentServiceDemo extends IntentService { public IntentServiceDemo() { //必须实现父类的构造方法 super("IntentServiceDemo"); } @Override public IBinder onBind(Intent intent) { System.out.println("onBind"); return super.onBind(intent); } @Override public void onCreate() { System.out.println("onCreate"); super.onCreate(); } @Override public void onStart(Intent intent, int startId) { System.out.println("onStart"); super.onStart(intent, startId); } @Override public int onStartCommand(Intent intent, int flags, int startId) { System.out.println("onStartCommand"); return super.onStartCommand(intent, flags, startId); } @Override public void setIntentRedelivery(boolean enabled) { super.setIntentRedelivery(enabled); System.out.println("setIntentRedelivery"); } @Override protected void onHandleIntent(Intent intent) { //Intent是从Activity发过来的，携带识别参数，根据参数不同执行不同的任务 String action = intent.getExtras().getString("param"); if (action.equals("oper1")) { System.out.println("Operation1"); }else if (action.equals("oper2")) { System.out.println("Operation2"); } try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public void onDestroy() { System.out.println("onDestroy"); super.onDestroy(); } } 我把生命周期方法全打印出来了，待会我们来看看它执行的过程是怎样的。接下来是Activity，在Activity中来启动IntentService： public class TestActivity extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); //可以启动多次，每启动一次，就会新建一个work thread，但IntentService的实例始终只有一个 //Operation 1 Intent startServiceIntent = new Intent("com.test.intentservice"); Bundle bundle = new Bundle(); bundle.putString("param", "oper1"); startServiceIntent.putExtras(bundle); startService(startServiceIntent); //Operation 2 Intent startServiceIntent2 = new Intent("com.test.intentservice"); Bundle bundle2 = new Bundle(); bundle2.putString("param", "oper2"); startServiceIntent2.putExtras(bundle2); startService(startServiceIntent2); } } 最后，别忘了配置Service，因为它继承于Service，所以，它还是一个Service，一定要配置，否则是不起作用的，开始我就是忘了，结果半天没反应。 <service android:name=".IntentServiceDemo"> <intent-filter > <action android:name="com.test.intentservice"/> </intent-filter> </service> 最后来看看执行结果： 从结果可以看到，onCreate方法只执行了一次，而onStartCommand和onStart方法执行了两次，开启了两个Work Thread，这就证实了之前所说的，启动多次，但IntentService的实例只有一个，这跟传统的Service是一样的。Operation1也是先于Operation2打印，并且我让两个操作间停顿了2s，最后是onDestroy销毁了IntentService。 我是天王盖地虎的分割线 本文转自我爱物联网博客园博客，原文链接：http://www.cnblogs.com/yydcdut/p/3960886.html，如需转载请自行联系原作者
2017-08-26
优秀的个人博客,低调大师

《云计算：原理与范式》一导读

前 言 云计算（cloud computing）如今已成为信息与通信技术（ICT）产业中的又一个流行语（buzzword）。众多IT厂商承诺提供计算、存储和应用托管服务，其服务范围涵盖了几大洲，并提供基于服务水平协议（Service Level Agreement，SLA）支持的性能和运行时间。尽管这些“云”是传统数据中心的自然进化，它们以展现资源（计算、数据/存储及应用）作为基于标准的Web服务并遵循“实用”的定价模式进行区分。根据客户的计算资源、存储及数据传输的利用率收费。这些“云”提供了基于订阅的访问基础设施、平台及应用的基础设施即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）和软件即服务（Software as a Service，
2017-07-31
优秀的个人博客,低调大师

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

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

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

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

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
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次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

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

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

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册