首页 文章 精选 留言 我的

精选列表

搜索[动态工作流],共10006篇文章
优秀的个人博客,低调大师

版本动态 | Apache Linkis 1.5.0 版本发布

Apache Linkis 1.5.0版本已经发布,非常感谢社区各位成员对 1.5.0版本的贡献和付出。 本次版本是一个大版本,新增了多个社区期待已久的特性,如:注册中心支持切换Nacos、新增Hbase、Nabula、repl等多个引擎、新增SPARK引擎插件支持 on Yarn Cluster模式、SPARK和Flink引擎插件支持 on k8s提交Jar任务等功能特性,并修复了多个已知问题。 详情请查看 Apache Linkis 官方1.5.0的版本信息: https://linkis.apache.org/zh-CN/download/release-notes-1.5.0 ApacheLinkis1.5.0版本简介 ●注册中心支持将Eureka切换为Nacos ●新增Hbase引擎插件,支持Hbase-shell全部语法并兼容多版本 ●新增Nebula引擎插件 ●新增Repl解释器引擎插件,支持运行Java和Scala代码片段 ●支持SparkEConk8s提交jar和Pyspark任务 ●支持FlinkEConk8s提交jar任务 ●Spark引擎插件支持onyarncluster运行模式 ●LinkisJDBCdriver支持多引擎多版本的选择 ●基础数据管理增加配置项管理,支持管理员管理各个引擎插件的配置项 ●管理台增加运维工具,并新加入了用户配置管理,支持管理员调整用户配置和模版管理 ●【实验性】Entrance支持任务接管,可以做到Entrance无状态 缩写: ●COMMON:LinkisCommon ●ENTRANCE:LinkisEntrance ●EC:EngineConn ●ECM:EngineConnManager ●ECP:EngineConnPlugin ●DMS:DataSourceManagerService ●MDS:MetaDataManagerService ●LM:LinkisManager ●PS:LinkisPublicService ●PE:LinkisPublicEnhancement ●RPC:LinkisCommonRPC ●CG:LinkisComputationGovernance ●DEPLOY:LinkisDeployment ●WEB:LinkisWeb ●GATEWAY:LinkisGateway ●EP:EnginePlugin 新特性 ●[EC]LINKIS-5008注册中心支持Nacos ●[GATEWAY]LINKIS-4992Gateway支持访问控制配置 ●[EC-REPL]LINKIS-4937新增Repl解释器引擎插件,支持执行scala和Java代码 ●[EC-NEBULA]LINKIS-4903新增nebula引擎插件 ●[EC-HBASE]LINKIS-4891新增Hbase引擎插件 ●[EC-SPARK]LINKIS-4850SPARK引擎插件支持OnYarnCluster运行 ●[EC-SPARK]LINKIS-4867SPARK引擎插件支持提交Jar任务onk8s ●[EC-SPARK]LINKIS-4906SPARK引擎插件支持提交pysparkjobonk8s ●[JDBC-DRIVER]LINKIS-4930JDBCDriver支持引擎多版本 ●[EC-FLINK]LINKIS-4753Flink引擎插件升级为1.16.2并兼容多版本 ●[ENTRANCE]LINKIS-4282实验性:Entrance服务支持HA ●[MONITOR]LINKIS-4905实验性:新增Linkis Monitor服务 ●[WEB]LINKIS-4940实验性:管理台前端新架构升级 功能增强 ●[ECM]LINKIS-4990支持管理台下载EC的日志文件 ●[EC]LINKIS-4982EC指标丰富增加锁空闲等时间指标 ●[WEB]LINKIS-4954管理台增加用户配置管理页面 ●[EC-SPARK]LINKIS-4961Pyspark新增更多的默认classimport ●[EC-PYTHON]LINKIS-4835Python引擎插件优化打印,错误信息打印优化 ●[EC-SPARK]LINKIS-4896SPARKOnce任务支持EngineConnRuntimeMode标签配置 ●[LM]LINKIS-4914LM资源排序选择规则优化为从按大到小 ●[WEB]LINKIS-4935管理台支持配置spark.conf参数,支持配置多个SPARK的原生参数 ●[EC]LINKIS-4714EC支持指定Debug端口范围 ●[EC-FLINK]LINKIS-5023Flink引擎插件支持读取用户自定义的log4j配置 ●[PES]LINKIS-4838文件读取和写入接口支持更多参数和操作 ●[LM]LINKIS-4850LM支持管理K8s资源 ●[PE]LINKIS-4847优化模块数合并公共数据源模块 ●[PE]LINKIS-4853优化模块数合并公共客户端模块为pes-client模块 ●[PE]LINKIS-4854优化模块数合并公共服务的多个模块 ●[PE]LINKIS-4934数据源服务支持合并和单独部署 ●[EC-FLINK]LINKIS-5025Flink引擎插件支持加载默认配置 ●[EC-JDBC]LINKIS-5007JDBC引擎插件支持多任务间的任务串联 修复功能 ●[EC-Flink]LINKIS-5041修复交互式FlinkSQL打印状态获取错误日志问题 ●[MDS]LINKIS-4998ES数据源兼容6.X和7.X ●[EC-SPARK]LINKIS-4996SPARK引擎插件Scala任务支持将错误信息打印到任务日志中 ●[ENTRANCE]LINKIS-4967修复SQL解析comment中带有分号导致的解析错误 ●[EC]LINKIS-4920修复结果集null返回为字符串NULL问题 ●[CLI]LINKIS-4919Client修复并发的NPE问题 ●[CG]LINKIS-4915修复LM的ECM选择逻辑存在错误选择负载高的问题 ●[LM]LINKIS-4860修复linkis-httpclientpost接口中文乱码问题 ●[LM]LINKIS-4771Linkis-Clioncejob提交应该为Once模式 ●[LM]LINKIS-4731KillEC脚本应该去跳过ECM的进程 详细指引 ●本版本总览:https://linkis.apache.org/zh-CN/download/release-notes-1.5.0 ●详细安装部署见指引:https://linkis.apache.org/zh-CN/docs/latest/deployment/deploy-quick ●官方下载链接:https://linkis.apache.org/zh-CN/download/main 社区贡献者 Apache Linkis 1.5.0的发布离不开 Linkis 社区的贡献者,感谢所有的社区贡献者,包括但不仅限于以下 Contributors(排名不分先后):

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

