检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
云容器实例提供如下特性,能够很好的支持这类场景。 高性能计算:提供高性能计算、网络和高I/O存储,满足密集计算的诉求 极速弹性:秒级资源准备与弹性,减少计算过程中的资源处理环节消耗 免运维:无需感知集群和服务器,大幅简化运维工作、降低运维成本 随启随用、按需付费:容器按需启动,按资源规格和使用时长付费
费用计算核时为核数和时间相乘,例如:730核时,表示您可以730核用1小时,也可以730小时用1核。 1 核*时= 1 * 3600(核*秒) 1 核*时:1核的CPU连续跑1个小时所用的资源量 1 核*秒:1核的CPU连续跑1秒所用的资源量 按需计费模式 以实例为单位,采用按量付费的计费模式,按秒计费,以小时为出账周期。
Pod规格的计算步骤如下: Pod 包含的所有 Init 容器上定义的任何特定资源的约束值 (limit) 或 请求值 (request) 的最大值,作为 Pod 有效初始 request/limit。 Pod 对资源的有效 limit/request ,是取如下两项的较大者: 所有应用容器对某个资源的
在客户端和服务器之间的加密传输,可以防止数据信息的泄露,保证了双方传递信息的安全性,而且可以通过服务器证书验证他所访问的网站是否是真实可靠。 SSL证书分为权威证书和自签名证书。权威证书由权威的数字证书认证机构签发,您可向第三方证书代理商购买,使用权威证书的Web网站,默认客户端
ernetes上的容器化业务,无需管理集群和服务器即可在CCI上快速创建和运行容器负载,使容器应用零运维,使企业聚焦业务核心,为企业提供了Serverless化全新一代的体验和选择。 而Serverless是一种架构理念,是指不用创建和管理服务器、不用担心服务器的运行状态(服务器
监控安全风险 通过AOM查看Pod监控数据 为使用户更好的掌握工作负载的运行状态,CCI配合AOM对其进行全方位的监控。 通过AOM界面您可监控CCI的基础资源和运行在CCI上的应用,同时在AOM界面还可查看相关的日志和告警。 更多内容,请参见监控管理。 Pod资源监控指标 CC
支持“滚动升级”和“替换升级”两种方式。 滚动升级:将逐步用新版本的实例替换旧版本的实例,升级的过程中,业务流量会同时负载均衡分布到新老的实例上,因此业务不会中断。 替换升级:将先把您工作负载的老版本实例删除,再安装指定的新版本,升级过程中业务会中断。 升级负载 登录云容器实例管理控制台,左侧导航栏中选择“工作负载
服务名称:服务名称即Service的名称,Service是用于管理Pod访问的对象。 命名空间:工作负载所在命名空间。 关联工作负载:要添加Service的工作负载。 负载端口配置 协议:访问负载的通信协议,可选择TCP或UDP。 访问端口:负载提供的访问端口。 容器端口:容器监听的端口,负载访问端口映射到容器端口。
负载访问504问题一般是因为ELB实例绑定的Port到后端 CCI 负载Pod的安全组没有放通。查看CCI负载Pod使用的安全组,确保安全组规则放通ELB实例绑定的Port。 Pod绑定的安全组可以通过查看负载对应Network获得,调用Network接口,响应里面metadata.annotations中的network
Namespace(命名空间)是一种在多个用户之间划分资源的方法。适用于用户中存在多个团队或项目的情况。当前云容器实例提供“通用计算型”和“GPU型”两种类型的资源,创建命名空间时需要选择资源类型,后续创建的负载中容器就运行在此类型的集群上。 通用计算型:支持创建含CPU资源的容器实例及工作负载,适用于通用计算场景。
Probe高级配置样例。 Exec:probe执行容器中的命令并检查命令退出的状态码,如果状态码为0则说明已经就绪。 Readiness Probe的工作原理 如果调用kubectl describe命令查看Service的信息,您会看到如下信息。 $ kubectl describe
理业务的运行有头有尾,而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出(Pod自动删除)。 任务的这种用完即停止的特性特别适合一次性任务,比如持续集成,配合云容器实例按秒计费,真正意义上做到按需使用。 创建任务 登录云容器实例管理控制台,左侧导航栏中选择“工作负载
重新采集。 日志出现丢失 原因一:日志文件的存在时间小于5秒。 详细说明:CCI感知日志文件的周期为5秒。日志文件从创建到被删除或重命名的时间小于5秒,则可能该日志文件不会被采集。 父主题: 日志采集类
建和管理服务器、不用担心服务器的运行状态(服务器是否在工作等),只需动态申请应用需要的资源,把服务器留给专门的维护人员管理和维护,进而专注于应用开发,提升应用开发效率、节约企业IT成本。传统上使用Kubernetes运行容器,首先需要创建运行容器的Kubernetes服务器集群,然后再创建容器负载。
CCI资源包中的核时怎么理解? 1 核*时 = 1 * 3600(核*秒) 1 核*时 :1核的CPU连续跑1个小时所用的资源量 1 核*秒: 1核的CPU连续跑1秒所用的资源量 案例一: 假设用户的Deployment是2.5核的,连续运行了2个小时,那么它所消耗的资源量为:2.5
当资源变得非常多的时候,如何分类管理就非常重要了,Kubernetes提供了一种机制来为资源分类,那就是Label(标签)。Label非常简单,但是却很强大,Kubernetes中几乎所有资源都可以用Label来组织。 Label的具体形式是key-value的标记对,可以在创建
升级策略:升级方式支持“滚动升级”和“替换升级”。 滚动升级:滚动升级将逐步用新版本的实例替换旧版本的实例,升级的过程中,业务流量会同时负载均衡分布到新老的实例上,因此业务不会中断。 最大无效实例数:每次滚动升级允许的最大无效实例数,如果等于实例数有断服风险(最小存活实例数 = 实例数 -
CCE突发弹性引擎(对接 CCI)作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台(如CCI)。 基于该插件,支持用户在短时高负载场景下,将部署在云容器引擎CCE上的无状态负载(Deploy
CCE突发弹性引擎(对接 CCI)作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台(如CCI)。 基于该插件,支持用户在短时高负载场景下,将部署在云容器引擎CCE上的无状态负载(Deploy
job的pod已经执行完成的情况下,为什么依然有实例在挂卷等事件,并且事件信息是失败的? 问题现象: job的Pod已经执行完成的情况下,依然有实例在挂卷等事件,并且事件信息是失败的。 图1 问题截图 问题原因: 各种类型的Pod(Deployment/StatefulSet/J