首页 文章 精选 留言 我的

精选列表

搜索[动态代码分析],共10000篇文章
优秀的个人博客,低调大师

Android系统默认Home应用程序(Launcher)的启动过程源代码分析(2)

Step 10. ActivityManagerService.systemReady 这个函数是在上面的Step 6中的ServerThread.run函数在将系统中的一系列服务都初始化完毕之后才调用的,它定义在frameworks/base/services/java/com/android/server/am/ActivityManagerServcie.java文件中: [java] view plain copy publicfinalclassActivityManagerServiceextendsActivityManagerNative implementsWatchdog.Monitor,BatteryStatsImpl.BatteryCallback{ ...... publicvoidsystemReady(finalRunnablegoingCallback){ ...... synchronized(this){ ...... mMainStack.resumeTopActivityLocked(null); } } ...... } 这个函数的内容比较多,这里省去无关的部分,主要关心启动Home应用程序的逻辑,这里就是通过mMainStack.resumeTopActivityLocked函数来启动Home应用程序的了,这里的mMainStack是一个ActivityStack类型的实例变量 Step 11. ActivityStack.resumeTopActivityLocked 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中: [java] view plain copy publicclassActivityStack{ ...... finalbooleanresumeTopActivityLocked(ActivityRecordprev){ //Findthefirstactivitythatisnotfinishing. ActivityRecordnext=topRunningActivityLocked(null); ...... if(next==null){ //Therearenomoreactivities!Let'sjuststartupthe //Launcher... if(mMainStack){ returnmService.startHomeActivityLocked(); } } ...... } ...... } 这里调用函数topRunningActivityLocked返回的是当前系统Activity堆栈最顶端的Activity,由于此时还没有Activity被启动过,因此,返回值为null,即next变量的值为null,于是就调用mService.startHomeActivityLocked语句,这里的mService就是前面在Step 7中创建的ActivityManagerService实例了。 Step 12.ActivityManagerService.startHomeActivityLocked 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerServcie.java文件中: [java] view plain copy publicfinalclassActivityManagerServiceextendsActivityManagerNative implementsWatchdog.Monitor,BatteryStatsImpl.BatteryCallback{ ...... booleanstartHomeActivityLocked(){ ...... Intentintent=newIntent( mTopAction, mTopData!=null?Uri.parse(mTopData):null); intent.setComponent(mTopComponent); if(mFactoryTest!=SystemServer.FACTORY_TEST_LOW_LEVEL){ intent.addCategory(Intent.CATEGORY_HOME); } ActivityInfoaInfo= intent.resolveActivityInfo(mContext.getPackageManager(), STOCK_PM_FLAGS); if(aInfo!=null){ intent.setComponent(newComponentName( aInfo.applicationInfo.packageName,aInfo.name)); //Don'tdothisifthehomeappiscurrentlybeing //instrumented. ProcessRecordapp=getProcessRecordLocked(aInfo.processName, aInfo.applicationInfo.uid); if(app==null||app.instrumentationClass==null){ intent.setFlags(intent.getFlags()|Intent.FLAG_ACTIVITY_NEW_TASK); mMainStack.startActivityLocked(null,intent,null,null,0,aInfo, null,null,0,0,0,false,false); } } returntrue; } ...... } 函数首先创建一个CATEGORY_HOME类型的Intent,然后通过Intent.resolveActivityInfo函数向PackageManagerService查询Category类型为HOME的Activity,这里我们假设只有系统自带的Launcher应用程序注册了HOME类型的Activity(见packages/apps/Launcher2/AndroidManifest.xml文件) [html] view plain copy <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.launcher" android:sharedUserId="@string/sharedUserId" > ...... <application android:name="com.android.launcher2.LauncherApplication" android:process="@string/process" android:label="@string/application_name" android:icon="@drawable/ic_launcher_home"> <activity android:name="com.android.launcher2.Launcher" android:launchMode="singleTask" android:clearTaskOnLaunch="true" android:stateNotNeeded="true" android:theme="@style/Theme" android:screenOrientation="nosensor" android:windowSoftInputMode="stateUnspecified|adjustPan"> <intent-filter> <actionandroid:name="android.intent.action.MAIN"/> <categoryandroid:name="android.intent.category.HOME"/> <categoryandroid:name="android.intent.category.DEFAULT"/> <categoryandroid:name="android.intent.category.MONKEY"/> </intent-filter> </activity> ...... </application> </manifest> 因此,这里就返回com.android.launcher2.Launcher这个Activity了。由于是第一次启动这个Activity,接下来调用函数getProcessRecordLocked返回来的ProcessRecord值为null,于是,就调用mMainStack.startActivityLocked函数启动com.android.launcher2.Launcher这个Activity了,这里的mMainStack是一个ActivityStack类型的成员变量。 本文转自 Luoshengyang 51CTO博客,原文链接:http://blog.51cto.com/shyluo/966528,如需转载请自行联系原作者

优秀的个人博客,低调大师

项目动态|Apache Pulsar 2.7.3 版本介绍

本文原文作者是 StreamNative 工程师丛搏、刘昱。译者刘梓霖,传智教育工程师。 关于 Apache Pulsar Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。GitHub 地址:http://github.com/apache/pulsar/ 近期,Apache Pulsar 社区发布了 Pulsar 2.7.3 版本!新版本涵盖 32 位贡献者提供的改进和错误修复,并提交了 79 次变更。 版本亮点: •游标读取遵循调度字节率限制器的设置,不会再导致意外的结果。[1]•Ledger 滚动任务按预期执行。[2] 本博客介绍了 2.7.3 版本最值得关注的进展,如需了解所有性能升级和 bug 修复的完整列表,请查阅Pulsar 2.7.3 发布注记[3]。 Bug 修复和性能升级 Broker PR-9826[4]:游标读取遵循调度字节率限制器的限制。 问题:无论是命名空间还是主题策略在限制分发速率时都未考虑使用字节速率限制。 解决方案:修复了调度字节速率限制器设置的行为。游标读取会遵循此设置并且不会在导致意外的结果。 PR-11226[5]:Ledger 滚动计划任务按照预期执行。 问题:在此 PR 之前,ledger 在达到最大滚动时间之前执行滚动任务,导致 ledger 不能及时滚动。 解决方案:修复 ledger 滚动调度的时间,任务只能在 ledger 成功创建之后运行。 PR-11136[6]:在重启 broker 时,主题级别的保留策略能正常工作。 问题:在此 PR 之前,当为一个 topic 设置 topic 级保留策略然后重启 broker 时,该 topic 级别的保留策略不生效。 解决方案:修正了此策略的行为,使其在启动policyCacheInitMap后重放所有策略消息,并在重新启动 broker 时添加了保留策略检查测试。 PR-10977[7]:调用 lastMessageId API 不会再导致内存泄露。 问题:在此 PR 之前,调用lastMessageIdAPI 时存在内存泄露,导致 broker 进程被 Kubernetes 停止。 解决方案:为PersistentTopic.getLastMessageId增加了缺失的 entry.release() 调用,以确保 broker 不会耗尽内存。 PR-10594[8]:ZooKeeper 读取由 broker 缓存。 问题:当执行管理操作以获取租户的命名空间时,是 ZooKeeper 使用在 ZooKeeper 客户端读取的, 而不是从broker 缓存中读取。 解决方案:修复 ZooKeeper 在为租户获取命名空间列表时的缓存问题。 PR-10512[9]:调用LeaderService.isLeader()的监控线程不再被阻塞。 问题:当LeaderService改变为 leadership 状态时,会被一个synchronized块锁定,这也阻止了其他线程调用LeaderService.isLeader()。 解决方案:通过修改ClusterServiceCoordinator和WorkerStatsManager以检查其是否来自MembershipManager的 leader ,修复了监控线程的死锁条件,使其不被LeaderService.isLeader()阻塞。 PR-10414[10]:hasMessageAvailable可以成功读取消息。 问题:因消息被acknowledgmentsGroupingTracker过滤,当hasMessageAvailableAsync返回true时无法读取消息。 解决方案:通过修改acknowledgmentsGroupingTracker过滤重复消息,并在之后连接打开时清理消息来修复竞争条件。 Proxy PR-8048[11]:Proxy 支持自动创建分区 topic。 问题:Proxy 因使用的是当前的 ZooKeeper 元数据而没有创建分区。 解决方案:通过从可用 broker 中选择和获取,而不是使用当前的 ZooKeeper 元数据来更改 proxy 以处理PartitionMetadataRequest。 Pulsar admin PR-11140[12]:增加标识来表明是否在复制的集群上创建元数据路径。 问题:在复制的命名空间上创建分区 topic时,没有在复制的集群上创建元数据路径/managed-ledgers。 解决方案:增加了一个标识(createLocalTopicOnly),用来表明是否为复制集群中的分区 topic 创建元数据路径。 PR-11131[13]:禁止为不存在的 topic 设置策略。 问题:由于 topic 策略中存在重定向循环,用户可以为不存在的 topic 或者已分区的 topic 设置策略。 解决方案:此项修复为 topic 策略增加了一个权威标识,以避免重定向循环。用户无法为不存在的 topic 或单分区 topic 的分区设置 topic策略。如果你为 0 分区 topic 的分区设置策略,它会重定向到 broker 。 PR-10806[14]:服务发现不再将 topic 硬编码为持久性。 问题:当对分区的非持久 topic 使用查找服务发现时,就会返回 0 而不是分区数。Pulsar 客户端会以连接普通 topic 的方式尝试连接到该 topic。 解决方案:实现topicName.getDomain().value()而不是硬编码persistent。现在用户可以成功地对一个分区的非持久 topic 使用服务发现。 PR-10744[15]:其他连接器现在可以使用 KinesisBackoff类 问题:Pulsar 客户端实现项目中的 Kinesis sink 连接器Backoff类结合依赖org.apache.pulsar:pulsar-client-original增加了连接器的大小。 解决方案:在函数 io-core 项目中增加了一个新的类Backoff,以便 Kinesis sink 连接器和其他连接器可以使用此类。 客户端 PR-10506[16]:无法发送许可为零的FLOW请求。 问题:当 broker 接收到一个零许可的FLOW请求时,会抛出异常并且关闭连接。这会引发频繁的重连,并导致重复或者乱序的消息。 解决方案:增加了一个在发送FLOW请求之前验证其许可的验证功能,如果请求是零许可,则不能发送FLOW请求。 函数和连接器 PR-10769[17]:Kinesis sink 连接器确认成功的消息。 问题:Kinesis sink 连接器在发送成功后没有确认消息。 解决方案:为 Kinesis sink 连接器增加了消息发送成功后的确认。 Docker PR-10531[18]:在使用 Kubernetes 运行时,Function 名称不能超过 52 个字符。 问题:当使用 Kubernetes 运行时,如果提交的 function 长度有效(小于 55 个字符),就会创建一个无法产生 pod 的 StatefulSet。 解决方案:将 Kubernetes 运行时的 function 名称的最大长度从 55 个字符改为 53 个字符。通过这一修复, function 名字的长度不能超过 52 个字符。 依赖 PR-10907[19]:启动 TLS 后,pulsar-admin与 proxy 的连接稳定了。 问题:因为 Jetty 9.4.39 中引入了 SSL 缓存的错误,pulsar-admin在 TLS 连接中不稳定,,导致大型 function jar 包上传频繁失败。 解决方案:将 Jetty 升级到 9.4.42.v20210604,这样当启用 TLS 时,pulsar-admin与 proxy 的连接是最稳定的。 参与其中 新版本使用 欢迎大家下载[20]并使用新版本!如果在使用中遇到问题,可以通过提 issue[21]或在微信群交流的方式抛出疑问并与社区交流。 加入 Apache Pulsar 社区 Pulsar 项目的成长来源于社区,也扎根于社区。一次次新版本的筹备与发布离不开社区伙伴们的贡献。你是否愿意成为其中的一员呢? 参与开源,可以获得公司及社区内外的认可,结交来自各个领域、志同道合的小伙伴;同时也可以提高个人影响力,促进个人发展。参与开源不是码农的专属,社区、文档等各个方面都可以让大家发挥一技之长。 作为全球性开源项目,截至目前,Apache Pulsar 已拥有 435 名贡献者、9.4K+ Star 、2.3 K+ Fork 。我们为大家提供了参与指南,欢迎越来越多的小伙伴助力 Apache Pulsar 项目的不断发展与前进。 •Apache Pulsar 官方贡献指南[22] •加入 Apache Pulsar 志愿者大家庭 译者信息 Hi~ 我叫刘梓霖,一名会 code 的斜杠青年 ~ 推荐阅读 •Pulsar 2.8.0 新增特性概览:独占 Producer、事务等•Apache Pulsar 2.7.1 版本正式发布! 引用链接 [1]游标读取遵循调度字节率限制器的设置,不会再导致意外的结果。:https://github.com/apache/pulsar/pull/11249 [2]Ledger 滚动任务按预期执行。:https://github.com/apache/pulsar/pull/11226 [3]Pulsar 2.7.3 发布注记:https://pulsar.apache.org/en/release-notes/ [4]PR-9826:https://github.com/apache/pulsar/pull/9826 [5]PR-11226:https://github.com/apache/pulsar/pull/11226 [6]PR-11136:https://github.com/apache/pulsar/pull/11136 [7]PR-10977:https://github.com/apache/pulsar/pull/10977 [8]PR-10594:https://github.com/apache/pulsar/pull/10594 [9]PR-10512:https://github.com/apache/pulsar/pull/10512 [10]PR-10414:https://github.com/apache/pulsar/pull/10414 [11]PR-8048:https://github.com/apache/pulsar/pull/8048 [12]PR-11140:https://github.com/apache/pulsar/pull/11140 [13]PR-11131:https://github.com/apache/pulsar/pull/11131 [14]PR-10806:https://github.com/apache/pulsar/pull/10806 [15]PR-10744:https://github.com/apache/pulsar/pull/10744 [16]PR-10506:https://github.com/apache/pulsar/pull/10506 [17]PR-10769:https://github.com/apache/pulsar/pull/10769 [18]PR-10531:https://github.com/apache/pulsar/pull/10531 [19]PR-10907:https://github.com/apache/pulsar/pull/10907 [20]下载:https://pulsar.apache.org/en/download/ [21]提 issue:https://github.com/apache/pulsar/issues [22]Apache Pulsar 官方贡献指南:http://pulsar.apache.org/en/contributing/

优秀的个人博客,低调大师

k8s-HPA动态伸缩

2 --> 一、认识HPA 参考: https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/ HPA全称是Horizontal Pod Autoscaler,中文意思是POD水平自动伸缩. 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。 除了 CPU 利用率,内存占用外,也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 自定义度量参考: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md Pod 自动扩缩不适用于无法扩缩的对象,比如 DaemonSet。 Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性的调整副本控制器或 Deployment 中的副本数量,以使得 Pod 的平均 CPU 利用率与用户所设定的目标值匹配。 二、HPA工作机制 Pod 水平自动扩缩器的实现是一个控制回路,由控制器管理器的 --horizontal-pod-autoscaler-sync-period 参数指定周期(默认值为 15 秒)。 每个周期内,控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 控制器管理器可以从资源度量指标 API(按 Pod 统计的资源用量)和自定义度量指标 API(其他指标)获取度量值。 对于按 Pod 统计的资源指标(如 CPU), 控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定的 Pod 的度量值,如果设置了目标使用率, 控制器获取每个 Pod 中的容器资源使用情况,并计算资源使用率。 如果设置了 target 值,将直接使用原始数据(不再计算百分比)。 接下来,控制器根据平均的资源使用率或原始值计算出扩缩的比例,进而计算出目标副本数。 需要注意的是,如果 Pod 某些容器不支持资源采集,那么控制器将不会使用该 Pod 的 CPU 使用率。 如果 Pod 使用自定义指示,控制器机制与资源指标类似,区别在于自定义指标只使用 原始值,而不是使用率。 如果 Pod 使用对象指标和外部指标(每个指标描述一个对象信息)。 这个指标将直接根据目标设定值相比较,并生成一个上面提到的扩缩比例。 在 autoscaling/v2beta2 版本 API 中,这个指标也可以根据 Pod 数量平分后再计算。 通常情况下,控制器将从一系列的聚合 API(metrics.k8s.io、custom.metrics.k8s.io 和 external.metrics.k8s.io)中获取度量值。 metrics.k8s.io API 通常由 Metrics 服务器(需要额外启动)提供。 确认安装metrics-server [root@master1 ~]# kubectl get pods -n kube-system |grep metrics-server metrics-server-869ffc99cd-lz68h 1/1 Running 5 23h [root@master1 ~]# kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 192.168.122.11 357m 4% 895Mi 17% 192.168.122.12 426m 5% 910Mi 28% 192.168.122.13 353m 4% 664Mi 20% 192.168.122.14 251m 3% 408Mi 12% 三、HPA API对象 HPA的API有三个版本 [root@master1 ~]# kubectl api-versions | grep autoscal autoscaling/v1 autoscaling/v2beta1 autoscaling/v2beta2 APA版本 描述 autoscaling/v1 只支持基于CPU指标的缩放 autoscaling/v2beta1 支持Resource Metrics(资源指标,如pod的CPU)和Custom Metrics(自定义指标)的缩放; autoscaling/v2beta2 支持Resource Metrics(资源指标,如pod的CPU)和Custom Metrics(自定义指标)和ExternalMetrics(额外指标)的缩放。 四、kubectl对HPA的支持 与其他 API 资源类似,kubectl 以标准方式支持 HPA。 通过 kubectl create 命令创建一个 HPA 对象 通过 kubectl get hpa 命令来获取所有 HPA 对象 通过 kubectl describe hpa 命令来查看 HPA 对象的详细信息 通过 kubectl delete hpa 命令删除对象。 此外,还有个简便的命令 kubectl autoscale 来创建 HPA 对象。 例如,命令 kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80 将会为名 为 foo 的 ReplicationSet 创建一个 HPA 对象, 目标 CPU 使用率为 80%,副本数量配置为 2 到 5 之间。 五、HPA演示案例 参考: https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ 基于CPU的HPA 1, 构建测试镜像 [root@master1 ~]# vim index.php <?php $x = 0.0001; for ($i = 0; $i <= 1000000; $i++) { $x += sqrt($x); } echo "OK!"; ?> [root@master1 ~]# vim Dockerfile FROM php:5-apache COPY index.php /var/www/html/index.php RUN chmod a+rx index.php [root@master1 ~]# docker build -f Dockerfile -t 192.168.122.18/library/hpa-example:v1 . 2, 上传到harbor [root@master1 ~]# docker login 192.168.122.18 Username: admin Password: WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded [root@master1 ~]# docker push 192.168.122.18/library/hpa-example:v1 3, 部署测试deployment [root@master1 ~]# vim php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: app: php-apache replicas: 1 template: metadata: labels: app: php-apache spec: containers: - name: php-apache image: 192.168.122.18/library/hpa-example:v1 ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m [root@master1 ~]# kubectl apply -f php-apache.yaml deployment.apps/php-apache created 4, 验证得到pod-IP [root@master1 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READIN ESS GATES php-apache-665fc66c67-cfj6f 1/1 Running 0 25m 10.3.104.15 192.168.122.14 <none> <none> 得到pod-IP为10.3.104.15,此IP下面测试需要用到 5, 创建HPA [root@master1 ~]# kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 horizontalpodautoscaler.autoscaling/php-apache autoscaled 说明: --cpu-percent=50表示所有Pod的平均CPU使用率维持在50%,超过就要扩容 --min=1 --max=10表示pod数量的范 6, 创建测试pod对其访问 用另一个终端(我这里是master2)使用busybox镜像产生一个测试pod,对10.3.104.15进行压测 [root@master2 ~]# kubectl run busybox -it --image=busybox /bin/sh / # while true; do wget -q -O- http://10.3.104.15; done OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!...... 不断查询hpa状态,大概一分钟后才会看到效果 [root@master1 ~]# kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 250%/50% 1 10 1 19m cpu用到250%了 [root@master1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE busybox 1/1 Running 0 3m27s php-apache-665fc66c67-8z6wj 1/1 Running 0 59s php-apache-665fc66c67-cfj6f 1/1 Running 0 26m php-apache-665fc66c67-fn4wg 1/1 Running 0 59s php-apache-665fc66c67-t9wpr 1/1 Running 0 44s php-apache-665fc66c67-zw662 1/1 Running 0 60s 也可以看到pod扩容到了5个 [root@master2 ~]# kubectl run busybox -it --image=busybox /bin/sh / # while true; do wget -q -O- http://10.3.104.15; done OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!^ ctrl+c取消压力测试 要等几分钟甚至更久后,就看到cpu与pod数量都回去了 [root@master1 ~]# kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 0%/50% 1 10 5 22m [root@master1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE busybox 1/1 Running 0 28m php-apache-665fc66c67-t9wpr 1/1 Running 0 25m 7, 测试完后删除 [root@master1 ~]# kubectl delete deployments.apps php-apache deployment.apps "php-apache" deleted [root@master1 ~]# kubectl delete pod busybox pod "busybox" deleted [root@master1 ~]# kubectl delete hpa php-apache horizontalpodautoscaler.autoscaling "php-apache" deleted 基于内存的HPA 1, 创建测试deployment [root@master1 ~]# vim nginx-hpa.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-hpa spec: selector: matchLabels: app: nginx-hpa replicas: 1 template: metadata: labels: app: nginx-hpa spec: containers: - name: nginx image: nginx:1.15-alpine ports: - containerPort: 80 name: http protocol: TCP resources: requests: cpu: 0.01 memory: 25Mi limits: cpu: 0.05 memory: 60Mi [root@master1 ~]# kubectl apply -f nginx-hpa.yaml deployment.apps/nginx-hpa created 2, 创建HPA [root@master1 ~]# vim mem-hpa.yaml apiVersion: autoscaling/v2beta1 # v2beta1版本 kind: HorizontalPodAutoscaler metadata: name: nginx-hpa spec: maxReplicas: 10 minReplicas: 1 # 1-10个pod范围内扩容与裁剪 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-hpa metrics: - type: Resource resource: name: memory targetAverageUtilization: 50 # 50%内存利用 [root@master1 ~]# kubectl apply -f mem-hpa.yaml horizontalpodautoscaler.autoscaling/nginx-hpa created [root@master1 ~]# kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 12%/50% 1 10 1 60s 3, 对pod进行测试 换一个终端(master2),进入pod后进行dd命令测试 [root@master2 ~]# kubectl exec -it nginx-hpa-74ccf95f7d-454z5 -- /bin/sh / # dd if=/dev/zero of=/tmp/file1 4, 验证 不断查询hpa状态,大概一分钟后才会看到效果 [root@master1 ~]# kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 204%/50% 1 10 5 3m10s [root@master1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-hpa-74ccf95f7d-454z5 1/1 Running 0 6m20s nginx-hpa-74ccf95f7d-8gznw 1/1 Running 0 30s nginx-hpa-74ccf95f7d-bv4hm 1/1 Running 0 30s nginx-hpa-74ccf95f7d-g9276 1/1 Running 0 15s nginx-hpa-74ccf95f7d-xmzqs 1/1 Running 0 30s 5, 裁剪测试 ctrl+c取消后,删除dd的文件 [root@master2 ~]# kubectl exec -it nginx-hpa-74ccf95f7d-454z5 -- /bin/sh / # rm /tmp/file1 -rf 等几分钟甚至更久后,就看到cpu与pod数量都回去了 [root@master1 ~]# kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 12%/50% 1 10 1 28m [root@master1 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-hpa-74ccf95f7d-xmzqs 1/1 Running 0 25m 6, 测试完后删除 [root@master1 ~]# kubectl delete deploy nginx-hpa deployment.apps "nginx-hpa" deleted [root@master1 ~]# kubectl delete hpa nginx-hpa horizontalpodautoscaler.autoscaling "nginx-hpa" deleted 写在最后,更多功能可以自己去探索。虽然目前HPA功能还在beta版,但以后肯定会越来越成熟。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

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

Nacos

Nacos

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

WebStorm

WebStorm

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

用户登录
用户注册