对于系统开发人员来说(比如云数据库,云 AI 平台),云原生的趋势也会产生相应的影响。 具体的例子比如我们可以通过用户的数据查询看到经常使用的过滤维度,来重新安排数据的排序和分区,这样在同样的数据量情况下,系统可以花更少的计算资源来完成查询,增加系统的利润 :) 云原生+AI 最后再来看下跟 AI 相关的部分。 而前面讲的“云原生语言”,则更关注在程序具体执行层面的关注点分离。 把两者结合起来看,云原生时代的 AI 平台开发会是一片巨大的未开垦之地,对于云和算法各自都有很宽很长的路可以走。 目前云原生跟 AI 结合的一个比较好的学习样例是 Kubeflow,之前春节期间读了一本《Kubeflow for Machine Learning[3]》,感觉收获还是挺多的,如Istio,CRD的应用等
云原生技术之docker学习笔记(5) 这两天在研究docker容器的底层原理和k8是相关的一些东西,说实话,这块儿的内容还挺复杂的,尤其是k8s的集群运维方面,没有一点沉淀真的很难理解各种模块之间的关系 再次查看mysqld进程的进程号: [root@VM-16-13-centos service]# ps -ef|grep mysql root 5152 5059 0 2020 pts/5 20 11:38 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 Nov 20 11:38 cpuacct -> cpu,cpuacct drwxr-xr-x 5 drwxr-xr-x 3 root root 0 Nov 20 11:38 freezer drwxr-xr-x 3 root root 0 Nov 20 11:38 hugetlb drwxr-xr-x 5
大家学习云原生,肯定都很少听过云原生一些真实的场景下如何去运用如何去落地,只知道Docker能干嘛干嘛,K8s能用来高效能的管理容器编排,云原生能够赋能项目如何如何减小成本等等。 那么本期文章就是笔者学习了一些腾讯云/阿里云基于云原生的产品项目开放的落地实践方案的一些感想与学习记录。后续也会多写一些云原生落地实践方案的学习记录! 大家有空可以多去关注阿里云、腾讯云。 前面的文章已经简单介绍了一些云原生的入门知识及简单实战。 在学习云原生的时候,我才发现原来云原生使得项目落地的方案离我们这么近,作业帮就是一个很好的例子。 2、原业务对服务间时延依赖,部分业务连接超时时间设置为5毫秒,所以无法承担细微系统调度和 网络波动,如果一旦在未经优化的内核和网络下,容易引起业务大面积超时。
腾讯云也制定了自己的云原生成熟度模型:图片图片腾讯云的成熟度模型,主要从研发效能和资源效能2个方面引导内部云原生建设。 云小微团队结合云小微现状以及公司云原生成熟度标准1.0和2.0的导向,横向对比业界做法,重点在云原生5大核心能力上进行了建设:服务化、可观测性、韧性、弹性、自动化能力,并逐步提升可调度能力。 图片新方案效果:30G的模型,服务扩容速度速度可以控制在5分钟以内,最快可以在1分钟左右完成扩容。图片图片特色与沉淀AI大数据模型服务启动速度慢是个行业通性问题。 通过上述的建设,云小微的AI大数据模型服务,扩容速度从10分钟左右,优化到5分钟以内,命中缓存时可以达到1分钟左右。 总结在智平各中心同学和CSIG质量部/智能产品质量中心同学的共同努力下,云小微重点在云原生的5大领域(服务化、可观测性、韧性、弹性、自动化能力)上进行了建设,完成了Re-host、Re-platform
张望,腾讯高级工程师,从事云上 GPU 和分布式训练加速,负责腾讯云 TKE 在 AI 场景的研发和支持工作。 不仅各大公有云厂商都已经基本收录或集成了 Kubeflow 的训练 operators,社区上其他与深度学习训练相关的项目(如用以自动机器学习的 Katib,又如提供自动化编排功能的 Flyte)都对接了 我们希望未来利用 Kubeflow Training Operator 来构建 AI 平台的开发者可以方便地将其与其他模块对接,实现诸如任务队列、流水线、超参数搜索等功能。 9月10日上午11点,由作者选出回答最佳的5位读者,送定制T恤一件。 资源利用率提高67%,腾讯实时风控平台云原生容器化之路 Getting Started and Beyond|云原生应用负载均衡选型指南 被集群节点负载不均所困扰?
: ---- 前言:12月19日,在 Cloud Native Days China -云原生AI大数据专场,腾讯技术事业群高级工程师薛磊发表了《云原生AI平台的加速与实践》主题演讲。 ? 演讲主要包含五部分的内容: Kubernetes介绍 AI离线计算 AI场景下Kubernetes的不足 Kubeflow 星辰算力平台的架构 Kubernetes介绍 K8s是生产级的容器编排系统,它也是云原生应用最佳的一个平台 因此,对于我们而言在AI平台上面也可以基于K8s的架构进行额外的开发。 AI离线计算 ? 典型的AI场景 ? ? 分布式AI计算 为什么要分布式AI计算? 提供TensorFlow原生PS-worker架构 的多机训练 推荐将PS和worker一起启动 通过service做服务发现 在社区中最早期的Operator 星辰算力平台的架构 它为私有云的一个离线计算平台
Kagent 架构详解 ❝本文档阐述 Kagent 的云原生设计理念——将 Agent 定义为 Kubernetes CRD,使其成为集群的一等公民❞ 目录 1. Agent CRD 设计 5. 运行时架构 6. 配置映射流程 7. 完整请求流程 1. 这不是简单地"把 Agent 跑在 K8s 上",而是深度融入 Kubernetes 的资源模型,让 Agent 天然具备云原生基础设施的所有能力。 AI Agent 框架,它将 Agent 定义为 Kubernetes CRD(Custom Resource Definition),让用户可以像管理 Deployment 一样管理 Agent。 自动接入 Kubernetes 可观测性生态: ┌─────────────────────────────────────────────────────────┐ │ 云原生可观测性栈
本文介绍了构建云原生权限的五个最佳实践,这些实践可以为开发人员减少很多麻烦。 基于云原生/微服务的产品很复杂,为这些产品构建访问控制和管理权限也很复杂。而且每次拉取请求只会让情况变得更糟。 为了让人们的工作和生活更轻松,需要了解构建云原生权限带来的独特挑战,并了解构建云原生权限的五个最佳实践,这些实践可以为开发人员减少很多麻烦。 构建云原生权限的5个最佳实践 为了处理所有这些更改,有一些最佳实践可以帮助开发人员构建云原生权限,并有时间实际开发功能,而不是在处理权限方面不堪重负。 (1)解耦策略和代码 构建云原生权限的最重要实践之一是策略和代码的解耦。将授权层的代码与应用程序代码本身混合在一起可能会产生很大的问题。 云原生权限的未来发展 随着复杂性的增加以及客户和安全需求的不断涌现,以一种为未来做好准备且不需要大量重构或重写的方式构建产品的访问控制至关重要。
本篇文章来自《华为云云原生王者之路训练营》黄金系列课程第5课,由华为云容器技术专家Jessia Ding主讲,帮你了解工作负载的概念以及Kubernetes提供的内置工作负载的信息;Deployment Job/CronJob 概述 Job 主要处理一些短暂的一次性任务: 保证指定数量Pod成功运行结束 支持并发执行 支持错误自动重试 支持暂停/恢复Job 典型使用场景: 计算以及训练任务, 如批量计算,AI
什么是云原生? 云原生(Cloud Native)是由 Pivotal 的Matt Stine在2013年提出的一个概念,是他多年的架构和咨询总结出来的一个思想的集合。 云原生应用 云原生应用是天然适合云特点的应用,云原生应用系统需要与操作系统等基础设施分离,不应该依赖Linux或Windows等底层平台,或依赖某个云平台。 CNCF给出了云原生应用的三大特征: 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。 云原生应用和本地部署应用程序之间的差异 云原生应用程序开发采用与传统企业应用程序完全不同的体系结构。 可更新 云原生应用程序始终是最新的,云原生应用始终可用。 本地部署应用程序需要更新,并且通常由供应商按订阅提供,并且在安装更新时需要停机。 弹性 云原生应用程序通过在峰值期间增加的资源来利用云的弹性。
由于云已成为许多组织的技术基础设施的首选方法,攻击者不可避免地把注意力投向了它。 虽然云可以提供一些安全优势,但它仍然需要引起高度重视;云打开了攻击面,为攻击者提供了更多的成功攻击机会,而且共享责任模型的复杂性——供应商和客户拥有基于云的堆栈的不同部分——会造成混淆,这很容易被被恶意行为者利用 克服保护云的挑战需要系统的战略方法。 解决这个问题的一种方法是使用“云上的租户模型”来确保数据隔离。云原生加密服务不仅可以用来保护所有这些静态数据,还可以用来保护跨系统共享的数据。 云上应用程序的一些特别脆弱的方面需要通过以下方式处理: 供应链攻击:保护云上的软件供应链需要您确保供应链每一步的完整性。您还需要将相关的供应链事件绑定到本地云 IAM,并将权限限制为仅授权活动。
本文将为大家讲解云原生架构中常见的反模式。 如果涉及个性化推荐的商业需求,大数据和 AI 平台也是必不可少的。 依据 DDD 的 Domain 原则划分子域后,我们会使用 Bounded Context 来实现这些子域的落地。 当开发人员同时投入 3 到 5 个微服务应用的开发和维护时,想要在不同的应用之间快速切换且不出现错误,则是非常困难的。所以一定要铭记,对于微服务来说,自动化的 CI/CD 是最低的要求。 4 架构不能充分使用云的弹性能力 云计算服务架构主要可划分为三层,分别是 IaaS、PaaS和 SaaS,如图所示。 云计算服务架构 IaaS 位于最底层,提供服务器、存储、网络等服务。 5 技术架构与组织能力不匹配 应用微服务化之后,会有更多的小团队负责不同的微服务应用,可能需要重新组建管理团队、开发团队和基础设施运维团队,由此可能会带来组织结构和管理方式的调整。
本文将为大家讲解云原生架构中常见的反模式。 如果涉及个性化推荐的商业需求,大数据和 AI 平台也是必不可少的。 依据 DDD 的 Domain 原则划分子域后,我们会使用 Bounded Context 来实现这些子域的落地。 当开发人员同时投入 3 到 5 个微服务应用的开发和维护时,想要在不同的应用之间快速切换且不出现错误,则是非常困难的。所以一定要铭记,对于微服务来说,自动化的 CI/CD 是最低的要求。 4 架构不能充分使用云的弹性能力 云计算服务架构主要可划分为三层,分别是 IaaS、PaaS和 SaaS,如图所示。 ? 云计算服务架构 IaaS 位于最底层,提供服务器、存储、网络等服务。 5 技术架构与组织能力不匹配 应用微服务化之后,会有更多的小团队负责不同的微服务应用,可能需要重新组建管理团队、开发团队和基础设施运维团队,由此可能会带来组织结构和管理方式的调整。
一、产品定位与核心亮点 腾讯云TAPD(Tencent Agile Product Development)是一款基于容器化技术的云原生研发协作平台,核心定位为面向开发团队的高性能、智能化研发基础设施。 其差异化优势在于深度融合项目管理(需求/任务/缺陷跟踪)与工程实践(代码管理/持续集成/自动化测试),通过云原生架构与AI能力提升研发全流程自动化与协作效率。 计算资源:云原生构建CPU资源 6,400核时/月,云原生开发资源 64,000核时/月。 云原生构建能力:基于容器化技术,支持高并发构建与缓存优化,提升编译效率。 自动化流水线:通过规则引擎自动触发流程(如代码提交→构建→测试→部署),减少手动操作。 数据来源:腾讯云TAPD官方产品介绍文档 特权说明:企业版用户(购买License ≥ 10)可申请长期有效的云原生构建与开发资源特权,需通过在线咨询核实后发放。
云原生不仅为传统业务的转型带来极大的便利,提升了生产效率,同时也适应了5G、IoT等边缘计算新场景,引领了IT基础设施的变迁。 当前,整个行业对云原生安全的认识仍然存在较大的差距。 云原生是一个快速发展的技术和体系,这就造成开发人员和运维人员对于云原生攻防的理解不足,而传统安全人员对于云原生技术和流程的理解也不到位。 这也是《云原生安全技术实践指南》一书的编写初衷——希望总结5年来在云原生安全领域的相关实践经验和技术积累,同时能够给相关的建设方和防守方一些指导和帮助。 此外,对于当前发展火热的5G和边缘计算场景,书中也给出了相关的云原生安全指导建议。 本书共分为六部分,由浅入深地阐述了云原生安全的技术实践。 第五部分防御篇,主要讲解如何构建新一代的云原生安全防御体系,并基于金融、运营商和互联网三个重点行业实践进行了深入的剖析。 第六部分进化篇,简要介绍了对5G及边缘计算下的云原生安全的新思考。
发生的冠状病毒疫情,促使人们更多采用数字化技术,云原生如今成为人们关注的焦点。 云原生加速了企业业务现代化的进程。 这使云原生服务更加引人注目。IDC公司指出,云原生开发实践是数字创新的核心,研究机构451 Group认为,云原生是企业高管可以用来应对不确定性和快速变化的市场条件的一种技术。其原因很简单。 其他云原生技术也是如此。 ? 这些项目通过新功能使云原生保持最新状态,并且保持稳定,使其非常适合企业IT需求。 5 降低成本 开源使IT团队摆脱了基础设施层面编码的束缚,创建了增值功能。云原生也是如此:大多数人都无法自行构建所需的规模系统(如果有的话),而不会消耗大量的资金和时间。 云原生项目的社区性质提供了企业团队重视的基础设施,同时节省了他们的时间、资金和精力。 云原生发挥的作用 云原生项目发展迅速,虽然这是一个优点,但这也可能使它们成为企业遵循和采用的挑战。
前引入LLM后自动生成攻击路径需人工查看N个系统,耗时N久一键攻击推演攻击链识别率低,人工漏掉链路是大概率发生非常高事前风险处置率低(几乎做不到)每周N+条可阻断攻击链三、打造你的“安全决策大脑”未来的云原生安全平台 云原生让基础设施变得流动,AI让攻防对抗变得极速。但不变的是安全的本质:看见风险、理解风险、处置风险。 第5期(本期):展望未来,讲解AI×云原生安全,即如何用大模型打造企业级的“风险决策引擎”,实现智能防火。 春根实战AI云原生安全简介我是深耕云安全领域十余年的资深架构师/产品专家,专注于LLM时代下的风险源头治理实战。本号的内容专为CTO、CISO、安全架构师等核心决策者而写。 如果您正在寻求高价值、去噪音的专业交流,对云原生安全治理的顶层设计感兴趣,欢迎关注本号。
给近半年做的云原生AI算力平台做一个回顾, 思考和实践参考了云溪大会上的分享:为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践[1],全文很长,我这边做一个牵引和解读。 1. 面对LLM和GAI这类对算力和数据都有极高需求的新负载,云计算也迎来了“智算”时代, 一方面以服务化资源池的概念提供万卡算力、PB级存储、和单机TB级高速网络互联,另一方面以云原生标准化交付算力给大模型的生产者和使用者 大模型带来的挑战 AI有工程化的要求,同时也对基础设施提出挑战。 3. 云原生AI的能力 最近在做的“AI大模型基础设施”, 宏观目标也是帮助AI工程从小作坊向端到端云原生解决方案演进。 云原生AI的架构实践 我们的云原生AI算力平台, 有参考上面的实践,针对企业业务的现状和侧重, 技术调研上做了调整和裁剪。 糟糕,我实现的k8s informer好像是依托答辩 参考资料 [1] 为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践: https://developer.aliyun.com/article
云原生安全发展可谓方兴未艾,云原生环境中的各类安全风险日益频发,云上的对抗也成为现实,越来越多的企业开始探讨如何设计、规划云原生环境中的安全架构,部署相应的安全能力。 云原生安全的现在和未来如何,笔者不妨从一个较高的视角进行探讨。 与云计算安全相似,云原生安全也包含两层含义:“面向云原生环境的安全”和“具有云原生特征的安全”。 1 面向云原生环境的安全 总体而言,云原生安全的第一阶段是安全赋能于云原生体系,即构建云原生的安全能力。 面向云原生环境的安全,其目标是防护云原生环境中的基础设施、编排系统和微服务等系统的安全。 如图1的左侧具有云原生特性的安全能力能够适用于5G和边缘计算的场景,如本书24.1和24.2节所讨论,也能够适用于电商微服务的场景,如本书第其部分所讨论的应用安全。 图1 原生安全的演进 总结 从上可知,原生安全发展会有三个阶段,在最终阶段,当安全设备或平台云原生化后,就能提供(云)原生的安全能力,不仅适用于通用云原生场景、5G、边缘计算等场景,甚至可以独立部署在大型电商等需要轻量级
在之前的文章中,我们介绍了容器和Pod的区别和关系。我们知道Pod是k8s调度的最小单位,而一个Pod中可以有多个容器,那么我们如何来定义一个我们自己的Pod呢?