项目动态|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版,但以后肯定会越来越成熟。

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

近期数据库动态解读

近段时间,数据库市场非常活跃,各类新闻层出不穷。整体市场发展也呈现出较之前明显不同的的变化。本文尝试从近期国内数据库榜单变化情况,分析行业发展特点。以下为个人观点,仅供参考。相关数据从墨天轮网站中获得,点击此处可查阅详情。 1.数据库榜单解读 1).第一阵营解读 TiDB:吹响HTAP的号角 TiDB,仍然在众多国产厂商中遥遥领先,当然与其他厂家的差距在缩小;这也变相说明国内数据库整体发展正在加速之中。TiDB与近期成功发布了5.0版本,将HTAP的趋势再度加温。随之各厂商,以巨杉、Oceanbase、PolarDB等为代表,也纷纷提出了自己对HTAP的支持增强。特别是Oceanbase通过TPCH+TPCC双料冠军的,更加夯实了自己在HTAP领域的重要地位。相信随着各产品HTAP能力已逐步成熟,客户会慢慢考虑将部分混合负载业务考虑通过HTAP架构来支持。 OceanBase:开源界的新兵 Oceanbase,是近期耀眼的明星厂商,通过TPCH打榜、产品开源等一系列动作,再次吸引了大量公众的关注。从榜单数据上也得到了对应的体现,发展趋势稳健,且进一步缩小与TiDB的差距。同样作为NewSQL类的典型代表,又同样冠以开源的理念,相信这两个“类似”产品会更多地提及比较。OB作为开源领域的后来者,如何构建自己的生态体系,成为后续发展的要点。相信在开源的加成下,OB必将取得更大的成绩。 PolarDB:云厂商的逆袭 作为云厂商的代表性产品,PolarDB近期表现也很亮眼,提升幅度很大,已非常接近第二名。在日前发布会上,阿里云数据库提出了新的战略发展,其中引人瞩目的正是PolarDB的开源。作为头部企业,阿里在开源策略上曾出现过一些波折,近期重拾开源大旗,相信未来会有更多的布局。其在发布会上,也公布了未来的系列开源计划,非常令人期待。 2).其他产品解读 除了三甲产品外,其他产品相较前者仍有一定差距。从一段时间观察来看,起起伏伏变化较大。在众多产品中,重点关注下上升最快的新兵-openGuass。虽然加入榜单的时间不长,但整体表现非常亮眼。特别是近两个月,连续提升了两个位次。这主要是openGuass近期动作频频,在自有生态建设下,现已吸引众多重量级企业加入。此外,基于openGuass内核的商业化产品也开始在大型商业客户中试水。 2.数据库趋势分析 人生基本上就是两件事,选题和解题。最好的人生是在每个关键点上,既选对题,又解好题。人生最大的痛苦在于解对了题,但选错了题,而且还不知道自己选错了题。正如人生最大的遗憾就是,不是你不行,而是你本可以。 总结近一阶段国内数据库市场发展,可用以下几个关键词来概括“促开源、建生态、求变革、新场景”。 促开源 开源,几乎成为近期最热关键词。伴随着几个大厂在开源上的举措,开源市场将迎来一场巨变。针对此次开源事件,个人解决更多是一种竞争中的求变策略。开源为这些企业带来的可谓一举多得,一是带来更多的关注度,有助于构建产品生态;二是吸引用户参与研发,提升产品质量;三是有助于在政策导向更强的企业中落地,建设企业对闭源的忧虑;四是更多切近业务,直接获得前线反馈。之前头部企业-PingCAP,秉承开源理念取得了不俗的成绩,如今大厂纷纷加入,相信未来开源市场将更加活跃,也会带动国内开源产业的发展。 建生态 前面开源部分谈到的建立自己生态,是开源的初衷之一。相较于国外大型商业数据库产品或知名开源产品而言,国内产品最为欠缺的正是生态建设。这不仅包括从上下游企业的配合,也包括个人使用者、乃至DBA群体的构建。开源是解决渠道之一,同时还包括技术布道、职业教育、厂商合作等等措施。某种意义上讲,在众多国产数据库中谁家能脱颖而出,更多正是取决于完整生态的构建。 求变革 主动求变,是我看到各个厂商动作频频的主要原因。随着国产数据库市场,已进入红海领域,竞争也日趋白热化。如何能在众多厂商中脱颖而出?如何找到企业的第二增长曲线?主动求变,也是企业不得而为之的选择。在当前还未形成巨头类企业的情况下,通过变革寻找新的机会,成为大家的共识。因此,无论是开源策略、合作方式、生态建设等等,各家都在不遗余力。 新场景 新场景,意味着新赛道。与其在传统领域中摸爬滚打,不如另辟蹊径找到新的数据使用场景。近段时间的HTAP场景,以TiDB、OceanBase、PolarDB等为代表;湖仓一体场景,以巨杉数据库、阿里云数据库产品为代表;新数仓场景,以TDSQL-A、ClickHouse、DorisDB为代表等。这些场景,部分并非全新领域;但通过技术积累,也促进部分场景的成熟落地。 墨天轮,围绕数据人的学习成长提供一站式的全面服务,打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台,持续促进数据领域的知识传播和技术创新。 更多精彩可以前往【墨天轮社区】 关注官方公众号:墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

资源下载

更多资源
腾讯云软件源

腾讯云软件源

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

Nacos

Nacos

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

Rocky Linux

Rocky Linux

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

Sublime Text

Sublime Text

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

用户登录
用户注册