关于云计算:Kubernetes-集成-KubeEdge-需要注意的问题汇总

作者:朱含近期小伙伴对在应用 KubeSphere v3.1 上集成边缘节点有不少疑难,这里阐明下 guide 文档地址,而后能够把这方面的问题汇总在这里,不便后续的小伙伴排查问题,也欢送大家持续补充。 官网 guide 文档传送门激活kubeedge边缘节点退出1. IP、端口凋谢问题如果应用 ks-installer 装置,须要激活 KubeEdge 以及配置 master节点对应的外网 IP 地址. 假如集群 master 节点 IP 192.168.10.7, 须要凋谢的外网端口如下: 序号内网IP内网端口(NodePort)外网端口 1192.168.10.73000010000https协定端口2192.168.10.73000110001Quic协定端口3192.168.10.73000210002cloudhub首次token获取证书4192.168.10.73000310003cloudstream端口5192.168.10.73000410004tunnel端口(edgestream连贯)外网端口须要防火墙通过。 如果遗记了设置 ks-installer 中 KubeEdge 组件局部中外网拜访 IP,cloudhub 起不来,能够应用以下命令补救: kubectl -n kubeedge edit cm cloudcore2. 获取边缘节点日志、metrics边缘节点与 master 节点不在一个局域网的状况较多,因而咱们在下面设计应用外网端口通信。另外,因为 KubeEdge 实现 kubectl exec,获取 logs 以及 metrics 的性能,依赖虚构 IP 进行相应的 iptable 转发到 cloudhub 对应的端口,继而获取边缘端的数据,也就是通过 edgemesh 实现,所以边缘节点绑定的虚构 IP 和边缘节点名称必须是惟一的,要自行按法则保护,留神这个虚构 IP 不能填边缘节点内网 IP,最好抉择与内网不抵触的网端,同时要保障 metrics-server 组件处于开启状态,须要更新为 0.4.1 版本以上以适应 KubeEdge(以后版本次要通过 metrics-server 获取边缘 metrics)。 ...

July 16, 2021 · 2 min · jiezi

关于云计算:阿里云低延时直播-RTS-能力升级-让直播推流效果更佳

行业背景直播技术飞速发展让各个行业的用户体验出现多样化和个性化,不同业务场景下翻新实际满足公众对于音视频互动体验和参加的高标准要求。历经2020年初的巨变之后,以视频、游戏、电商、教育为主的互联网经济迎来飞速发展,“直播+”已成为一种趋势,宽泛融入到人们的工作和生存中。在搭建直播零碎时,大家会常常听到两个高频词:RTMP(Real Time Messaging Protocol)和OBS(Open Broadcaster Software)。 RTMP协定是由Adobe公司提出的一种基于TCP的应用层的协定,用来解决多媒体数据传输流的多路复用(Multiplexing)和分包(Packetizing)的问题。RTMP已有近20年历史,广泛应用于直播行业的主播推流及不同零碎间互通。 OBS是一款好用的直播流媒体内容制作软件,为用户提供了视频、文本、图像等的捕捉录制性能,OBS界面简洁并业余,功能强大。OBS程序和其源代码都是收费提供给大家应用,版本更新始终比拟沉闷,反对 OS X、Windows、Linux操作系统,实用于多种直播场景,满足大部分直播行为的操作需要。 降级计划针对主播推流应用RTMP存在的TCP链接耗时过长、拥塞管制齐全依赖TCP传输层、无奈提供实时带宽数据来动静调整视频编码码率等问题引起的推流提早和卡顿。阿里云低延时直播RTS(Real-time Streaming)产品在上行UDP革新的根底上,进行上行UDP底层WebRTC技术优化,通过公布挪动端、PC端推流RTS SDK插件来晋升整个行业的主播推流品质,提供低延时、低卡顿、安全可靠的直播观看体验。客户端接入简略,只须要在 OBS 端嵌入RTS SDK即可新增一个推流协定,无需扭转原有的推流端采集架构。 成果比照主播端数据出自外部试验测算。 应用步骤Step 1、推流域名开明RTS在直播控制台增加好推流域名后,在域名治理页面推流域名的域名配置中通过低延时推流开关关上、敞开此性能。 Step 2、集成RTS SDKRTS SDK是为了OBS量身打造,无需改变OBS原生框架,接入RTS SDK实现obs-output插件即可,如下图所示。能够参考集成文档 https://help.aliyun.com/docum... 实现自主接入。为了不便用户接入,同时也封装了artc-stream的obs-output插件,只需退出OBS编译即可集成应用,详见《OBS示例插件artc-stream集成阐明》。 Step 3、应用RTS推流地址推流推流地址的拼接办法与RTMP统一,只须要应用新的协定头artc://来辨别,例如控制台生成的RTMP地址为: rtmp://push.rts*.grtn.aliyunlive.com/live/123?auth_key=1624860195-* 您只须要更换rtmp为artc即可: artc://push.rts*.grtn.aliyunlive.com/live/123?auth_key=1624860195-* Demo体验https://help.aliyun.com/docum... 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实际技术文章,在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群,和业内大咖一起探讨音视频技术,获取更多行业最新信息。

July 16, 2021 · 1 min · jiezi

关于云计算:超视频化到来你能看见什么

当人类优渥于一种状态,总有想象力冲破均衡。 1905 年,爱因斯坦否定了相对时空,引发物理世界三大革命。杨振宁曾说过,“爱因斯坦没有错失重点,是因为他对时空有着更自在的眼光。而要有自在的眼光,必须可能同时近观和远观同一课题。” 2021,阿里云视频云全景翻新峰会,致力尝试站在远景和近景之处,全景察看这个时代的超视频化课题。 这是个怎么的时代?这是超视频化时代。 视频让流淌的文字和图像演化成时代语言,视频把情绪、立场、眼界、思维立体化封装。视频在工夫域和空间域,一直地破维和延长。 视频化是一场博物学,包罗文字、影音,包罗空间、引力,包罗人文、情感,它出现没有边界的世界图景,它表白自在和发明新自在。 在超视频化时代,视频衍生了更多新形态,构建了全新的内容链条,所谓超内容;视频化逐步演变成以人为核心的交互,承载了多维感官、甚至超过时空的体验,所谓超交互;视频化让万物皆媒,人与人、人与物、人与自然,感应式链接,产生一种超社交能力和景象,所谓超链接。 视频成为全新的时代语言,视频化成为新世纪的新文化运动;而超将来的另一端,事实世界与虚拟世界的物理感知界线将模糊化,最终实现全场景的数字孪生。 当然,5G 是这个时代演进的助推器,让万物互联。而 “云 + 视频 “是场景变革的催化剂,让虚实交融。 随之,所有内容和交互,都将在这个时代产生聚变。 内容和交互的止境在哪?先谈内容。 技术,各式各样的技术,首先是在出现一个意义的世界。 技术制作意义并传递情感。是这样的,就像当带宽承载无限时,人们聚焦信息的传递;当带宽承载高增时,人们通过多维状态信息传递的,是情感。乔布斯在 2001 年的访谈中,曾经开始冀望通过互联网更多来传递情感,明天,视频云的技术能够实现。 如果技术助力内容传递情感,那回顾内容的演进,能够看到清晰的脉络:从一行文字、一幅画、到一部影像,始终倒退到明天的直播、短视频满溢,再到资讯和常识的视频化出现,直至全场景内容的逐步视频化,最终演变到以三维化、可交互为主的沉迷式内容状态。而在这一演进过程中,凸显了更大密度、更多维度、更多感官、拓扑空间的成长力。 现在,咱们能提前预感到沉迷式的学习场域,通过 5G、XR、全息投影、数字孪生和云化网络等技术的充沛交融,将形象的常识可视化、具象化,打造线上线下无边界课堂。能把浏览新闻演化成体验 “空间新闻 “,利用无限虚构、超高清技术、3D 和 360 全景技术,让人取得置身感与参与感,使新闻行业面临极大颠覆。更常见的是沉迷式文博,以文旅 IP 联合虚构 / 加强事实、全息投影、智能交互,造成万物沉迷、互动叙事的产业雏形。 在国外,沉迷式演唱会将搬上舞台,索尼与 Verizon 单干,将于今年冬天推出” 麦迪逊・比尔沉迷式 VR 演唱会 “。据说该体验联合 3D 动捕、容积捕获和 3D 重建技术,利用游戏引擎开发而成。同时,松下也发表和 Illuminariums 娱乐公司单干打造了一个大型沉迷式娱乐中心,场内内置 46 台 4K 投影,联合 LiDAR 传感器进行交互,还将交融空间音频,具备高度定制化。 认真品尝,沉迷式内容的状态有限设想。在内容状态中,咱们能纵览到从实体沉迷、虚构沉迷、虚构混合沉迷,再到泛在智能沉迷的线性成长路线,而止境的内容状态将会通过全域交互的模式重构体验,带来千人千面的独特内容。 再看交互。 《迷信的历程》中提到,“近代思想的一个革命性的变动,就在于从无限关闭的世界走向有限的宇宙。“ 认真反观交互的推演,也正是如此。 从线下到线上,所有场景都在试图腾挪空间,发明无界。基于科技和商业的推动,人们的交互在缓缓转向全场景线上化,而最终的状态也将是沉迷式的交互关系。不难发现,多端链接、多人共享、突破空间、虚实无缝联合,正是这一演进的趋势。而在能看到的起点,人机交互、脑机接口都是摸索重点。 如果纵览交互倒退的 60 年,能够分成三个次要倒退时代,而将来十年将外围聚焦在人机交互、传感器、在线社交通信、脑机接口和特色辨认。 材料起源:International Journal of Human–Computer Interaction 《Mapping Human–Computer Interaction Research Themes and Trends from Its Existence to Today: A Topic Modeling-Based Review of past 60 Years》 ...

July 15, 2021 · 2 min · jiezi

关于云计算:Kubernetes-必备工具2021

有别于前些天的文章 - 罕用的几款工具让 Kubernetes 集群上的工作更容易 偏重于工具类来晋升工作效率,明天这篇文章更加适宜用来做选型时的参考。 文档翻译自 Kubernetes Essential Tools: 2021,篇幅较长,做了局部增删。 介绍在本文中,我将尝试总结我最喜爱的 Kubernetes 工具,并特别强调最新的和鲜为人知但我认为会十分风行的工具。 这只是我依据我的教训得出的集体清单,但为了防止偏见,我还将尝试提及每种工具的代替计划,以便你能够依据本人的须要进行比拟和决定。我将尽可能缩短这篇文章并提供链接,以便你能够自行摸索更多内容。我的指标是答复这个问题:“我如何在 Kubernetes 中做 X?” 通过形容不同软件开发工作的工具。 K3DK3D 是我最喜爱的在笔记本电脑上运行 Kubernetes (K8s) 集群的形式。它十分笨重且速度十分快。它是应用 Docker 围绕 K3S 的包装器。所以,你只须要 Docker 来运行它并且资源使用率非常低。惟一的问题是它不完全符合 K8s 规范,但这不应该是本地开发的问题。对于测试环境,你能够应用其余解决方案。K3D 比 Kind 快,但 Kind 齐全兼容。 备选K3S 物联网或者边缘计算Kind 齐全兼容 Kubernetes 的备选MicroK8sMiniKubeKrewKrew 是治理的必备工具 Kubectl 插件,这是一个必须有任何 K8S 用户。我不会具体介绍超过 145 个可用插件,但至多装置 kubens 和 kubectx。 LensLens 是实用于 SRE、Ops 和开发人员的 K8s IDE。它实用于任何 Kubernetes 发行版:本地或云端。它疾速、易于应用并提供实时可察看性。应用 Lens 能够十分轻松地治理多个集群。如果你是集群操作员,这是必须的。 备选对于那些喜爱轻量级终端替代品的人来说,K9s 是一个很好的抉择。K9s 会继续察看 Kubernetes 的变动,并提供后续命令来与你察看到的资源进行交互。HelmHelm 不须要介绍,它是 Kubernetes 最驰名的包管理器。你应该在 K8s 中应用包管理器,就像在编程语言中应用它一样。Helm 容许你将应用程序打包到 Charts 中,将简单的应用程序形象为易于定义、装置和更新的可重用简略组件。 ...

July 15, 2021 · 4 min · jiezi

关于云计算:Oracle-DBA01Oracle-11G-R2-for-Solaris-10Spac安装实施报告

1 零碎环境需要1.1 装置前的零碎环境筹备查看Solaris服务器装置实现并打上最新的补丁集网络环境连通并调试失常。磁盘阵列装置实现并按ORACLE零碎进行磁盘划分。1.2 硬件要求内存:> 2G。SWAP区:2G。通常等于物理内存,最低不少于1G。硬盘容量:数据库软件 > 4G。数据库 > 2G。/tmp:长期目录空间大于500M。1.3 软件要求操作系统及Patches:Solaris 10补丁 SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibm SUNWlibms SUNWmfrun SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt SUNWcsl SUNWxcu42 筹备工作2.1 查看操作系统运行环境查看是否蕴含所需Patch。命令:pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibm SUNWlibms SUNWmfrun SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt SUNWcsl SUNWxcu4查看操作系统的版本# uname -r查看理论可用内存,命令:# /usr/sbin/prtconf | grep "Memory size"查看替换区大小。命令:# /usr/sbin/swap -s查看文件系统可用空间和长期目录/tmp可用空间。命令:# df -h /tmp# df -h查看操作系统内核架构# /bin/isainfo -kv查看网络# hostname# ifconfig –a# ping服务器的hosts文件内容: #public IP172.16.10.1 BXDB1172.16.10.2 BXDB2#private IP172.16.1.3 BXDB1-priv172.16.1.4 BXDB2-priv#VIP172.16.10.7 BXDB1-vip172.16.10.8 BXDB2-vip#SCAN172.16.10.9 BXDB-scan查看节点工夫保障同步# date2.2 用户的筹备工作(BXDB1和BXDB2雷同)批改UDP参数$ vi /etc/rc2.d/S99ndd增加 ...

July 14, 2021 · 7 min · jiezi

关于云计算:kubebuilder实战之七webhook

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 本篇概览本文是《kubebuilder实战》系列的第七篇,之前的文章咱们实现了一个Operator的设计、开发、部署、验证过程,为了让整个过程放弃简洁并且篇幅不收缩,实战中刻意跳过了一个重要的知识点:<font color="red">webhook</font>,现在是时候学习它了,这是个很重要的性能;本篇由以下局部形成:介绍webhook;联合后面的elasticweb我的项目,设计一个应用webhook的场景;筹备工作生成webhook开发(配置)开发(编码)部署验证Defaulter(增加默认值)验证Validator(合法性校验)对于webhook相熟java开发的读者大多晓得过滤器(Servlet Filter),如下图,内部申请会先达到过滤器,做一些对立的操作,例如转码、校验,而后才由真正的业务逻辑解决申请: Operator中的webhook,其作用与上述过滤器相似,内部对CRD资源的变更,在Controller解决之前都会交给webhook提前解决,流程如下图,该图来自《Getting Started with Kubernetes | Operator and Operator Framework》: 再来看看webhook具体做了哪些事件,如下图,kubernetes官网博客明确指出webhook能够做两件事:批改(mutating)和验证(validating)kubebuilder为咱们提供了生成webhook的根底文件和代码的工具,与制作API的工具相似,极大地简化了工作量,咱们只需聚焦业务实现即可;基于kubebuilder制作的webhook和controller,如果是同一个资源,那么<font color="red">它们在同一个过程中</font>;设计实战场景为了让实战有意义,咱们为后面的elasticweb我的项目上减少需要,让webhook施展理论作用;如果用户遗记输出总QPS,零碎webhook负责设置默认值<font color="red">1300</font>,操作如下图: 为了爱护零碎,给单个pod的QPS设置下限<font color="red">1000</font>,如果内部输出的singlePodQPS值超过1000,<font color="blue">就创立资源对象失败</font>,如下图所示: 源码下载本篇实战中的残缺源码可在GitHub下载到,地址和链接信息如下表所示(https://github.com/zq2599/blo...:名称链接备注我的项目主页https://github.com/zq2599/blo...该我的项目在GitHub上的主页git仓库地址(https)https://github.com/zq2599/blo...该我的项目源码的仓库地址,https协定git仓库地址(ssh)mailto:git@github.com:zq2599/blog_demos.git该我的项目源码的仓库地址,ssh协定这个git我的项目中有多个文件夹,kubebuilder相干的利用在<font color="blue">kubebuilder</font>文件夹下,如下图红框所示: kubebuilder文件夹下有多个子文件夹,本篇对应的源码在<font color="blue">elasticweb</font>目录下,如下图红框所示: 筹备工作和controller相似,webhook既能在kubernetes环境中运行,也能在kubernetes环境之外运行;如果webhook在kubernetes环境之外运行,是有些麻烦的,须要将证书放在所在环境,默认地址是:/tmp/k8s-webhook-server/serving-certs/tls.{crt,key}为了省事儿,也为了更靠近生产环境的用法,接下来的实战的做法是<font color="red">将webhook部署在kubernetes环境中</font>为了让webhook在kubernetes环境中运行,咱们要做一点筹备工作<font color="blue">装置cert manager</font>,执行以下操作:kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml上述操作实现后会新建很多资源,如namespace、rbac、pod等,以pod为例如下:[root@hedy ~]# kubectl get pods --all-namespacesNAMESPACE NAME READY STATUS RESTARTS AGEcert-manager cert-manager-6588898cb4-nvnz8 1/1 Running 1 5d14hcert-manager cert-manager-cainjector-7bcbdbd99f-q645r 1/1 Running 1 5d14hcert-manager cert-manager-webhook-5fd9f9dd86-98tm9 1/1 Running 1 5d14h...操作实现后,筹备工作完结,能够开始实战了;生成webhook进入elasticweb工程下,执行以下命令创立webhook:kubebuilder create webhook \--group elasticweb \--version v1 \--kind ElasticWeb \--defaulting \--programmatic-validation上述命令执行结束后,先去看看<font color="blue">main.go</font>文件,如下图红框1所示,主动减少了一段代码,作用是让webhook失效: 上图红框2中的<font color="blue">elasticweb_webhook.go</font>就是新增文件,内容如下:package v1import ( "k8s.io/apimachinery/pkg/runtime" ctrl "sigs.k8s.io/controller-runtime" logf "sigs.k8s.io/controller-runtime/pkg/log" "sigs.k8s.io/controller-runtime/pkg/webhook")// log is for logging in this package.var elasticweblog = logf.Log.WithName("elasticweb-resource")func (r *ElasticWeb) SetupWebhookWithManager(mgr ctrl.Manager) error { return ctrl.NewWebhookManagedBy(mgr). For(r). Complete()}// EDIT THIS FILE! THIS IS SCAFFOLDING FOR YOU TO OWN!// +kubebuilder:webhook:path=/mutate-elasticweb-com-bolingcavalry-v1-elasticweb,mutating=true,failurePolicy=fail,groups=elasticweb.com.bolingcavalry,resources=elasticwebs,verbs=create;update,versions=v1,name=melasticweb.kb.iovar _ webhook.Defaulter = &ElasticWeb{}// Default implements webhook.Defaulter so a webhook will be registered for the typefunc (r *ElasticWeb) Default() { elasticweblog.Info("default", "name", r.Name) // TODO(user): fill in your defaulting logic.}// TODO(user): change verbs to "verbs=create;update;delete" if you want to enable deletion validation.// +kubebuilder:webhook:verbs=create;update,path=/validate-elasticweb-com-bolingcavalry-v1-elasticweb,mutating=false,failurePolicy=fail,groups=elasticweb.com.bolingcavalry,resources=elasticwebs,versions=v1,name=velasticweb.kb.iovar _ webhook.Validator = &ElasticWeb{}// ValidateCreate implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateCreate() error { elasticweblog.Info("validate create", "name", r.Name) // TODO(user): fill in your validation logic upon object creation. return nil}// ValidateUpdate implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateUpdate(old runtime.Object) error { elasticweblog.Info("validate update", "name", r.Name) // TODO(user): fill in your validation logic upon object update. return nil}// ValidateDelete implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateDelete() error { elasticweblog.Info("validate delete", "name", r.Name) // TODO(user): fill in your validation logic upon object deletion. return nil}上述代码有两处须要留神,第一处和填写默认值无关,如下图: ...

July 14, 2021 · 4 min · jiezi

关于云计算:github搜索技巧小结

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 对于搜寻对本人而言,这是篇迟来的重要的笔记,github是宝库,搜寻办法不当可能与宝贵的代码擦肩而过,于是将罕用搜寻办法分类总结以备不时之需;集体罕用搜寻办法总的来说分为<font color="blue">作者</font>和<font color="blue">内容</font>两种,依照本人的习惯做了简略分类,如下图: 尽管搜寻更罕用,然而本着先易后难的准则,先从作者搜寻开始;作者搜寻如下图红框,github帐号能够设置本人的<font color="blue">fullname</font>,咱们能够通过这个字段准确搜寻到集体: 在网页左上角输出<font color="red">fullname:程序员欣宸</font>就能够搜寻到这个作者,如下图: 很多github帐号会设置本人的地址,如下图红框,这些也能够作为找人的条件: 例如搜寻<font color="blue">tom</font>,会有很多同名的: 如果咱们晓得要找的tom在深圳,就能够大幅度放大搜寻范畴,关键字是<font color="blue">fullname:tom location:shenzhen</font>,只有22个后果: 以上就是搜寻用户的操作,接下来是更罕用的内容搜素;内容搜寻概览搜寻内容时的参数略多,依照应用习惯,我这简略分为三类:准确:格局是<font color="blue">language:残缺关键词</font>,如<font color="red">language:java</font>含糊:相似字符串的含糊匹配,格局是<font color="blue">in:条件名 关键词</font>,如<font color="red">in:name spring-boot</font>范畴:和量化范畴无关的,格局是<font color="blue">条件名:>数量</font>,常和其余条件一起应用,如<font color="red">in:name spring-boot stars:>10000</font>接下来细说上述三类搜寻;准确最罕用的准确搜寻就是指定语言类型了,先看不指定语言类型时,搜寻<font color="blue">断点续传</font>的后果如下图,各种语言都有: 如果只有java语言的,用<font color="blue">断点续传 language:java</font>去搜,后果如下图: 含糊含糊是锁定内容的要害,罕用的有三种条件:name(项目名称)、description(我的项目形容)、readme(仓库中的READ.md文件)通过项目名称搜寻,如名称中有spring和boot两个关键词的我的项目,搜寻条件是<font color="blue">in:name spring boot</font> 通过我的项目形容搜寻,这个是我本人用的最多的形式,例如我想找到现成的断点续传代码,java版的,搜寻条件是<font color="blue">in:description 断点续传 language:java</font> 通过仓库中的README.md的内容搜寻也很罕用,这外面通常会有具体的文档信息,例如我想grpc的server端代码,java版,搜寻条件是<font color="blue">in:readme grpc server language:java</font> 例如我想找kubernetes进阶实战相干的内容,搜寻条件是<font color="blue">in:readme kubernetes进阶实战</font>,后果如下,红框中是欣宸本人的仓库,外面有关键字<font color="red">kubernetes进阶实战</font>,查得...挺准的: 范畴如果用后面伎俩搜寻的内容太多,还能够指定范畴,罕用的类型有:stars(star数)、forks(fork数)、pushed(最初提交工夫)、size(文件大小)搜寻名称中有spring-boot且star数大于一万的我的项目,<font color="blue">in:name spring-boot stars:>10000</font> 搜寻名称中有spring-boot且fork数大于一万的我的项目,<font color="blue">in:name spring-boot forks:>10000</font> 搜寻名称中有spring-boot且2021年3月12日之后更新过的我的项目<font color="blue">in:name spring-boot pushed:>2021-03-12</font> 搜寻名称中有spring-boot且内容大于<font color="red">100k</font>的我的项目<font color="blue">in:name spring-boot size:>100</font>,留神这个数字的默认单位是<font color="red">k</font>: 排序搜寻出后果后,还能够对后果排序进行调整,操作地位如下图红框: 把上图红框中的每个排序类型列出来: 名称意义Best match关键词匹配水平Most stars最多starFewest stars起码starMost forks最多forkFewest forks起码forkRecently updated最近更新Least recently updateed更新工夫距今最长远以上就是我的github搜寻技巧小结了,心愿能给您一些参考,更高效的挖掘github宝藏;你不孤独,欣宸原创一路相伴Java系列Spring系列Docker系列kubernetes系列数据库+中间件系列DevOps系列欢送关注公众号:程序员欣宸微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界...https://github.com/zq2599/blog_demos

July 14, 2021 · 1 min · jiezi

关于云计算:云原生爱好者周刊长得最像苹果的-Linux-桌面

云原生一周动静要闻 SUSE 公布 Harvester 0.2.0IBM 收买容器服务提供商 BoxBoatKubernetes 和云原生经营报告 2021 公布实用于 Kubernetes 的下一代 Crunchy Postgres 公布开源我的项目举荐文章举荐无论学习任何常识,咱们都要经验“先把书读厚,再把书读薄”这个过程。读厚就是合成、详细分析,是输出的过程,读薄便是演绎总结,是输入的过程。演绎总结最好的形式就是思维导图这种模式,计算机领域也不例外。GitHub 上有位热心大佬就用思维导图总结了本人对 Linux 操作系统,网络,C++,Golang 以及 Kubernetes 的了解。例如:为什么须要 Pod? 关注公众号 「KubeSphere 云原生」,后盾回复「psyduck」即可获取所有思维导图的下载链接。 云原生动静SUSE 公布 Harvester 0.2.0,一个应用 Kubernetes 构建的 HCI 解决方案Harvester 是一种应用 Kubernetes 构建的开源超交融基础设施 (HCI) 软件,最近公布了 0.2.0 版本。Harvester 可用于在裸机服务器上施行 HCI,是 vSphere 和 Nutanix 的开源替代品。第一个版本 0.1.0 已于往年早些时候公开。 Harvester 当初反对 VM 实时迁徙,使 VM 可能从一个节点迁徙到另一个节点以执行保护工作。 Harvester 0.2.0 减少了虚拟机备份反对,提供了一种在集群外备份虚拟机镜像的办法。能够通过创立 S3 兼容端点或 NFS 服务来存储 VM 卷的备份。 PXE 疏导装置反对当初能够在 Harvester 中应用,从而能够轻松地应用所需的操作系统填充裸机节点。 ...

July 13, 2021 · 2 min · jiezi

关于云计算:Rego不好用用Pipy实现OPA

还不晓得 Pipy 是什么的同学能够看下 GitHub 。 Pipy 是一个轻量级、高性能、高稳固、可编程的网络代理。Pipy 外围框架应用 C++ 开发,网络 IO 采纳 ASIO 库。 Pipy 的可执行文件仅有 5M 左右,运行期的内存占用 10M 左右,因而 Pipy 非常适合做 Sidecar proxy。Rego 不好用?用 Pipy 实现 OPAPipy 内置了自研的 pjs 作为脚本扩大,使得Pipy 能够用 JS 脚本依据特定需要疾速定制逻辑与性能。 Pipy 采纳了模块化、链式的解决架构,用程序执行的模块来对网络数据块进行解决。这种简略的架构使得 Pipy 底层简略牢靠,同时具备了动静编排流量的能力,兼顾了简略和灵便。通过应用 REUSE_PORT 的机制(支流 Linux 和 BSD 版本都反对该性能),Pipy 能够以多过程模式运行,使得 Pipy 不仅实用于 Sidecar 模式,也实用于大规模的流量解决场景。 在实践中,Pipy 独立部署的时候用作“软负载”,能够在低提早的状况下,实现媲美硬件的负载平衡吞吐能力,同时具备灵便的扩展性。 在玩过几次 Pipy 并探索其工作原理后,又有了更多的想法。 初探可编程网关 Pipy可编程网关 Pipy 第二弹:编程实现 Metrics 及源码解读可编程网关 Pipy 第三弹:事件模型设计在应用OPA的时候,始终感觉Rego不是那么棘手,应用pipy js来写规定的想法油然而生。明天就一起试试这个思路。果然,不试不晓得,一试发现太多的惊喜~Pipy不止于“代理”,更有很多能够实用的场景: 极小的繁多可执行文件(single binary)使得 pipy 可能是最好的 “云原生 sidecar”sidecar 不仅仅是代理,还能够做控制器,做运算单元proxy 的串路构造适宜各种管控类的操作,比方访问控制Pipy js 的扩大能力和疾速编程能力,很适宜做 “规定引擎”,或者用最近风行的说法 “云原生的规定引擎”。比照 OPA 我认为它齐全够格做一个 “羽量级规定执行引擎”当初我更偏向于定义 pipy 是一个 “云原生的流量编程框架”,代理只是其底层的外围能力,叠加了 pipy js 当前,下层能够做的事件很多,“流量滋润万物”。 ...

July 13, 2021 · 4 min · jiezi

关于云计算:Linux云计算06Linux磁盘管理

本章介绍硬盘简介、硬盘数据存储形式、如何在企业生产服务器增加硬盘、对硬盘进行分区、初始化、挂载等。 1 计算机硬盘简介硬盘是计算机次要存储媒介之一,由一个或者多个铝制或者玻璃制的碟片组成,碟片外笼罩有铁磁性资料,硬盘外部由磁道、柱面、扇区、磁头等部件组成,如图所示: Linux零碎中硬件设施相干配置文件寄存在/dev下,常见硬盘命名:/dev/hda、/dev/sda、/dev/sdb、/dev/sdc、/dev/vda。不同硬盘接口,在零碎中辨认的设施名称不一样。 IDE硬盘接口在Linux中设施名为/dev/hda,SAS、SCSI、SATA硬盘接口在Linux中设施名为sda,高效云盘硬盘接口会辨认为/dev/vda等。 文件贮存在硬盘上,硬盘的最小存储单位叫做Sector(扇区),每个Sector贮存512字节。操作系统在读取硬盘的时候,不会一一Sector的去读取,这样效率非常低,为了晋升读取效率,操作系统会一次性间断读取多个Sector,即一次性读取多个Sector称为一个Block(块)。 由多个Sector组成的Block是文件存取的最小单位。Block的大小常见的有1KB、2KB、4KB,Block在Linux中常设置为4KB,即间断八个Sector组成一个Block。 能够通过如下办法查看Linux分区的Block大小: [root@superman-vm01 ~]# stat /boot | grep "IO Block" Size: 4096 Blocks: 8 IO Block: 4096 directory[root@superman-vm01 ~]# 例如创立一个一般文件,文件大小为10Bytes,而默认设置Block为4K,如果有1万个小文件,因为每个Block只能寄存一个文件,如果文件的大小比Block大,会申请更多的Block,相同如果文件的大小比默认Block小,仍会占用一个Block,这样残余的空间会被节约掉。 1万个文件实践只占用空间大小:10000x10=100000Bytes=97.65625MBytes;1万个文件实在占用空间大小:10000x4096Bytes=40960000Bytes=40000MBytes=40GB;依据企业理论需要,此时能够将Block设置为1K,从而节俭更多的空间。2 硬盘Block及Inode详解通常而言,操作系统对于文件数据的寄存包含两个局部:文件内容、权限及文件属性。操作系统文件寄存是基于文件系统,文件系统会将文件的理论内容存储到Block中,而将权限与属性等信息寄存至Inode中。 在硬盘分区中,还有一个超级区块 (SuperBlock) ,SuperBlock会记录整个文件系统的整体信息,包含Inode、Block总量、应用大小、残余大小等信息,每个inode与block都有编号对应,不便Linux零碎疾速定位查找文件。 Superblock:记录文件系统的整体信息,包含inode与block的总量、应用大小、残余大小, 以及文件系统的格局与相干信息等;Inode:记录文件的属性,权限,同时会记录该文件的数据所在的block编号;Block:存储文件的内容,如果文件超过默认Block大小,会主动占用多个Block。因为每个inode与block都有编号,而每个文件都会占用一个inode ,inode内则有文件数据搁置的block号码。如果可能找到文件的inode,就能够找到该文件所搁置数据的block号码,从而读取该文件内容。 操作系统进行格式化分区时,操作系统主动将硬盘分成两个区域。一个是数据Block区,用于寄存文件数据;另一个是Inode Table区,用于寄存inode蕴含的元信息。 每个inode节点的大小,能够在格式化时指定,默认为128Bytes或256Bytes,/boot分区Inode默认为128Bytes,其它分区默认为256Bytes,查看Linux零碎Inode办法如下: [root@superman-vm01 ~]# stat /boot | grep "Inode" Device: 801h/2049d Inode: 64 Links: 5[root@superman-vm01 ~]# 3 硬链接介绍个别状况下,文件名和inode编号是一一对应的关系,每个inode号码对应一个文件名。但UNIX/Linux零碎多个文件名也能够指向同一个inode号码。这意味着能够用不同的文件名拜访同样的内容,对文件内容进行批改,会影响到所有文件名。但删除一个文件名,不影响另一个文件名的拜访。这种状况就被称为硬链接(hard link)。 创立硬链接的命令为:ln superman1.txt superman2.txt,其中superman1.txt为源文件,superman2.txt为指标文件。如上命令源文件与指标文件的inode号码雷同,都指向同一个inode。inode信息中有一项叫做"链接数",记录指向该inode的文件名总数,这时会减少1,变成2,如图7-3所示: 同样删除一个superman2.txt文件,就会使得superman1.txt inode节点中的"链接数"减1。如果该inode值减到0,表明没有文件名指向这个inode,零碎就会回收这个inode号码,以及其所对应block区域,如图所示: 实用小技巧:硬链接不能跨分区链接,硬链接只能对文件失效,对目录有效,也即是目录不能创立硬链接。硬链接源文件与指标文件共用一个inode值,从某种意义上来,节俭inode空间。不论是独自删除源文件还是删除指标文件,文件内容始终存在。同时链接后的文件不占用零碎多余的空间。 4 软链接介绍除了硬链接以外,还有一种链接-软链接。文件superman1.txt和文件superman2.txt的inode号码尽管不一样,然而文件superman2.txt的内容是文件superman1.txt的门路。读取文件superman2.txt时,零碎会主动将访问者导向文件superman1.txt。 无论关上哪一个文件,最终读取的都是文件superman1.txt。这时,文件superman2.txt就称为文件superman1.txt的"软链接"(soft link)或者"符号链接(symbolic link)。 文件superman2.txt依赖于文件superman1.txt而存在,如果删除了文件superman1.txt,关上文件superman2.txt就会报错:"No such file or directory"。 ...

July 13, 2021 · 2 min · jiezi

关于云计算:云具匠心在宜宾-浪潮云亮相第二届中国国际智能终端产业发展大会

7月9日,由四川省人民政府主办,中国通信学会、中国信息通信研究院,四川省经济和信息化厅、宜宾市人民政府承办的“第二届中国智能终端产业倒退大会”在宜宾市国内会展中心正式拉开帷幕,大会以“智翻新生态 共赢新时代”为主题,分享数字经济产业前沿倒退成绩。作为宜宾数字经济的重要参与者与支持者,浪潮云应邀参会,并于现场全方位展现业余、生态、可信赖的高品质云产品、解决方案和实际案例。 “构建以国内大循环为主体、国内国内双循环相互促进的新倒退格局”策略背景下,宜宾以十四五年布局和2035年近景指标大纲为领导,充分发挥数据新型生产因素的关键作用和数字技术的驱动作用,增强数字社会、数字政府建设,晋升公共服务、社会治理等数字化智能化程度。在此过程中浪潮云基于国内最大的分布式云体系,以宜宾云数据中心为依靠,通过云网边端交融、云数智交融、建管运交融的全栈云服务踊跃助力数字宜宾的建设。 浪潮宜宾云数据中心以“分布式云+”为根底,将数据服务、AI、信创、运管、云原生五大能力逐步内化于宜宾政企行业倒退基底,为宜宾的整体倒退提供翻新根底反对——护航数十万名考生的人事考试报名、高考意愿填报以及中考意愿填报,高效撑持宜宾人才培养及人才提拔; 助力“快、稳、准”圈粉有数的宜宾智轨,通过独创“智轨控制系统”以“看似无轨、芯中有轨”的形式实现“类轨道”云上运行不便市民出行; 以政务云为底座,交融政府数据、社会凋谢数据及互联网数据打造的城市对立服务平台——“戎e通”(爱城市网)APP,实现了宜宾市民“掐点儿”坐公交、“衰弱宜宾”电子衰弱卡一卡通用多家医院、一键查问五险一金……推动城市低碳、文化运行,打造宜宾城市服务名片; 反对宜宾市政府大数据共享开放平台继续优化,撑持全市政务资源凋谢共享,晋升政务服务能力,守护市民“不跑腿、办快事”的取得感和幸福感; 宜宾疫情防疫大数据平台、白酒打假大数据平台以及浪潮与五粮液团体、中国酒业协会、电子科大联结成立的中国酒业大数据中心……宜宾云数据中心已不再局限于宜宾市政府行政办公,更面向民生、智慧城市等畛域,让智慧翻新赋予城市翻新的能源和方向。

July 12, 2021 · 1 min · jiezi

关于云计算:Open-Policy-Agent-Top-5-Kubernetes-准入控制策略

如何应用 Open Policy Agent 实现准入策略管制,能够参考这里 本文翻译自 Open Policy Agent: The Top 5 Kubernetes Admission Control Policies Kubernetes 开发人员和平台工程师通常接受着十分大的压力,以放弃应用程序部署的疾速进行,并且总是为了速度和进度而做出斗争。平台团队越来越有责任确保这些斗争(例如治理 Ingress)不会导致客户数据裸露在整个互联网上等结果。 侥幸的是,Kubernetes 提供了设置策略的能力,通过查看并避免部署谬误将其投入生产,从而防止这些结果。为了确保团队的应用程序不会比信念更重要,以下是当初应该在集群中运行的前五个 Kubernetes 准入控制策略。 1. 可信镜像仓库此策略很简略,但功能强大:仅容许从受信赖的镜像仓库中拉取的容器映像,并且能够抉择仅拉取与容许的仓库镜像地址列表匹配的那些镜像。 当然,从互联网(或可信镜像仓库库以外的任何中央)拉取未知镜像会带来危险——例如恶意软件。然而还有其余很好的理由来保护繁多的可信起源,例如在企业中实现可支持性。通过确保镜像仅来自受信赖的镜像仓库,能够亲密管制镜像库存,升高软件熵和蔓延的危险,并进步集群的整体安全性。 相干策略: 禁止所有带有“latest” tag 的镜像仅容许签名镜像或匹配特定哈希/SHA 的镜像策略示例: package kubernetes.validating.images deny[msg] { some i input.request.kind.kind == "Pod" image := input.request.object.spec.containers[i].image not startswith(image, "hooli.com/") msg := sprintf("Image '%v' comes from untrusted registry", [image])}2. 标签平安此策略要求所有 Kubernetes 资源都蕴含指定的标签并应用适当的格局。因为标签决定了 Kubernetes 对象和策略的分组,包含工作负载能够运行的地位——前端、后端、数据层——以及哪些资源能够发送流量,标签谬误会导致生产中无法解释的部署和可支持性问题。此外,如果没有对标签利用形式的访问控制,集群就不足根本的安全性。最初,手动输出标签的危险在于谬误会蔓延,特地是因为标签在 Kubernetes 中既灵便又弱小。利用此策略并确保标签配置正确且统一。 相干政策: 确保每个工作负载都须要特定的注解(annotations)指定污点和容忍度以限度能够部署映像的地位策略示例: package kubernetes.validating.existence deny[msg] { not input.request.object.metadata.labels.costcenter msg := "Every resource must have a costcenter label"} deny[msg] { value := input.request.object.metadata.labels.costcenter not startswith(value, "cccode-") msg := sprintf("Costcenter code must start with `cccode-`; found `%v`", [value])}
## 3. 禁止(或指定)特权模式 ...

July 12, 2021 · 2 min · jiezi

关于云计算:KubeSphere-Argo-CD实现真正的-GitOps

来自社区用户 willqy 的分享Argo CD 简介Argo CD 是用于 Kubernetes 的申明性 GitOps 继续交付工具,利用程序定义,配置和环境应为申明性的,并应受版本控制,应用程序部署和生命周期治理应该是自动化、可审核且易于了解。 Argo CD 遵循 GitOps 模式,该模式应用 Git 仓库作为定义所需应用程序状态的实在起源。 Argo CD 可在指定的指标环境中主动部署所需的应用程序状态,应用程序部署能够在 Git 提交时跟踪对分支,标签的更新,或固定到清单的特定版本。 官网:https://argoproj.github.io/ Argo CD 架构图: Argo CD 被实现为 Kubernetes 控制器,该控制器继续监督正在运行的应用程序,并将以后的活动状态与所需的指标状态(在 Git 存储库中指定)进行比拟。当已部署应用程序的运行状态偏离指标状态时将被 Argo CD 视为 OutOfSync。 Argo CD 报告并可视化差别,同时提供了主动或手动将实时状态同步回所需指标状态的性能。在 Git 存储库中对所需指标状态所做的任何批改都能够主动利用并同步到指定的指标环境中。 Argo CD 反对的 Kubernetes 配置清单包含 helm charts、kustomize 或纯 YAML/json 文件等。 本篇文章波及内容: 应用 KubeSphere DevOps 实现 CI 局部, CD 局部由 Argo CD 实现;Argo CD 继续监测 Git 仓库某个目录下 yaml 文件变动,主动将 yaml 文件部署到 K8s 集群;Argo CD 继续监测 Harbor 镜像仓库某个镜像 tag 变动,主动将最新镜像部署到 K8s 集群。基本原理图: ...

July 12, 2021 · 7 min · jiezi

关于云计算:clientgo实战之五DiscoveryClient

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 对于DiscoveryClient本文是《client-go实战》系列的第五篇,配角是最初一种客户端:DiscoveryClient,咱们之前学习的Clientset和dynamicClient都是面向资源对象的(例如创立deployment实例、查看pod实例),而DiscoveryClient则不同,它聚焦的是资源,例如查看以后kubernetes有哪些Group、Version、Resource,上面是DiscoveryClient数据结构的字段和关联办法,再次看到了相熟的restClient字段,还有一众办法皆是与Group、Version、Resource无关: 从上图可见,DiscoveryClient数据结构有两个字段:restClient和LegacyPrefix,这个<font color="blue">LegacyPrefix</font>是啥呢?去看看新建DiscoveryClient实例的办法,如下图红框,原来是个固定字符串<font color="red">/api</font>,看起来像是url中的一部分: 挑一个DiscoveryClient的关联办法看看,如下图红框,果然,LegacyPrefix就是url中的一部分: 相比其余几个客户端,DiscoveryClient要更简略一些,罗唆间接实战吧!需要确认本次实战的需要很简略:从kubernetes查问所有的Group、Version、Resource信息,在控制台打印进去;源码下载本篇实战中的源码可在GitHub下载到,地址和链接信息如下表所示(https://github.com/zq2599/blo...:名称链接备注我的项目主页https://github.com/zq2599/blo...该我的项目在GitHub上的主页git仓库地址(https)https://github.com/zq2599/blo...该我的项目源码的仓库地址,https协定git仓库地址(ssh)mailto:git@github.com:zq2599/blog_demos.git该我的项目源码的仓库地址,ssh协定这个git我的项目中有多个文件夹,client-go相干的利用在<font color="blue">client-go-tutorials</font>文件夹下,如下图红框所示: client-go-tutorials文件夹下有多个子文件夹,本篇对应的源码在<font color="blue">discoveryclientdemo</font>目录下,如下图红框所示: 编码新建文件夹discoveryclientdemo,在外面执行以下命令,新建module:go mod init discoveryclientdemo增加k8s.io/api和k8s.io/client-go这两个依赖,留神版本要匹配kubernetes环境:go get k8s.io/api@v0.20.0go get k8s.io/client-go@v0.20.0新建main.go,内容如下,外部已有具体正文,要重点关注的是ServerGroupsAndResources办法的第二个返回值,它的数据结构中有切片,切片的每个元素外面又有切片,这才是每个资源的信息:package mainimport ( "flag" "fmt" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/client-go/discovery" "k8s.io/client-go/tools/clientcmd" "k8s.io/client-go/util/homedir" "path/filepath")func main() { var kubeconfig *string // home是家目录,如果能获得家目录的值,就能够用来做默认值 if home:=homedir.HomeDir(); home != "" { // 如果输出了kubeconfig参数,该参数的值就是kubeconfig文件的绝对路径, // 如果没有输出kubeconfig参数,就用默认门路~/.kube/config kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file") } else { // 如果取不到以后用户的家目录,就没方法设置kubeconfig的默认目录了,只能从入参中取 kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file") } flag.Parse() // 从本机加载kubeconfig配置文件,因而第一个参数为空字符串 config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig) // kubeconfig加载失败就间接退出了 if err != nil { panic(err.Error()) } // 新建discoveryClient实例 discoveryClient, err := discovery.NewDiscoveryClientForConfig(config) if err != nil { panic(err.Error()) } // 获取所有分组和资源数据 APIGroup, APIResourceListSlice, err := discoveryClient.ServerGroupsAndResources() if err != nil { panic(err.Error()) } // 先看Group信息 fmt.Printf("APIGroup :\n\n %v\n\n\n\n",APIGroup) // APIResourceListSlice是个切片,外面的每个元素代表一个GroupVersion及其资源 for _, singleAPIResourceList := range APIResourceListSlice { // GroupVersion是个字符串,例如"apps/v1" groupVerionStr := singleAPIResourceList.GroupVersion // ParseGroupVersion办法将字符串转成数据结构 gv, err := schema.ParseGroupVersion(groupVerionStr) if err != nil { panic(err.Error()) } fmt.Println("*****************************************************************") fmt.Printf("GV string [%v]\nGV struct [%#v]\nresources :\n\n", groupVerionStr, gv) // APIResources字段是个切片,外面是以后GroupVersion下的所有资源 for _, singleAPIResource := range singleAPIResourceList.APIResources { fmt.Printf("%v\n", singleAPIResource.Name) } }}执行<font color="blue">go run main.go</font>,截取局部执行后果如下,所有资源都被打印进去了:...*****************************************************************GV string [discovery.k8s.io/v1beta1]GV struct [schema.GroupVersion{Group:"discovery.k8s.io", Version:"v1beta1"}]resources :endpointslices*****************************************************************GV string [flowcontrol.apiserver.k8s.io/v1beta1]GV struct [schema.GroupVersion{Group:"flowcontrol.apiserver.k8s.io", Version:"v1beta1"}]resources :flowschemasflowschemas/statusprioritylevelconfigurationsprioritylevelconfigurations/status以上就是DiscoveryClient的根本用法,您是否感觉这样的实战太easy了,那咱们就来个延长浏览,看看DiscoveryClient的周边场景;kubectl中如何应用DiscoveryClient<font color="blue">kubectl api-versions</font>命令,大家应该不生疏吧,能够返回以后kubernetes环境的所有Group+Version的组合,如下:zhaoqin@zhaoqindeMBP-2 discoveryclientdemo % kubectl api-versionsadmissionregistration.k8s.io/v1admissionregistration.k8s.io/v1beta1apiextensions.k8s.io/v1apiextensions.k8s.io/v1beta1apiregistration.k8s.io/v1apiregistration.k8s.io/v1beta1apps/v1authentication.k8s.io/v1...通过查看kubectl源码可见,上述命令的背地就是应用了DiscoveryClient来实现的,如下图红框所示: ...

July 12, 2021 · 1 min · jiezi

关于云计算:Linux云计算05Linux软件包管理

本章介绍Linux系统软件的装置、卸载、配置、保护以及如何构建企业本地YUM光盘源及HTTP本地源。 1 RPM软件包治理Linux软件包治理大抵可分为二进制包、源码包,应用的工具也各不相同。Linux常见软件包分为两种,别离是源代码包(Source Code)、二进制包(Binary Code),源代码包是没有通过编译的包,须要通过GCC、C++编译器环境编译能力运行,二进制包无需编译,能够间接装置应用。 通常而言,能够通过后缀简略区别源码包和二进制包,例如.tar.gz、.zip、.rar结尾的包通常称之为源码包,以.rpm结尾的软件包称之为二进制包。真正辨别是否为源码还是二进制还得基于代码外面的文件来判断,例如蕴含.h、.c、.cpp、.cc等结尾的源码文件,称之为源码包,而代码外面存在bin目录能够执行文件,称之为二进制包。 CentOS操作系统中有一款默认软件治理的工具,红帽包管理工具(Red Hat Package Manager,RPM)。 应用RPM工具能够对软件包实现疾速装置、治理及保护。RPM管理工具实用的操作系统包含:CentOS,RedHat,Fedora,SUSE等,RPM工具罕用于治理.rpm后缀结尾的软件包。 RPM软件包命令规定详解如下: RPM包命名格局为:name-version.rpmname-version-noarch.rpmname-version-arch.src.rpm如下软件包格局:epel-release-6-8.noarch.rpmperl-Pod-Plainer-1.03-1.el6.noarch.rpm以yasm-1.2.0-4.el7.x86_64.rpm为列解析如下:RPM包格局解析如下: name 软件名称,例如yasm、perl-pod-Plainer; version 版本号,1.2.0通用格局:“主版本号.次版本号.修改号”;4示意是公布版本号,该RPM包是第几次编译生成的; arch 实用的硬件平台,RPM反对的平台有:i386、i586、i686、x86_64、sparc、alpha等。 .rpm 后缀包示意编译好的二进制包,可用rpm命令间接装置; .src.rpm 源代码包,源码编译生成.rpm格局的RPM包方可应用; el* 软件包发行版本,el6示意该软件包实用于RHEL 6.x/CentOS 6.x; devel: 开发包; noarch: 软件包能够在任何平台上装置。RPM工具命令详解如下: RPM 选项 PACKAGE_NAME-a, --all 查问所有已装置软件包;-q,--query 示意询问用户,输入信息;-l, --list 打印软件包的列表;-f, --file FILE查问蕴含FILE的软件包;-i, --info 显示软件包信息,包含名称,版本,形容;-v, --verbose 打印输出详细信息;-U, --upgrade 降级RPM软件包;-h,--hash 软件装置,能够打印装置进度条;--last 列出软件包时,以安装时间排序,最新的在下面;-e, --erase 卸载rpm软件包--force 示意强制,强制装置或者卸载;--nodeps RPM包不依赖-l, --list 列出软件包中的文件;--provides 列出软件包提供的个性;-R, --requires 列出软件包依赖的其它软件包;--scripts 列出软件包自定义的小程序。 RPM企业案例演示: # 查看sysstat包是否装置;[root@superman-vm01 ~]# rpm -q sysstatpackage sysstat is not installed[root@superman-vm01 ~]# # 装置sysstat软件包;[root@superman-vm01 ~]# rpm -ivh sysstat-10.1.5-17.el7.x86_64.rpmPreparing... ################################# [100%]Updating / installing... 1:sysstat-10.1.5-17.el7 ################################# [100%][root@superman-vm01 ~]# # 查看软件装置的门路;[root@superman-vm01 ~]# rpm -ql sysstat/etc/cron.d/sysstat/etc/sysconfig/sysstat/etc/sysconfig/sysstat.ioconf/usr/bin/cifsiostat/usr/bin/iostat/usr/bin/mpstat/usr/bin/nfsiostat-sysstat/usr/bin/pidstat/usr/bin/sadf/usr/bin/sar/usr/bin/tapestat.......... # 查看软件装置的版本信息;[root@superman-vm01 ~]# rpm -qi sysstatName : sysstatVersion : 10.1.5Release : 17.el7Architecture: x86_64Install Date: Sat 10 Jul 2021 06:46:49 AM CSTGroup : Applications/SystemSize : 1172947License : GPLv2+Signature : RSA/SHA256, Mon 12 Nov 2018 10:47:27 PM CST, Key ID 24c6a8a7f4a80eb5Source RPM : sysstat-10.1.5-17.el7.src.rpmBuild Date : Wed 31 Oct 2018 04:04:26 AM CSTBuild Host : x86-01.bsys.centos.orgRelocations : (not relocatable)Packager : CentOS BuildSystem <http://bugs.centos.org>Vendor : CentOSURL : http://sebastien.godard.pagesperso-orange.fr/Summary : Collection of performance monitoring tools for LinuxDescription :The sysstat package contains sar, sadf, mpstat, iostat, pidstat, nfsiostat-sysstat,tapestat, cifsiostat and sa tools for Linux...........# 卸载sysstat软件;[root@superman-vm01 ~]# rpm -qa|grep sysstatsysstat-10.1.5-17.el7.x86_64[root@superman-vm01 ~]# [root@superman-vm01 ~]# rpm -e sysstat-10.1.5-17.el7.x86_64[root@superman-vm01 ~]# # 降级sysstat软件;[root@superman-vm01 ~]# rpm -Uvh sysstat-10.1.5-17.el7.x86_64.rpm Preparing... ################################# [100%]Updating / installing... 1:sysstat-10.1.5-17.el7 ################################# [100%][root@superman-vm01 ~]# # 查看sysstat相干的软件包是否装置;[root@superman-vm01 ~]# rpm -qa|grep sysstat sysstat-10.1.5-17.el7.x86_64[root@superman-vm01 ~]# # 强制卸载sysstat;[root@superman-vm01 ~]# rpm -e --nodeps sysstat[root@superman-vm01 ~]## 不依赖其它软件包;[root@superman-vm01 ~]# rpm -ivh --nodeps sysstat-10.1.5-17.el7.x86_64.rpm Preparing... ################################# [100%]Updating / installing... 1:sysstat-10.1.5-17.el7 ################################# [100%][root@superman-vm01 ~]# 2 Tar软件包治理Linux操作系统除了应用RPM管理工具对软件包治理之外,还能够通过tar、zip、jar等工具进行源码包的治理。 ...

July 11, 2021 · 13 min · jiezi

关于云计算:Kubernetes-的魔力在于企业标准化而不是应用程序的可移植性

笔者:Kubernetes 形象了资源和工作负载的操作模式,对立了工具集,实现人机接口的标准化。正如类 Docker 工具提供了利用运行时的操作模式;Spring Framework 提供了 Java 利用的开发模式。 Kubernetes 是对于跨云的技能、工具和实际的可移植性。不是工作负载的可移植性。 -- Bilgin Lbryam @bibryam本文翻译自 Kubernetes magic is in enterprise standardization, not app portability Kubernetes 不会神奇地使你的应用程序具备可移植性,但它可能会给你带来更好的货色。云为企业提供了看似有限的抉择。然而,依据 Canonical-sponsored 的一项考察,这并不是大多数企业采纳 Kubernetes 等云敌对技术的起因。相同,Kubernetes 的次要指标是标准化——外观和操作与其他人一样。 可移植性不是指标我之前曾经探讨过这个问题,参考了 Gartner 对于 Kubernetes 和可移植性的指南。许多人认为 Kubernetes(和容器)能够让他们在云之间轻松移植,但事实证明并不是这样的。正如 Gartner 分析师 Marco Meinardi 所写,当被问及公司是否应该采纳“Kubernetes 使他们的应用程序可移植......答案是:不。” 再说一次? 考察显示,[在云提供商之间挪动应用程序] 的可能性实际上非常低。一旦部署在供应商中,应用程序往往会留在那里。这是因为数据湖难以移植且老本昂扬,因而最终成为迁徙的重心。因而 Kubernetes 通常不会被公司承受,以加强应用程序的可移植性;相同,议论人员可移植性或换言之,技能可移植性更靠近事实。Weaveworks 首席执行官亚历克西斯·理查森(Alexis Richardson)将这个主题打回家: 重点是“技能可移植性”,因为应用规范操作模型和工具链。大型组织心愿开发人员应用规范的工作形式,因为这能够升高培训老本,并打消员工在不同我的项目之间转移的阻碍。如果你的“平台”(或多个平台)基于雷同的外围云原生工具集,那么它也能够更轻松、更便宜地利用策略。这让咱们回到标准考察。 Samesies当被问及确定与采纳 Kubernetes 等云原生技术相干的技术指标时,考察受访者将可移植性排在最初,将更间接的问题排在第一位: 改良保护、监控和自动化 - 64.6%。基础设施现代化 - 46.4%。更快的上线工夫 - 26.5%。删除供应商依赖项 - 12.8%。寰球覆盖率 - 12.5%。围绕流量顶峰的敏捷性 - 9.2%。确保便携性 - 8.9%我喜爱 Google Cloud 的开发者倡导者 Kelsey Hightower 在调查报告中评论这些后果的形式: ...

July 11, 2021 · 1 min · jiezi

关于云计算:云端干货|企业用云成本过高看SpotMax解决方案

Spot 实例始终被低估的低成本资源 从实例的购买模式来看,能够分为按需实例、预留实例、Spot实例等类型。 Amazon EC2 Spot 实例,是 AWS 服务中的可用闲暇计算容量。与按需实例的价格相比,应用 Spot 实例最高能够享受 90% 的折扣。 按需实例与 Spot 实例的区别在于,当 EC2 须要更多容量时,它会收回两分钟的告诉继而中断 Spot 实例。中断起因是企业设定最高价不够高或 Spot 实例的容量不够,须要进行回收。因而,领有极低成本劣势的 Spot 实例个别实用于各种无状态、容错或者灵便的应用程序,例如大数据、容器化工作负载、CI/CD、Web 服务器、高性能计算 (HPC) 以及测试和开发工作负载。 SpotMax开释Spot实例的“宝藏属性” 在实际上云过程中,如何用好价格低廉但稳定性差 Spot 实例,实现高效低成本上云? SpotMax 提供一套云老本优化的综合解决方案,能在保障实例稳定性的同时,最大化利用 Spot 实例资源,无效节俭用云老本。强效稳定性、开箱即用、本地化反对及宽泛实用等个性,让 SpotMax 帮忙企业用户更释怀地应用费用最低的 Spot 实例降低成本,而无需放心稳定性受影响。 SpotMax 蕴含 MaxArch、MaxChaos 和 MaxGroup 产品及解决方案。 其中,MaxGroup 作为 SpotMax 的产品,其智能布局集群形成、稳固与节俭兼顾、时刻稳固集群容量、继续升高中断概率、确保状态一致性、拥抱云原生等个性,让开发者能充沛享受云计算便宜的闲置算力而不必放心可靠性问题,缩小额定洽购包含按需实例、预留实例等低廉算力。 SpotMax 来自 Mobvista 本身用云实际,经验过日均千亿次广告申请的大规模可行性验证,目前已胜利治理了不同类型的线上零碎,其寰球治理的 Spot 实例数量超过 50,000 vCPU。 底层根底的个性让 SpotMax 能实用于多元业务场景,帮忙各行业无效升高用云老本。尤其是对于领有大量用户申请、须要疾速响应、与用户体验极为相干的场景,SpotMax 的作用更为突出。 理解 SpotMax : https://spotmaxtech.com/ ...

July 9, 2021 · 1 min · jiezi

关于云计算:Linux云计算04Linux用户及权限管理

Linux是一个多用户的操作系统,引入用户,能够更加方便管理Linux服务器,零碎默认须要以一个用户的身份登录,而且在零碎上启动过程也须要以一个用户身份器运行,用户能够限度某些过程对特定资源的权限管制。 本章介绍Linux零碎如何治理创立、删除、批改用户角色、用户权限配置、组权限配置及非凡权限深刻分析。 1 Linux用户及组Linux操作系统对多用户的治理,是十分繁琐的,所以用组的概念来治理用户就变得简略,每个用户能够在一个独立的组,每个组也能够有零个用户或者多个用户。 Linux零碎用户是依据用户ID来辨认的,默认ID长度为32位,默认ID编号从0开始,然而为了和老式零碎兼容,用户ID限度在60000以下,Linux用户分总共分为三种,别离如下: root用户 (ID 0)零碎用户 (ID 1-499)普通用户 (ID 500以上)Linux零碎中的每个文件或者文件夹,都有一个所属用户及所属组,应用id命令能够显示以后用户的信息,应用passwd命令能够批改以后用户明码。Linux操作系统用户的特点如下: 每个用户领有一个UserID,操作系统理论读取的是UID,而非用户名;每个用户属于一个主组,属于一个或多个从属组,一个用户最多有31个从属组;每个组领有一个GroupID;每个过程以一个用户身份运行,该用户可对过程领有资源管制权限;每个可登陆用户领有一个指定的Shell环境。2 Linux用户治理Linux用户在操作系统能够进行日常治理和保护,波及到的相干配置文件如下: /etc/passwd 保留用户信息/etc/shdaow 保留用户明码(以加密模式保留)/etc/group 保留组信息/etc/login.defs 用户属性限度,明码过期工夫,明码最大长度等限度/etc/default/useradd 显示或更改默认的useradd配置文件如需创立新用户,能够应用命令useradd,执行命令useradd superman即可创立superman用户,同时会创立一个同名的组superman,默认该用户属于superman主组。 useradd superman命令默认创立用户superman,会依据如下步骤进行操作: 在/etc/passwd文件中增加用户信息;如应用passwd命令创立明码,明码会被加密保留在/etc/shdaow中;为superman创立家目录:/home/superman;将/etc/skel中的.bash结尾的文件复制至/home/superman家目录;创立与用户名雷同的superman组,superman用户默认属于superman同名组;superman组信息保留在/etc/group配置文件中。在应用useradd命令创立用户时,能够反对如下参数: 用法:useradd [选项] 登录useradd -Duseradd -D [选项]选项:-b, --base-dir BASE_DIR 指定新账户的家目录;-c, --comment COMMENT 新账户的GECOS字段;-d, --home-dir HOME_DIR 新账户的主目录;-D, --defaults 显示或更改默认的useradd配置;-e, --expiredate EXPIRE_DATE 新账户的过期日期;-f, --inactive INACTIVE 新账户的明码不活动期;-g, --gid GROUP 新账户主组的名称或ID;-G, --groups GROUPS 新账户的附加组列表;-h, --help 显示此帮忙信息并推出;-k, --skel SKEL_DIR 应用此目录作为骨架目录;-K, --key KEY=VALUE 不应用/etc/login.defs中的默认值;-l, --no-log-init 不要将此用户增加到最近登录和登录失败数据库;-m, --create-home 创立用户的主目录;-M, --no-create-home 不创立用户的主目录;-N, --no-user-group 不创立同名的组;-o, --non-unique 容许应用反复的UID创立用户;-p, --password PASSWORD 加密后的新账户明码;-r, --system 创立一个零碎账户;-R, --root CHROOT_DIR chroot到的目录;-s, --shell SHELL 新账户的登录shell;-u, --uid UID 新账户的用户ID;-U, --user-group 创立与用户同名的组;-Z, --selinux-user SEUSER 为SELinux用户映射应用指定SEUSER。2.1 useradd案例演示1、新建superman2用户,并退出到superman,superman1从属组 ...

July 8, 2021 · 6 min · jiezi

关于云计算:云原生爱好者周刊Lens-50-发布更炫更快更强

云原生一周动静要闻: Lens 5.0.0 公布GitHub 推出 AI 编程工具 GitHub CopilotKubernetes 公布 2020 年社区年度报告Weaveworks 推出实用于 Kubernetes 的集成 GitOps 平台HashiCorp Boundary 0.4.0 公布开源我的项目举荐文章举荐IT 从业人员想必都据说过 《深刻了解计算机系统》 这本神书,也就是赫赫有名的 CSAPP(Computer Systems: A Programmer's Perspective),它将 硬件、零碎、软件 这三者联合起来,造成一个对立的框架,从程序员的视角来了解计算机系统的运作模式。 这本书也是 CMU(Carnegie Mellon University),即卡内基梅隆大学的计算机系统入门教材,CMU 还录制了讲课视频,如果感觉看书难度比拟大,能够先看一遍视频,再回过头来浏览教材,或者能够两者联合。当然,如果你的英文程度还不太现实,能够抉择观看带中文字幕的视频,视频链接在 B 站。 云原生动静Lens 5.0.0 公布Lens 是一个弱小的 kubernetes IDE。能够实时查看 kubernetes 集群状态,比方 Pod 实时日志查看、集群 Events 实时查看、集群故障排查等。有了 Lens,不再须要敲打很长的 kubectl 命令,只有应用鼠标点击几下,十分便捷。 Lens 为在 Kubernetes 中运行的所有内容提供残缺的态势感知。它升高了老手的进入门槛,并进步了经验丰富的人的工作效率。 这个新版本的亮点是 Catalog、Hotbars 和 Spaces。 Hotbar 当初是次要导航,容许用户从目录中筛选最重要和最罕用的性能(例如凋谢集群)并将它们调配给 hotbar。用户能够拜访多个快捷栏,在它们之间疾速切换并依据本人的爱好进行自定义以不便调用。 应用 Spaces 时,你能够抉择共享对集群的拜访权限。你还能够承受其他人的邀请以拜访他们的集群。为了实现这一点,Lens 创立了一项全新的技术:集群连贯。它容许 Lens 用户将他们的任何集群连贯到 Spaces,而无需在防火墙上启用入站端口。它利用端到端加密来爱护用户和集群之间的连贯,打消对 VPN 的需要。这意味着无需通过 Internet 公开 Kubernetes API。开发人员和运营商能够从任何中央轻松拜访和应用他们的 Kubernetes 集群。 ...

July 7, 2021 · 2 min · jiezi

关于云计算:实现双碳目标-高光谱来助力

二氧化碳排放 力争于2030年实现碳达峰 努力争取2060年实现碳中和 是我国提出的两个阶段碳减排奋斗目标 实现这一指标,必须以科技翻新为先导 「高光谱」技术,就是其中的一项机密法宝 光谱分析作为自然科学剖析的重要伎俩 光谱技术经常用来检测物体的 物理构造、化学成分等指标 那么什么是高光谱技术呢? 咱们看到的整个世界是五彩缤纷的 其实它所有的能量都来自太阳光 然而咱们为什么看到树是绿色的? 因为树除了把绿色的光反射进去了 其它的光都被排汇了 所以人眼睛看到的恰好是物质不排汇的光 正是因为不同的物质构造对于光入射当前 排汇的特色是不一样的 所以就相当于有了一个指纹和身份证 地球上不同的元素及其化合物都有本人独特的光谱特色 光谱被看作是分别物质的“指纹” 高光谱则是帮助咱们看清这些“指纹”的“有色眼镜” 通过高光谱技术 咱们可能更分明看到物质世界的样貌 取得物质世界的数据 并将技术利用在具体的场景中 通常人眼可看见的光波被称为可见光 波长个别在390纳米到780纳米之间 而一台短波红外高光谱仪可能分辨2500纳米光谱 是人眼齐全看不到的局部 但借助这束光波就可能 让咱们有一双看透所有物质的眼睛 不同材质的货色 它的光谱曲线也不一样 科研人员就是通过这个原理 来进行物质特色检测 正是基于这些原理 高光谱技术在工业互联网畛域 可能实现煤炭热值检测和工业设施润滑油检测 通过光谱成像辨认、剖析并反映二氧化碳排放状况 为此 浪潮云与中科谱光单干共建 “高光谱技术创新利用联结实验室”正式揭牌成立 实验室将在国家“碳达峰、碳中和”背景下 通过提供碳计量设施及双碳双控等服务 推动高光谱技术 在“双碳”业务等畛域的推广和利用落地 在助力实现「双碳」指标的路线上 咱们始终在致力

July 7, 2021 · 1 min · jiezi

关于云计算:Linux云计算03必备基础命令

Linux系统启动默认为字符界面,个别不会启动图形界面,所以对命令行的熟练程度能更加不便、高效的治理Linux零碎。 本章介绍Linux零碎必备命令各项参数及性能场景,Linux常见命令包含:cd、ls、pwd、mkdir、rm、cp、mv、touch、cat、head、tail、chmod、vim等。 1 cd命令详解cd命令次要用于目录切换,例如:cd /home切换至/home目录,cd /root示意切换至/root目录 ;cd ../切换至上一级目录;cd ./切换至当前目录。 其中.和..能够了解为相对路径,例如cd ./test示意以当前目录为参考,示意绝对于以后,而cd /home/test示意残缺的门路,了解为绝对路径),如下所示: [root@superman-vm01 ~]# [root@superman-vm01 ~]# cd /tmp[root@superman-vm01 tmp]# [root@superman-vm01 tmp]# cd /home[root@superman-vm01 home]# [root@superman-vm01 home]# cd ..[root@superman-vm01 /]# [root@superman-vm01 /]# cd ./home[root@superman-vm01 home]# [root@superman-vm01 home]# cd /etc/rc.d/rc3.d[root@superman-vm01 rc3.d]# [root@superman-vm01 rc3.d]# cd ../..[root@superman-vm01 etc]# 2 ls命令详解ls命令次要用于浏览目录下的文件或者文件夹,应用办法参考:ls ./ 查看当前目录所有的文件和目录,ls -a 查看所有的文件,包含暗藏文件,以.结尾的文件,罕用参数详解如下: -a, --all 不暗藏任何以.开始的我的项目;-A, --almost-all 列出除.及..以外的任何我的项目; --author 与-l同时应用时列出每个文件的作者;-b, --escape 以八进制溢出序列示意不可打印的字符; --block-size=大小 块以指定大小的字节为单位;-B, --ignore-backups 不列出任何以"~"字符完结的我的项目;-d, --directory 当遇到目录时列出目录自身而非目录内的文件;-D, --dired 产生适宜Emacs的dired模式应用的后果;-f 不进行排序,-aU选项失效,-lst选项生效;-i, --inode 显示每个文件的inode号;-I, --ignore=PATTERN 不显示任何合乎指定shell PATTERN的我的项目;-k 即--block-size=1K;-l 应用较长格局列出信息;-n, --numeric-uid-gid 相似-l,但列出UID及GID号;-N, --literal 输入未经解决的项目名称 (如不特地解决控制字符) ;-r, --reverse 排序时保留程序;-R, --recursive 递归显示子目录;-s, --size 以块数模式显示每个文件调配的尺寸;-S 依据文件大小排序;-t 依据批改工夫排序;-u 同-lt 一起应用:依照拜访工夫排序并显示; 同-l一起应用:显示拜访工夫并按文件名排序; 其余:依照拜访工夫排序;-U 不进行排序;依照目录程序列出我的项目;-v 在文本中进行数字(版本)的天然排序。2.1 长格局显示-l 参数次要是能够看到文件的更具体的信息。 ...

July 7, 2021 · 7 min · jiezi

关于云计算:clientgo实战之一准备工作

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 系列文章链接client-go实战之一:筹备工作client-go实战之二:RESTClientclient-go实战之三:Clientsetclient-go实战之四:dynamicClientclient-go实战之五:DiscoveryClient对于client-goclient-go是kubernetes官网提供的go语言的客户端库,go利用应用该库能够拜访kubernetes的API Server,这样咱们就能通过编程来对kubernetes资源进行增删改查操作;除了提供丰盛的API用于操作kubernetes资源,client-go还为controller和operator提供了重要反对,如下图,client-go的informer机制能够将controller关注的资源变动及时带给此controller,使controller可能及时响应变动: GitHub仓库:https://github.com/kubernetes...对于《client-go实战》系列《client-go实战》系列是欣宸推出的实战主题原创,旨在与大家一起入手体验client-go的相干技术,从简略的实际开始,逐渐深刻理解client-go的弱小性能,为后续的operator学习打下扎实的根底; 重要前提开始client-go实战之前要对以下知识点有所理解:kubernetes基本原理和操作;kubernetes的Group、Version、Resource等概念,举荐浏览《Kubernetes的Group、Version、Resource学习小记》本篇概览作为整个系列的开篇,除了对client-go做介绍,还要为前面的实战做好如下筹备工作: 列出要用到的硬件;列出要用到的软件及其版本;同步kubernetes配置文件,使得开发环境能够近程拜访kubernetes; 环境信息如下图所示,本次实战一共用到两台电脑: Linux电脑:操作系统是<font color="blue">CentOS 7.9</font>,已装置<font color="blue">1.20.0</font>版本的kubernetesMacBook Pro:操作系统是<font color="blue">macOS Big Sur(11.1)</font>,编码工作在此电脑上进行MacBook Pro上装置的go版本为<font color="blue">1.15.7</font>您能够依照集体习惯抉择IDE,我这里用的是GoLand-2020.2版本确定要用的client-go版本client-go官网提供了多个版本,并且给出了和kubernetes版本的匹配列表,如下所示: Kubernetes 1.15Kubernetes 1.16Kubernetes 1.17Kubernetes 1.18Kubernetes 1.19Kubernetes 1.20kubernetes-1.15.0✓+-+-+-+-+-kubernetes-1.16.0+-✓+-+-+-+-kubernetes-1.17.0/v0.17.0+-+-✓+-+-+-kubernetes-1.18.0/v0.18.0+-+-+-✓+-+-kubernetes-1.19.0/v0.19.0+-+-+-+-✓+-kubernetes-1.20.0/v0.20.0+-+-+-+-+-✓HEAD+-+-+-+-+-+-这里解释一下表格中的✓ 、+ 、- 的含意: ✓ 示意准确匹配,如下图红框,示意<font color="blue">v0.20.0</font>版本能够准确匹配<font color="red">1.20.0</font>版本的kubernetes: + 示意有的新个性是client-go反对的,然而此kubernetes版本却不反对;- 示意有的新个性是kubernetes反对的,然而此client-go版本却不反对;我这里kubernetes版本为<font color="blue">1.20.0</font>,因而选用client-go的<font color="red">0.20.0</font>版本最合适;复制k8s环境的配置文件为了能让MacBook Pro电脑上的go利用顺利拜访K8S,请将K8S环境下的<font color="blue">~/.kube/config</font>文件复制到MacBook Pro电脑的<font color="blue">~/.kube/</font>目录下;客户端对象简述本篇聚焦筹备工作,不做编码,这里提前介绍一下前面的实战内容:通过client-go提供的客户端对象与kubernetes的API Server进行交互,而client-go提供了以下四种客户端对象,前面的实战会一一体验:RESTClient:这是最根底的客户端对象,仅对HTTPRequest进行了封装,实现RESTFul格调API,这个对象的应用并不不便,因为很多参数都要使用者来设置,于是client-go基于RESTClient又实现了三种新的客户端对象;ClientSet:把Resource和Version也封装成办法了,用起来更简略间接,一个资源是一个客户端,多个资源就对应了多个客户端,所以ClientSet就是多个客户端的汇合了,这样就好了解了,不过ClientSet只能拜访内置资源,拜访不了自定义资源;DynamicClient:能够拜访内置资源和自定义资源,个人感觉有点像java的汇合操作,拿出的内容是Object类型,按理论状况本人去做强制转换,当然了也会有强转失败的危险;DiscoveryClient:用于发现kubernetes的API Server反对的Group、Version、Resources等信息;至此,咱们的环境和常识筹备工作就实现了,接下来一起去摸索弱小的client-go吧!你不孤独,欣宸原创一路相伴Java系列Spring系列Docker系列kubernetes系列数据库+中间件系列DevOps系列欢送关注公众号:程序员欣宸微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界...https://github.com/zq2599/blog_demos

July 6, 2021 · 1 min · jiezi

关于云计算:视频云峰会|超视频化时代的全景创新-是什么

随着 5G、云计算、人工智能的高速倒退,人与人、人与物、人与社会之间的内容表白状态、信息交互方式在迅速更迭,视频化交融了内容与交互的双重演进,让超视频化时代到来。 在这样的时代,视频云将如何为社会翻新和商业发明带来全新的想象力? 阿里云联结 Intel,将于 2021 年 7 月 10 日在北京举办 “Imagine”——2021 阿里云视频云全景翻新峰会暨寰球视频云翻新挑战赛决赛颁奖典礼。 全维,看超视频化时代演进 在超视频化时代,视频成为时代语言,视频化成为新文化运动,实现超内容的承载、超交互的体验、超时空的链接,最终将基于虚实交融实现超将来的全场景数字孪生图景。 在超视频化时代,视频云所打造的音视频数智化能力,在一直延展新技术、发明新机会、缔造新物种。 峰会上,咱们将从全景视角察看时代,聚焦视频化在新内容和新交互的演进历程,畅谈场景的变革和发明,摸索驱动体验演进的关键技术,设想交融 5G、云、AI、音视频的视频云,在将来如何构建技术新价值和商业新方向。 精彩看点: 超视频化时代图景新内容演进与内容可视化摸索新交互演进与关键技术驱动视频云的数智化价值发明和设想深度,洞察云上视频新场景 对于竞争强烈、疾速迭代的大视频产业,视频云曾经逐步倒退成一项要害的基础设施,不仅大幅升高了视频利用的准入门槛,更通过促成产业效率晋升一直推动大视频产业的凋敝。 目前,视频云在互联网泛娱乐以及在线教育场景渗透率最高。此外,平台的电商化、传媒行业的数智化转型、企业的挪动协同办公,亦是视频云技术利用的重点场景。深度分析这些场景,发现场景链路中的盲点、痛点、机会点、翻新点,是技术扭转商业的高价值出现。 峰会上,咱们将深度摸索泛滥云上新场景,和新兴场域的设想空间,并将眼帘放远,眺望视频云将来的技术极致化和全新体验。 精彩看点: 《2021 中国视频云场景利用洞察白皮书》联结公布大视频产业的需要端、供应端、产业链剖析五大云上新场景深度分析视频云行业趋势瞻望实际,AI 驱动超高清 “视” 界 2021 年 2 月,央视开始试播寰球首个 8K 超高清频道,央视春晚进行 8K 直播。 超高清视频是视频技术继模仿、标清、高清后的新一轮代际演进,与 5G、人工智能等同为当今新一代信息技术的重要倒退方向。2021 年,超高清迈入 “8K” 时代。 超高清视频将带来全新视听体验:更丰盛的细节,更活泼的色调,更沉迷的体验以及更宽泛的利用,但超高清生产在内容生产层面也面临着超高清存量少、生产设施更新换代慢、制作周期成倍增加的窘境。 本次峰会,将从超高清产业的生产现状与窘境登程,深度分析 AI 技术如何驱动视听降级,并分享达摩院在超高清生产畛域的实际。 精彩看点: AI 加强关键技术AI 加强典型算法达摩院超高清生产实践AI 驱动超高清倒退瞻望翻新,开启内容数字化浪潮 随着社会节奏的放慢,用户碎片化生产工夫一直减少,以后短视频的生产用户规模已超 7.73 亿人,短视频的市场规模超过 2000 亿元。短视频行业倒退迅速,但也存在低质内容泛滥,精品内容稀缺的问题。 总体来看,在内容供应侧,制作一个好的视频十分艰难,次要体现在创意生产艰难、工具实现艰难。阿里娱乐心愿为媒体的创作与编辑提供更大的助力,因而推出 Media AI 平台。 本次峰会,将从短视频畛域的内容生产窘境登程,分享 MediaAI 平台的技术能力及利用实际,带来优酷短视频智能生产的技术解密。 精彩看点: 创作因素解构,建设数字工业化能力体系概念级视频解构赋能短视频生产AI 赋能剧本开掘和创作内容出现:特效如何让视频更好看冲破,技术延展社会想象力 为延展技术能量,2021 年 2 月,阿里云联手英特尔主办、与优酷策略技术单干的 “新内容 新交互” 寰球视频云翻新挑战赛拉开帷幕。 ...

July 5, 2021 · 1 min · jiezi

关于云计算:必看史上最全云原生全景图解读攻略来啦

起源 | 尔达 Erda 公众号 带你理解云原生技术图谱如果你钻研过云原生应用程序和相干技术,大概率你遇到过 CNCF 的云原生全景图。这张全景图技术之多、规模之大无疑会让人感到震惊,那么咱们该如何去了解这张图呢? 如果把它拆开来,一次只剖析一小块内容,你会发现整个全景图没有那么简单。事实上,该全景图依照性能有序地组织在一起,一旦你理解了每个类别代表的内容,你就能够轻松游走于全景图中。本文咱们首先把整个全景图拆解开来,并对整个全景图进行综述,接着聚焦在每一层(or 每一列),对每个类别解决的问题和原理进行了更为具体的解读。 1. 云原生全景图的 4 层首先,咱们剥离掉所有单个的技术,仅查看类别(如下图)。图中有不同的“行”,像修建的不同层,每层都有本人的子类别。最底层提供了构建云原生基础设施的工具。往上,你能够开始增加运行和管理应用程序所需的工具,比方运行时和调度层。在最上层,有定义和开发应用程序的工具,比方数据库、镜像构建和 CI/CD 工具(咱们将在后文探讨)。 好了,当初你应该记住了云原生全景图始于基础设施,往上的每一层都更靠近理论的应用程序。这就是每层代表的意思(前面咱们会探讨上图左边的两“列”)。上面咱们就从最底层开始,逐层进行解析。 1)供给层 (Provisioning)供给指的是为云原生利用筹备规范根底环境所波及的工具。它蕴含了基础设施的创立、治理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供给层通过提供设置和施行策略,在应用程序和平台中构建身份验证和受权,以及解决密钥散发等等的工具,也拓展到了平安畛域。供给层包含: 自动化和部署工具:帮忙工程师在无需人工干预状况下即可构建计算环境;容器注册表:存储应用程序的可执行文件;不同平安畛域的平安和合规框架;密钥治理解决方案:通过加密确保只有受权的用户能力拜访特定的应用程序。这些工具使工程师能够编写基础设施参数,使零碎能够按需搭建新环境,确保了一致性和安全性。2)运行时层(Runtime)接下来是运行时层。这个词可能会让你感到蛊惑。像很多 IT 术语一样,运行时没有严格的定义,且能够依据语境有不同的用法。广义上讲,运行时是特定机器上筹备运行应用程序的沙盒——也就是保障应用程序失常运行所需的最低配置。狭义上讲,运行时是运行一个应用程序所需的所有工具。在 CNCF 云原生全景图中,运行时保障了容器化应用程序组件的运行和通信, 包含: 云原生存储:为容器化利用提供虚构磁盘或长久化存储;容器运行时:为容器提供隔离、资源和平安;云网络:分布式系统的节点(机器或过程)通过其连贯和通信。3)编排和管理层(Orchestration and Management)一旦依照平安和合规性规范(供给层)自动化基础设施供给,并装置了利用程序运行所需的工具(运行时层),工程师就须要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务(应用程序组件)作为一个群组治理。这些容器化服务须要互相辨认和通信,并须要进行协调。这一层可为云原生利用提供自动化和弹性能力,使云原生利用人造具备可扩展性。这一层蕴含: 编排和调度:部署和治理容器集群,确保它们具备弹性伸缩能力,相互之间低耦合,并且可扩大。事实上,编排工具(绝大多数状况下就是 Kubernetes)通过治理容器和操作环境形成了集群;协调和服务发现:使得服务(应用程序组件)之间能够互相定位和通信;近程过程调用(RPC):使跨节点服务间通信的技术;服务代理:服务间通信的中介。服务代理的惟一目标就是对服务之间的通信进行更多管制,而不会对通信自身增加任何内容。服务代理对上面将提到的服务网格(Service Mesh)至关重要。API 网关:一个形象层,内部利用可通过 API 网关进行通信;Service Mesh:某种程度上相似于 API 网关,它是应用程序进行通信的专用基础架构层,提供基于策略的外部服务间通信。此外,它还可能蕴含流量加密、服务发现、应用程序监控等内容。4)利用定义和开发层 (Application Definition and Developement)当初,咱们来到了最顶层。利用定义和开发层,顾名思义,汇集了让工程师构建和运行应用程序的工具。上述所有内容都是对于构建牢靠、平安的环境,以及提供全副所需的应用程序依赖。这一层包含: 数据库:使应用程序能以有序的形式收集数据;流和消息传递:使应用程序能发送和接管音讯(事件和流)。它不是网络层,而是让音讯成为队列并解决音讯的工具;利用程序定义和镜像构建:用于配置、保护和运行容器镜像(应用程序的可执行文件)的服务;继续集成和继续交付(CI/CD):使开发者可主动测试代码是否与代码库(应用程序的其余部分)兼容。如果团队足够成熟,甚至能够主动部署代码到生产环境。2. 贯通所有层的工具接下来咱们将进入到云原生全景图右侧贯通所有层的两列。可察看性和剖析(Observability&analysis)是监控各层的工具,平台则将各层中不同的技术捆绑为一个解决方案。 1)可察看性和剖析(Observability and Analysis)为了限度服务中断并升高解决问题的均匀工夫(MRRT),你须要监控和剖析应用层序的方方面面,以便在出现异常时可立刻发现并纠正。简单环境中容易呈现故障,这些工具可疾速辨认并解决故障,从而升高故障带来的影响。因为这一类别贯通并监控各层,因而它在侧面,而不是嵌入到某一层中。这一类别你将发现: 日志工具:收集事件日志(无关过程的信息);监控计划:收集指标(以数字示意的零碎参数,例如 RAM 可用性);追踪工具:追踪比监控更进了一步,它们监控用户申请的流传,与服务网格相干。混沌工程(Chaos Engineering):在生产环境中测试软件的工具,可辨认缺点并进行修复,缩小其对服务交付的影响。2)平台类(Platform)能够看到,图中每一个模块解决一个特定的问题。但咱们晓得,仅有存储并不能提供应用程序所需的全副性能。你还须要编排工具、容器运行时、服务发现、网络和 API 网关等等。平台笼罩多层,将不同的工具组合在一起,以解决更大的问题。配置和微调不同的模块使其安全可靠,并确保它利用的技术都能及时更新、所有破绽都打了补丁,这并不是一件容易的事件。应用平台时,用户不必额定放心这些细节问题。你可能会留神到,所有的类别都围绕着 Kubernetes 开展。这是因为 Kubernetes 尽管只是云原生景观图这张拼图中的一块,但它却是云原生技术栈的外围。顺便说一下,CNCF 刚创立时,Kubernetes 就是其中的第一个种子我的项目,起初才有了其余我的项目。平台可分为四类: K8s 发行版:采纳未经批改的凋谢源代码(只管有人对其进行了批改),并依据市场须要减少了其余性能。托管的 K8s:相似于 Kubernetes 发行版,然而由提供商托管。K8s 安装程序:主动执行 Kubernetes 的装置和配置过程。PaaS / 容器服务:相似于托管的 Kubernetes,然而蕴含了一套更宽泛的利用部署工具(通常是来自云原生景观图)。3. 小结在每个类别中,针对雷同或类似的问题,都有不同的工具可抉择。有一些是实用于新事实的预云原生技术,还有一些则是全新的。区别在于它们的实现和设计办法。没有完满的技术合乎你的所有需要。大多数状况下,技术受设计和架构抉择的限度——始终须要衡量取舍。在抉择技术栈时,工程师必须认真思考每种能力和须要衡量取舍的中央,以确定最合适的选项。尽管这样会让状况变得更简单,但在抉择应用程序所需的最适宜的数据存储、基础设施治理、音讯零碎等计划时,这样做是最可行的方法。当初,构建一个零碎比云原生之前的时代容易多了。如果构建失当,云原生技术将提供更弱小的灵活性。在现如今疾速变动的技术生态中,这可能是最重要的能力之一。上面咱们来具体介绍云原生全景图的每一层。 ...

July 5, 2021 · 5 min · jiezi

关于云计算:今天浪潮云说直播间开讲啦

浪潮云作为分布式云的引领者, 粗浅理解中国政企用户数字化转型需要。 本期次要基于分布式云延长到各个业务场景中, 解说如何为政企用户疾速输入全面云化和全栈智能的能力。 浪潮云分布式云实际(上)解说了分布式云的定义、发展趋势、长处特点等, 以及浪潮分布式云的架构、服务能力等方面的内容, (下)将重点介绍下浪潮在分布式云的实际案例

July 5, 2021 · 1 min · jiezi

关于云计算:隐藏在水印的秘密

最近明天在测试火山引擎的ImageX解决的时候发现提供一种能力叫盲水印; 看盲水印介绍内容: 应用办法测试: 在放拜访某个url时候会主动增加上盲水印;增加结束后,会从新提取图片外面的信息; 我在其余公众号上看到这么一个文章,我猜想他们是一个原理,毕竟火山引擎属于字节跳动的业务,但算法是否一个就不晓得了; 相干文章: ———————————————— 一、前言1.1、暗水印是什么狭义来说,暗水印能够了解为,在一些载体数据中增加暗藏标记,这些标记在人类和机器可轻易感知的范畴之外。相较于常见的明水印,比方图片和视频中的公司logo、纸币中的水印纹理等。暗水印对大部分感知零碎来说是通明的,不可见的。上面通过两个例子来阐明。 1.1.1暗藏在白纸中的符号比方下图是中科院上海某化学所的隐写耐火纸,能够看到在一张看似一般的白纸之中,却暗藏了一个图案和字母。这个图案和字母就属于暗水印。它能够用来隐秘传输信息、做防伪标识等。 1.1.2暗藏在图片中的二维码上面这个例子可能就比拟少见了。它是 2020 ByteCTF(字节跳动网络安全攻防大赛) Misc 的一道隐写题目。通过暗藏水印的办法,将一个有意思的二维码嵌入到上面这幅彩图中,而这个二维码是肉眼不可见的。 加有暗水印的图像: 图像中的暗藏信息: 1.2常见的暗水印技术这个分类是基于传输载体进行分类的。一般来说暗水印能够暗藏在大部分多媒体传输和存储载体中,比方图片、视频、音频、邮件、文档等都是不错的载体。 1.2.1图像水印基于图像的暗水印技术是暗水印外面最成熟的一种,嵌入办法也多种多样。依据嵌入维度不同,又能够细分为空域水印和变换域水印。空域水印能够简略的了解为间接对解码后的图像像素值进行编辑和嵌入信息;变换域水印是将图像的像素信息转换到变换域,而后在变换域增加信息后再转换到空域,这个过程中空域信息也会被批改。所以变换域水印也能够了解为间接的空域水印。 1.2.1.1空域水印 间接选取空域特定地位的像素值进行批改来嵌入信息。空间域水印的难点在于如何在空域抉择水印区域和在水印块中如何嵌入数据。依据水印区域选取形式不同可分为上面几种。 Least Significant Bits(LSB)水印这个办法简略粗犷,间接在图像的像素值上进行批改。假如水印载体为色彩深度8bit的RGB图像,水印信息为二值化图像。 加水印过程对原始图像的最初1bit(最低位)置零,将用二进制示意的版权信息,赋值给原始图像的最初1bit,实现版权信息写入。(写入后原始图像像素值扭转幅度为1) 解水印过程将图像的前7bits(高7位)置零,提起最初1bit(最低位),失去版权信息。 算法简评此算法计算复杂度绝对较低;对图像视觉效果影响很小;鲁棒性较低,难以抵制常见的水印攻打伎俩。 1.2.1.2变换域水印 变换域水印最终也会批改空域的数据,与下面不同的是并不是间接批改像素值,而是将图像的空域数据转换到变换域,而后依照肯定办法写入水印信息,最初再将变换域数据转换回空域的值并从新生成图像信息。 常见的变换域水印用到的根底算法有 DCT、DFT、DWT,这三个算法特点各不相同,可独自应用也能够穿插应用。 基于 DCT 的水印算法DCT 离散余弦变换属于一种非凡的 DFT 离散傅里叶变换,在暗水印畛域有十分类似的应用手法。所以这里仅对基于 DCT 变换的水印进行开展。下图为对“蒲公英”灰度图做 DFT 和 DCT 变换后的频谱散布,可见峰值散布是不同的。 什么是频域变换下图能够艰深了解频域变换的逻辑。左下角“工夫域”(能够粗略了解为空域)的一维波形,能够由右上角 f1 f2 f3 f4...等多个规定波形叠加而成,而这些波形都对应一个固定频率,那么将他们投影到右下角的“频率域”中,造成另一幅坐标图。这个过程就能够简略了解为傅里叶变换的过程。 那么它在图像处理畛域有何作用呢? 上面四幅图别离是 原图 >> DCT 变换后的频域的灰度图 >> 将频域左上角数据清零 >> 再次转换成空域的图片。 能够看到转换实现后的图片失落大量信息,然而仍可看出局部毛发的细节信息。 如何用基于 DCT 来写入暗藏水印暗藏水印嵌入过程大略如下,框架绝对简略。在理论利用中会依据不同的场景抉择不同的分块和不同的频域区域,这些须要通过大量的试验和实践的积淀才能够做出抉择。 ...

July 2, 2021 · 1 min · jiezi

关于云计算:基于-KubeSphere-的-Nebula-Graph-多云架构管理实践

本文是杭州站 Meetup 讲师乔雷依据其分享内容整顿而成的文章。图数据库是一种应用图构造进行语义查问的数据库,它应用节点、边和属性来示意和存储数据。图数据库的应用领域十分宽泛,在反馈事物之间分割的计算都能够应用图数据库来解决,罕用的畛域如社交畛域里的好友举荐、金融畛域里的风控治理、批发畛域里的商品实时举荐等等。 Nebula Graph 简介与架构Nebula Graph 是一个高性能、可线性扩大、开源的分布式图数据库,它采纳存储、计算拆散的架构,计算层和存储层能够依据各自的状况弹性扩容、缩容,这就意味着 Nebula Graph 能够最大化利用云原生技术实现弹性扩大、老本管制,可能包容千亿个顶点和万亿条边,并提供毫秒级查问延时的图数据库解决方案。 上图所示为 Nebula Graph 的架构,一个 Nebula 集群蕴含三个外围服务,Graph Service、Meta Service 和 Storage Service。每个服务由若干个正本组成,这些正本会依据调度策略平均地散布在部署节点上。 Graph Service 对应的过程是 nebula-graphd,它由无状态无关联的计算节点组成,计算节点之间互不通信。Graph Service 的次要性能,是解析客户端发送 nGQL 文本,通过词法解析Lexer 和语法解析 Parser 生成执行打算,并通过优化后将执行打算交由执行引擎,执行引擎通过 Meta Service 获取图点和边的 schema,并通过存储引擎层获取点和边的数据。 Meta Service 对应的过程是 nebula-metad ,它基于 Raft 协定实现分布式集群,leader 由集群中所有 Meta Service 节点选出,而后对外提供服务,followers 处于待命状态并从 leader 复制更新的数据。一旦 leader 节点 down 掉,会再选举其中一个 follower 成为新的 leader。Meta Service 不仅负责存储和提供图数据的 meta 信息,如 Space、Schema、Partition、Tag 和 Edge 的属性的各字段的类型等,还同时负责指挥数据迁徙及 leader 的变更等运维操作。 ...

July 2, 2021 · 2 min · jiezi

关于云计算:KubeSphere-Meetup-北京站火热报名中-搭载-CIC-2021-云计算峰会

“CIC 2021 云计算峰会”是一场 Top 级行业盛会,将汇聚 800 家青云QingCloud 企业客户信息化负责人,采取线上线下相结合的形式,与会规模将超过 10000 人。 大会的主题为“预感·数字自在”,将有技术大牛分享前沿成绩,行业大咖带来实战经验。本次大会除了主论坛,还设置了多个分论坛。KubeSphere Meetup 将作为其中一个分论坛,连续之前上海、杭州、成都三站的“KubeSphere & Friends”的主题,为大家带来技术的交换和碰撞。 减速“云原生”,引领业务新改革从工业时代、互联网时代到云原生时代,企业 IT 零碎与业务零碎的关系产生了显著变动,从 IT 撑持业务转变为 IT 引领业务、甚至 IT 与业务融为一体,业务的构建形式也围绕着流动在云端的数据产生根本性改革。在此过程中,云原生既赋予了大数据灵便的存储形式、新级别的自动化服务、更好的集成和剖析性能,又提供了麻利构建云原生利用并施行对立治理的全生命周期工具链,正成为企业通过 IT 引领业务改革的利器。 如何减速云原生,持续引领业务新改革?微服务、多云与多集群治理、DevOps、Serverless 又将如何落地?围绕云原生话题的探讨,也将会成为往年 CIC 云计算峰会的一大热门。 流动议程北京站 KubeSphere Meetup 是往年的第四站,目前已确定讲师和议程。 工夫和地点流动工夫:2021 年 7 月 29 日 14:00-17:00 流动地点:北京国际饭店-北京国际饭店会议核心 F3 紫金大厅 B 流动礼品本次流动特地定制了 KubeSphere 全套留念周边礼品:T恤、马克杯、留念徽章、帆布袋、口罩...... 除了提供周边礼品之外,咱们还会赠送各种云原生相干的硬核书籍,有电子工业出版社提供的 《云原生操作系统Kubernetes》《将来架构从服务化到云原生》,还有人民邮电出版社图灵教育提供的张磊大神的巨著《深刻分析 Kubernetes》。 在本场流动中参加互动交换,即可取得精美礼品一份! 流动报名目前报名曾经开启,欢送各位 KubeSphere 社区的小伙伴以及对云原生技术感兴趣的敌人踊跃报名!在本次 Meetup 中,不仅能够获取各位云原生技术大牛的实践经验分享,还能和各位业界的大咖现场交换! 地位无限,先到先得!放松报名吧! 本文由博客一文多发平台 OpenWrite 公布!

July 1, 2021 · 1 min · jiezi

关于云计算:剑指双碳目标浪潮云牵手中科谱光一起做光谱捕手

夏日炎炎,入目绿色即是清凉。但,为什么树是绿色的?初中物理说树排汇了光的其余六种色彩,这样人眼就看到了树不排汇的绿色。正是因为不同物质构造对于光入射后排汇的特色不一样,物质有了举世无双的光谱“指纹”。现在在“双碳”指标导向下,浪潮云正牵手中科谱光,利用能看清“指纹”的“有色眼镜”——高光谱焕发新能量。 6月30日,浪潮云与天津中科谱光单干共建的“高光谱技术创新利用联结实验室”正式揭牌成立。单方将通过建设长期互利互惠的策略合作伙伴关系造成聚合效应,独特推动高光谱技术在工业互联网、数字农业、“双碳”业务等畛域的推广和利用落地。中国科学院院士、中科院空天信息翻新研究院研究员、中科谱光资深科学家童庆禧,中科谱光创始人、董事长张立福,浪潮云党委书记、董事长肖雪等缺席揭牌典礼。 保持翻新驱动倒退,全面塑造倒退新劣势,是国家十四五布局的重要批示和要求。高光谱遥感技术作为以后遥感技术的前沿畛域,利用物质对太阳光谱的选择性排汇差别,可能实现对地物品种的精密分类和理化个性的信息反演,是遥感畛域所获得的重大科技冲破之一。 中科谱光在高光谱遥感应用领域长期深耕,以一系列具备创新性、先进性与适用性的技术及产品,始终处于国内领先地位。作为浪潮集团在云计算、大数据、工业互联网等畛域的重要布局,浪潮云则致力于成为高品质云服务运营商,通过云网边端交融、云数智交融、建管运交融的全栈云服务,提供业余、生态、可信赖的分布式云。 浪潮云与中科谱光整合各自劣势资源联结共建的高光谱技术创新利用联结实验室,围绕全国当先的高光谱技术研发核心、高光谱翻新利用核心和高端智库三大定位: 邀请童庆禧院士负责声誉主任职务,并履行双主任制——由肖雪和张立福独特负责实验室主任,下设研发测试中心、计划验证核心、市场营销中心三大核心,独特反对实验室产品研发和经营推广; 放慢推动技术利用翻新与成绩转化,聚焦工业互联网、数字农业、双碳业务等畛域,发展软硬一体产品的定制化研发,独特推动相干课题钻研与我的项目落地; 同时摸索高效的科技成果转移转化机制,打造产学研用融通翻新样板,抢占科技竞争的制高点。打造人才汇聚的“高地”、科技翻新的“洼地”、成绩转化的“基地”、交换单干的“平台”。 以理论推广和利用落地为例,高光谱技术创新利用联结实验室将在工业互联网畛域,可为工业设施提供要害控制点智能检测服务;在数字农业方面,提供农作物氮磷钾等含量检测、病虫害辨认、作物长势监测等服务;在国家“碳达峰、碳中和”背景下,聚焦“双碳”业务畛域,提供煤炭热值检测、碳计量设施及双碳双控等服务。

July 1, 2021 · 1 min · jiezi

关于云计算:Kubernetes-源码解析-HPA-水平自动伸缩如何工作

HPA - Horizontal Pod Autoscaler 的缩写,Pod 程度主动伸缩。通过对 Pod 负载的监控,来主动减少或者缩小 Pod 的正本数量。 从字面意思来看,其次要蕴含了两局部: 监控 Pod 的负载管制 Pod 的正本数量那具体是如何实现的呢?以下基于1.17 源码,来剖析下 HPA 如何工作。 留神:文章中的代码在源码的根底上进行了精简:删掉了正文、序列化等信息,或保留了局部外围代码,加上新的正文。 资源HPA 的资源是HorizontalPodAutoscaler,在v1版本中,只反对基于 CPU 指标的计算;在v2beta2版本中退出了基于内存和自定义指标的计算。 v1//staging/src/k8s.io/api/autoscaling/v1/types.gotype HorizontalPodAutoscaler struct { metav1.TypeMeta metav1.ObjectMeta Spec HorizontalPodAutoscalerSpec Status HorizontalPodAutoscalerStatus }type HorizontalPodAutoscalerSpec struct { ScaleTargetRef CrossVersionObjectReference //监控的指标资源 MinReplicas *int32 //最小正本数 MaxReplicas int32 //最大正本数 TargetCPUUtilizationPercentage *int32 //触发调整的CPU 使用率}v2//staging/src/k8s.io/api/autoscaling/v2beta2/types.gotype HorizontalPodAutoscaler struct { metav1.TypeMeta metav1.ObjectMeta Spec HorizontalPodAutoscalerSpec Status HorizontalPodAutoscalerStatus }type HorizontalPodAutoscalerSpec struct { ScaleTargetRef CrossVersionObjectReference //监控的指标资源 MinReplicas *int32 MaxReplicas int32 Metrics []MetricSpec //新退出的自定义指标}type MetricSpec struct { Type MetricSourceType //指标源的类型:Object(基于某个对象)、Pods(基于pod 数)、Resource(基于资源应用计算,比方v1 版本中cpu)、External(基于内部的指标)。对应 MetricsClient 接口的四个办法 Object *ObjectMetricSource //对应 Object 类型的指标源 Pods *PodsMetricSource //对应 Pod 类型的指标源 Resource *ResourceMetricSource //对应 Resource 类型的指标源 External *ExternalMetricSource //对应 External 类型的指标源}type ObjectMetricSource struct { DescribedObject CrossVersionObjectReference //指标对象 Target MetricTarget //指定指标的目标值、平均值或者均匀使用率 Metric MetricIdentifier //指标标识:名字、label选择器}type PodsMetricSource struct { Metric MetricIdentifier Target MetricTarget }type ResourceMetricSource struct { Name v1.ResourceName Target MetricTarget }type ExternalMetricSource struct { Metric MetricIdentifier Target MetricTarget}type MetricTarget struct { Type MetricTargetType //类型:Utilization、Value、AverageValue Value *resource.Quantity AverageValue *resource.Quantity AverageUtilization *int32}控制器 HorizontalControllerHorizontalController被通过 key horizontalpodautoscaling 退出到 controller manager 中。用来管制HorizontalPodAutoscaler实例。 ...

July 1, 2021 · 3 min · jiezi

关于云计算:kubebuilder实战之七webhook

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 本篇概览本文是《kubebuilder实战》系列的第七篇,之前的文章咱们实现了一个Operator的设计、开发、部署、验证过程,为了让整个过程放弃简洁并且篇幅不收缩,实战中刻意跳过了一个重要的知识点:<font color="red">webhook</font>,现在是时候学习它了,这是个很重要的性能;本篇由以下局部形成:介绍webhook;联合后面的elasticweb我的项目,设计一个应用webhook的场景;筹备工作生成webhook开发(配置)开发(编码)部署验证Defaulter(增加默认值)验证Validator(合法性校验)对于webhook相熟java开发的读者大多晓得过滤器(Servlet Filter),如下图,内部申请会先达到过滤器,做一些对立的操作,例如转码、校验,而后才由真正的业务逻辑解决申请: Operator中的webhook,其作用与上述过滤器相似,内部对CRD资源的变更,在Controller解决之前都会交给webhook提前解决,流程如下图,该图来自《Getting Started with Kubernetes | Operator and Operator Framework》: 再来看看webhook具体做了哪些事件,如下图,kubernetes官网博客明确指出webhook能够做两件事:批改(mutating)和验证(validating)kubebuilder为咱们提供了生成webhook的根底文件和代码的工具,与制作API的工具相似,极大地简化了工作量,咱们只需聚焦业务实现即可;基于kubebuilder制作的webhook和controller,如果是同一个资源,那么<font color="red">它们在同一个过程中</font>;设计实战场景为了让实战有意义,咱们为后面的elasticweb我的项目上减少需要,让webhook施展理论作用;如果用户遗记输出总QPS,零碎webhook负责设置默认值<font color="red">1300</font>,操作如下图: 为了爱护零碎,给单个pod的QPS设置下限<font color="red">1000</font>,如果内部输出的singlePodQPS值超过1000,<font color="blue">就创立资源对象失败</font>,如下图所示: 源码下载本篇实战中的残缺源码可在GitHub下载到,地址和链接信息如下表所示(https://github.com/zq2599/blo...:名称链接备注我的项目主页https://github.com/zq2599/blo...该我的项目在GitHub上的主页git仓库地址(https)https://github.com/zq2599/blo...该我的项目源码的仓库地址,https协定git仓库地址(ssh)mailto:git@github.com:zq2599/blog_demos.git该我的项目源码的仓库地址,ssh协定这个git我的项目中有多个文件夹,kubebuilder相干的利用在<font color="blue">kubebuilder</font>文件夹下,如下图红框所示: kubebuilder文件夹下有多个子文件夹,本篇对应的源码在<font color="blue">elasticweb</font>目录下,如下图红框所示: 筹备工作和controller相似,webhook既能在kubernetes环境中运行,也能在kubernetes环境之外运行;如果webhook在kubernetes环境之外运行,是有些麻烦的,须要将证书放在所在环境,默认地址是:/tmp/k8s-webhook-server/serving-certs/tls.{crt,key}为了省事儿,也为了更靠近生产环境的用法,接下来的实战的做法是<font color="red">将webhook部署在kubernetes环境中</font>为了让webhook在kubernetes环境中运行,咱们要做一点筹备工作<font color="blue">装置cert manager</font>,执行以下操作:kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml上述操作实现后会新建很多资源,如namespace、rbac、pod等,以pod为例如下:[root@hedy ~]# kubectl get pods --all-namespacesNAMESPACE NAME READY STATUS RESTARTS AGEcert-manager cert-manager-6588898cb4-nvnz8 1/1 Running 1 5d14hcert-manager cert-manager-cainjector-7bcbdbd99f-q645r 1/1 Running 1 5d14hcert-manager cert-manager-webhook-5fd9f9dd86-98tm9 1/1 Running 1 5d14h...操作实现后,筹备工作完结,能够开始实战了;生成webhook进入elasticweb工程下,执行以下命令创立webhook:kubebuilder create webhook \--group elasticweb \--version v1 \--kind ElasticWeb \--defaulting \--programmatic-validation上述命令执行结束后,先去看看<font color="blue">main.go</font>文件,如下图红框1所示,主动减少了一段代码,作用是让webhook失效: 上图红框2中的<font color="blue">elasticweb_webhook.go</font>就是新增文件,内容如下:package v1import ( "k8s.io/apimachinery/pkg/runtime" ctrl "sigs.k8s.io/controller-runtime" logf "sigs.k8s.io/controller-runtime/pkg/log" "sigs.k8s.io/controller-runtime/pkg/webhook")// log is for logging in this package.var elasticweblog = logf.Log.WithName("elasticweb-resource")func (r *ElasticWeb) SetupWebhookWithManager(mgr ctrl.Manager) error { return ctrl.NewWebhookManagedBy(mgr). For(r). Complete()}// EDIT THIS FILE! THIS IS SCAFFOLDING FOR YOU TO OWN!// +kubebuilder:webhook:path=/mutate-elasticweb-com-bolingcavalry-v1-elasticweb,mutating=true,failurePolicy=fail,groups=elasticweb.com.bolingcavalry,resources=elasticwebs,verbs=create;update,versions=v1,name=melasticweb.kb.iovar _ webhook.Defaulter = &ElasticWeb{}// Default implements webhook.Defaulter so a webhook will be registered for the typefunc (r *ElasticWeb) Default() { elasticweblog.Info("default", "name", r.Name) // TODO(user): fill in your defaulting logic.}// TODO(user): change verbs to "verbs=create;update;delete" if you want to enable deletion validation.// +kubebuilder:webhook:verbs=create;update,path=/validate-elasticweb-com-bolingcavalry-v1-elasticweb,mutating=false,failurePolicy=fail,groups=elasticweb.com.bolingcavalry,resources=elasticwebs,versions=v1,name=velasticweb.kb.iovar _ webhook.Validator = &ElasticWeb{}// ValidateCreate implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateCreate() error { elasticweblog.Info("validate create", "name", r.Name) // TODO(user): fill in your validation logic upon object creation. return nil}// ValidateUpdate implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateUpdate(old runtime.Object) error { elasticweblog.Info("validate update", "name", r.Name) // TODO(user): fill in your validation logic upon object update. return nil}// ValidateDelete implements webhook.Validator so a webhook will be registered for the typefunc (r *ElasticWeb) ValidateDelete() error { elasticweblog.Info("validate delete", "name", r.Name) // TODO(user): fill in your validation logic upon object deletion. return nil}上述代码有两处须要留神,第一处和填写默认值无关,如下图: ...

July 1, 2021 · 4 min · jiezi

关于云计算:2021云原生避坑经验分享|CIC-阵容官宣

云原生(Cloud Native)无疑是近两年云计算畛域最热的词,随着 Kubernetes 和 Docker 等开源技术的遍及,也推动了云原生技术的疾速落地。云原生技术首先在新兴互联网企业失去了宽泛的实际,同时也逐步进入传统行业,并失去了进一步的倒退,帮忙千行百业实现数字化转型。 云原生时代,企业与开发者们所面临的新挑战是如何使企业架构与云基础设施充沛适配、最大化利用云计算的个性,实现云原生基础架构弹性扩大、稳固牢靠和降本增效。 去哪儿网在做容器化的过程中,各个系统 portal 平台、中间件、ops 基础设施、监控等都做了相应的适配革新,在这过程中也遇到很多问题,积淀了许多避坑教训。 云原生技术更是间接击中了快递行业的每个痛点,中通快递微小的业务量、顶峰期间流量稳定、简单的终端类型与业务状态,都是云原生平台擅于解决的问题,使得中通容器化团队的实战经验尤其贵重。 越来越多的传统服务从物理机、虚拟机迁徙到 Kubernetes,然而,目前大部分基于 Kubernetes 的部署的服务都是无状态的,有状态服务容器化的实现有哪些难点呢?新东方在有状态服务 in K8s 落地过程中,通过自研高性能存储服务 XLSS,以解决原生 K8s 撑持有状态服务能力有余的问题。 在容器化、CI/CD 等技术落地后,如何利用开源工具和 Kubernetes 设计高效的治理开发测试环境?以及如何利用 IM 零碎开放平台,构建 chatops 工作流?红亚科技给出了本人的实战经验。 Intel作为寰球科技巨头,不仅提供了丰盛的云原生利用案例以及解决方案,在云原生技术演进、市场趋势、行业图景等方面也有深刻的钻研。 7 月 29 日,CIC 云计算峰会「云原生技术实际分论坛」,汇合了来自于 Intel、去哪儿、中通、新东方、红亚科技的技术大咖,带给你实实在在的企业云原生化、容器化的实践经验。 上面是精彩预报—— 英特尔技术助力推动性能强劲、简略易用、优化高效的云原生基础架构落地,以云原生平台为数据处理、剖析和 AI 提供全面减速,助力客户实现云原生基础架构弹性扩大、稳固牢靠和降本增效。 演讲提纲: 1、云原生发展趋势 数字化改革趋势 云原生技术演进、市场趋势 云原生行业图景 2、Intel 助力云原生落地实际 Intel 软硬件技术使能云原生架构 计算、存储、网络等技术解析 3、云原生利用案例与解决方案 近几年,容器技术十分火爆,且日趋成熟,泛滥企业缓缓开始容器化建设,并在云原生技术方向上一直的摸索和实际。基于这个大的趋势, 2020 年底去哪儿网也向云原生迈出了第一步——容器化。截止到 2021 年 6 月初,去哪儿网生产环境曾经接入了 150 多个利用,其余利用也在陆续接入中。回顾整个容器化落地过程,其实有不少技术难点。 本次分享将次要介绍去哪儿网在云原生路线上容器化落地过程中基础架构、运维配套工具、公布零碎做的相干适配革新,以及推广过程中遇到的问题和解决思路。 演讲提纲: 1、容器化在去哪儿网的倒退历程 2、去哪儿网容器化落地实际 计划介绍 ...

June 30, 2021 · 1 min · jiezi

关于云计算:浪潮云说丨浪潮云智能对话想你所想无限畅聊

智能语音技术可能实现人与机器以语音为纽带的通信,人机对话通过声音信号的前端解决、语音辨认、自然语言解决、语音合成等造成残缺的人机语音交互。2020年以来,受新冠疫情的影响,市场对对话型机器人及服务型机器人等交互硬件产品的需要大幅减少,带动智能语音行业的疾速倒退。浪潮云智能对话产品可能更好地了解人类所说的话和所提出的需要,从而提供更天然、更靠近人类程度的交换服务,想你所想,有限畅聊。 产品定义 浪潮云智能对话(Inspur Chat Bot,简称IBot)基于自然语言了解、常识抽取、机器学习等关键技术,提供常识管理工具、对话引擎、数据统计及剖析和开发者工具,精准了解用户对话用意和要害信息,帮忙用户疾速创立个性化智能对话零碎。 图片 产品劣势 浪潮云智能对话的产品劣势次要体现在四个方面: 利用场景 浪潮云智能对话面向智能客服、智慧城市、智能硬件等畛域具备广大的利用场景,为客服等服务性行业带来了产业改革及效率优化,促成了一系列生产级智能硬件产品的呈现或降级。 从细分场景来说,浪潮云智能对话能利用于政务、医疗、司法、教育、公安等泛滥垂直畛域中: 智能政务服务:在智能化政务服务办事大厅中,浪潮云智能对话产品补充和革新了既有政务零碎的服务交互模式,提供智能征询、互动交换、业务导办等服务,满足政策查问、业务征询、业务办理、投诉倡议、告诉播报等利用场景,针对不同办事案例,疏导公众发展按需适己的办事行为,缓解事先征询压力,晋升征询解决疑难案件的效力和智能化体验取得感,进步公众的政务办事效率和满意度。 智能导诊:提供就医者自助信息征询平台,帮助医护人员分流,进步办事效率。提供疾病和保健知识宣传,让患者对疾病的预防和护理更理解。 智能法律咨询:用来辅助人工征询,分流、接待大众,遍及法律常识等。使业余工作人员从大量的重复性劳动中解放出来,集中精力解决司法外围业务。 智能家居:为不同厂家、不同类型设施的智能家居提供对立的管制入口。能够进行网上购物、点播歌曲,或者理解天气预报,或者管制智能家居设施。 落地实际 浪潮云智能对话产品在爱城市网的客服核心找到了落地生根的土壤: 将来,浪潮云智能对话产品将在持续深耕智慧城市、智能硬件等利用场景的同时扩大新的应用领域,针对细分畛域继续优化产品性能,输入创新能力和产品,助力政企客户实现数字化转型和价值晋升。

June 30, 2021 · 1 min · jiezi

关于云计算:Kubernetes-源码解析-Informer-的工作原理

上篇扒了 HPA 的源码,然而没深刻细节,明天往细节深刻。 为什么要有 Informer?Kubernetes 中的长久化数据保留在 etcd中,各个组件并不会间接拜访 etcd,而是通过 api-server裸露的 RESTful 接口对集群进行拜访和管制。 资源的控制器(图中右侧灰色的局部)读取数据也并不会间接从 api-server 中获取资源信息(这样会减少 api-server 的压力),而是从其“本地缓存”中读取。这个“本地缓存”只是表象的存在,加上缓存的同步逻辑就是明天要是说的Informer(灰色区域中的第一个蓝色块)所提供的性能。 从图中能够看到 Informer 的几个组件: Reflector:与 api-server交互,监听资源的变更。Delta FIFO Queue:增量的 FIFO 队列,保留 Reflector 监听到的资源变更(简略的封装)。Indexer:Informer 的本地缓存,FIFO 队列中的数据依据不同的变更类型,在该缓存中进行操作。 Local Store:上篇 提到了程度主动伸缩的控制器HorizontalController,其构造方法就须要提供 Informer。 //pkg/controller/podautoscaler/horizontal.gotype HorizontalController struct { scaleNamespacer scaleclient.ScalesGetter hpaNamespacer autoscalingclient.HorizontalPodAutoscalersGetter mapper apimeta.RESTMapper replicaCalc *ReplicaCalculator eventRecorder record.EventRecorder downscaleStabilisationWindow time.Duration hpaLister autoscalinglisters.HorizontalPodAutoscalerLister hpaListerSynced cache.InformerSynced podLister corelisters.PodLister podListerSynced cache.InformerSynced queue workqueue.RateLimitingInterface recommendations map[string][]timestampedRecommendation}func NewHorizontalController( evtNamespacer v1core.EventsGetter, scaleNamespacer scaleclient.ScalesGetter, hpaNamespacer autoscalingclient.HorizontalPodAutoscalersGetter, mapper apimeta.RESTMapper, metricsClient metricsclient.MetricsClient, //从HorizontalPodAutoscalerInformer 获取hpa 实例信息 hpaInformer autoscalinginformers.HorizontalPodAutoscalerInformer, //从PodInformer 中获取 pod 信息 podInformer coreinformers.PodInformer, resyncPeriod time.Duration, downscaleStabilisationWindow time.Duration, tolerance float64, cpuInitializationPeriod, delayOfInitialReadinessStatus time.Duration,) *HorizontalController { ...... hpaInformer.Informer().AddEventHandlerWithResyncPeriod( //增加事件处理器 cache.ResourceEventHandlerFuncs{ AddFunc: hpaController.enqueueHPA, UpdateFunc: hpaController.updateHPA, DeleteFunc: hpaController.deleteHPA, }, resyncPeriod, ) ......}type HorizontalPodAutoscalerInformer interface { Informer() cache.SharedIndexInformer Lister() v1.HorizontalPodAutoscalerLister}HorizontalPodAutoscalerInformer的实例化办法中就呈现了明天的正主cache.NewSharedIndexInformer()。 ...

June 30, 2021 · 4 min · jiezi

关于云计算:kubebuilder实战之五operator编码

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 系列文章链接kubebuilder实战之一:筹备工作kubebuilder实战之二:首次体验kubebuilderkubebuilder实战之三:基础知识速览kubebuilder实战之四:operator需要阐明和设计kubebuilder实战之五:operator编码kubebuilder实战之六:构建部署运行kubebuilder实战之七:webhookkubebuilder实战之八:知识点小记本篇概览本篇是《kubebuilder实战》系列的第五篇,后面的所有致力(环境筹备、常识储备、需要剖析、数据结构和业务逻辑设计),都是为了将之前的设计用编码实现;既然曾经充分准备,现在无需太多语言,咱们开始入手吧!源码下载本篇实战中的残缺源码可在GitHub下载到,地址和链接信息如下表所示(https://github.com/zq2599/blog_demos):名称链接备注我的项目主页https://github.com/zq2599/blog_demos该我的项目在GitHub上的主页git仓库地址(https)https://github.com/zq2599/blog_demos.git该我的项目源码的仓库地址,https协定git仓库地址(ssh)git@github.com:zq2599/blog_demos.git该我的项目源码的仓库地址,ssh协定这个git我的项目中有多个文件夹,kubebuilder相干的利用在<font color="blue">kubebuilder</font>文件夹下,如下图红框所示: kubebuilder文件夹下有多个子文件夹,本篇对应的源码在<font color="blue">elasticweb</font>目录下,如下图红框所示: 新建我的项目elasticweb新建名为<font color="blue">elasticweb</font>的文件夹,在外面执行以下命令即可创立名为<font color="blue">elasticweb</font>的我的项目,domain为<font color="blue">com.bolingcavalry</font>:go mod init elasticwebkubebuilder init --domain com.bolingcavalry而后是CRD,执行以下命令即可创立相干资源:kubebuilder create api \--group elasticweb \--version v1 \--kind ElasticWeb而后用IDE关上整个工程,我这里是goland: CRD编码关上文件<font color="blue">api/v1/elasticweb_types.go</font>,做以下几步改变:批改数据结构ElasticWebSpec,减少前文设计的四个字段;批改数据结构ElasticWebStatus,减少前文设计的一个字段;减少String办法,这样打印日志时不便咱们查看,留神RealQPS字段是指针,因而可能为空,须要判空;残缺的<font color="blue">elasticweb_types.go</font>如下所示:package v1import ( "fmt" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "strconv")// 冀望状态type ElasticWebSpec struct { // 业务服务对应的镜像,包含名称:tag Image string `json:"image"` // service占用的宿主机端口,内部申请通过此端口拜访pod的服务 Port *int32 `json:"port"` // 单个pod的QPS下限 SinglePodQPS *int32 `json:"singlePodQPS"` // 以后整个业务的总QPS TotalQPS *int32 `json:"totalQPS"`}// 理论状态,该数据结构中的值都是业务代码计算出来的type ElasticWebStatus struct { // 以后kubernetes中理论反对的总QPS RealQPS *int32 `json:"realQPS"`}// +kubebuilder:object:root=true// ElasticWeb is the Schema for the elasticwebs APItype ElasticWeb struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty"` Spec ElasticWebSpec `json:"spec,omitempty"` Status ElasticWebStatus `json:"status,omitempty"`}func (in *ElasticWeb) String() string { var realQPS string if nil == in.Status.RealQPS { realQPS = "nil" } else { realQPS = strconv.Itoa(int(*(in.Status.RealQPS))) } return fmt.Sprintf("Image [%s], Port [%d], SinglePodQPS [%d], TotalQPS [%d], RealQPS [%s]", in.Spec.Image, *(in.Spec.Port), *(in.Spec.SinglePodQPS), *(in.Spec.TotalQPS), realQPS)}// +kubebuilder:object:root=true// ElasticWebList contains a list of ElasticWebtype ElasticWebList struct { metav1.TypeMeta `json:",inline"` metav1.ListMeta `json:"metadata,omitempty"` Items []ElasticWeb `json:"items"`}func init() { SchemeBuilder.Register(&ElasticWeb{}, &ElasticWebList{})}在elasticweb目录下执行<font color="blue">make install</font>即可部署CRD到kubernetes:zhaoqin@zhaoqindeMBP-2 elasticweb % make install/Users/zhaoqin/go/bin/controller-gen "crd:trivialVersions=true" rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/baseskustomize build config/crd | kubectl apply -f -Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitioncustomresourcedefinition.apiextensions.k8s.io/elasticwebs.elasticweb.com.bolingcavalry created部署胜利后,用<font color="blue">api-versions</font>命令能够查到该GV: ...

June 29, 2021 · 5 min · jiezi

关于云计算:浪潮云荣获2021中国智能运维领导厂商奖项

6月25日,由中国电子商会主办,信息化和软件服务网、北京软信信息技术研究院独特承办的2021中国IT运维高峰论坛在北京胜利举办。会上,系列奖项评比后果正式颁发,浪潮云凭借多年丰盛的运维服务教训积攒,以及领跑行业的技术积淀,推出云泽智能运维产品,胜利摘得“2021 中国智能运维领导厂商”奖项,为泛滥政府和企业用户提供运维服务。 据悉,本次论坛以“数智时代新运维”主题,会集政府、制作、互联网、金融、通信、教育、能源、交通、医疗等多个行业的行业首领和企业代表,独特探讨新基建浪潮下IT运维的挑战与时机,以“智能运维”为外围,分享IT运维畛域最具权威的声音。 云泽智能运维产品以用户场景为依靠,以运维服务为保障,为租户、云服务商、云监管方、IDC 服务厂商等不同类型客户提供场景化运维服务,由利用质效管理系统(AOM)、对立云管零碎(MSP)、运维技术服务(MTS)和数据中心服务(DCS)四个产品系列组成。 浪潮云以服务为外围,不仅提供工具还提供常识教训,造成了“PPT”方法论(People 人、Process 流程制度、Technology工具)为领导的交付体系,实现更欠缺的体系化产品交付。云泽打造笼罩云网边端的全场景业务服务能力,体现了浪潮云建、管、运间断服务的能力,一直晋升运维管理效率,在数智时代,减速助力政府、企业实现翻新与数字化转型。 如需理解更多分割咱们浪潮云售前电话:400-607-6657

June 28, 2021 · 1 min · jiezi

关于云计算:Thoughtworks-Tech-Radar-Vol-24-解读

昨天,Thoughtworks推送了2021上半年技术雷达,总第24期。从本期开始,咱们对其中关键技术趋势,站在云厂商视角,解读与思考。<!--more--> 驳回设计体系[设计体系](https://www.thoughtworks.com/cn/radar/techniques/design-systems)定义了一组设计模式,组件库,以及良好的设计和工程实际,以确保数字产品的一致性。观点这个与各个云厂商提供基于本人云的最佳实际、白皮书的目标是统一的。 扩大浏览《APPLE 的 Human Interface Guidelines APPLE DesignGoogle 的 Material DesignGoogle DesignMicrosoft 的 Fluent Design SystemMicrosoft DesignAtlassian 的设计体系IBM 的 Carbon 设计体系蚂蚁金服的 Ant Design腾讯挪动互联网用户体验设计部平台工程产品团队采纳云计算和DevOps,尽管进步了团队生产力,缩小了对集中式运维团队和基础设施的依赖,但也制约了那些不足自治理残缺利用和运维技巧的团队。一些组织通过创立 [平台工程产品团队](https://www.thoughtworks.com/cn/radar/techniques/platform-engineering-product-teams) 来应答这些挑战。这些团队保护着一个外部的利用平台,该平台使交付团队可能自助部署和运维零碎,从而缩小交付工夫和升高技术栈的复杂度。这里的重点是 API 驱动的自服务和反对工具,而交付团队依然须要对部署在该平台上的利用负责。观点云厂商是否能承当此角色?答案是不齐全能。云厂商的服务/工具,白皮书最佳实际,是为了帮忙业务团队以最小的代价承当此团队的角色。落地的具体的企业,成果可能存在较大差别,这个依赖企业本身能力与企业组织。互联网原生数字企业,实际成果比拟好;传统制作企业、政府部门实际成果可能比拟差,这种情景就须要带上咨询服务,不过咨询服务如何做到授人以鱼不如授人以渔呢? Sentry在前端错误报告方面,Sentry曾经成了许多团队的默认选项。Sentry提供了一些便当的性能,比方谬误分组,以及应用适当的参数定义谬误过滤规定,能够极大地帮忙解决来自终端用户设施的大量谬误。通过将Sentry集成到继续交付流水线中,你能够上传源码映射文件,从而更高效地调试谬误,并能很容易追踪到是在哪个版本的软件中产生了这些谬误。咱们很观赏只管Sentry是一个SaaS产品,但它的源代码是公开的,这样就能够收费用于一些较小的用例和[自托管](https://develop.sentry.dev/self-hosted/)中。观点既提供SaaS服务又开源,难道这就是优良软件该当具备的素质么。 试验CDK咱们许多应用AWS的团队中发现,[AWS云开发工具包](https://docs.aws.amazon.com/cdk/latest/guide/home.html)(AWS CDK)是一个正当的 AWS 默认工具,以实现基础设施的整备工作。其特别之处在于,他们喜爱应用支流编程语言而不是配置文件来进行开发,从而能够应用现有的工具、测试方法和技能。但与相似的工具一样,此时也仍须要审慎地确保部署易于了解和保护。这个开发工具包目前反对TypeScript、JavaScript、Python、Java、C# 和 .NET。新语言的反对正在被增加到 CDK 中。此外,咱们应用了 AWS 云开发工具包和 HashiCorp 的[Terraform 云开发工具包](https://learn.hashicorp.com/tutorials/terraform/cdktf)来生成 Terraform 配置,并胜利实现了与Terraform平台的整备。观点云是一个超级大的零碎,烟囱式的套件重叠在一起,不是云。AWS就是一个超大软件系统。 Backstage随着组织在寻求反对和简化其开发环境时,开始采纳开发者门户,咱们看到人们对 [Backstage](https://backstage.io/) 的趣味和使用量在一直增长。随着工具和技术数量的减少,采纳某种模式的标准化,对于放弃开发的一致性变得越来越重要。因为一旦实现了一致性,开发人员就能够专一于翻新和产品开发,而不是陷入反复创造轮子的泥淖。Backstage 是由 Spotify 创立的开源开发者门户平台。它由软件模板、对立的基础设施工具和统一且集中的技术文档所形成。插件式架构为组织的基础设施生态系统,提供了可扩展性和适应性。观点Backstage,就是对应平台工程产品团队所须要的撑持工具。此我的项目还是CFCF孵化我的项目,须要关注。 用Kafka API而非Kafka随着越来越多的企业开始使用事件在微服务之间共享数据、收集剖析数据或传输数据到数据湖, [Apache Kafka](https://www.thoughtworks.com/cn/radar/tools/apache-kafka) 曾经成为撑持事件驱动架构的最受欢迎的平台。只管 Kafka 的可伸缩的音讯长久化概念是革命性的,但要使其失常工作,还是须要依赖泛滥的流动部件,包含 Zookeeper、代理、分区和镜像。尽管实现和保护这些组件会很辣手,然而它们的确在须要的时候,尤其是在企业规模的利用中,提供了极大的灵活性和弱小性能。因为采纳 Kafka 残缺生态系统的门槛较高,所以咱们乐于见到一些平台在最近的爆发式增长。这些平台提供 用Kafka API而非Kafka 的性能。最近涌现出的 [Kafka on Pulsar](https://github.com/streamnative/kop) 和 [Redpanda](https://www.thoughtworks.com/cn/radar/platforms/redpanda),就是属于这类平台。而 [Azure Event Hubs for Kafka](https://github.com/Azure/azure-event-hubs-for-kafka) 则提供了对 Kafka 生产者和消费者 API 的兼容。但因为 Kafka 的某些性能(例如数据流客户端库)与这些代替代理不兼容,因而依然有理由抉择 Kafka 而不是这些代替代理。然而到底开发者是否会采纳“用Kafka API而非Kafka”的策略,抑或这只是 Kafka 的竞争对手试图将用户诱惑到 Kafka平台之外,还有待察看。最终,兴许Kafka最长久的影响力,就是其提供给客户的易用协定和API。观点最终,兴许Kafka最长久的影响力,就是其提供给客户的易用协定和API,任何实体都会沦亡,唯有文化生生不息。Kafka能做到这个境界,曾经是高峰了。 ...

June 27, 2021 · 3 min · jiezi

关于云计算:可编程网关-Pipy-第三弹事件模型设计

自从加入了 Flomesh 的 workshop,理解了可编程网关 Pipy。对这个“小东西”充斥了好奇,前后写了两篇文章,看了局部源码解开了其局部面纱。但始终未见其全貌,没有涉及其外围设计。 不是有句话,“好奇害死猫”。其实应该还有后半句,“满足了就没事”(见维基百科)。 所有就有了明天的这一篇,对前两篇感兴趣的能够跳转翻看。 初探可编程网关 Pipy可编程网关 Pipy 第二弹:编程实现 Metrics 及源码解读言归正传。 事件模型上篇写了 Pipy 基于事件的信息流转,其实还未深刻涉及其外围的事件模型。既然是事件模型,先看事件。 src/event.hpp:41 中定义了 Pipy 的四种事件: DataMessageStartMessageEndSessionEnd翻看源码可知(必须吐槽文档太少)这几种事件其实是有程序的:MessageStart -> Data -> MessageEnd -> SessionEnd。 这种面向事件模型,必然有生产者和消费者。又是翻看源码可知,生产者和消费者都是 pipy::Filter。咱们在上篇文章中讲过:每个 Pipeline 都有一个过滤器链,相似单向链表的数据结构。 那是不是依照下面说的,事件是从一个 Filter 流向下一个 Filter?也对,也不对。 矛盾?先看 Filter 如何向下传递事件,src/session.cpp:55 处,Filter 持有 output 变量,相似为 Event::Receiver(参数为 Event 的 std::function 的别名,作为在行的笔者并不懂 c++,但不障碍理解程序设计)。通过 Receiver 调用下一个 Filter 的 #process 办法。 这里的 Receiver 就能够了解为事件发送的窗口,而 #process(Context *ctx, Event *inp) 就是事件的接管窗口。 这就是后面为什么说 “事件是从一个 Filter 流向下一个 Filter” 是正确的。 ...

June 27, 2021 · 1 min · jiezi

关于云计算:常用的几款工具让-Kubernetes-集群上的工作更容易

之前写过一篇 介绍了工具减速云原生 Java 开发。 其实日常工作中在集群上的操作也十分多,明天就来介绍我所应用的工具。 kubectl-alias应用频率最高的工具,我本人略微批改了一下,退出了 StatefulSet 的反对。 这个是我的 https://github.com/addozhang/kubectl-aliases,基于 https://github.com/ahmetb/kubectl-aliases。 比方输入某个 pod 的 json,kgpoojson xxx 等同于 kubectl get pod xxx -o json。 联合 jq 应用成果更好 。 语法解读k=kubectl sys=--namespace kube-systemcommands: g=getd=describerm=deletea:apply -fak:apply -kk:kustomizeex: exec -i -tlo: logs -fresources: po=pod, dep=deployment, ing=ingress, svc=service, cm=configmap, sec=secret,ns=namespace, no=nodeflags: output format: oyaml, ojson, owideall: --all or --all-namespaces depending on the commandsl: --show-labelsw=-w/--watchvalue flags (should be at the end): n=-n/--namespacef=-f/--filenamel=-l/--selectorkubectx + kubens装置看这里 kubectx 用于在不同的集群间进行疾速切换。如果用 kubectl,你须要: # context 列表kubectl config current-context # 设置 contextkubectl config use-context coffee kubens 就是在不同 namespace 间疾速切换的工具。用 kubectl 的话,须要: ...

June 26, 2021 · 3 min · jiezi

关于云计算:KubeSphere-Helm-应用仓库源码分析

作者:蔡锡生,LStack 平台研发工程师,近期专一于基于 OAM 的利用托管平台落地。背景介绍KubeSphere 利用商店简介作为一个开源的、以利用为核心的容器平台,KubeSphere 在 OpenPitrix 的根底上,为用户提供了一个基于 Helm 的利用商店,用于利用生命周期治理。OpenPitrix 是一个开源的 Web 平台,用于打包、部署和治理不同类型的利用。KubeSphere 利用商店让 ISV、开发者和用户可能在一站式服务中只需点击几下就能够上传、测试、部署和公布利用。 KubeSphere 中的 Helm 仓库性能默认状况下,利用商店中内置了 16 个利用,但您能够通过利用模板增加更多利用。 KubeSphere Helm 仓库增加 Helm repo list KubeSphere Helm 仓库中的利用模版查问 Helm 仓库简介Helm charts 是寄存 K8s 利用模版的仓库,该仓库由 index.yaml 文件和 .tgz 模版包组成。 [root@ningbo stable]# ls -al 总用量 400drwxr-xr-x. 26 root root 4096 6月 22 17:01 .drwxr-xr-x. 4 root root 86 6月 22 16:37 ..-rw-r--r--. 1 root root 10114 6月 22 17:12 index.yaml-rw-r--r--. 1 root root 3803 6月 8 2020 lsh-cluster-csm-om-agent-0.1.0.tgz-rw-r--r--. 1 root root 4022 6月 8 2020 lsh-mcp-cc-alert-service-0.1.0.tgz-rw-r--r--. 1 root root 4340 6月 8 2020 lsh-mcp-cc-sms-service-0.1.0.tgz-rw-r--r--. 1 root root 4103 6月 8 2020 lsh-mcp-cpm-metrics-exchange-0.1.0.tgz-rw-r--r--. 1 root root 4263 6月 8 2020 lsh-mcp-cpm-om-service-0.1.0.tgz-rw-r--r--. 1 root root 4155 6月 8 2020 lsh-mcp-csm-om-service-0.1.0.tgz-rw-r--r--. 1 root root 3541 6月 8 2020 lsh-mcp-deploy-service-0.1.0.tgz-rw-r--r--. 1 root root 5549 6月 8 2020 lsh-mcp-iam-apigateway-service-0.1.0.tgzindex.yaml 文件apiVersion: v1entries: aliyun-ccm: - apiVersion: v2 appVersion: addon created: "2021-06-21T08:59:58Z" description: A Helm chart for Kubernetes digest: 6bda563c86333475255e5edfedc200ae282544e2c6e22b519a59b3c7bdef9a32 name: aliyun-ccm type: application urls: - charts/aliyun-ccm-0.1.0.tgz version: 0.1.0 aliyun-csi-driver: - apiVersion: v2 appVersion: addon created: "2021-06-21T08:59:58Z" description: A Helm chart for Kubernetes digest: b49f128d7a49401d52173e6f58caedd3fabbe8e2827dc00e6a824ee38860fa51 name: aliyun-csi-driver type: application urls: - charts/aliyun-csi-driver-0.1.0.tgz version: 0.1.0 application-controller: - apiVersion: v1 appVersion: addon created: "2021-06-21T08:59:58Z" description: A Helm chart for application Controller digest: 546e72ce77f865683ce0ea75f6e0203537a40744f2eb34e36a5bd378f9452bc5 name: application-controller urls: - charts/application-controller-0.1.0.tgz version: 0.1.0.tgz 解压缩后的文件目录[root@ningbo stable]# cd mysql/[root@ningbo mysql]# ls -al总用量 20drwxr-xr-x. 3 root root 97 5月 25 2020 .drwxr-xr-x. 26 root root 4096 6月 22 17:01 ..-rwxr-xr-x. 1 root root 106 5月 25 2020 Chart.yaml-rwxr-xr-x. 1 root root 364 5月 25 2020 .Helmignore-rwxr-xr-x. 1 root root 76 5月 25 2020 index.yamldrwxr-xr-x. 3 root root 146 5月 25 2020 templates-rwxr-xr-x. 1 root root 1735 5月 25 2020 values.yamlChart.yaml[root@ningbo mysql]# cat Chart.yaml apiVersion: v1appVersion: "1.0"description: A Helm chart for Kubernetesname: mysqlversion: 0.1.0增加 Helm 仓库代码介绍接口实现剖析路由注册handler,参数解析,调用 models 方面models ,调用 models 办法crd client,调用 K8s api 存储路由注册 webservice.Route(webservice.POST("/repos"). To(handler.CreateRepo). // 跟进 Doc("Create a global repository, which is used to store package of app"). Metadata(restfulspec.KeyOpenAPITags, []string{constants.OpenpitrixTag}). Param(webservice.QueryParameter("validate", "Validate repository")). Returns(http.StatusOK, api.StatusOK, openpitrix.CreateRepoResponse{}). Reads(openpitrix.CreateRepoRequest{}))校验参数, 构建 modelsfunc (h *openpitrixHandler) CreateRepo(req *restful.Request, resp *restful.Response) { createRepoRequest := &openpitrix.CreateRepoRequest{} err := req.ReadEntity(createRepoRequest) if err != nil { klog.V(4).Infoln(err) api.HandleBadRequest(resp, nil, err) return } createRepoRequest.Workspace = new(string) *createRepoRequest.Workspace = req.PathParameter("workspace") user, _ := request.UserFrom(req.Request.Context()) creator := "" if user != nil { creator = user.GetName() } parsedUrl, err := url.Parse(createRepoRequest.URL) if err != nil { api.HandleBadRequest(resp, nil, err) return } userInfo := parsedUrl.User // trim credential from url parsedUrl.User = nil repo := v1alpha1.HelmRepo{ ObjectMeta: metav1.ObjectMeta{ Name: idutils.GetUuid36(v1alpha1.HelmRepoIdPrefix), Annotations: map[string]string{ constants.CreatorAnnotationKey: creator, }, Labels: map[string]string{ constants.WorkspaceLabelKey: *createRepoRequest.Workspace, }, }, Spec: v1alpha1.HelmRepoSpec{ Name: createRepoRequest.Name, Url: parsedUrl.String(), SyncPeriod: 0, Description: stringutils.ShortenString(createRepoRequest.Description, 512), }, } if strings.HasPrefix(createRepoRequest.URL, "https://") || strings.HasPrefix(createRepoRequest.URL, "http://") { if userInfo != nil { repo.Spec.Credential.Username = userInfo.Username() repo.Spec.Credential.Password, _ = userInfo.Password() } } else if strings.HasPrefix(createRepoRequest.URL, "s3://") { cfg := v1alpha1.S3Config{} err := json.Unmarshal([]byte(createRepoRequest.Credential), &cfg) if err != nil { api.HandleBadRequest(resp, nil, err) return } repo.Spec.Credential.S3Config = cfg } var result interface{} // 1. validate repo result, err = h.openpitrix.ValidateRepo(createRepoRequest.URL, &repo.Spec.Credential) if err != nil { klog.Errorf("validate repo failed, err: %s", err) api.HandleBadRequest(resp, nil, err) return } // 2. create repo validate, _ := strconv.ParseBool(req.QueryParameter("validate")) if !validate { if repo.GetTrueName() == "" { api.HandleBadRequest(resp, nil, fmt.Errorf("repo name is empty")) return } result, err = h.openpitrix.CreateRepo(&repo) //跟进 } if err != nil { klog.Errorln(err) handleOpenpitrixError(resp, err) return } resp.WriteEntity(result)}调用 createRep 办法func (c *repoOperator) CreateRepo(repo *v1alpha1.HelmRepo) (*CreateRepoResponse, error) { name := repo.GetTrueName() items, err := c.repoLister.List(labels.SelectorFromSet(map[string]string{constants.WorkspaceLabelKey: repo.GetWorkspace()})) if err != nil && !apierrors.IsNotFound(err) { klog.Errorf("list Helm repo failed: %s", err) return nil, err } for _, exists := range items { if exists.GetTrueName() == name { klog.Error(repoItemExists, "name: ", name) return nil, repoItemExists } } repo.Spec.Description = stringutils.ShortenString(repo.Spec.Description, DescriptionLen) _, err = c.repoClient.HelmRepos().Create(context.TODO(), repo, metav1.CreateOptions{}) // 跟进 if err != nil { klog.Errorf("create Helm repo failed, repo_id: %s, error: %s", repo.GetHelmRepoId(), err) return nil, err } else { klog.V(4).Infof("create Helm repo success, repo_id: %s", repo.GetHelmRepoId()) } return &CreateRepoResponse{repo.GetHelmRepoId()}, nil}调用 K8s api, 创立 crd HelmRepo// Create takes the representation of a HelmRepo and creates it. Returns the server's representation of the HelmRepo, and an error, if there is any.func (c *HelmRepos) Create(ctx context.Context, HelmRepo *v1alpha1.HelmRepo, opts v1.CreateOptions) (result *v1alpha1.HelmRepo, err error) { result = &v1alpha1.HelmRepo{} err = c.client.Post(). Resource("Helmrepos"). VersionedParams(&opts, scheme.ParameterCodec). Body(HelmRepo). Do(ctx). Into(result) return}查问Helm 仓库利用模版代码介绍接口实现路由注册handler,参数解析,调用 models 方面models ,调用 models 办法crd client,调用 K8s api 存储路由注册webservice.Route(webservice.GET("/apps").LiHui, 6 months ago: • openpitrix crd Deprecate(). To(handler.ListApps). // 跟进 Doc("List app templates"). Param(webservice.QueryParameter(params.ConditionsParam, "query conditions,connect multiple conditions with commas, equal symbol for exact query, wave symbol for fuzzy query e.g. name~a"). Required(false). DataFormat("key=%s,key~%s")). Param(webservice.QueryParameter(params.PagingParam, "paging query, e.g. limit=100,page=1"). Required(false). DataFormat("limit=%d,page=%d"). DefaultValue("limit=10,page=1")). Param(webservice.QueryParameter(params.ReverseParam, "sort parameters, e.g. reverse=true")). Param(webservice.QueryParameter(params.OrderByParam, "sort parameters, e.g. orderBy=createTime")). Metadata(restfulspec.KeyOpenAPITags, []string{constants.OpenpitrixTag}). Returns(http.StatusOK, api.StatusOK, models.PageableResponse{}))参数解析,调用 models 方面func (h *openpitrixHandler) ListApps(req *restful.Request, resp *restful.Response) limit, offset := params.ParsePaging(req) orderBy := params.GetStringValueWithDefault(req, params.OrderByParam, openpitrix.CreateTime) reverse := params.GetBoolValueWithDefault(req, params.ReverseParam, false) conditions, err := params.ParseConditions(req) if err != nil { klog.V(4).Infoln(err) api.HandleBadRequest(resp, nil, err) return } if req.PathParameter("workspace") != "" { conditions.Match[openpitrix.WorkspaceLabel] = req.PathParameter("workspace") } result, err := h.openpitrix.ListApps(conditions, orderBy, reverse, limit, offset) // 跟进 if err != nil { klog.Errorln(err) handleOpenpitrixError(resp, err) return } resp.WriteEntity(result)}从缓存中获取 applistfunc (c *applicationOperator) ListApps(conditions *params.Conditions, orderBy string, reverse bool, limit, offset int) (*models.PageableResponse, error) { apps, err := c.listApps(conditions) // 重点跟进 if err != nil { klog.Error(err) return nil, err } apps = filterApps(apps, conditions) if reverse { sort.Sort(sort.Reverse(HelmApplicationList(apps))) } else { sort.Sort(HelmApplicationList(apps)) } totalCount := len(apps) start, end := (&query.Pagination{Limit: limit, Offset: offset}).GetValidPagination(totalCount) apps = apps[start:end] items := make([]interface{}, 0, len(apps)) for i := range apps { versions, err := c.getAppVersionsByAppId(apps[i].GetHelmApplicationId()) if err != nil && !apierrors.IsNotFound(err) { return nil, err } ctg, _ := c.ctgLister.Get(apps[i].GetHelmCategoryId()) items = append(items, convertApp(apps[i], versions, ctg, 0)) } return &models.PageableResponse{Items: items, TotalCount: totalCount}, nil}// line 601func (c *applicationOperator) listApps(conditions *params.Conditions) (ret []*v1alpha1.HelmApplication, err error) { repoId := conditions.Match[RepoId] if repoId != "" && repoId != v1alpha1.AppStoreRepoId { // get Helm application from Helm repo if ret, exists := c.cachedRepos.ListApplicationsByRepoId(repoId); !exists { klog.Warningf("load repo failed, repo id: %s", repoId) return nil, loadRepoInfoFailed } else { return ret, nil } } else { if c.backingStoreClient == nil { return []*v1alpha1.HelmApplication{}, nil } ret, err = c.appLister.List(labels.SelectorFromSet(buildLabelSelector(conditions))) } return}缓存具体获取应用逻辑func (c *cachedRepos) ListApplicationsByRepoId(repoId string) (ret []*v1alpha1.HelmApplication, exists bool) { c.RLock() defer c.RUnlock() if repo, exists := c.repos[repoId]; !exists { return nil, false } else { ret = make([]*v1alpha1.HelmApplication, 0, 10) for _, app := range c.apps { if app.GetHelmRepoId() == repo.Name { // 利用的仓库ID雷同则追加 ret = append(ret, app) } } } return ret, true}既然 app template 是从缓存中获取的,那么缓存中的数据又是什么时候录入的呢? ...

June 25, 2021 · 9 min · jiezi

关于云计算:存储大师班NFS-的诞生与成长

作者| QingStor 黄蒙 <center><font color=#00a971 size=5>咱们为什么须要 “网络文件协定”</font></center>存储文件是大家日常工作生存中最常见的需要,随着文件数量和占用存储空间的回升,以及在肯定范畴内共享拜访文件的需要产生,咱们天然须要把存储文件的工作从单个计算机设备中剥离进去,作为一个独自的服务资源(或物理硬件)来对外提供存储性能,提供更大的容量的同时,为多个终端通过网络共享拜访。 这里提到的存储设备就是咱们常说的 NAS(Network Attached Storage:网络从属存储)。 <center>常见 NAS 架构</center> 而终端通过网络来共享拜访 NAS,须要规范的协定标准。NFS 就是其中最重要也是利用最宽泛的协定规范之一(其它风行的网络文件协定还有 SMB[1] 协定,后续会有专门的文章进行介绍,尽请期待)。明天咱们就来聊聊 NFS 协定。 <center><font color=#00a971 size=5>一直倒退的 NFS</font></center><font color=#262626 size=3>1. 简略好用的无状态协定诞生</font>NFS 第一次呈现在咱们的视线中,是在 1985 年。NFS version2 作为 SunOS 2.0 的组件正式公布。所以在过后把它叫做 “Sun 网络文件系统” 可能更为贴切。另外,你没有看错,第一个正式对外公布的版本就是 v2 版本(v1 版本从未对外正式公布,这也是咱们从不探讨 NFS v1 的起因)。 不过 NFS 并不是最早的网络文件系统,彼时曾经有一些更早的网络文件系统存在,比方 UNIX SVR3 零碎中蕴含的 RFS(Remote File System)[2] RFS 曾经引入了 RPC(Remote Procedure Call)概念,并成为 NFS v2 的借鉴的范本。但 RFS 也有本人显著的问题,比方其为每个客户端关上文件记录状态(即有状态协定),所以很难应答服务端宕机或重启的状况。NFS v2 为了在设计层面很好的解决 RFS 的缺点,设计成了一个齐全无状态的协定。 1995 年,NFS v3 正式公布。此时 NFS 协定的开发曾经不再齐全依赖 Sun 公司,而是多家公司独特主导实现. NFS v3 蕴含泛滥优化,但大多数能够认为是性能层面的优化。总体看来,NFS v3 依然遵循无状态协定的设计。 ...

June 24, 2021 · 2 min · jiezi

关于云计算:开启-Calico-eBPF-数据平面实践

简介Calico 从 v3.13 开始,集成了 eBPF 数据立体。 对于什么是 eBPF, 以及 Calico 为什么引入了 eBPF , 并不是本篇文章的重点,感兴趣的敌人能够自行浏览相干文档。 相比于 Calico 的默认基于 iptables 数据立体,eBPF 具备更高的吞吐量以外, 还具备 source IP preservation 这个性能。 在 K8s 中通常都是间接或者间接以 NodePort 形式对外裸露接口的。而对于 K8s 这个分布式集群来讲,通常状况下,客户端连贯 Node Port 端口的节点和负责响应申请的后端业务 Pod 所在的节点不是同一个节点,为了买通整个数据链路,就不可避免的引入了 SNAT。然而这样显然也会带来一个副作用,即业务 Pod 在收到 Packet 当前,其 SRC IP 曾经不再是客户端的理论 IP(被伪装成节点的内网 IP )。另一方面,对于一些业务利用来讲,获取客户端 IP 是一个实实在在的刚需。比方:业务利用须要通过客户端 IP 来获取客户登陆的 geo 信息。 目前 K8s 次要是通过设置 externaltrafficpolicy 来躲避这个问题的,然而这个计划自身并不能齐全令人满意。Calico 从 v3.13 开始通过集成 eBPF 优雅地解决了这个问题。 在本篇文章中,咱们将首先演示通过 KubeKey 创立一个规范的 K8s 集群,并切换数据立体到 eBPF,最初基于该数据立体做一个简略的演示。 ...

June 24, 2021 · 2 min · jiezi

关于云计算:浪潮云说丨叮这是一份浪潮云物联网平台的简历请查收

通过十几年的倒退历程,物联网的倒退动能继续丰盛,技术和利用翻新不断涌现,作为撑持数字经济倒退的要害基础设施,物联网高速倒退已成必然趋势。依据GSMA公布的《The mobile economy 2020》报告显示,2019年寰球物联网总连接数达到120亿,其中,我国物联网连接数高达36.3亿,占30%,预计到2025年将达到80.1亿,年复合增长率14.1%。以车联网、城市服务、智慧农业、智慧工业、医疗衰弱、水务电力等为代表的传统产业畛域内物联网连接数增长迅速。 在行业需要驱动引发的物联感知畛域的微小改革中,浪潮云物联网平台大有可为。 是什么?浪潮云物联网平台(简称浪潮云IoT平台),是一个平安、稳固、高效的物联网平台,可能帮忙物联网畛域的开发者疾速且低成本的实现设施接入、设施治理、数据解析、事件检测、存储计算以及剖析利用等物联网利用开发;可能赋能物联网利用开发商和生态合作伙伴,实现终端与云端的双向数据通道,助力智能物联网利用翻新。 能干什么?浪潮云IoT平台的次要性能如下: 有何劣势?企业基于物联网通过经营设施数据实现效益晋升已是行业趋势、业内共识。浪潮云IoT平台为解决传统企业面向物联网、工业互联网转型过程中遇到的各类妨碍,提供一系列的解决方案,助力企业实现通过经营设施数据升高经营老本、寻求新的盈利模式及经济增长点。浪潮云IoT平台产品劣势: 用在哪里? 利用场景1——设施监控浪潮云IoT平台可能撑持预测培修、近程运维、故障诊断等设施监控性能的实现,满足数控机床厂家近程监控机床在用户现场的运行状况、监测机床要害参数的须要,实现故障疾速响应,缩小现场培修次数,升高数控机床客户故障培修工夫、非打算停机次数、预测故障产生概率,进步机床的无效运行工夫,进步投资回报率。 利用场景2——能源管理浪潮云IoT平台面向企业用户在S-平安用能、E-经济用能、M-用能精细化治理等方面提供智慧能源管理云服务,撑持电气运检治理、售电信息化治理、用电平安预警等智慧能源管理利用,帮忙企业升高用能损耗、防止力调电费罚款、优化节能降耗,保障企业用能平安。 利用场景3——智慧交通交通被认为是物联网最有前景的利用场景之一,智慧交通是物联网在交通畛域利用的体现模式,通过集成先进的信息技术、数据传输技术以及计算机解决等技术到交通运行体系中,使人、车和路可能紧密配合,改善交通运输环境、保障交通安全、进步资源利用率。浪潮云IoT平台可能赋能智慧交通的八大利用场景: 利用场景4——智慧园区智慧园区是集感知、传输、记忆、判断和决策于一体的综合智能化解决方案。面向新园区,浪潮云IoT平台撑持提供基于物联网的整套解决方案;针对老园区,整合园区已有的电梯、门禁、消防设备、视频等物联设施,革新无奈近程监测管制的设施,减少感知设施,综合集成,全面晋升园区智能化治理与保障程度。 面向未来,5G、物联网、区块链等新一代信息技术正减速融入千行百业,浪潮云物联网平台将通过自主研发、科技翻新、场景利用、价值经营的交融倒退,与生态合作伙伴独特输入创新能力和产品,助力政企客户实现价值晋升。

June 24, 2021 · 1 min · jiezi

关于云计算:kubebuilder实战之四operator需求说明和设计

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 系列文章链接kubebuilder实战之一:筹备工作kubebuilder实战之二:首次体验kubebuilderkubebuilder实战之三:基础知识速览kubebuilder实战之四:operator需要阐明和设计kubebuilder实战之五:operator编码kubebuilder实战之六:构建部署运行kubebuilder实战之七:webhookkubebuilder实战之八:知识点小记本篇概览作为《kubebuilder实战》系列的第四篇,经验了后面的充分准备,从本篇开始,咱们来开发一个有理论作用的operator,该operator名为<font color="blue">elasticweb</font>,既弹性web服务;这将是一次残缺的operator开发实战,设计、编码、部署等环节都会参加到,与《kubebuilder实战之二:首次体验kubebuilder》的不同之处在于,elasticweb从CRD设计再到controller性能都有明确的业务含意,能执行业务逻辑,而《kubebuilder实战之二》仅仅是一次开发流程体验;为了做好这个operator,本篇不急于编码,而是认真的做好设计工作,咱们的operator有什么性能,解决了什么问题,有哪些核心内容,都将在本篇整顿分明,有了这样的筹备,能力在下一章写出符合要求的代码;接下来咱们先聊一些背景常识,以便更好的进入正题;需要背景QPS:Queries-per-second,既每秒查问率,就是说服务器在一秒的工夫内解决了多少个申请;背景:做过网站开发的同学对横向扩容应该都理解,简略的说,假如一个tomcat的QPS下限为500,如果内部拜访的QPS达到了600,为了保障整个网站服务质量,必须再启动一个同样的tomcat来独特摊派申请,如下图所示(简略起见,假如咱们的后盾服务是无状态的,也就是说不依赖宿主机的IP、本地磁盘之类): 以上是横向扩容惯例做法,在kubernetes环境,如果内部申请超过了单个pod的解决极限,咱们能够减少pod数量来达到横向扩容的目标,如下图: 以上就是背景信息,接下来咱们聊聊elasticweb这个operator的具体性能;需要阐明为了说分明需要,这里虚构一个场景:小欣是个java开发者,就是下图这个妹子: 当初小欣要将springboot利用部署到kubernetes上,她的现状和面临的问题如下:springboot利用已做成docker镜像;通过压测得出单个pod的QPS为500;估算得出上线后的总QPS会在800左右;随着经营策略变动,QPS还会有调整;总的来说,小欣手里只有三个数据:docker镜像、单个pod的QPS、总QPS,她对kubernetes不理解,须要有个计划来帮她将服务部署好,并且在运行期间能撑持内部的高并发拜访;以上就是小欣的需要了,咱们来小结一下: 咱们为小欣开发一个operator(名为<font color="blue">elasticweb</font>),对小欣来说,她只有将手里的三个参数(docker镜像、单个pod的QPS、总QPS)通知elasticweb就完事儿了;elasticweb在kubernetes创立pod,至于pod数量当然是主动算进去的,要确保能满足QPS要求,以后面的状况为例,须要两个pod能力满足800的QPS;单个pod的QPS和总QPS都随时可能变动,一旦有变,elasticweb也要主动调整pod数量,以确保服务质量;为了确保服务能够被内部调用,咱们再顺便帮小欣创立好service(她对kubernetes理解不多,这事儿咱们就棘手做了吧);自保申明看过上述需要后,聪慧的您肯定会对我投来鄙视的眼光,其实kubernetes早就有现成的QPS调节计划了,例如批改deployment的正本数、单个pod纵向扩容、autoscale等都能够,本次应用operator来实现仅仅是为了展现operator的开发过程,并不是说自定义operator是惟一的解决方案;所以,如果您感觉我这种用operator实现扩容的形式很low,<font color="red">请不要把我骂得太惨</font>,我这也只是为了展现operator开发过程而已,况且咱这个operator也不是一无是处,用了这个operator,您就不必关注pod数量了,只有聚焦单实例QPS和总QPS即可,这两个参数更贴近业务;为了不把事件弄简单,<font color="blue">假如每个pod所需的CPU和内存是固定的</font>,间接在operator代码中写死,其实您也能够本人改代码,改成能够在内部配置,就像镜像名称参数那样;把需要都交代分明了,接下来进入设计环节,先把CRD设计进去,这可是外围的数据结构;CRD设计之Spec局部Spec是用来保留用户的期望值的,也就是小欣手里的三个参数(docker镜像、单个pod的QPS、总QPS),再加上端口号: image:业务服务对应的镜像port:service占用的宿主机端口,内部申请通过此端口拜访pod的服务singlePodQPS:单个pod的QPS下限totalQPS:以后整个业务的总QPS对小欣来说,输出这四个参数就完事儿了;CRD设计之Status局部Status用来保留理论值,这里设计成只有一个字段<font color="blue">realQPS</font>,示意以后整个operator理论能反对的QPS,这样无论何时,只有小欣用<font color="blue">kubectl describe</font>命令就能晓得以后零碎实际上能反对多少QPS;CRD源码把数据结构说明确的最好办法就是看代码:package v1import ( "fmt" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "strconv")// 冀望状态type ElasticWebSpec struct { // 业务服务对应的镜像,包含名称:tag Image string `json:"image"` // service占用的宿主机端口,内部申请通过此端口拜访pod的服务 Port *int32 `json:"port"` // 单个pod的QPS下限 SinglePodQPS *int32 `json:"singlePodQPS"` // 以后整个业务的总QPS TotalQPS *int32 `json:"totalQPS"`}// 理论状态,该数据结构中的值都是业务代码计算出来的type ElasticWebStatus struct { // 以后kubernetes中理论反对的总QPS RealQPS *int32 `json:"realQPS"`}// +kubebuilder:object:root=true// ElasticWeb is the Schema for the elasticwebs APItype ElasticWeb struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty"` Spec ElasticWebSpec `json:"spec,omitempty"` Status ElasticWebStatus `json:"status,omitempty"`}func (in *ElasticWeb) String() string { var realQPS string if nil == in.Status.RealQPS { realQPS = "nil" } else { realQPS = strconv.Itoa(int(*(in.Status.RealQPS))) } return fmt.Sprintf("Image [%s], Port [%d], SinglePodQPS [%d], TotalQPS [%d], RealQPS [%s]", in.Spec.Image, *(in.Spec.Port), *(in.Spec.SinglePodQPS), *(in.Spec.TotalQPS), realQPS)}// +kubebuilder:object:root=true// ElasticWebList contains a list of ElasticWebtype ElasticWebList struct { metav1.TypeMeta `json:",inline"` metav1.ListMeta `json:"metadata,omitempty"` Items []ElasticWeb `json:"items"`}func init() { SchemeBuilder.Register(&ElasticWeb{}, &ElasticWebList{})}业务逻辑设计CRD的实现代表外围数据结构曾经确定,接下来是业务逻辑的设计,次要是理分明controller的Reconcile办法外面做些啥,其实外围逻辑还是非常简单的:算出须要多少个pod,而后通过更新deployment让pod数量达到要求,在此外围的根底上再把创立deployment和service、更新status这些琐碎的事件做好,就完事儿了;这里将整个业务逻辑的流程图给进去如下所示,用于领导开发: ...

June 24, 2021 · 1 min · jiezi

关于云计算:中国政府大数据市场我们又是第一

近日,赛迪参谋正式公布《2020-2021年中国政府大数据市场钻研报告》,数据显示,浪潮在市场位置与倒退能力方面,双双位居第一位! 赛迪参谋在报告中指出,随着政府数据量一直减少,数据共享凋谢水平越来越高,数据利用场景更加多元化,大数据与云计算、人工智能、区块链等新技术一直交融,为政府决策与服务能力的晋升提供无力撑持。2020年中国政府大数据市场仍然保持良好的增长态势,整体规模达到405.7亿元,增速为27.6%,其中浪潮持续领跑政府大数据市场政务畛域,在主营业务支出和技术创新方面均有不错的体现。 作为政府大数据市场较早的布局者,浪潮围绕数据汇聚、数据治理、数据共享、数据利用四部曲,在国内率先提出“政府数据凋谢五级技术成熟度模型”,造成了“平台+产品+服务”的数据治理计划,屡次参加起草政务数据国家标准,全面反对政府数据业务服务化转型。2020年浪潮撑持公布的“疫情数据查问核验服务”,无效助力了衰弱码全国互信,服务调用超过1000亿次,日增调用量最高达到2亿次,充沛实现了数据价值的智能化利用。 目前,浪潮正在踊跃推动国家数据开放平台和各地政府数据开放平台的布局建设工作,作为国内惟一具备独自的政府数据开放平台产品线的厂商,浪潮积极探索政府数据凋谢、社会化利用和翻新,已胜利为全国100多个省(区、市)政府建设大数据平台,实现了数据的共享共用,为山东、宁夏、广西、重庆、广州、成都、哈尔滨、佛山、济南、青岛等省(区、市)提供数据服务,为放慢推动政府数据共享凋谢、数据流通以及利用翻新注入了全新生机。

June 23, 2021 · 1 min · jiezi

关于云计算:融合云Unified-IaaS面向未来的IT基础设施架构选择

作者介绍:邱剑,云联万维(Yunion)CTO,清华本硕,前美团云架构师和技术外围,率领团队实现了美团云最早的技术选型、架构设计和代码交付。 随着数字化时代的到来,IT零碎已成为人类社会失常运行不可或缺的组成部分。不远的将来,智能制作,5G和人工智能等技术将成为推动生产力倒退的重要引擎,人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT零碎运行的平台和载体,是实现数字化的基石。在这场数字化浪潮中,企业必须踊跃拥抱云计算技术,采纳合乎技术发展趋势、面向未来的IT根底构架,能力在将来的竞争中博得先机。 一、云计算历经十余年倒退的趋势判断 云计算技术自2006年AWS推出第一个私有云服务S3开始,倒退到2019年的明天,一些格局和趋势开始逐渐清晰: 首先,公有云仍然是大中型企业以及一些细分行业,例如政务、金融、医疗、教育、能源和制作等的首选IT基础设施。随着各大公有云厂商陆续推出其私有云在政企客户私有化部署的扩大计划,例如AWS Outposts、Azure Stack,Google Anthos,以及国内阿里云、腾讯云等的公有云/专有云部署计划,“公有云是否会随着私有云的倒退逐渐沦亡”的命题已被私有云厂商本人否定。事实证明,公有云将长期继续存在,将和私有云共生,成为企业IT基础设施的一个重要组成部分。 其次,私有云继续迅猛发展,逐渐成为企业IT基础设施的次要提供者。2018年Q3云硬件收入占IT总收入的50.9%。2018年中国公有云基础架构收入38.0亿美元,私有云基础架构收入达到82亿美元(起源:IDC)。因而,私有云曾经成为IT基础设施的最次要提供者。尤其对于中小企业而言,其IT基础设施可能齐全构建在私有云之上。同时,一些处于技术当先行业的大型企业,例如互联网,金融,制作等,也曾经开始应用私有云,摸索联合私有云和公有云劣势的混合云架构。 与此同时,私有云市场竞争异样强烈,最初将只剩下多数技术和资本都非常雄厚的玩家,进入寡头垄断市场阶段。一方面,私有云厂商提供的产品和服务实质雷同,都是IT基础设施资源以及其上的软件服务,另一方面,各家厂商都竭力欠缺本身产品,丰盛产品线,做出特色,以取得竞争劣势,吸引增量用户,防止存量用户的散失。因而,最终私有云提供的产品性能矩阵都根本趋同,然而在特色性能、区域笼罩、用户体验方面则各有千秋,差别很大。随着用户对私有云产品服务依赖的加深,私有云之间的服务切换和迁徙将变得越来越难,云和云之间存在隐形的鸿沟。当然,私有云进入寡头垄断阶段也意味着私有云供应商列表将长期保持绝对稳固,这意味着针对所有私有云API的适配老本将变得可控可行。 还有一个不容忽视的趋势是Kubernetes已成为容器编排的事实标准,逐渐成为云原生时代利用部署和运行的规范环境。随着Kubernetes对存储、网络反对的逐步完善,不仅无状态服务能够在Kubernetes上部署运行,有状态的数据存储服务也能够在Kubernetes上运行。同时,基于Kubernetes之上曾经倒退出了一个凋敝并且弱小的开源软件生态和残缺的工具链,例如Helm实现软件套件的主动部署,Operator实现软件的自动化运维,lstio提供微服务RPC通信治理架构,Knative提供Serverless的运行框架等等。能够预感,Kubernetes将成为将来分布式应用的规范运行时环境,成为分布式应用时代的“Linux”。Kubernetes之上将构建出一个齐全由开源软件主导的软件生态,不仅仅蕴含应用软件,还蕴含各种PaaS中间件,例如消息中间件,各类开源数据库,开发框架,AI训练框架等,真正实现"开源统治世界"的愿景。正是基于这个趋势判断,各大公有云厂商都相继推出了本人的Kubernetes解决方案,容许原生Kubernetes在本人的云平台上更高效运行。 二、企业将来IT基础设施的确定和不确定 基于这些事实和趋势,咱们能够设想将来的企业IT基础设施将是这样: 首先,混合云架构是企业的最佳抉择。 未来企业的IT基础设施计划,私有云和公有云不再是二选一的选项,而是一个残缺的IT基础设施的两个必然组成部分。一方面,企业可能会有本人的公有云,但也存在一些齐全运行在私有云的企业。另一方面,企业必然会应用私有云,其购买的私有云资源将成为其公有IT基础设施的一部分。 其次,Kubernetes将会成为企业云原生利用的规范运行环境。 就像企业明天企业应用都运行在Linux中一样,未来的企业服务将云原生化,散布化,运行在Kubernetes中。企业将会有若干Kubernetes集群,运行着不同的利用,散布在不同的基础设施之上,有的运行在本地IDC,有的运行在公有云,有的运行在私有云。 以上两点是公认比拟确定的论断,然而还有其余很多问题目前没有确定性的论断,例如: 1、尽管应用私有云是企业必然的抉择,然而企业会在应用多个私有云还是繁多私有云进行抉择。采纳多私有云计划的起因很多,收益也不言而喻,例如防止供应商锁定,进步议价的能力,取得更丰盛的性能个性和地区抉择等。但同时,应用多个私有云资源的对立治理难度大,云间服务切换和迁徙老本较高的问题则妨碍了用户抉择多个私有云。 2、尽管云计算技术倒退了十多年,然而仍然有很大比例的企业的本地IT基础设施并未云化,既没有通过公有云治理,甚至都没有采纳虚拟化技术。尽管将来的云原生利用将运行在Kubernetes的容器环境中,然而企业还有很多未容器化的传统利用。而且,捕风捉影地讲,对于大多数企业来讲,兴许将来很长一段时间,仍然是以非云原生的传统利用为主。因而,企业将来的IT基础设施并不能简略地假如为全副都归一化地运行Kubernetes,而是应该给这些传统利用提供运行所需的虚拟机或者裸机环境。这类企业云转型过程中是否还是须要通过公有云-混合云-多云的漫长门路,再部署一套公有云实现本地IT基础设施的云化? 3、一方面,随着业务倒退和行业驱动,企业对IT基础设施的要求,无论是规模、效率还是稳定性都将越来越刻薄。麻利开发和DevOps将成为企业的标配。另一方面,随着技术的倒退,企业IT基础设施也将愈发简单和难以驾驭。企业IT资源将不仅是物理服务器,还有虚拟机,容器,除了x86,还会有小型机、ARM,甚至还有GPU、FPGA、TPU等异构计算资源。网络和存储也有多种技术抉择。同时,截止今日,仅支流私有云供应商在寰球200多个区域500多个可用区提供上千种云产品和服务。只有企业违心,一个寰球规模的IT基础设施唾手可得。企业IT人员如何应答IT基础设施在规模、效率和复杂度方面的挑战? 4、即便将来的企业IT基础架构将收敛到齐全运行在Kubernetes上,单个Kubernetes集群往往只用于一个繁多特定目标,例如特定部门的测试或生产集群,企业内有多个Kubernetes集群是常态。治理多Kubernetes集群,尤其是部署在多云环境下的多Kubernetes集群仍然是一个难题。尽管Kubernetes屏蔽了底层基础设施的差别,向上提供了统一的接口和运行环境,然而Kubernetes在各个私有云以及本地IDC的治理接口以及网络存储计划都没有对立,在新建、扩容和调整配置Kubernetes集群时候,仍然面临对接多个供应商接口的问题。同时,散布在多个私有云上的Kubernetes集群之间没有买通,不仅管制信息无奈同步,数据链路层面更是互相隔离,互为孤岛。因而无奈实现多个集群的联动,更无奈实现集群之间的切换和协同。多云环境下的Kubernetes集群计划仍然有待摸索。  5、随着Kubernetes生态的欠缺,用户在私有云上应用PaaS服务将有两个抉择:应用私有云提供的PaaS服务还是基于Kubernetes的云原生开源PaaS服务。前者产品化水平高,更加易于应用,能失去商业反对。但也存在被商业产品锁定,切换艰难,应用费用昂扬的问题。应用后者则须要对开源软件有肯定掌控力,然而价格便宜(云主机的使用费),基于开源技术,有弱小社区反对,架构凋谢灵便且易于扩大。 三、交融云(Unified IaaS),面向未来的IT基础设施架构抉择 针对以上确定性论断和不确定问题,咱们的答案是面向未来的IT基础设施架构治理的最佳抉择是交融云(Unified IaaS)。顾名思义,所谓交融云就是交融治理散布在多云环境(本地IDC,公有云和私有云)中的所有IT基础设施,构建一个“云上之云”的交融IaaS平台。交融云实质上是公有云,然而治理的IT资源的范畴不再局限于本地IDC,还包含企业在私有云购买的IaaS资源。对于纯私有云架构的企业,交融云治理的则齐全是企业购买的私有云资源。交融云和传统云平台的区别不在于治理的资源范畴的不同,而在于针对上述企业IT的发展趋势和问题,在设计理念上,交融云和传统的云平台有如下不同: 首先,交融云面向的是多云环境。 交融云的部署场景中,企业用户IT基础设施不仅蕴含部署在本地IDC的局部,还蕴含用户在私有云购买的局部。交融云通过一个平台治理企业所有的IT基础设施。首先是在治理立体的对立和交融,实现公有云和私有云资源的对立API拜访,不仅实现资源的治理,还包含账单的对立,资源管理的对立。让用户跨云调用就像应用一个云平台一样的便当。其次是数据立体的买通,通过和跨云网络计划的整合,实现管制立体和数据平台的协同,达到整个平台的跨云内网的互通。另外,交融云还将提供跨云数据迁徙的工具,不便用户实现跨云的利用迁徙。总之,交融云的指标就是填补云和云之间的鸿沟,升高跨云切换和迁徙的老本,让多云部署更简略。 其次,交融云实现企业整体异构IT基础设施的全面云化。 交融云不仅能治理曾经云化的公有云和私有云资源,还需内置了治理裸机的裸金属云,KVM和VMware ESXi等虚拟化技术、以及ARM,GPU等计算资源的公有云技术。对于还没有部署公有云的企业,通过部署交融云,一步到位地实现企业公有IT基础设施的公有云化,实现裸金属、KVM、VMware ESXi、GPU等的云化治理,无需再引入额定的公有云计划,升高了企业上云的施行老本和治理复杂度。 第三,智能将是交融云的外围特色。 交融云一方面优化IT资源分配的调度策略,找出闲置节约的IT资源,晋升IT资源的利用率。另一方面提前预测资源需要和发现系统故障隐患,确保零碎的安稳运行和扩大。通过数据和算法,使得IT基础设施更加智能,帮忙企业IT人员驾驭将来的IT基础设施在规模、效率和复杂度方面的挑战。  第四,交融云面向的是Kubernetes。 交融云一方面实现多云环境下Kubernetes底层基础设施的对立和交融。一是通过对立的API为Kubernetes提供多云环境下对立的IaaS接口,为跨云部署Kubernetes环境提供便当。二是在数据立体买通跨云Kubernetes的内网,实现跨云通信。另一方面则间接提供对立的Kubernetes集群管理控制API以及集群信息的同步机制,实现跨集群Kubernetes的对立管控,实现跨Kubernetes集群的账号、权限、配置的同步和对立。 最初,交融云全面拥抱开源技术。 软件倒退的历程表明PaaS的将来是开源。供应商都无奈仅凭一己之力满足企业客户所有的PaaS需要。因而,交融云聚焦于企业散布在本地IDC和私有云的计算、网络和存储IaaS资源的对立治理,为多云Kubernetes提供牢靠的底层基础设施,Kubernetes之上的软件和利用需要则依赖开源生态来提供解决方案。交融云用户对PaaS的需要通过Kubernetes利用市场,通过整合开源PaaS利用向用户提供服务。这一方面升高用户应用开源PaaS的技术门槛,另一方面则依赖弱小的开源社区给用户提供凋谢灵便丰盛的软件产品,防止公有PaaS软件对用户的锁定。 基于以上的构想,交融云的架构如下所示。 向下:交融云对立治理多云基础设施,次要实现多云环境下计算、网络、存储等IaaS资源的对立治理。对于本地IDC的未云化资源,次要是裸机,KVM虚拟机(Libvirt),VMware ESXi虚拟机(vSphere),通过内置的公有云计划实现云化治理。对于公有云和私有云资源,则通过API实现对立治理。 向上:交融云一方面通过虚拟机、裸机等模式为传统利用提供残缺操作系统运行时环境,另一方面则给Kubernetes提供多云运行环境,对立治理多云Kubernetes。在Kubernetes之上则提供云原生利用的容器运行时环境。同时,基于Kubernetes和开源组件提供PaaS中间件服务。 总之,交融云向下对立治理多云IaaS资源;向上为Kubernetes提供多云反对,通过开源生态满足企业PaaS需要;用户其余需要则能够通过拜访私有云的原生服务取得,从而全方位满足将来企业对IT基础设施的多层次需要。 随着大数据、人工智能技术的遍及,5G时代的到来,IT基础设施变得更加重要,成为企业数字化转型,全面拥抱数字时代的基石。基于企业IT架构多云趋势,交融云应运而生。交融云是面向未来的企业IT基础设施治理的云平台,针对企业在将来IT基础架构的问题而设计,将帮忙企业迎接行将到来的数字化转型的挑战。

June 21, 2021 · 1 min · jiezi

关于云计算:浪潮云说-开源新势力云溪数据库ZNBase

随着云计算、大数据、AI、5G、量子计算等新兴技术的迅猛发展,社会各行业均面临着海量数据、高并发、超高峰值等场景的微小冲击。裸露如下痛点 传统关系型数据库遭逢“程度扩大”瓶颈,在海量数据时代,体现非常疲软;数据库单机故障,失落数据无奈找回,更是粗茶淡饭;Hadoop体系简单,组件泛滥,保护老本高,数据流转提早显著;面对上述痛点,“云溪数据库ZNBase”应运而生!知道不?ZNBase何方神圣?ZNBase采纳业界当先的对等分布式架构,兼具云原生、强统一、横向扩大、多核心部署、安全可靠、高可用等低劣个性,并附加部署、备份、容灾、监控等全套工具。彻底解决了传统数据库在高并发、实时交易和简单场景实时剖析等场景下的低迷体现。ZNBase砥砺前行,拥抱开源凋谢原子开源基金会由工信部于2020年6月15日成立,目前一共收到6大团体的8个我的项目,其中浪潮的ZNBase云原生分布式数据库就是8个我的项目之一。ZNBase产品性能ZNBase是一款成熟的高性能数据库,在浪潮云官网提供了全套治理服务。 实例治理:实例创立、实例删除(按需)、实例减少节点、实例存储扩容灵便的购买形式:反对用户按需付费和包年包月备份还原:反对手动备份实例,备份文件还原参数治理:反对参数信息列表、参数批改、最近批改记录监控告警:反对实例级别的监控告警ZNBase劣势之所在 国产化平台兼容,自主可控建设开源社区,构建生态体系分布式存储与运算,实现数据集中管理反对Spark、Flink等组件对接,助力决策分析云原生设计,适应多租户业务隔离建设跨区域多核心,保障数据同步、业务同步ZNBase之利用场景 金融级商业数据库利用场景ZNBase 数据库系统基于分布式数据库架构设计,可在通用 x86 服务器撑持起上亿的用户拜访,并且残缺反对分布式事务、强统一、多正本高可用 多地部署异地多活场景ZNBase 数据库系统具备原生数据强一致性的独特劣势,反对对立部署,数据天文分区,能够满足“地方-中央”多级多地部署需要 海量数据存储拜访场景ZNBase 数据库系统反对节点疾速弹性实现垂直、程度扩大缩容,存储容量最大到 4EB,齐全满足用户的海量数据存储和查问要求 HTAP 混合场景ZNBase数据库系统充沛实现了HTAP (Hybrid Transactional and Analytical Processing, HTAP) 解决方案,能做到针对同样数据的 OLTP 与 OLAP 业务同时运行且互不烦扰

June 21, 2021 · 1 min · jiezi

关于云计算:再添新誉浪潮云斩获年度领先品牌等多项殊荣

6月16日-18日,由宁波市人民政府领导、Informa Markets主办的第九届寰球云计算大会·中国站(Cloud Connect China 2021 )在宁波举办。会议期间,第八届“云鼎奖”获奖名单揭晓,浪潮云斩获“2020-2021年度当先品牌奖”、浪潮云副总经理王闰生斩获“2020-2021年度云计算行业影响力人物奖”。据悉,此次大会以“新技术赋能双循环倒退”为主题,聚焦数字化平台助力企业转型倒退案例,分享行业技术资讯,探讨云计算最新发展趋势,全面展示云计算产业在寰球及国内的倒退及利用前景。作为每年寰球云计算大会·中国站的外围流动,“云鼎奖”(Top Cloud Connect Awards)旨在表彰年度对中国云计算产业做出突出贡献和具备翻新精力的个体、集体,进而促成云计算在中国衰弱、疾速、有序倒退。在国家大力发展新基建的浪潮下,数据成为根底战略性资源和重要生产因素,以云计算为代表的信息技术正在新基建中施展着不可或缺的作用。基于在分布式云畛域的摸索和实际,5月17日浪潮云正式公布“1231”业务策略,即1个对立架构、2个要害畛域、3项交融能力、1个平安体系。作为中国分布式云的引领者,浪潮云致力于成为高品质云服务提供商,具备“业余、生态、可信赖”三大外围劣势。为客户提供云网边端交融、云数智交融、建管运交融的全栈云服务,构建零信赖的云数平安体系,打造新一代混合云。此外,基于分布式云的能力,浪潮云还重磅推出“分布式云+”行动计划——1+2+N+生态,即打造一朵分布式云,聚焦数字政府和工业互联网2大重点畛域。浪潮云此举,充分发挥了云计算+大数据的能力禀赋,受到行业、政企客户及合作伙伴高度认可。将来,浪潮云将持续加大在云计算、大数据畛域的科研和市场投入,以翻新技术和当先理念,向成为高品质云服务运营商指标迈进。依靠浪潮云丰盛的产品体系以及本身多年来积攒的技术劣势与实践经验,赋能企业数字化转型,联合新生态实现数据价值最大化,全面助推数字中国建设指标实现。

June 18, 2021 · 1 min · jiezi

关于云计算:容器实践线路图

随着容器技术越来越炽热,各种大会上标杆企业分享容器化收益,带动其余还未施行容器的企业也在思考施行容器化。不过真要在本人企业实际容器的时候,会意识到容器化不是一个简略工程,甚至会有一种茫然不知从何动手的感觉。 本文总结了通用的企业容器化施行线路图,次要针对企业有存量零碎革新为容器,或者局部新开发的零碎应用容器技术的场景。不蕴含企业零碎从0开始全新构建的场景,这种场景绝对简略。<!--more--> 容器实际路线图企业着手实际容器的路线,倡议从3个维度评估,而后依据评估后果落地施行。3个评估维度为:商业指标,技术选型,团队配合。 商业指标是重中之重,须要答复为何要容器化,这个也是牵引团队在容器实际路上一直前行的能源,是遇到问题是解决问题的方向指引,最重要的是让决策者认同商业指标,并能理解到反对商业指标的技术原理,高低指标对齐才好办事。商业指标确定之后,须要确定容器相干的技术选型,容器是一种轻量化的虚拟化技术,与传统虚拟机比拟有长处也有毛病,要找出这些差别点辨认出对基础设施与利用的影响,提前辨认危险并采取应答措施。技术选型明确之后,在公司或部门外部推广与评审,让开发人员、架构师、测试人员、运维人员相干人员与团队了解与认同计划,听取他们意见,他们是间接应用容器的客户,不要让他们有埋怨。最初是落地策略,个别是选取一些辅助业务先试点,在实际过程中一直总结经验。商业指标容器技术是以利用为核心的轻量级虚拟化技术,而传统的Xen与KVM是以资源为核心的虚拟化技术,这是两者的实质差别。以利用为核心是容器技术演进的领导准则,正是在这个准则领导下,容器技术绝对于传统虚拟化有几个特点:打包既部署、镜像分层、利用资源调度。 打包即部署:打包即部署是指在容器镜像制作过程蕴含了传统软件包部署的过程(装置依赖的操作系统库或工具、创立用户、创立运行目录、解压、设置文件权限等等),这么做的益处是把利用及其依赖封装到了一个绝对关闭的环境,缩小了利用对外部环境的依赖,加强了利用在各种不同环境下的行为一致性,同时也缩小了利用部署工夫。镜像分层:容器镜像包是分层构造,同一个主机上的镜像层是能够在多个容器之间共享的,这个机制能够极大缩小镜像更新时候拉取镜像包的工夫,通常应用程序更新降级都只是更新业务层(如Java程序的jar包),而镜像中的操作系统Lib层、运行时(如Jre)层等文件不会频繁更新。因而新版本镜像本质有变动的只有很小的一部分,在更新降级时候也只会从镜像仓库拉取很小的文件,所以速度很快。利用资源调度:资源(计算/存储/网络)都是以利用为核心的,核心体现在资源分配是依照利用粒度分配资源、资源随利用迁徙。基于上述容器技术特点,能够推导出容器技术的3大应用场景:CI/CD、晋升资源利用率、弹性伸缩。这3个应用场景天然推导出通用的商业层面收益:CI/CD晋升研发效率、晋升资源利用率降低成本、按需弹性伸缩在体验与老本之间达成均衡。 当然,除了商业指标之外,可能还有其余一些思考因素,如基于容器技术实现计算任务调度平台、放弃团队技术先进性等。 CI/CD晋升研发效率为什么容器技术适宜CI/CDCI/CD是DevOps的要害组成部分,DevOps是一套软件工程的流程,用于继续晋升软件开发效率与软件交付品质。DevOps流程来源于制造业的精益生产理念,在这个畛域的领头羊是丰田公司,《丰田套路》这本书总结丰田公司如何通过PDCA(Plan-Do-Check-Act)办法施行继续改良。PDCA通常也称为PDCA循环,PDCA施行过程简要形容为:确定指标状态、剖析以后状态、找出与指标状态的差距、制订施行打算、施行并总结、开始下一个PDCA过程。 DevOps根本也是这么一个PDCA流程循环,很容易认知到PDCA过程中效率是要害,同一时间段内,施行更多数量的PDCA过程,收益越高。在软件开发畛域的DevOps流程中,各种期待(期待编译、期待打包、期待部署等)、各种中断(部署失败、机器故障)是影响DevOps流程效率的重要因素。 容器技术进去之后,将容器技术利用到DevOps场景下,能够从技术手段打消DevOps流程中的局部期待与中断,从而大幅度晋升DevOps流程中CI/CD的效率。容器的OCI规范定义了容器镜像标准,容器镜像包与传统的压缩包(zip/tgz等)相比有两个要害区别点:1)分层存储;2)打包即部署。 分层存储能够极大缩小镜像更新时候拉取镜像包的工夫,通常应用程序更新降级都只是更新业务层(如Java程序的jar包),而镜像中的操作系统Lib层、运行时(如Jre)层等文件不会频繁更新。因而新版本镜像本质有变动的只有很小的一部分,在更新降级时候也只会从镜像仓库拉取很小的文件,所以速度很快。 打包即部署是指在容器镜像制作过程蕴含了传统软件包部署的过程(装置依赖的操作系统库或工具、创立用户、创立运行目录、解压、设置文件权限等等),这么做的益处是把利用及其依赖封装到了一个绝对关闭的环境,缩小了利用对外部环境的依赖,加强了利用在各种不同环境下的行为一致性,同时也缩小了利用部署工夫。基于容器镜像的这些劣势,容器镜像用到CI/CD场景下,能够缩小CI/CD过程中的等待时间,缩小因环境差别而导致的部署中断,从而晋升CI/CD的效率,晋升整体研发效率。 CI/CD的要害诉求与挑战快开发人员本地开发调试实现后,提交代码,执行构建与部署,期待部署实现后验证性能。这个期待的过程尽可能短,否则开发人员工作容易被打断,造成结果就是效率升高。如果提交代码后几秒钟就可能实现部署,那么开发人员简直不必期待,工作也不会被打断;如果须要好几分钟或十几分钟,那么能够设想,这十几分钟就是节约了,这时候很容易做点别的事件,那么思路又被打断了。所以构建CI/CD环境时候,快是第一个须要思考的因素。要达到快,除了有足够的机器资源罢黜排队期待,引入并行编译技术也是罕用做法,如Maven3反对多核并行构建。 自定义流程不同行业存在不同的行业标准、监管要求,各个企业有一套外部品质标准,这些要求都对软件交付流程有定制需要,如要求应用商用的代码扫描工具做平安扫描,如构建后果与企业外部通信零碎对接发送音讯。在团队协同方面,不同的公司,对DevOps流程在不同团队之间分工有差别,典型的有开发者负责代码编写构建出构建物(如jar包),而部署模板、配置由运维人员负责;有的企业开发人员负责构建并部署到测试环境;有的企业开发人员间接能够部署到生产环境。这些不同的场景,对CI/CD的流程、权限管控都有定制需要。 晋升资源利用率OCI规范蕴含容器镜像规范与容器运行时规范两局部,容器运行时规范聚焦在定义如何将镜像包从镜像仓库拉取到本地并更新、如何隔离运行时资源这些方面。得益于分层存储与打包即部署的个性,容器镜像从到镜像仓库拉取到本地运行速度十分快(通常小于30秒,依赖镜像自身大小等因素),基于此能够实现按需分配容器运行时资源(cpu与内存),并限定单个容器资源用量;而后依据容器过程资源使用率设定弹性伸缩规定,实现主动的弹性伸缩。这种形式绝对于传统的按峰值配置资源形式,能够晋升资源利用率。 按需弹性伸缩在体验与老本之间达成均衡联动弹性伸缩利用运行到容器,按需分配资源之后,现实状况下,Kubernetes的池子里没有闲暇的资源。这时候扩容利用实例数,新扩容的实例会因资源有余调度失败。这时候须要资源池能主动扩容,退出新的虚拟机,调度新扩容的利用。因为利用对资源的配比与Flavor有要求,因而新退出的虚拟机,该当是与利用所须要的资源配比与Flavor统一的。缩容也是相似。弹性伸缩还有一个诉求点是“平滑”,对业务做到不感知,也称为“优雅”扩容/缩容。 申请风暴下面提到的弹性伸缩个别是有打算或迟缓增压的场景,存在另外一种无奈预期的申请风暴场景,这种场景的特色是无奈预测、忽然申请量增大数倍或数十倍、持续时间短。典型的例子如行情交易系统,当行情渐变的时候,用户访问量徒增,继续几十分钟或一个小时。这种场景的弹性诉求,要求短时间内能将资源池扩充数倍,要害是速度要快(秒级),否则会来不及扩容,零碎曾经被冲垮(如果有限流的话)。 目前基于 Virtual Kubelet 与云厂家的 Serverless 容器,实践上能够提供应答申请风暴的计划。不过在具体实施时候,须要思考传统托管式Kubernetes容器治理平台与Serverless容器之间互通的问题,须要基于具体厂家提供的能力来评估。 基于容器技术实现计算调度平台计算(大数据/AI训练等)场景的特色是短时间内须要大量算力,算完即开释。容器的环境一致性以及调度便利性适宜这种场景。 技术选型容器技术是属于基础设施范畴,然而与传统虚拟化技术(Xen/KVM)比拟,容器技术是利用虚拟化,不是纯正的资源虚拟化,与传统虚拟化存在差别。在容器技术选型时候,须要联合以后团队在利用治理与资源管理的现状,对照容器技术与虚拟化技术的差别,抉择最合适的容器技术栈。 什么是容器技术(1)容器是一种轻量化的利用虚拟化技术。 在探讨具体的容器技术栈的时候,先介绍目前几种罕用的利用虚拟化技术,以后有3种支流的利用虚拟化技术: LXC,MicroVM,UniKernel(LibOS)。 LXC: Linux Container,通过 Linux的 namespace/cgroups/chroot 等技术隔离过程资源,目前利用最广的docker就是基于LXC实现利用虚拟化的。MicroVM: MicroVM 介于 传统的VM 与 LXC之间,隔离性比LXC好,然而比传统的VM要轻量,轻量体现在体积小(几M到几十M)、启动快(小于1s)。 AWS Firecracker 就是一种MicroVM的实现,用于AWS的Serverless计算畛域,Serverless要求启动快,租户之间隔离性好。UniKernel: 是一种专用的(特定编程语言技术栈专用)、单地址空间、应用 library OS 构建进去的镜像。UniKernel要解决的问题是缩小应用软件的技术栈档次,古代软件档次太多导致越来越臃肿:硬件+HostOS+虚拟化模仿+GuestOS+APP。UniKernel指标是:硬件+HostOS+虚拟化模仿+APP-with-libos。三种技术比照表: 开销体积启动速度隔离/平安生态LXC低(简直为0)小快(等同过程启动)差(内核共享)好MicroVM高大慢(小于1s)好中(Kata我的项目)UniKernel中中中好差根据上述比照来看,LXC是利用虚拟化首选的技术,如果LXC无奈满足隔离性要,则能够思考MicroVM这种技术。以后社区曾经在着手交融LXC与MicroVM这两种技术,从利用打包/公布调度/运行层面对立标准,Kubernetes集成Kata反对混合利用调度个性能够理解一下。 UniKernel 在利用生态方面绝对比较落后,目前在追赶中,目前通过 linuxkit 工具能够在UniKernel利用镜像中应用docker镜像。这种形式笔者还未验证过,另外docker镜像运行起来之后,如何监控目前还未知。 从上述三种利用虚拟化技术比照,能够得出结论: (2)容器技术与传统虚拟化技术一直交融中。 再从标准视角来看容器技术,能够将容器技术定义为: (3)容器=OCI+CRI+辅助工具。 OCI标准蕴含两局部,镜像标准与运行时标准。简要的说,要实现一个OCI的标准,须要可能下载镜像并解压镜像到文件系统上组成成一个文件目录构造,运行时工具可能了解这个目录构造并基于此目录构造治理(创立/启动/进行/删除)过程。 容器(container)的技术形成就是实现OCI标准的技术汇合。 对于不同的操作系统(Linux/Windows),OCI标准的实现技术不同,以后docker的实现,反对Windows与Linux与MacOS操作系统。以后应用最广的是Linux零碎,OCI的实现,在Linux上组成容器的次要技术: chroot: 通过分层文件系统重叠出容器过程的rootfs,而后通过chroot设置容器过程的根文件系统为重叠出的rootfs。cgroups: 通过cgroups技术隔离容器过程的cpu/内存资源。namesapce: 通过pid, uts, mount, network, user namesapce 别离隔离容器过程的过程ID,工夫,文件系统挂载,网络,用户资源。网络虚拟化: 容器过程被搁置到独立的网络命名空间,通过Linux网络虚拟化veth, macvlan, bridge等技术连贯主机网络与容器虚构网络。存储驱动: 本地文件系统,应用容器镜像分层文件重叠的各种实现驱动,以后举荐的是overlay2。狭义的容器还蕴含容器编排,即当下很炽热的Kubernetes。Kubernetes为了把控容器调度的生态,公布了CRI标准,通过CRI标准解耦Kubelet与容器,只有实现了CRI接口,都能够与Kubelet交互,从而被Kubernetes调度。OCI标准的容器实现与CRI标准接口对接的实现是CRI-O。 ...

June 18, 2021 · 2 min · jiezi

关于云计算:停车场事故频频AI-达人将摄像头变身安全卫士

2021 年 2 月,“新内容 新交互” 寰球视频云翻新挑战赛启幕。本次大赛由英特尔联结阿里云主办,与优酷策略技术单干,天池平台和阿里云视频云团队独特承办。大赛自开赛以来,吸引了寰球超过 4600 名选手报名参赛,咱们遴选了参赛选手中优良案例和动人故事,一起走进视频云守业创新者的世界。 私家车,曾经成为了古代社会必不可少的交通工具。依据公安部统计,2020 年,全国机动车保有量达 3.72 亿辆,随着私家车数量的井喷,停车场安全事故也频频产生,特地是因为汽车盲区造成的儿童伤亡事故,成为了事实的安全隐患。依据 “中小学生交通安全教育课题组” 的剖析,孩子们在小区出入口、停车场、路侧停车区等区域产生事变的比例高达 17.1 %。 在本次的寰球视频云翻新挑战赛中,就有选手关注到了这一威逼儿童平安的社会痛点,来自山东青岛大学的刘宝印开发的智慧停车场零碎,就聚焦解决停车盲区的问题,以期缩小停车场喜剧的产生。 图片来源于网络 视频云 + AI,小小摄像头变身安全卫士通过一番实地察看,刘宝印发现停车场周边根本都装置了监控摄像头,这些摄像头平时仅用于监控录像。他决定从停车场摄像头捕捉到的视频流动手,对监控视频进行智能解决,取得停车场实时停车状况以及危险报警零碎。这样的一款智慧停车场零碎既能充分利用监控视频资源,又不须要减少额定的设施,疾速地推广遍及。 在视频解决的技术选型上,刘宝印基于 Intel Xeon SG1 GPU,利用 Intel OpenVINO toolkit 及优化 Mask R-CNN 实例宰割模型,对摄像头采集视频中的人及车辆进行宰割、比对,进而实现停车场场景下车辆数量统计,以及停车场中行人危险状况预警 (如在汽车盲区左近驻留、游玩)。 我的项目样例演示 这个零碎还可为支流地图 App 等服务商提供公共停车场车位信息接口,对停车场停车状况可视化解决,协同公共停车场监控以及播送喇叭或警示信号灯等公共设施,对停车场内车辆及行人平安收回预警信号。 从答辩高手到 AI 达人刘宝印目前是青岛大学计算机科学技术业余的大四学生,刚走进校园的他已经热衷于答辩较量,曾取得青岛大学第十四届精英辩论赛优胜辩手。 他说:“答辩能够让人从不同角度思考问题,在交换中发现有余和破绽,不至于眼光太全面。” 左一为刘宝印 从辩论赛中成长起来的宝印,将视线瞄向了更广大的人工智能畛域,在两年内别离获得了第十六届 “挑战杯” 山东省大学生课外学术科技作品比赛一等奖、第五届山东省科技翻新大赛三等奖、Kaggle 数据挖掘比赛铜牌的好问题。 他说:“写代码跟答辩一样对逻辑思维要求很高,然而编程还须要创造力及自主学习能力,是一件更有挑战的事。” 参赛后,他也更加动摇了将来的职业规划 - 成为一名 AI 工程师。 在加入视频云较量前,刘宝印接触都是 OpenCV 相干的深度学习开源模型,而参加本次较量他第一次基于 Intel Xeon 平台搭配 SG1 GPU 进行 OpenVINO 开发我的项目,他说:“AI 工程师这个职业须要不停的学习最新的技术,不然就没有方法跟着时代去开发。” ...

June 17, 2021 · 1 min · jiezi

关于云计算:浪潮云入选中国网络安全百强综合实力领军者象限

6月16日,国内数字化产业第三方调研与咨询机构数世征询正式公布《中国网络安全百强报告(2021)》。浪潮云凭借在云原生平安畛域内的技术当先劣势与政务云市场影响力入选「综合实力百强」领军者象限。 《中国网络安全百强报告(2021)》调研了国内700余家经营网络安全业务的企业,基于上百项评估指标联合多种角度、不同维度的企业相干数据进行梳理和评估。报告分为两大部分,一是综合实力较为突出的100家企业,评为「综合实力百强」,并划分为领军者、竞争者和挑战者三类,通过品牌影响力、企业规模、技术创新力三大维度,以数轴点阵图的模式予以展示。二是「创新能力百强」企业的举荐,目标在于突出业务规模目前较小,但在网络安全技术创新能力方面体现优良的企业。入选领军者的企业共32家,次要为深交所、上交所的上市企业,大型互联网企业,以及ICT企业、软件企业和齐全具备上市条件的网络安全企业。领军者企业是整个网络安全市场上的主导力量,很大水平上代表着平安产业的根本倒退情况。 近年来,浪潮云深耕信息安全技术,基于长期实践和摸索推出了云御系列云平安产品——平安大脑和云原生平安资源池。云原生平安资源池可能实现租户平安产品的低提早接入,产品除涵盖了防火墙、主机杀毒、云WAF、堡垒机、日志审计等根底平安产品服务外,还蕴含沙箱、蜜罐、数据库审计、数据库防火墙、网页防篡改、云加密机等针对利用和数据的平安产品服务,实现用户从主机平安、边界平安、利用平安、数据安全等方面的全方位笼罩。而浪潮云平安大脑作为整个信息安全体系的协调指挥中枢,将内外部主客观的平安数据进行收集与整合剖析,最终由浪潮云平安专家团队提供稳固的辅助决策,实现对安全事件闭环解决的同时,大大晋升了用户被动发现未知平安威逼的能力。 截止目前,浪潮云御平安产品曾经为浪潮云全国90余个云核心以及浪潮云私有云平台提供对立的云原生平安服务,使得用户能够像用水、用电一样方便快捷的应用平安服务产品,为政府用户云上平安保驾护航。此次浪潮云入选「综合实力百强」领军者象限,代表着市场及行业对浪潮云网络安全畛域能力的统一认可。将来,浪潮云将持续加大投入研发力量,力争在平安畛域减少科技创新力,为云上用户提供更优的平安产品及解决方案, 为网络安全产业的蓬勃发展贡献力量。

June 17, 2021 · 1 min · jiezi

关于云计算:深入浅出-LVS-负载均衡三实操-NATDR-模型

之前介绍了 LVS 负载平衡 NAT、FULLNAT、DR、TUN 模型的实现原理。本章来入手实际一下~ 实际环境LVS 目前曾经是 Linux 内核-中的一部分,在内核中的模块叫做 ipvs,反对 NAT、DR、TUNNEL 模型。用户不能间接操作 ipvs 模块,须要装置交互软件 ipvsadm,应用 ipvsadm 和 ipvs 进行交互。 应用 3 台 UCloud 云主机来搭建试验环境,创立云主机的时候抉择分时购买,更划算。 试验机器及环境 3 台 UCloud 云主机,CentOS 7.9 64位,1 核 1 G,须要留神⼀下防⽕墙规定,实际中抉择的是【Web服务器举荐】,凋谢 22、3389、80、443 的端⼝号,这个能够⾃⾏配置两台 Real Server:RS01、RS02,⼀台负载平衡服务器:LB01RS01:10.23.190.76、RS02:10.23.122.152、LB01:10.23.21.184RS01、RS02 装置 httpd,疾速启动 http 服务器,且配置不同的申请响应LB01 装置 ipvsadm,并启动 ipvsadm试验机器展现NAT 模式实操回顾一下 NAT 模式的特点 NAT 模式批改数据包的「指标 IP 地址」或「源 IP 地址」,所有的申请数据包、响应数据包都要通过负载均衡器,所以NAT模式反对对端口的转换实在服务器的默认网关是负载均衡器,所以实在服务器和负载均衡器必须在同一个网段实操开始,首先要做一些前置的筹备工作,即把该装置的软件和服务,装置和启动起来。 RS01、RS02 装置 httpd,疾速启动 http 服务 yum install httpd -y && service httpd startecho "HelloFrom RS01/RS02" > /var/www/html/index.html验证:curl 0.0.0.0,返回对应的信息 ...

June 17, 2021 · 2 min · jiezi

关于云计算:Redis最佳实践

缓存数据库在古代零碎架构中越来越成为标准配置之一,特地是随着微服务架构的风行,微服务无状态革新要求状态外置,外置的状态就须要存储到内部缓存服务中。Redis是以后支流的缓存数据库实现,本文介绍Redis基本概念与最佳实际。 架构与概念Redis是一个应用ANSI C编写的开源、反对网络、基于内存、可选持久性的键值对存储数据库。从2015年6月开始,Redis的开发由Redis Labs资助,而2013年5月至2015年6月期间,其开发由Pivotal资助。在2013年5月之前,其开发由VMware资助。依据月度排行网站DB-Engines.com的数据,Redis是最风行的键值对存储数据库。 单机/主备/集群模式Redis是单线程模式,因为Redis设计理念是不耗费CPU,且单线程的联合异步IO解决效率也很高,以后Redis单实例能够达到10万QPS。个别的利用场景,应用单机或主备(高可用)即可满足要求。 然而现在应用程序越来越依赖Redis,对Redis的要求越来越高:拜访低时延(<5ms)、高QPS(百万QPS)、高吞吐量(百MB/s),从而导致很多场景下,单CPU无奈满足需要。因而多Redis过程组成的Redis集群是高性能缓存服务的一种解决办法。在集群模式之下,因为应用程序特色,存在“热Key”景象,热Key会导致集群上面的Redis应用不平衡,热Key命中的实例很忙碌,其余实例闲暇。解决热Key的通常做法有两个:一个是在Redis集群角度,提供读写拆散个性,通过多个Redis实例分担负载,当然读写拆散自身是一个复制集群,如何缩小实例间数据复制时延以及复制时对主实例的耗费是读写拆散模式设计的要害;另一个办法是在应用程序外部应用内存做一级缓存,应用Redis做二级缓存。 Codis集群Redis官网版本3.0才反对集群模式,在此之前,有不少Redis集群计划,次要实现思路都是在Redis实例之上减少一个Proxy,由Proxy负责分区转发,同时Redis实例的状态由哨兵监控,哨兵将状态写入到分布式配置核心(ZK/ETCD),Proxy通过配置核心刷新Redis实例路由信息。在开源畛域认可度较高的Proxy集群实现是Codis,下图是Codis的架构。 Redis原生集群Redis3.0版本反对集群模式,与下面的带Proxy集群形式不一样,Redis官网提供的集群实现,在Server端是没有Proxy的,Proxy路由的性能,由客户端SDK来实现。为了与Proxy集群辨别,Redis官网的集群称为原生集群。 Redis集群节点之间通信机制为 Redis Cluster Bus,基于Gossip协定实现。 Redis客户端通过CLUSTER相干命令获取集群配置信息,客户端与节点之间通过MOVED/ASK来协调Key所属的槽位变更。 原生集群与Proxy集群相比拟,没有Proxy层之后,程度扩大能力更好,官网宣传反对1000节点。当然没有了Proxy层,流量、路由管控会更麻烦一些。 原生集群的槽位Slot空间总共为16383个,因而实践上集群节点数量是不能超过16383个。 Redis规格评估因素抉择Redis规格时候,须要评估业务模型,防止抉择的规格与理论业务模型不匹配。 内存容量依据Key写入数量/频度,TTL时常,是否显示删除判断容量增长状况,防止容量满。当Redis内存容量满时,再次写入则会触发淘汰Key操作。同时因为内存满,可能导致系统资源有余,淘汰Key的操作会很耗时,从而导致写入超时。 是否落盘数据须要落盘的话,须要确认 appendfsync=everysec 如果开启,底下磁盘是否是SSD;否则在高QPS写的场景,如果不是SSD盘,可能会导致利用拜访Redis时延减少,极其状况会拜访超时。 数据是否可重生成如果数据能够重生成,则不须要迁徙数据。 如果数据不能重生成,那么意味着须要迁徙数据。以后并没有Redis在线迁徙的工具或服务(DRS服务对Redis反对还不欠缺),因而须要业务代码配合实现迁徙,依据业务状况探讨迁徙计划。典型的办法有: 业务代码双写如果反复Key值能够笼罩,则能够写一个工具从源库读,写到目标库,而后在某个工夫点,短暂停业务切换库简略粗犷的是停业务迁徙QPSQPS是抉择Redis规格的次要根据之一,有的场景是数据量很小,QPS很高,因为主备版本的最大QPS无限,如果须要的QPS超过了主备版本的QPS最大值,那么也得上集群版本。内存很小,QPS很高的场景,也是小规格集群的次要场景之一。 读写QPS占比QPS指标须要辨别读/写,写QPS很高的话要留神 AOF REWRITE,在执行 AOF REWRITE 时再写入的话,时延会变高,极其状况下会导致拜访超时。参考连贯 并发连接数依据要求的并发连接数选定对应的规格。如果是短链接形式拜访,要特地留神。 是否cpu耗费类型一些场景下如MSET、MGET等耗费CPU的命令较多,评估时候肯定要思考CPU算力是否足够,有时候内存足够了然而CPU有余,导致Redis CPU忙碌。这种状况是小内存规格集群的典型应用场景。 是否有TTL设置过长会导致内存满可能有一些Key的TTL设置的很长(如一个月),且没有被动删除机制,那么就可能会导致内存满,从而触发Key淘汰策略,这时候再写入可能会超时。 是否应用Pipeline在QPS很高的场景下,应用Pipeline相比拟单个Key操作,效率和性能都有很大晋升。然而须要限定Pipeline中的命令数量,以后Codis Proxy默认的 session_max_pipeline=10000 ,倡议不要超过此值。同时还须要评估一次Pipeline返回的数据量。 是否应用多DB有一些云厂商(如阿里云)反对Redis集群有多DB个性,不同DB中的Key值能够雷同。Codis集群、Redis原生集群是不反对多DB的。 长连贯or短连贯短连贯须要特地关注连接数这个指标。如果是短链接,须要关注内存参数本地端口、最大句柄数等值是否调优。 支流云厂家缓存服务比照Redis作为支流缓存服务,各个云厂家都提供了托管式的Redis缓存服务,不过各个厂家实现上并不完全一致,在此列出各个厂家次要实现原理以供选型参考。 AWSAWS提供Redis集群托管服务。用户指定flavor机器(计算、存储、网络),AWS帮忙客户讲Redis集群部署到服务器上。同时用户创立实例时候能够指定节点数量、正本数量、槽位与节点调配形式。 计算/存储/网络:可指定flavor。LB:不波及。Proxy:不波及。多DB:不反对。正本数:可指定正本数。读写拆散:不反对。扩缩容:在线扩缩容。跨集群复制:不反对。性能规格:应用限度:应用限度Redis版本兼容:可抉择,范畴:3.2.4, 3.2.6, 3.2.10, 4.0.10, 5.0.0, 5.0.3, 5.0.4阿里云阿里云提供Proxy模式的集群,Proxy自研。 计算/存储/网络:与Redis规格绑定,不可指定flavor。LB:应用SLB,QPS峰值为200万。Proxy:Proxy数量与集群规格有肯定配比关系,可反对用户自定义Proxy数量,应答cpu耗费场景。多DB:集群反对多DB。正本数:单正本、双正本读写拆散:反对。slave同步数据存在肯定提早。扩缩容:在线扩缩容。跨集群复制:反对。提供寰球多活个性。性能规格:性能规格应用限度:应用限度Redis版本兼容:2.8, 4.0腾讯云腾讯里云提供Proxy模式的集群,Proxy自研。同时腾讯云提供两种Redis引擎:开源Redis,自研CKV。 计算/存储/网络:与Redis规格绑定,不可指定flavor。LB:单节点10万QPS,QPS下限未知。Proxy:数量不可指定。多DB:集群不反对多DB。正本数:可抉择:1,2,3,4,5读写拆散:不反对。扩缩容:在线扩缩容。跨集群复制:不反对。性能规格:性能规格)应用限度:应用限度)Redis版本兼容:单机/主从版2.8,集群版4.0华为云华为云提供两种Proxy模式的集群:Codis与Redis原生集群。原生集群不带LB与Proxy。 计算/存储/网络:与Redis规格绑定,不可指定flavor。LB:100万QPS。Proxy:数量不可指定。多DB:集群不反对多DB。正本数:2读写拆散:不反对。扩缩容:在线扩容。跨集群复制:不反对。性能规格:性能规格))应用限度:应用限度)Redis版本兼容:2.8, 3.x, 4.0, 5.0更多云最佳实际 https://best.practices.cloud

June 16, 2021 · 1 min · jiezi

关于云计算:阿里云视频云-Retina-多媒体-AI-体验馆开张啦

带你体验视频更多可能海量视频治理难度大?翻库检索特定人物费时费力?视频内容剪辑效率低?您的得力助手“Retina多媒体AI”体验馆已上线。带你感触视频AI黑科技,开启极致智能体验。 1、智能媒资治理,节俭人力投入ProblemMicheal 负责社交网站短视频业务的经营工作,进行平台视频内容的治理。平台每天会接管用户上传的数万条小视频,这些视频都须要进行内容审核和打标签,以确保视频中没有违规内容,并不便后续的归档治理和视频散发举荐。 传统的形式是由平台的审核团队人工来进行内容审核,同时手动给视频录入内容标签。均匀每条视频须要破费3分钟,光是审核打标工作就须要投入约100人的团队来反对。随着视频业务的增长,人力和估算投入就跟不上了。 Solution有了视频云弱小的视频AI性能帮助,能够帮忙疾速进行智能审核和打标工作,大大节省时间和人力: 应用智能审核能力来审核内容,疾速找出涉黄、暴恐、广告等违规信息,及时警示潜在的危险点,审核人员仅须要大量的复核确认工作即可,能够解放90%以上的人力。应用智能标签性能,可能主动将视频内容标签化,为视频打上类别标签,并具体标记出视频中哪些工夫片段呈现了哪些公众人物、事件、场景、物体等信息,帮忙进行更精准的视频举荐和视频检索。 通过应用视频DNA查重的性能,帮忙平台发现反复上传的视频内容,调整视频的散发举荐策略,防止为用户屡次举荐反复视频,晋升用户的观看体验。2、人物翻库搜寻,疾速下架视频Problem前阵子劣迹艺人和落马官员新闻频出,作为经营的 Micheal 又面临成千上万条视频须要对全网相干视频进行紧急下架问题,没有足够人手来对媒资库内的所有视频进行检索,也没有足够工夫去挨个下架,如何是好? Solution 通过应用视频云多媒体AI的人物搜寻性能,能够在上传入库时即进行特征分析,对视频中呈现的人物进行聚类。一旦须要检索相干人物的视频,能够依据特征分析后果,疾速检索出全副呈现该人物的内容,实现秒级的翻库搜寻速度,高效实现视频紧急下架的工作。 3、视频智能剪辑,晋升制作效率Problem在视频的剪辑制作过程中,对于视频内容的解决也是非常让人头疼的。David 是一名新媒体视频编辑,每天要花费大量工夫来进行视频内容的制作。他须要从多个综艺节目视频中,剪辑制作出一段明星的混剪短视频,他须要做大量的反复工作: 从几十条视频里一一查找定位明星呈现的片段,作为视频编辑的原始素材再对每一个镜头认真做画面裁剪,去除一些字幕和台标,确保人物处于画面核心选好一段配乐后,还要把每个视频片段和转场对齐音乐节奏再加上视频字幕的编辑、配音如果要公布到手机平台,他还须要进行框选,确保人物不会出框一套操作下来,仅仅半分钟视频成品,David 至多要花上好几个小时。 Solution应用视频AI的智能检索和智能剪辑技术,视频内容生产将变得更方便快捷。 在搜寻明星的视频素材时,能够依据内容标签疾速搜寻定位到有明星呈现的镜头,具体到视频的具体工夫片段;花式组合检索,人物+动作等,或者依据一张图片或视频查找类似的片段,想要找什么样的视频素材都能够信手拈来;在找到须要剪辑的素材后,如果原始视频素材中有台标、字幕,须要擦除后剪辑新的视频,应用AI性能能够主动对字幕、台标进行检测和去除,还原污浊的视频画面;应用横屏转竖屏性能,AI能够自动识别主体人物并进行画面裁剪,一键生成竖屏的小视频;另外,AI能够依据视频的语音主动生成字幕,或者依据剪辑作者输出的文字主动生成旁白配音,不再须要费时费力本人录入配音或敲入字幕;在给视频加音乐配乐时,AI可能帮忙智能辨认歌曲的副歌、节奏点,依据节奏点来智能编排视频和图片的转场工夫,生成动感的卡点视频。这样,一个混剪视频就零打碎敲地实现了,从之前的几个小时,缩短到几分钟,大大晋升了视频剪辑速度。 看到这里,有着同样苦恼的你是否按捺不住想要亲自体验一番了?那就连忙点击http://retina.aliyun.com 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实际技术文章,在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云技术交换群,和作者一起探讨音视频技术,获取更多行业最新信息。

June 16, 2021 · 1 min · jiezi

关于云计算:连续七年我们持续领跑

近日,赛迪参谋正式公布《2020-2021 年中国政务云市场钻研年度报告》,数据显示,浪潮云在市场位置和倒退能力方面获得双料第一,间断7年蝉联中国政务云市场第一位。 赛迪在报告中指出,随着国家对“进步数字政府建设程度”要求的一直深入,政务云作为数字政府建设的外围基础设施建设过程提速,2020 年,中国政务云市场规模达 653.6 亿元,同比增长 42.3%。但同时政府对政务云服务的要求也将越来越高,“办公协同”成为政务云建设的外围诉求,混合云架构的政务云开始受到越来越多用户青眼。在此过程中,浪潮云凭借高市场占有率、齐备的产品体系、宽泛的用户根底、欠缺的云平安服务和良好的生态体系,间断7年稳居中国政务云市场占有率第一。 作为政务云市场最早的布局者及“政务云”概念的提出者,浪潮云通过云网边端交融、云数智交融、建管运交融的全栈云服务,提供业余、生态、可信赖的分布式云。浪潮云目前已造成了一朵分布式云、统一技术架构、统一用户体验、一套运管体系,往年5月浪潮云更是降级公布全新的“1231”业务策略,推出“分布式云+”行动计划,建成了全国最大的分布式云骨干体系。全新降级后的“分布式云+”具备数据服务、AI、信创、运管、云原生五大能力,推动着政务云迈向新的倒退阶段。 浪潮云认为,在政务云畛域,中国政务云的倒退在经验了资源物理集中、业务上云两个阶段后,2021年开始走向以数据因素为外围的云上翻新阶段,数据因素化、计算边缘化、利用原生化以及经营一体化成为政务云倒退新趋势。在这一阶段,数据首次被明确成为新型生产因素,对数采形式、数算能力、数用体系提出了新的要求,计算能力走向边缘节点,算力场景边缘化、数据处理基层化、管理模式协同化成为新的倒退方向,业务倒退驱动云原生需要增长。同时也推动政务云向经营一体化迈进,在治理上实现“省市区县”向下延长,在技术上实现平台、数据和利用向上协同,为用户带来集中化、可视化、智能化、精细化的极简运维新体验。 截至目前,浪潮云已建成了中国最大的分布式云体系,涵盖288个分布式云节点,基于对立的OpsCenter,实现了持续性迭代降级;服务我国245 个省市政府、2 万个政府部门、128 万家企业,具备16 大类 200 多种产品及 1 万个业务场景服务能力。 谈到将来政务云市场的倒退变动时,赛迪指出,云服务商要一直降级政务云“一体化”服务能力,打造蕴含“城市大脑”、“数据中台”等产品的一体化政务云解决方案;其次,要重视政务混合云解决方案的研发,其可能同时满足政府对外围数据的安全性要求和业务拓展对计算弹性的要求,将成为政务上云的次要部署模式。这些与浪潮云今年以来的一系列策略降级不约而同,时值“十四五”布局开局之年,浪潮云致力于成为高品质云服务运营商,基于本身多年来积攒的技术劣势与实践经验,持续深耕政务云行业迭代降级,全面助推数字中国建设指标实现。

June 16, 2021 · 1 min · jiezi

关于云计算:Kurento实战之四应用开发指南

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 本篇概览本文是《Kurento实战》的第四篇,后面的文章中,咱们先部署KMS再启动官网demo,还把Kurento的重要概念都分类学习过,接下来要开始利用开发了;本文的次要内容是剖析官网的<font color="blue">kurento-hello-world</font>我的项目,理解Kurento利用开发的根本流程和知识点,本文应用的代码是官网公布的6.15.0版本,地址:https://github.com/Kurento/ku...浏览代码时,如果能从整体上将划分分明功能模块,再有针对性的一一攻破细节,将会更高效的学习和了解源码,接下来咱们就依照Kurento官网的规范套路去拆分并一一攻破;如何划分功能模块依照不同的职责划分,整个代码被拆分为三局部: WebSocket相干:WebSocket相干的通用解决,例如连贯建设、敞开、异样的回调,业务逻辑的散发等;WebRTC信令相干:ICE、SDP相干的解决;业务逻辑:如果说1和2代表的是WebRTC的通用解决,那么剩下的就是如何应用Kurento来实现业务需要了,这部分的次要内容是业务利用应用Kurento官网client和KMS交互,管制KMS为端侧提供服务,交互方式如下图:依照上述形式将代码做好拆分,划定边界,不论是浏览官网demo还是本人开发利用,都能条理清晰的应答,接下来一起学习官网的hello-world源码,看看一个残缺的Kurento利用是如何开发进去的WebSocket相干最简略的逻辑应该是通用的WebSocket解决了,咱们先看这部分,简单的稍后再说,Handler类中和WebSockert相干的逻辑如下: 继承自TextWebSocketHandler(只解决text类型的数据,对于二进制数据间接敞开会话);重写afterConnectionEstablished:WebSocket连贯建设的回调,只打了一行日志;重写handleTransportError:WebSocket产生异样时候的回调,仅敞开WebSocketSession;重写afterConnectionClosed:不管WebSocket是失常敞开还是产生异样,此办法都会执行,逻辑也很简略,就是调用stop办法,这个办法是用来开释KMS资源的,有好几处都会调用,咱们留到稍后和其余解决KMS的中央一起讲;WebSockert局部最重要的代码是handleTextMessage办法,外面是收到前端数据时的解决逻辑:先把数据转为JsonObject对象,此对象的messageId字段有四种值,每一种id及其对应的解决办法如下表格所示:messageId解决办法阐明PROCESS_SDP_OFFERhandleProcessSdpOffer收到前端SDPOffer数据后的解决逻辑ADD_ICE_CANDIDATEhandleAddIceCandidate收到前端ICE数据后的解决逻辑STOPhandleStopHashMap删除用户数据,再近程调用MediaPipeline.releaseERRORhandleErrorHashMap删除用户数据,再近程调用MediaPipeline.release并不是所有的利用都须要重写上诉全副代码,还是以理论需要登程决定是否要重写,以<font color="blue">kurento-one2one-call</font>我的项目为例,只重写了handleTextMessage和afterConnectionClosed,其余的应用父类的即可,如下图: 还有一个发送音讯到浏览器侧的sendMessage办法,以及发送错误信息的sendError办法;信令相干<font color="blue">kurento-hello-world</font>利用的性能是和KMS实现实时音视频通信,因而WebRTC规范的信令解决是必不可少的,惋惜Kurento官网并没有对信令解决做太多封装(也可能是信令和不同的业务解决逻辑都不一样,导致不好形象),后果就是一堆信令解决的代码散落在业务代码中;就算业务和信令的解决代码同时呈现在Handler类中,只有相熟WebRTC的信令解决流程,也很容易读懂代码,下图联合了WebRTC规范的信令解决流程,对前端和服务端的代码串联在一起就行剖析,右边是浏览器上执行的js代码,左边是服务端,这些代码都用红色箭头标识了处于WebRTC信令解决流程的具体位置,至此,整个流程都清晰的展示进去: 如果您在电脑或手机上看上图感觉含糊,请下载原始文件,用<font color="blue">draw.io</font>关上,文件所在目录是:https://github.com/zq2599/blo... ,文件名为<font color="red">helloworld-flow.drawio</font>上图列出了信令相干的所有代码,等到看完这些,剩下的就是业务代码了,也就是图中紫色局部的<font color="blue">handleProcessSdpOffer</font>办法; 业务相干<font color="blue">kurento-hello-world</font>利用是把本地摄像头和麦克风数据传到KMS,再从KMS获得这些数据在页面展现,先看看官网是如何形容KMS pipeline的: 从上图可见pipeline逻辑非常简单:只有一个WebRtcEndpoint,把本人的Src和Sink接上就实现了,咱们来看看对应的代码,在办法handleProcessSdpOffer中: // 创立pipeline final MediaPipeline pipeline = kurento.createMediaPipeline(); user.setMediaPipeline(pipeline); // 创立webRtcEndpoint final WebRtcEndpoint webRtcEp = new WebRtcEndpoint.Builder(pipeline).build(); user.setWebRtcEndpoint(webRtcEp); // 本人的sink连贯上本人的src webRtcEp.connect(webRtcEp); // ---- Endpoint configuration String sdpOffer = jsonMessage.get("sdpOffer").getAsString(); // 注册各类监听,例如媒体资源状态变动、ICE变动等 // 通过websocket回复SDP Offer initWebRtcEndpoint(session, webRtcEp, sdpOffer); log.info("[Handler::handleStart] New WebRtcEndpoint: {}", webRtcEp.getName()); // ---- Endpoint startup // 获得ICE信息 startWebRtcEndpoint(webRtcEp);再来看看进行WebRtc的stop办法,其实就是向KMS发送了release指令: private void stop(final WebSocketSession session) { // Remove the user session and release all resources final UserSession user = users.remove(session.getId()); if (user != null) { MediaPipeline mediaPipeline = user.getMediaPipeline(); if (mediaPipeline != null) { log.info("[Handler::stop] Release the Media Pipeline"); mediaPipeline.release(); } } }小结以上就是整个<font color="blue">kurento-hello-world</font>的源码剖析,整个工程的代码在拆分后再剖析时,变得异样清晰和简略: ...

June 16, 2021 · 1 min · jiezi

关于云计算:源码解析一文读懂-Kubelet

本文次要介绍 kubelet 性能、外围组件,以及启动流程的源码剖析,总结了 kubelet 的工作原理。 kubelet 简介 从官网的架构图中很容易就能找到 kubelet 执行 kubelet -h 看到 kubelet 的性能介绍: kubelet 是每个 Node 节点上都运行的次要“节点代理”。应用如下的一个向 apiserver 注册 Node 节点:主机的 hostname;笼罩 host 的参数;或者云提供商指定的逻辑。kubelet 基于 PodSpec 工作。PodSpec 是用 YAML 或者 JSON 对象来形容 Pod。Kubelet 承受通过各种机制(次要是 apiserver)提供的一组 PodSpec,并确保外面形容的容器良好运行。除了由 apiserver 提供 PodSpec,还能够通过以下形式提供: 文件HTTP 端点HTTP 服务器kubelet 性能演绎一下就是上报 Node 节点信息,和治理(创立、销毁)Pod。 性能看似简略,理论不然。每一个点拿进去都须要很大的篇幅来讲,比方 Node 节点的计算资源,除了传统的 CPU、内存、硬盘,还提供扩大来反对相似 GPU 等资源;Pod 不仅仅有容器,还有相干的网络、安全策略等。 kubelet 架构 重要组件kubelet 的架构由 N 多的组件组成,上面简略介绍下比拟重要的几个: PLEG即 Pod Lifecycle Event Generator,字面意思 Pod 生命周期事件(ContainerStarted、ContainerDied、ContainerRemoved、ContainerChanged)生成器。 其保护着 Pod 缓存;定期通过 ContainerRuntime 获取 Pod 的信息,与缓存中的信息比拟,生成如上的事件;将事件写入其保护的通道(channel)中。 ...

June 15, 2021 · 3 min · jiezi

关于云计算:浪潮云说丨云应用容灾四大关键能力护航业务连续性

数字化转型浪潮中,保障业务连续性所面临的挑战日益凸显。例如,业务流程撑持的智能化经营,以及IT资源撑持的数字化翻新,一旦遭逢故障中断、劫难事件、勒索攻打等,都会影响到这些外围数字化能力的继续运行,妨碍整个数字化转型过程。 以政务云为例,以后面临的次要业务连续性挑战包含: 从业务视角来看,我国大力提倡和倒退“互联网+政务服务”模式,在实现互联网与政务服务深度交融,为企业和大众提供高效、便捷的政务服务,优化营商环境的同时,也面临互联网上防不胜防的业务危险;从IT视角来看,政务云模式下,承载大量国计民生等政务利用部署在云环境中,须要与时俱进的面向新型基础架构的利用爱护能力;数据安全危险:政务云利用一旦产生数据失落,一旦呈现业务故障,负面影响微小;短少自动化响应机制:呈现业务故障时,灾备业务零碎必须疾速主动启动并接管;更高的业务连续性SLA:灾备业务零碎的SLA广泛要求较高:秒级或分钟级RPO,分钟级或小时级RTO;建设老本:传统容灾建设老本高,限度多,复杂性高。为了应答以上挑战,同时业务连续性作为组织和企业数字化转型保障的重要一环,从新设计和更新劫难复原打算显得尤为重要。构建更具弹性的业务连续性的翻新办法,必将减速数字化转型过程。 浪潮云容灾要害能力,护航业务连续性,助力数字化转型浪潮浪潮云基于云的业务级和利用级容灾,提供四大要害能力,包含:浪潮云云利用容灾四大要害能力实时数据保护以后混合云环境下,数据复制须要面对不同的IT基础架构、不同的业务零碎要求,通过实时复制技术、继续数据保护技术等,躲避数据安全危险,防备业务故障危险。容灾自动化治理浪潮云利用容灾,提供云平台利用和数据恢复的自动化与指挥治理。自动化并不是说咱们要齐全依赖于自动化解决方案,而是说必须将自动化与指挥治理纳入到响应机制中。自动化和可视化还将构建一个涵盖所有业务不同局部的全局视图——这是在危机中疾速响应的基本要素。SLA驱动针对业务级和利用级容灾的SLA,须要达到秒级RPO和分钟级RTO.同时提供合规保障与审计报告,能够满足您受监管业务的品质和合规性要求。容灾IaaS就绪能力浪潮云基于分布式云的对立架构提供IaaS就绪能力,显著升高容灾建设老本,更可疾速上线部署。最终能够像应用云计算一样,应用弹性的云容灾DRaaS(劫难复原即服务)。浪潮云云利用容灾解决方案,将两地三核心的容灾最佳实际,扩大到云时代。将来可平滑过渡到多云多核心、云原生利用爱护等场景。

June 15, 2021 · 1 min · jiezi

关于云计算:Kurento实战之三知识点小导游

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 本篇概览作为《Kurento实战》的第三篇,咱们一起将重要的知识点梳理分明,并从整体上察看和了解Kurento,这样前面的学习和开发能更好的死记硬背,还能高效施展Kurento的能力;WebRTC很重要Kurento 是一个 WebRTC 媒体服务器和一组客户端API,因而,根底WebRTC常识储备是强制的、必要的,建议您提前有所理解;没有Kurento时基于WebRTC的点对点音视频流解决逻辑如下: 有Kurento后变成上面这种,客户端实际上和KMS(Kurento Media Server)建设了点对点连贯,收到的数据也来自KMS,这些数据能够是原生的,又或者是被KMS解决过的(如上一篇文章中戴一顶帽子的demo): 和GStreamer的关系对WebRTC有了理解后,应该对GStreamer有根本的理解,而后再去学习Kurento会有更好的成果,这样当你在学习Kurento的过程中,遇到pipeline、element、src、sink这些概念时会有种本该如此的感觉:这些概念在GStream中同样存在且非常重要,它们施展的作用和在Kurento中十分相似;Kurento的KMS中,录制、播放、编解码等能力都来自GStream库;GStreamer 是个开源多媒体框架,能够构建流媒体利用,以管道(Pipeline)形式将各步骤串联,每个步骤的元素(Element)基于GObjec通过插件(plugins)形式实现;上面是个典型的pipeline,性能是将一个多媒体文件的音视频拆散,再别离输入到音频和视频设施上: 作为比照,再来看看Kurento的pipeline,上面是滤镜demo的pipeline示意图,性能是给视频中的人头上戴一顶帽子: 下面两个图比照可见,基于GStreamer的Kurento也有pipeline、element、src、sink,但Kurento有本人的特点:KMS、WebRtcEndpoint、JsonRpc这些概念都和网络服务相干,回到Kurento的官网文档首页看看它的定位,如下图所示: 看到这里,聪慧的您对GStreamer和Kurento应该有了更粗浅全面的意识:Kurento在设计上和GStreamer根本对齐,并且将GStreamer的已有能力和WebRtc实时音视频技术在Pipeline+Element机制下整合组装,打造出高效可扩大的音视频技术计划;随着Kurento学习的深刻,会接触到更多的GStreamer常识,如下图是Kurento源码的脚手架文件夹中的模板代码: Kurento的客户端为了更好的应用KMS的能力,Kurento官网提供了java和nodejs两个版本的客户端;如果您善于的编程语言不是java或nodejs也没关系,能够参考Kurento Protocol本人来实现客户端(作为java程序员的欣宸涌现出一丝自卑感...);客户端的作用:提供API给业务调用,通过这些API能够向KMS发送指令,让KMS为业务服务,例如编排pipeline,如下图,重点是业务应用服务,集成了Kurento的客户端后就能向KMS发送指令了: 基本概念梳理Kurento中波及的概念并不算多,且很多都向GStreams对其了,总的来说比拟好了解,在此将所有重要概念梳理进去便于前面的学习: module:Kurento自身是插件化的框架,所有插件(plugin)都被称为module;官网将所有module分为三大类:main、built-in、custome,下图很形象的解释了它们在Kurento中的定位: 紧接着官网抛出了<font color="blue">Kurento toolbox</font>的概念,并且将相熟的各种能力都展示在toolboox中: toolbox中的所有element与后面划分的module都是有归属关系的,我这里用思维导图整顿好了,心愿能帮忙您梳理分明这些关系: 上述思维导图中唯有<font color="blue">Group Communications</font>的地位无奈从后面的信息中失去,最终通过翻阅源码的办法确定了属于<font color="blue">kms-elements</font>(因为其源码在kms-elements工程中)几千字写完,已经的纳闷和记录的笔记都成了这篇文章的一部分,心愿本文能帮忙您疾速抓住重点,少走弯路少踩坑,接下来就要开始编码实战了,您筹备好了么?你不孤独,欣宸原创一路相伴Java系列Spring系列Docker系列kubernetes系列数据库+中间件系列DevOps系列欢送关注公众号:程序员欣宸微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界...https://github.com/zq2599/blog_demos

June 15, 2021 · 1 min · jiezi

关于云计算:信封加密与密钥管理实践

信封加密原理信封加密应用对称加密AES+非对称加密RSA两种实现,应用RSA加密AES算法的Key,并将Key与一并存储或传输,密文+加密的AES Key就形象比喻为信封。 信封加密用于加密大量数据的场景,因为RSA加密的长度不容许超过RSA Key长度(通常RSA Key长度为1024/2048/4096 bit),因而对于大文件加密的场景,如图片/视频/文本等,须要应用对称加密算法。对称加密算法的Key在网路或组织之间传输存在泄露危险,因而应用RSA非对称算法加密对称密钥的Key,能够保障Key的平安传输。 <!--more--> 信封加密实际上在SSL协定中就有应用,SSL协定在替换公钥之后,最终会协商一个AES加密的Key,这个Key在单方之间传输时候是应用RSA算法加密的。 信封加密的加密过程 生成AES明文密钥应用AES明文密钥加密数据应用RSA公钥加密AES明文密钥,失去密文密钥密文密钥与加密数据一并存储,这两者形象比喻为装到信封里信封加密的解密过程 数据接收者接管到信封,外面蕴含密文数据与应用RSA私钥解密AES密文密钥,失去明文密钥应用AES明文密钥解密密文数据私有云 KMS 服务信封加密的要害是加密对称密钥的RSA Key,RSA Key须要主密钥治理、数据加密密钥治理、有访问控制、拜访审计日志、Key轮换更新的性能。以后各大公有云厂商都提供密钥治理服务,并且与云服务器对接集成,如对象存储服务能够应用KMS加密数据,RDS能够应用KMS加密硬盘数据。 主密钥治理:创立新的主密钥、从已有密钥导入到KMS、主密钥轮换更新(加密的数据密钥中记录了应用哪个主密钥加密,主密钥轮换更新后之前的密钥还存在)、密钥访问控制、拜访审计日志。数据加密密钥治理:创立、加密、解密。云服务对接:对象存储、云硬盘、数据库等。应用自定义密钥资料作为根密钥企业个别会存在曾经在应用的AES加密密钥,如线上线下数据交换,存在一方加密数据在另一方解密,要求密钥统一。因而须要在创立主加密密钥的时候,导入已有的密钥资料创立。应用已有密钥资料导入到KMS创立主密钥的流程为:从KMS服务下载RSA公钥(用于加密主密钥资料)、指定RSA填充算法、用RSA公钥+RSA算法加密密钥资料、导入到KMS。 能够参考华为云KMS导入主密钥的帮忙文档,上面是参考帮忙文档的操作实例。 从KMS服务下载RSA公钥,并抉择RSA 填充算法华为云下载加密AES密钥资料所需的内容为三个文件: drwxr-xr-x 1 user01 1049089 0 4月 28 19:47 ./drwxr-xr-x 1 user01 1049089 0 4月 28 19:47 ../-rw-r--r-- 1 user01 1049089 2236 4月 28 19:46 importToken_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633-rw-r--r-- 1 user01 1049089 302 4月 28 19:46 README_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633.txt-rw-r--r-- 1 user01 1049089 294 4月 28 19:46 wrappingKey_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633wrappingKey_密钥ID_下载工夫:即包装密钥,用于加密密钥资料的包装密钥importToken_密钥ID_下载工夫:即导入令牌,KMS导入密钥资料时须要应用README_密钥ID_下载工夫:即阐明文件,记录包装密钥序列号、密钥包装算法、包装密钥文件名称、令牌文件名称以及包装密钥和令牌的过期工夫README 内容 $ cat README_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633.txtWrapping Key Spec: RSA_2048Wrapping Algorithm: RSAES_OAEP_SHA_1Wrapping Key File: wrappingKey_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633Import Token File: importToken_d4a19541-800d-4a6c-9678-c9c7d7249887_20190428114633Wrapping Key and Import Token Expiration: 2019-04-29 11:46:33 UTC生成256位的AES密钥资料AES 密钥长度为256 bits,应用openssl生成密钥资料 ...

June 14, 2021 · 1 min · jiezi

关于云计算:WebAssembly-–-Where-is-it-going

"WebAssembly is a safe, portable, low-level code format designed for efficient execution and compact representation" – W3C. 本文章介绍WASM与WASI的利用场景,这些场景中曾经有一些探索性的我的项目进行中,这些我的项目中隐含了将来利用架构与散发的模式。本文翻译自《WebAssembly – Where is it going?》,作者为 MATEUS PIMENTA 。 从 WASM 到 WASI当 WebAssembly (Wasm) 在2017年被支流浏览器反对的时候,代表着一种更快的(靠近本地)在浏览器中运行计算机程序的技术标准成形。 不过,当 Mozilla 在 2019年公布 WebAssembly System Interface (WASI) 之时,这是一个革命性的时刻。WASI 解除了 WASM 仅浏览器运行中的限定,扩大到了作为一个独立的虚构运行环境,可运行在主机上。这代表着一种全新的计算机应用程序编码、打包、运行的技术的诞生。 运行在浏览器中的WASM在2017年 WASM 被支流浏览器(Microsoft Edge, Safari, Google Chrome and Firefox)反对之后,W3C起草了一个WASM规范并很快的进入"recommendation"状态,并在2019年正式公布。这意味着开发者能够在浏览器中以"靠近本地程序性能"运行重负载的程序,不受JavaScript引擎性能限度、也没有跨浏览器适配问题。 在浏览器中应用WASM,开发者能够持续应用JavaScript开发传统的页面程序,同时将重负载的性能卸载到WASM编码的程序中,通过 WebAssembly JS API 交互。 游戏游戏是WASM最初始的指标场景,当失去一些游戏引擎公司的反对之后,(如 Unreal游戏引擎 发表反对WASM),牵引了WASM的技术构建方向。当然,WASM不仅仅用于游戏场景,在 图像处理 , 视频解决 , 音频解决工作室,这些场景下的工作以后只能在桌面或服务器上实现。 人工智能模型推理人工智能的模型推理也是WASM的一个典型场景。端侧的应用程序脱离服务端,间接加载简单的模型,例如人脸识别,语音转文字,在端侧实现推理。所有的简单逻辑都脱离了JavaScript,以Native Code形式运行。 Tensorflow.js 我的项目为此场景提供了一个WASM应用程序,Tensorflow.js还能够应用 multithreading and Single Instruction Multiple Data (SIMD) 技术减速计算。如果 WASM 的 Threading 与 SIMD 标准公布,一些新的我的项目将会随之呈现用于工程化这些技术。 ...

June 13, 2021 · 1 min · jiezi

关于云计算:Kubernetes-边缘节点抓不到监控指标试试这个方法

KubeSphere v3.1.0 通过集成 KubeEdge,将节点和资源的治理延长到了边缘,也是 KubeSphere 正式反对边缘计算的第一个版本。 笔者也第一工夫搭建和试用了边缘节点相干的性能,然而在边缘节点纳管之后遇到了一些监控的小问题,在排查过程中也顺带理解了一下 KubeSphere 对于边缘节点的监控原理,收回来和大家分享,不便其余的开发者可能更快的排查问题或进行二次开发。 环境版本和形成通过 KubeKey 装置,参数如下,其余组件版本默认未改变。Kubernetes : v1.19.8KubeSphere : v3.1.0 主机名称角色k8s-worker-03workerk8s-worker-02masterk8s-worker-01master,etcd问题景象通过生成的 keadm 命令即将边缘节点退出集群,并在边缘节点上部署 POD,该 POD 的监控信息不能显示。 监控原理定位和解决问题之前,必定是要先搞懂工作原理。 1. KubeEdgeKubeEdge 的 Edgecore 组件对 Kubelet 进行了轻量化革新,Edgecore 和 Cloudcore(云端)也不在同一个 Cluster 网络中,通过 k8s 默认的形式进行 metrics 获取必定是行不通的(logs 和 exec 原理雷同)。 以后 KubeEdge 的实现办法是 kube-apiserver 上的 iptables 转发给云端的 Cloudcore,Cloudcore 通过和 Edgecore 之间的 WebSocket 通道向边缘端进行音讯和数据传递。 KubeEdge 官网的使用手册和文档:https://kubeedge.io/en/docs/a... 为了便于大家了解,作者画了一张图,整体的流程请参考如下: 2. Metrics-server原生的 K8S 中就是通过 Metrics-server 这个官网组件进行节点和 POD 的 CPU/Memory 等数据的监控。 ...

June 11, 2021 · 2 min · jiezi

关于云计算:七牛云618年中大促就算躺平也能省钱

十八年当前,当咱们面对「养猫」、「盖楼」等一系列「电商打法」而莫衷一是时,准会想起已经纯拼手速就能抢到便宜货的单纯年代。 十八年,是呱呱坠地到加入高考的时间跨度。只不过,「6.18」面对的是大家真金白银的考验。作为国内最早最大的电商节之一,它交出的答卷还令人满意吗? 提振生产信念,激发生产激情,作为一个节日,「6.18」有着它明确的指向和意义。只不过从「拼手速」到「砍一刀」,从「组团 PK」到「组队养猫」,越来越多的套路和规定给大家严严实实地上了一节「价格歧视」的经济学课。只不过连摩尔庄园都要代练的年老人们,以「躺平」之姿表白着「躺平」的态度。 然而真的就「躺平」了吗?也未必,只有吸引力足够大,排除万难也可「扶我起来,我还能战」。那真的就不能「躺平」和「省钱」兼得吗?七牛云「6.18」年中大促,理解一下。 「秒」上云,热门产品超值动手如果你是新用户,咱们贴心地为你筹备了能够「秒速」上云的老手礼包。「规范存储空间 100GB」、「人脸核验 100 次」、「0 元云主机」等多种爆款产品,为你一秒备齐。 领优惠,超强折扣万券齐发不必组团,不必兑换,超多满减券点击就送!不管新老用户,折扣叠加应用享受折上折。云存储 Kodo 低至 0.07 元/GB/月 ,中国大陆 CDN 流量低至 0.043 元/GB/年,视频直播 Pili 低至 4.2 折,数据处理 低至 4 折,RTC、短视频、视频监控、云主机也有劲爆价。简简单单,优惠满满! 惊喜福利,买产品赢手机流动期间,但凡注册的新用户,均可参加 iPhone 12 抽奖。下单,就有机会!送奖品,咱们素来都是认真的。 更多详情,请点击七牛云官网查看~置信我,「省钱」和「躺平」不矛盾。这波 6.18,一起安顿!

June 11, 2021 · 1 min · jiezi

关于云计算:中通快递关键业务和复杂架构挑战下的-Kubernetes-集群服务暴露实践

本文是上海站 Meetup 讲师王文虎依据其分享内容整顿的文章。KubeSphere 社区的小伙伴们,大家好。我是中通快递容器云平台的研发工程师王文虎,次要负责中通快递容器云平台开发、利用容器化推广、容器平台运维等工作。非常感谢 KubeSphere 社区的邀请,让我有机会跟大家分享中通快递要害业务和简单架构挑战下的 Kubernetes 集群服务裸露实际。 ZKE 容器治理平台首先介绍一下中通的容器云治理平台 ZKE。ZKE 平台是基于 KubeSphere 开发的,当初治理的中通外部集群超过十个,蕴含开发、测试、预公布、生产等环境,所有用户都通过 ZKE 平台治理容器利用。 Kubernetes 集群服务裸露计划依据中通的理论业务需要和一些摸索,梳理出了中通 kubernetes 集群服务裸露的几种计划。 Dubbo 服务之间拜访中通大部分利用都是基于 Java 语言开发的,应用的微服务框架为 Dubbo。在上容器之初,咱们思考到虚拟机和容器并存的场景可能会继续很长时间,所以在布局 Kubernetes 集群的时候,通过把容器网络和物理网络买通的形式,来解决 Dubbo 服务在容器和虚拟机混布的场景下相互调用的问题。 如何买通 Kubernetes 容器网络和物理网络?咱们外部环境中 Kubernetes 集群网络组件应用 calico BGP 模式,数据中心物理网络也开启了 BGP 路由协定,通过在物理网络上开启 BGP RR(Route Reflector),防止前期集群规模太大导致 BGP 宣告路由条目过多的问题。BGP RR 和 Kubernetes 集群节点建设 EBGP 街坊,互相学习路由。 泛域名形式拜访在初步推广开发和测试容器化时,咱们遇到最多的问题就是用户在利用公布到容器环境后如何拜访。 用户在 ZKE 平台上创立 Ingress 当前,该域名是不能拜访的,必须要运维把域名指向集群 Ingress Controller,而且公司申请域名须要走 OA 流程,所以这就使得咱们的容器环境在初始推广阶段进度很慢。 咱们收集了局部用户的反馈,加上本人的思考,终于摸索出了一条开发/测试环境比拟高效的 Ingress 应用之路: 通过给每个集群调配一个三级泛域名,在公司 DNS 上配置把对应泛域名指向集群的 Ingress Controller,用户后续创立业务域名时能够间接在 ZKE 界面上创立 Ingress,该域名便会立刻失效,省去了很大部分测试和开发环境上容器的工夫,因为公司平安治理要求,Ingress 只提供了裸露 HTTP 协定的性能,然而这一措施也还是很大水平放慢了测试开发容器化的推广速度。 ...

June 11, 2021 · 1 min · jiezi

关于云计算:KubeSphere-在直播应用中的实践

本文是上海站 Meetup 讲师唐明依据其分享内容整顿的文章。引言目前媒体的支流流传渠道已从传统的报纸、播送、电视转向了互联网,各种视频及社交 App 成为了人们获取资讯的首选路径。苏州市广播电视总台面对互联网媒体的新局势,一直摸索新形势下了信息公布形式、流传路径和相干的 IT 技术,为的是能在新的媒体战场上紧跟时代倒退,一直放弃当先劣势。 技术门路在 IT 架构选型上,技术团队放弃对新技术的关注和实际,通过总结这些年 IT 技术的实践经验,深信云原生才是云计算时代技术的倒退方向。如果仅仅是将物理服务器虚拟化,或者将虚机从本地环境迁徙上私有云,并无奈齐全施展云计算高效平安可扩大的个性。所以技术团队始终保持对容器技术进行实际。 2019 年初开始将 Kubernetes 利用于生产环境。在学习 Kubernetes 的过程中接触到了 KubeSphere,在对 KubeSphere 进行了较长时间的测试和验证后,往年开始应用 KubeSphere 治理 Kubernetes 集群。 需要剖析媒体行业最次要的业务零碎就是媒体的生产制作零碎。媒体生产能够分为媒体采集、媒体解决和媒体散发三个环节。 随着技术的倒退,采集设施从原先的业余摄像机倒退到了单反、无人机、GoPro、全景摄像机、手机等多种多样的设施均可用于视频拍摄,使得视频拍摄的数量大大增加且格局品种、编码方式、帧率等都变得纷繁复杂。此外媒体的散发渠道也不再仅仅是电视和播送,还有网站、app、公众号、短视频平台等。采集端和公布端的巨大变化对媒体解决能力提出了更高的要求。为了能解决好这些视频文件,业务零碎须要提供弱小对解决能力,包含视频对编解码、提取视频标签、进行智能解决等。 业务痛点对媒体文件进行解决的工作难度很大。媒体解决零碎须要可能解决海量的、不同拍摄设施、不同视频格式、不同拍摄人员所采集的媒体素材,并且须要为不同的平台提供不同长度、不同类型(横屏竖屏)、不同编码格局、不同码率、不同分辨率的成品视频文件。同时须要对这些素材和成片进行妥善得分类和治理。 于是通过自建一套容器平台,来实现这些视频解决能力。抉择容器平台是因为进过评估和剖析,认为容器是最适宜用于解决媒体文件的技术形式。 容器能极大得进步零碎的资源利用率,为海量文件的解决提供计算能力;容器平台能提供很好的零碎弹性,满足不同时间段不同业务需要的工作运行;容器的标准化镜像便于降级治理和保护,可满足媒体解决能力需一直进行降级;容器能实现跨云的反对,不便将局部热点业务迁徙至私有云提供服务;容器平台能充分利用原有的服务器资源而不必放心硬件的兼容性和稳定性问题。KubeSphere 利用落地 以 “慢看苏州”的直播业务为例,该业务需要是将许多点位监控摄像头信号与指定的音频进行混合,为视频配上背景音乐,再推送至直播平台。在推动这个我的项目的过程中也通过了几轮测试:首先应用 ffmpeg 实现了视频和音频文件的合成,但因为摄像头数量十分多,且会随时进行调整,保护大量的 ffmpeg 过程并不可行,于是通过 Docker 以容器形式启动编码工作,最终将这些容器对立运行在 KubeSphere 平台上,为一个工作负载对应一个编码工作。 KubeSphere 功效剖析 KubeSphere 很不便得实现了编码工作的启动、进行、监控、调度、统计等性能,大大减少了咱们运维的工作量,且能及时发现编码过程中的异样,收到了很好的成果。 这只是咱们目前的一个尝试,下一步还思考将更多的视频解决能力迁徙至KubeSphere 容器平台,如视频转码、视频优化、人脸识别、语音辨认、语音合成、OCR 辨认、标签提取、视频水印、视频特征提取等,为媒体生产制作提供更弱小的服务撑持。 本文由博客一文多发平台 OpenWrite 公布!

June 11, 2021 · 1 min · jiezi

关于云计算:Litmus-实践让群魔在混沌中乱舞看-K8s-能撑到何时

对于云服务而言,如果零碎出现异常,将会带来很大的损失。为了最大水平地升高损失,咱们只能一直探寻零碎何时会出现异常,甚至放大到某些特定参数变动是否会造成零碎异样。然而随着云原生的倒退,一直推动着微服务的进一步解耦,海量的数据与用户规模也带来了基础设施的大规模分布式演进,零碎中的故障变得越来越难以预料。咱们须要在零碎中一直进行试验,被动找出零碎的缺点,这种办法被称作混沌工程。毕竟实际是测验真谛的唯一标准,所以混沌工程能够帮忙咱们更加透彻地把握零碎的运行法则,进步零碎的弹性能力。 Litmus 是一种开源的云原生混沌工程工具集,专一于 Kubernetes 集群进行模仿故障测试,以帮忙开发者和 SRE 发现集群及程序中的缺点,从而进步零碎的健壮性。 Litmus 架构Litmus 的架构如图所示: Litmus 的组件能够划分为两局部: PortalAgentsPortal 是一组 Litmus 组件,作为跨云治理混沌试验的管制立体 (WebUI) ,用于协调和察看 Agent 上的混沌试验工作流。 Agent 也是一组 Litmus 组件,包含运行在 K8s 集群上的混沌试验工作流。 应用 Portal,用户能够在 Agent 上创立和调度新的混沌试验工作流,并从 Portal 上察看后果。用户还能够将更多的集群连贯到 Portal,并将 Portal 作为跨云混沌工程治理的单个门户。 Portal 组件Litmus WebUI Litmus WebUI 提供了 Web 用户界面,用户能够在这里轻松构建和察看混沌试验工作流。Litmus WebUI 也充当了跨云混沌试验管制立体。 Litmus Server Litmus Server 作为中间件,用于解决来自用户界面的 API 申请,并将配置和处理结果详情信息存储到数据库中。它还充当各个申请之间的通信接口,并将工作流程调度到 Agent。 Litmus DB Litmus DB 作为混沌试验工作流及其测试后果详情的存储系统。 Agent 组件Chaos Operator Chaos Operator 监督 ChaosEngine 并执行 CR 中提到的混沌试验。Chaos Operator 是命名空间范畴的,默认状况下运行在 litmus 命名空间中。试验实现后,Chaos Operator 会调用 chaos-exporter 将混沌试验的指标导出到 Prometheus 数据库中。 ...

June 11, 2021 · 3 min · jiezi

关于云计算:云小课-华为云KYON之私网NAT网关

摘要:本文介绍KYON独创的私网NAT网关服务,反对云上重叠组网,反对云上重叠组网,助您的业务麻利上云。本文分享自华为云社区《云小课 | 华为云KYON之私网NAT网关》,原文作者:云小萌。 华为云KYON(Keep Your Own Network)企业级云网络解决方案,打造极简麻利的上云之路,助力企业极简布局,麻利迁徙,无缝交融,是企业上云的不二之选。以后企业在迁徙上云的过程中,存在本地数据中心组网布局简单、网段重叠的问题,妨碍着企业的上云之路。针对这一痛点,华为云KYON之私网NAT网关帮您解决。 华为云KYON独创私网NAT网关服务,反对云上重叠组网,可保留原有组网上云,无需从新布局,极大简化了业务迁徙上云过程。 NAT网关是什么?私网NAT网关(Private NAT Gateway),可能为虚构公有云内的云主机(弹性云服务器、裸金属服务器、云桌面)提供私网地址转换服务。自定义配置SNAT、DNAT规定,可将源、目标网段地址转换为私网IP,通过应用私网IP实现处于不同虚构公有云中具备重叠IP地址的云主机互访或实现指定IP接入远端私网中的数据中心或VPC。 私网NAT网关提供SNAT和DNAT两个性能: SNAT性能通过绑定直达IP,可实现VPC内跨可用区的多个云主机共享直达IP,拜访内部数据中心或其余VPC。DNAT性能绑定直达IP,可通过IP映射或端口映射两种形式,实现VPC内跨可用区的多个云主机共享直达IP,为内部私网提供服务。私网NAT网关反对大小网段灵便组网,IP网段可重叠,业务零革新,可升高企业上云的老本和危险。 如上图所示,两个本端VPC网段重叠,应用两个私网NAT网关,配置SNAT、DNAT规定,将本端VPC私网地址转换为直达IP地址,实现两个本端VPC中云主机利用直达IP互访,解决了VPC间网段重叠互访的问题;拜访远端私网中的用户数据中心(IDC)和VPC被要求指定IP地址接入,远端私网中的IDC和VPC别离通过云专线/VPN和对等连贯接入公共VPC,本端VPC应用私网NAT网关,配置SNAT规定,将本端VPC私网地址转换为指定IP地址,实现本端VPC中的云主机以指定IP地址接入远端私网。 中转子网——私网NAT网关服务中的直达网络。您能够在中转子网中创立私网IP,即直达IP,使本端VPC中的云主机能够共享该私网IP拜访用户IDC或同Region远端VPC。 公共VPC——中转子网所在VPC。 NAT网关的劣势华为云独创的私网NAT网关服务,反对大小网段灵便组网,具备简布局、易治理、零抵触和更平安的劣势。 简布局以后企业本地数据中心(IDC)组网布局简单,有重叠网段映射等诉求,企业上云之后须要保留原有组网不变。华为云私网NAT网关助力简化网络布局流程,实现IDC组网零批改迁徙上云。 易治理企业外部网络分层分域,多个部门之间会存在网段重叠的状况。应用私网NAT网关,企业迁徙上云后组网不调整,企业网络仍旧分层分域治理。 零抵触私网NAT反对私网地址映射,对网段重叠的VPC间进行私网地址转换,上云过程中IP地址无需批改,即便网段重叠也能互通和互访。 更平安企业往往须要对IP地址对立治理,私网NAT网关可将企业不同部门各自的网段地址映射为合乎企业平安标准的对立地址段进行互通。同时反对依据企业平安要求凋谢特定的IP地址和端口。 NAT网关如何配置?三步玩转私网NAT网关,如下图所示。 第一步:购买私网NAT网关拜访IDC或其余VPC,或对外提供服务,需先购买私网NAT网关。 第二步:创立中转子网和直达IPVPC内多个云主机需共享直达IP地址。 第三步:创立SNAT/DNAT规定创立SNAT规定,用于VPC内云主机拜访用户IDC或其余远端VPC; 创立DNAT规定,用于VPC内云主机对外部私网提供服务。 获取更多私网NAT网关信息,请戳这里。 点击关注,第一工夫理解华为云陈腐技术~

June 11, 2021 · 1 min · jiezi

关于云计算:平阴玫瑰×浪潮云洲见证一朵玫瑰的绽放

赠人玫瑰,手有余香。一支玫瑰,总让人想到浪漫与美妙。 6月8日举办的济南市工业互联网翻新倒退高峰论坛上,平阴玫瑰讲述了利用浪潮云洲智能制作解决方案,推动产业降级的案例,让人真切感受到平阴玫瑰的价值绽开。 从地标到市花 平阴玫瑰是国家天文标记产品,产自有着“中国玫瑰之都”名称的济南市平阴县,有着独特的品质要求。国家标准GB/T 19696《天文标记产品 平阴玫瑰》规定,玫瑰鲜花应为半开状态、色泽娇艳;鲜花蕾应全副露红、萼片全副裂开,处于丰满期。2021年4月,玫瑰增选为济南市市花,进一步晋升了平阴玫瑰知名度。平阴县玫瑰花种植总面积6万多亩,年产玫瑰鲜花2万余吨,加工企业42家,加工产品拓展到医药、化工、食用等畛域,研发出130多个品类,年产值约50亿元,带动5万余户花农增收致富。多年来,平阴玫瑰产业获得了长足发展,但同时也存在肯定的窘境难题。平阴玫瑰产业倒退核心主任刘勇坦言,产业正处于数字化转型降级的要害阶段,信息化程度落后,品牌溢价能力单薄,社会认知度较低等,已成为掣肘企业倒退的关键性问题。 建设产业服务平台与大数据中心 基于平阴玫瑰产业数字化转型需要,2021年1月,平阴玫瑰产业倒退核心联结浪潮云洲,建设工业互联网产业服务平台,以及产业大数据中心,摸索数字化背景下平阴玫瑰高质量倒退门路。一产种植方面,在玫瑰花田建设网格一体化物联网,预判玫瑰长势、产量及采收期;依靠标识解析体系,实现墒情、苗情、病虫情、灾情等“四情”数据的主动采集,以及花田、地块、种植户三者信息的主动关联,为20000余吨鲜花产能提供迷信服务保障;开发鲜花数字化采收零碎,代替传统开具纸质单据收花形式,实现对玫瑰花蕾、花冠、大花的分类采收、疾速统计和结算。二产加工方面,使用云计算等新技术,智能化革新鲜花烘干生产线,对产线各管制单元和水分检测设施进行联网,通过烘干数据边缘运算,实现生产线烘干速率的自动化管制;发展平阴玫瑰区域品牌数字化认证,进步认证效率及品牌经营能力。三产营销方面,在业务端,依靠标识解析体系,打造农户码、通货码、产品码、箱码、门店码“五码”关联系统,升高农户操作难度,晋升收花效率,帮忙企业治理经销商和终端零售店出入库;使用区块链技术,打造流通、生产、文旅交融倒退新模式。通过平阴玫瑰码,能够查问产品质量信息,构建用户画像,理解当地景点和特色文旅服务。“它是一二三产兼顾,不是一个简略的玫瑰种植,而是玫瑰产业的降级。”浪潮工业互联网党委书记、董事长肖雪示意,从智慧化种植到智能化生产,再到智慧化产品,浪潮云洲为平阴玫瑰提供软硬一体化工业设施和静默式智能革新,依靠产业链数据贯通与流动,驱动生产方式和企业状态改革,实现提质增效。平阴玫瑰产业大数据中心实时展现大屏显示,物联网设施、气象、土壤等环境信息,收花主体、收花品类、销售监控等产量剖析,网格数、赋码量、扫码监控等流通地图,数据高深莫测,动静实时把握,构建起平阴玫瑰工业大数据“一张网”,助力产业降级。 产业降级见实效 比照利用浪潮云洲工业互联网服务前后,刘勇举了两组数据。2021年玫瑰花均匀收购价格,由今年的每斤4元,增长到每斤7.7元,采收效率进步30%,企业结算效率进步90%。综合测算,玫瑰鲜花烘干生产线革新后,均匀每月帮忙一条中型生产线节俭近540个人工时,约10万元,鲜花的水分管制达标率进步至98%。平阴玫瑰联手浪潮云洲,实现了平阴玫瑰产业数字化,晋升了产业生产效率,拓宽了品牌宣传路径,实现了区域专用品牌动静监管,最终实现一二三产交融倒退,协同降级。“打造‘工业互联网+特色产业’倒退模式的平阴样板。”将来,平阴玫瑰心愿与浪潮云洲深入单干,联手生态搭档,赋能全产业链数字化、智能化降级,为促成农民增收、倒退县域经济、推动生态建设开拓新的增长极。

June 11, 2021 · 1 min · jiezi

关于云计算:阿里云李松林全球实时传输网络GRTN在互动直播中技术实践

2021年6月9日,亚太内容散发大会暨CDN峰会在北京举办,阿里云智能边缘云技术专家李松林受邀加入互动直播论坛,分享基于阿里云边缘云节点打造的寰球实时传输网络GRTN的设计思路、技术原理、特质与利用实际,以及面向直播利用客户提供稳固牢靠的业务体验。 图片 以后,支流的直播技术利用架构次要有两种:直推和回源拉流 ,产生这两种架构的起因也比较简单:一是业务场景须要连麦,须要低提早云合流;二是基于UDP的公有协定推流。为保障主播在弱网状况下能有较好的推流成果,而最重要的起因是目前支流云厂商还没有通用成熟的低提早互动场景大规模利用的服务,这就导致了他们须要自建源站。只应用云厂商通用的散发能力。反对 HTTPFLV 、RTMP 、HLS 大规模散发。 视频直播服务自建面临的挑战图片 随着直播场景和内容越来越丰盛和业余,互动的需要也越来越多,交互的提早要求也越来越高。原有的这套架构就很难满足需要了。因为无奈满足本人的业务需要,许多企业客户纷纷开始尝试自建源站,做协定优化, 然而因为直播技术门槛绝对较高,不仅须要投入资源,还须要业余的研发能力,同时后续还要长期继续运维和治理。 阿里云GRTN的定位图片 为了可能升高直播的端到端延时,阿里云从直播、短延时直播、RTC等利用场景登程,构建了GRTN(Global Realtime Transport Network)寰球实时传输网。李松林介绍,阿里云GRTN的定位是基于公共云核心Region和边缘云节点,构建超低延时、全分布式下沉的通信级流媒体传输网络。GRTN目前交融了互联网直播和RTC等多种业务场景的音视频流传输和替换。基于GRTN的短延时直播RTS能够反对规范H5 WebRTC推播,在千万级并发状况下延时能够管制在1s以内;RTC端到端延时能够管制在250ms左右。GRTN可提供三大原子能力:流的公布、订阅、切换,用户能够基于这些能力构建通话场景、直播场景、连麦场景等等。 阿里云GRTN的架构图片 阿里云GRTN 的整体架构是由原来的直播体系进化而来。该架构具备管制和数据拆散、混合组网、多路径传输、自学习Qos等技术特点,对外能够反对多种接入协定(rtc /rtmp / hls/ httpflv/ srt/ quic)。GRTN带来的外围价值有:降老本,GRTN是一个多业务交融的网络,能够反对直播、RTC和视频上云等多种场景,业务复用率高,另外GRTN外部链路更短,节点内的老本也更低。 提品质,GRTN外部组网反对采纳动静选路的形式来构建的网状结构,外部链路延时能够做到20ms左右,并且外部链路采纳了公有协定来进行高效传输。另外客户端的推流和散发都是基于WebRTC来构建的,QoS拥塞管制是专门针对流媒体个性来进行设计的,并且还在基于线上数据建设进行继续迭代和打磨。 易扩大,GRTN反对了WebRTC协定,能够在单个连贯通道上进行全双工的通信,从而能够很自在的进行公布和订阅媒体流,在业务的扩展性上带来了更大的设想空间。 GRTN关键技术-分布式异构部署图片 在谈到GRTN部署时,李松林指出,GRTN 的数据面能够在不同的资源上部署,实现一份代码,多种资源部署, 满足了低提早寰球笼罩的需要。不仅领有了CDN原有的节点笼罩资源 ,而且还反对核心Region和 MEC 等资源,让业务体验更优。 GRTN 的关键技术-对等组网和动静门路布局图片 针对丰盛的资源实现高效利用是外围。传统的门路布局次要关注品质 ,对节点的属性和水位等状况思考较少,同时因为流媒体的复用性,当一个流曾经呈现在某一个节点的时候,整个门路抉择就面临新的调整。目前的策略是通过探测选路寻找优质的节点和门路汇合。建设节点门路状态表。对每条门路的不同维度进行量化打分。综合权重和策略失去一个新的最优解。GRTN采纳了混合组网形式,即层级构造和对等图形形式相结合的组网的形式。选路核心会周期性收集外部链路探测的后果,为了配合动静组网,流媒体大脑模块须要对流信息进行治理,同时还须要反对门路切换、容量布局以及在老本和品质之间做综合的调度。 GRTN的关键技术-双向实时音讯网图片 有了管制面的门路布局和策略管制,如何疾速精确的下发到数据面的每一个节点,每一个机器也是挑战。在RTC场景下有一个比拟罕用的性能是客户端网络的Mobility,比方用户在散会的过程中回家或是来到家的时候手机网络须要在4G和wifi之间切换,另外思考客户端接入的CDN节点出现异常的时候,这两种状况都会造成客户端在和GRTN通信过程中切换接入节点,GRTN构建的双向的实时信令网可能做到切网音讯的毫秒级传递,当有一个公布端的媒体流产生网络切换后,订阅的客户端对GRTN外部产生的切换行为是齐全无感知的。 GRTN的关键技术-流媒体孪生图片 李松林介绍:GRTN借鉴数字孪生的思维设计了一个流媒体孪生(Streamimg Media Digital Twin)零碎,用于容量评估、算法训练、事件复盘和模仿压测等。通过将零碎分成事实和虚构两个环境。事实环境简单收集实在的场景和数据,虚拟环境负责做容量评估和算法训练。当批改了新的策略之后能够通过事实的历史数据输出到虚拟环境中利用新的算法。通过数据处理,生成数据报表比照之前这些数据在实在环境中的状况。这样就能够领导新的算法调优,也能够评估新算法是否无效。 GRTN的关键技术-可编程图片 媒体技术的下层业务场景十分丰盛,比方电商直播、视频会议、在线教育、企业直播、新批发等,因而有很多定制化开发的需要。可编程化革新是GRTN在晋升零碎稳定性上的一次尝试,目前GRTN的核心流媒体大脑,节点侧的业务模块,媒体数据发送模块、媒体信令解决模块等都曾经进行了可编程化革新,大部分状况下都能够防止二进制的公布。 GRTN的关键技术-全链路可视化监测图片 李松林认为,可观测性是评估一个零碎是否能够对外服务的根底。当线上呈现问题能够及时疾速的定位和解决,防止影响扩充。同时也能够通过观测零碎收集数据,一直优化零碎。 基于GRTN打造超低延时直播RTS图片 为了更加不便客户和行业拥抱GRTN,阿里云基于GRTN打造了超低延时直播服务RTS,其有四个技术个性:秒级延时和卓越的抗弱网能力,在雷同卡顿率下延时能够升高80%,相比于传统的RTMP和FLV的5-10s延时,RTS的延时能够达到1s以内,并且还在基于线上的大数据,在自我学习和继续迭代中。 成熟稳固,RTS历经2年多工夫的潜心研发,并经验了淘宝直播618大促的线上考验,目前曾经在淘宝直播上线。 凋谢规范,为了可能不便自研播放器的客户应用咱们的RTS服务,阿里云的WebRTC接入的信令协定的齐全凋谢的、通明的。 广覆盖和高并发,RTS服务是构建在阿里云2800+边缘节点之上,能够反对千万级并发播放。 李松林还分享了具体案例:淘宝直播在2020年双11首次大规模应用寰球实时传输网络GRTN的技术,交互体验失去了极大的改善,成交转化率失去进步,直播带货GMV晋升了5%。面向未来,越来越多的直播利用到人们的生存中,阿里云将继续加码直播畛域技术创新,买通直播的最初一公里,依靠遍布寰球2800+边缘云节点,提供稳固、牢靠、平安的直播服务,面向用户打造更靠近实在场景的直播体验。

June 10, 2021 · 1 min · jiezi

关于云计算:浪潮云说丨数据工场助力行业数据发挥生产要素新价值

近几年来,随着数据采集、数据处理、数据挖掘和数据算法等技术的一直成熟,在数字经济高速倒退的催生下,在党的十九届四中全会以及《对于构建更加欠缺的因素市场化配置体制机制的意见》等重要会议、文件政策的引领下,数据曾经逐渐深刻生产过程,逐步倒退成为继劳动、资本、土地、技术之外的第五大生产因素,为企业经营决策、商品服务内容、社会治理伎俩带来了新的价值增值。如何通过大数据、云计算、人工智能、区块链等新兴技术赋能,助力数据施展生产因素价值,实现数据对数字经济的“燃料”作用成为要害。 在此背景下,浪潮云IBP数据工场找到了“用武之地”。数据工场通过集成大数据、数据湖、人工智能等技术和工具,构建笼罩数据全生命周期的智能化一站式开发经营平台,提供大数据存储与计算引擎等数据底座,提供数据集成、数据开发、数据治理、数据服务、数据可视化等能力,实现数据资源化,帮忙政府和企业施行大数据和数据中台策略、实现数据驱动的业务智能,激活数据“生产因素”属性,推动数据参加到社会生产经营性流动中,实现数据因素与传统产业宽泛、深度交融,为数据使用者或所有者带来经济效益,推动政府和企业数字化转型降级和业务模式翻新,助力数字经济的倒退。 具体而言,IBP数据工场以数据赋能为指标,提供数据集成、数据存储与计算、数据开发、数据治理、数据服务、数据可视化等端到端一站式大数据解决方案能力: 通过数据集成获取各种起源数据,造成数据湖;提供Hadoop生态大数据服务,存储海量数据与计算;提供一站式数据开发工具,实现数据的加工解决;通过数据治理性能,落地数据规范、标准、模型及改善数据品质,治理数据资产,保障数据安全,实现数据可视、可管、可用;面向数据利用提供对立数据服务及数据可视化展示能力。浪潮云IBP数据工场依靠本身弱小的技术能力,取得了四项数据中心联盟大数据产品能力权威评测证书,包含分布式批处理平台根底能力测试证书、数据集成工具根底能力测试证书、数据管理平台根底能力测试证书、数据挖掘平台根底能力测试证书;并以优异成绩通过数据中心联盟大数据产品性能评测,在分布式批处理平台17项性能测试中,有12项超过历批次最优性能。浪潮云IBP数据工场通过多年的研发与实际,已广泛应用到政务、教育、水利等几十个行业数百个我的项目中,通过汇聚各行业数据资源,施展数据因素价值,推动行业数字化转型。数据引领将来,翻新成就幻想,浪潮云IBP数据工场将与合作伙伴共迎数据翻新的美好未来。

June 10, 2021 · 1 min · jiezi

关于云计算:2021亚太内容分发大会-阿里云荣获三项大奖

2021年6月9日,亚太内容散发大会暨CDN峰会在北京隆重举行。阿里云凭借在边缘云计算畛域的先发劣势、技术实力与丰盛实际,荣获“CDN领导力TOP3首领奖”、“边缘云领导力奖”、“互动直播经营奖”三项大奖。! 此次再度取得行业大奖,代表了阿里云边缘云节点服务在产品、技术、利用、规范等多方面失去了行业、市场的统一认可。 2021年5月28日,阿里云基础设施服务降级,边缘云节点作为阿里云基础设施服务之一正式发表商用,阿里云边缘云节点是飞天提供的凑近用户的边缘计算服务,依靠阿里云遍布寰球的2800+边缘云节点,通过凑近客户侧的去中心化小型云计算平台能力,实现了广覆盖、低时延、大带宽的技术特点,帮忙客户解决在音视频、游戏、终端虚拟化等利用场景中遇到的算力、网络、部署和时延问题。 阿里云曾经和行业合作伙伴独特打造了5大场景和15个细分市场的解决方案,笼罩交通、新批发、教育、智慧住建、家庭等场景实现数字化降级。

June 9, 2021 · 1 min · jiezi

关于云计算:引领-TEE-行业实践SOFAEnclave-通过权威认证

在当下云计算和数据暴发的时代,企业、组织、集体都会面临这样一个问题:一方面心愿本人的数据上云享受数据单干的红利或者服务的便当,一方面又对云计算提供商或服务提供方如何应用和爱护本人的数据心存担心。绝对于集体终端或企业外部设施上的本地数据保护,云端数据因其流动性和应用方转移,波及的信赖和爱护问题显著更加简单。 基于可信执行环境(TEE)的平安计算(国外常称为秘密计算)能够保证数据应用时平安,联合数据网络传输平安、数据存储平安,咱们第一次惊喜地看到了数据全生命周期平安的可能性,看到了技术代替商业承诺晋升数据安全和用户信赖的心愿。所以云端TEE这一新兴技术一经推出,立马引起了学术界和工业界的宽泛关注。 用户隐衷爱护和合规始终是蚂蚁团体的第一优先级工作。SOFAEnclave 平安计算平台正是蚂蚁敏锐察觉和追随 TEE 技术趋势,很早就投入研发的平安计算产品。最近 SOFAEnclave 通过中国通信标准化协会(CCSA)《基于可信执行环境的平安计算零碎技术框架》行业标准全副测试项,成为首个通过该规范的平安计算产品。从启动测试计划到最终通过所有测试项目,整个规范测试过程历时1个月左右,最终取得现场评审验收专家的认可。本文心愿跟读者分享一些对规范的了解和测试教训,供大家参考。 TEE 技术计划百花齐放,信通院行业标准应时而生依照 Gartner 2020 年云端平安技术预测,基于 TEE 的平安计算还处于较晚期的自在倒退阶段。从最开始的 ARM TrustZone,到 Intel SGX、AMD SEV、Keystone,再到行将推出的 Intel TDX、ARM CCA,还有一些其余相似 AWS Nitro Enclave 虚拟化计划等等,百花齐放的背地随同的是差异化倒退。这些 TEE 计划在体系结构、隔离模式、接口反对和可信模型方面都存在很大区别。 因而,咱们心愿整个业界有对立的对于 TEE 的参考标准,领导行业有序倒退。《基于可信执行环境的平安计算零碎技术框架》就是在这个背景下,由中国信息通信研究院、中国移动牵头,蚂蚁团体发动,华为、腾讯、百度、光之树、Oppo、360、高通、大唐电信、中国电信、如家首旅、上海交大等诸多行业领军的产学研机构独特参加的平安计算行业标准。规范的参加阵容十分弱小,权威性毋庸置疑。 TEE 规范的技术要求与指导意义首先,规范的推出能够帮忙咱们了解 TEE 技术的实质,对症下药地进行 TEE 技术选型。咱们面对泛滥的 TEE 技术,如何界定其安全性?如何抉择适合的 TEE 技术产品?规范被及时推出,帮忙咱们拨开乌云见晴天。规范中提出的一些 TEE 根本技术要求总结如下: 硬件信赖根:一个真正技术中立和可信的 TEE 计划肯定是基于不可篡改和假冒的硬件信赖根,从而构建软硬件一体的可信执行环境。隔离性:TEE 技术一个最根本的机密性保护方式就是隔离可信执行环境和非可信执行环境。另外,大部分 TEE 技术都提供内存加密引擎爱护运行中数据和代码的机密性。完整性:TEE 技术计划通常提供近程证实等伎俩确保可信利用的完整性。可用性:一个实用的 TEE 技术计划应该在生产环境性能损耗、额定老本、施行复杂度方面都是可承受的。其次,规范的另一个重要意义在于通过业界共识领导咱们设计一个真正平安的 TEE 平安计算零碎。规范中给出了平安计算零碎的定义和平安计算零碎设计参考技术架构。同时也从多个方面全面残缺地定义了总计 74 项基于 TEE 的平安计算零碎的各项要求,详细情况如下图: 其中: 性能要求:包含平安零碎中各软件层级的性能要求,而且特地提出了偏理论生产的要求,比方集群治理和监控运维相干要求。这些要求即体现了对系统的实用性的导向,也交融了平安设计贯通整个软件生命周期的理念。隔离性要求:标准了对 TEE 技术个性自身的要求。性能要求:对TEE技术规定了肯定门槛。兼容性及可用性要求:对系统设计的兼容性、健壮性提出肯定要求。通用平安要求及数据安全要求:体现了 TEE 平安计算零碎的指标是平安计算,而平安计算的实质是保证数据在计算时的平安。SOFAEnclave 平安计算平台成为首个通过信通院平安计算行业标准测试的产品SOFAEnclave 平安计算平台的设计初衷就是服务蚂蚁外部大标准集群化业务应用场景,是一款面向生产环境的产品。同时 SOFAEncalve 也被冀望用到联结风控、多方数据合作、区块链可信计算、敏感数据爱护等多技术畛域和业务场景。如何设计好这样一个偏底层、笼罩广的平安计算零碎,咱们的设计思考过程和上述规范中的要求是根本相符的。 ...

June 9, 2021 · 1 min · jiezi

关于云计算:Kubernetes-的自动伸缩你用对了吗

本文翻译自 learnk8s 的 Architecting Kubernetes clusters — choosing the best autoscaling strategy,<u>有增删局部内容</u>。 TL;DR: 在默认设置下,扩大 Kubernetes 集群中的 pod 和节点可能须要几分钟工夫。理解如何调整集群节点的大小、配置程度和集群主动缩放器以及适度配置集群以放慢扩大速度。 主动扩展器在 Kubernetes 中,常说的“自用扩大”有: HPA:Pod 程度缩放器VPA:Pod 垂直缩放器CA:集群主动缩放器不同类型的主动缩放器,应用的场景不一样。 HPAHPA 定期检查内存和 CPU 等指标,主动调整 Deployment 中的正本数,比方流量变动: VPA有些时候无奈通过减少 Pod 数来扩容,比方数据库。这时候能够通过 VPA 减少 Pod 的大小,比方调整 Pod 的 CPU 和内存: CA当集群资源有余时,CA 会主动配置新的计算资源并增加到集群中: 主动缩放 Pod 出错时比方一个利用须要 1.5 GB 内存和 0.25 个 vCPU。一个 8GB 和 2 个 vCPU 的节点,能够包容 4 个这样的 Pod,完满! ...

June 9, 2021 · 3 min · jiezi

关于云计算:发展云原生技术推动数字化建设陈纯院士受邀致辞云原生产业大会

5月26日,由中国信通院主办的,云计算开源产业联盟、中国信通院云原生产业联盟、云原生计算基金会(CNCF)反对的“2021年云原生产业大会”在京召开。中国工程院院士、浙江大学传授陈纯应邀发表视频致辞。 陈纯院士指出:“云计算是数字基础设施建设的核心技术,也是《十四五布局和2035年近景指标大纲》重点布局的数字经济产业。作为最新的云计算技术理念,云原生逐步被宽泛承受并成为行业趋势,云计算倒退和利用进入到云原生阶段”。 云原生是施展云效力的最佳实际门路 云原生是面向云利用设计的一种思维理念,是云计算畛域煊赫一时的支流技术,极大地开释了云计算红利,成为施展云效力的最佳实际门路。随着全行业上云的逐渐深入,云计算的倒退利用已进入云原生阶段。 陈纯院士从三个方面剖析了云原生产业倒退的意义和趋势: 从技术特色来看,云原生具备极致的弹性能力、故障自愈能力以及大规模可复制能力,使得云平台的运维更简略。 从利用价值来看,云原生实现了异构资源标准化,减速了数字基础设施降级,晋升了业务利用的迭代速度,使云资源和利用更“便宜”。 从产业交融来看,云原生为其余信息技术大规模利用提供了重要撑持,可能为区块链、人工智能、大数据、边缘计算等新兴技术提供部署环境和根底撑持能力,对于建设交融、共赢的产业生态具备促进作用。 云原生面临重大倒退时机,放慢人才培养 以后,倒退云原生已是大势所趋,行业内正热火朝天的推动云原生的技术钻研和落地实际,云原生进入蓬勃发展期。 陈纯院士示意:“云原生面临着重要倒退时机:数字中国建设为技术创新和产业倒退提供了良好土壤;云原生技术倒退总体与国内同步,无望实现要害核心技术的自主翻新。 核心技术的冲破与产业的倒退离不开人才的培养,浙江大学积极参与国内社区,成为云原生基金会开创会员,十年来为国内造就了一大批云原生技术的中坚力量”。 最初,陈纯院士心愿与会专家对我国云原生关键技术和产业利用的现状及趋势进行深刻研究,凝练技术问题,促成产业倒退,这对于我国抢抓新一代信息技术倒退时机,建设创新型国家和世界科技强国具备非常重要的意义。

June 7, 2021 · 1 min · jiezi

关于云计算:一口气了解2021-阿里云峰会重磅发布

一口气理解阿里云现场的重磅发表飞天再进化:一云多芯、本地 Region、计算巢在主会场的演讲中,阿里云根底产品负责人蒋江伟颁布了飞天操作系统最新的进化方向:一云多芯、本地 region、计算巢。蒋江伟示意,飞天是中国惟一的自研云操作系统,阿里云将保持 “做深根底” 的技术策略,从飞天云操作系统向下延长定义硬件。 在能力晋升的同时,飞天提供了丰盛的部署状态。首先,阿里云推出本地 region 服务,让公共云从核心 region 延长到本地 region,减少笼罩密度,满足客户对于低延时、区域网络覆盖的诉求。本地 region 将部署在南京等十余个地区,提供计算、存储、数据库等 40 多种云产品。同时,本地 Region 的实质仍是公共云,领有统一的操作体验,开发人员无需放心提早和性能之间折中的限度。 其次,阿里云推出边缘云节点,不仅可用于内容散发、视频点播,更适宜视频直播、在线教育、云游戏等对时延要求极高的场景。在原有 CDN 减速的根底上,边缘云节点将视频、图片等内容的计算前置,进行就近计算,从而晋升用户体验。目前,阿里云在寰球领有 2800 多个边缘计算节点,超 150Tbps 带宽储备。 最初,阿里云还提供了可在客户本地部署的云盒,开箱即用,将公共云延长部署到企业数据中心或指定的边缘数据中心,实现软硬全托管免运维、享受和公共云统一的服务体验的计算服务。 一站式数据服务 为数据智能而生脱胎于海量数据和 AI 需要,“南征北战” 的阿里云能为各行各业提供数据中台、数据引擎、数据库、大数据分析等平台级能力。基于这些能力,阿里云推出了一站式数据服务,笼罩从数据获取、数据存储、数据资产治理、数据分析和数据利用的全生命周期,为批发、政务、金融、医疗、制作等重点行业提供全链路的数据服务。该平台的推出让企业级用户在云上不仅能享受到平安便捷的 IT 资源,更可通过一站式的数据智能服务推动业务的数字化、智能化。 第七代 ECS 云服务器正式商用 算力晋升 40%往年 2 月,阿里云对第七代 ECS 云服务器家族进行了公测,基于第三代自研神龙架构,相较于上一代整体算力晋升 40%,针对目前最风行的容器进行了优化,最多可晋升 6 倍部署密度,并全量搭载平安芯片,是最佳的云原生载体。 减速推动云钉一体云钉一体能力进一步降级,钉钉将宜搭、氚云、简道云等钉钉低代码生态产品聚合,企业和集体开发者能够按需选购。同时,钉钉将凋谢更多的底层能力,晋升开发体验,致力于成为业界最凋敝的利用开发平台。 往年 1 月,钉钉公布低代码开发平台,让企业能够间接在钉钉上开发利用,低代码利用快速增长。截止到 2021 年 3 月 31 日,钉钉平台利用总数超百万,3 个月增长了近一倍,其中低代码利用 3 个月工夫增长了近 38 万。 这是阿里云另一项独特劣势。企业不需间接在传统 IT 服务器或者云基础设施上开发利用,而是通过钉钉采纳低代码或无代码的形式开发,放慢翻新效率。 张建锋示意,云钉深度交融之后,钉钉成为企业应用云的一个全新界面,越来越多的企业对云和钉钉的需要增长显著。山东能源、鲁花团体、越秀地产、立白、百丽、蒙牛、复星、卡宾等企业同时减少了对云和钉的应用。 例如,山东能源从 2016 年开始应用钉钉办公,联合了云的底层能力,让团体业务零碎和数据可能实时和钉钉买通,减速了利用开发的效率,速度快时,在 15 天内上线了 5 款利用。 ...

June 7, 2021 · 1 min · jiezi

关于云计算:云钉一体应用创新音视频如何带来灵活高效的协同体验

云钉一体的阿里云音视频解决方案,将音视频与协同各业务紧密结合,实现员工、业务及设施的全链接,为客户提供线上线下,软件端到会议室的端到端音视频协同办公体验。阿里云视频云负责人林昊与罗技策略产品事业部总经理陈进宇,在阿里云峰会的【超级探访】中独特探讨阿里云音视频会议与罗技硬件设施如何联合打造灵便高效的音视频会议,讲述音视频是如何带来灵便高效的协同体验。 将来挪动协同会利用在哪些场景,视频化是不是协同的必然?2021 年,阿里云 “云钉一体” 能力曾经进一步降级,无论是在技术层面还是场景落地层面。家喻户晓,挪动协同利用已利用在各行各业。随着挪动网络及智能手机的倒退,利用已从最后以文本为根底的邮件浏览,流程审批场景演进到以实时音视频通信为根底的声音及图像合作。 这次疫情中,无论是复工不停产还是复课不停学,近程音视频合作的广泛应用均起到了很大的撑持作用。比方钉钉音视频在疫情期间撑持了超过 1.2 亿的并发音视频通话,同一时刻召开的会议超过 2000 万场。这都体现了用户工作外围的转变。传统的工作外围,基于本地化部署,集体文档、邮箱、会议零碎都是单点宰割,彼此独立,而现在的工作外围,强调在线合作、流程治理,更须要基于云的连贯,将人与工作串连起来,无论是内外部沟通、还是培训、研究,都产生了更多元化的音视频需要。 罗技策略产品事业部总经理陈进宇示意,将来挪动协同肯定存在于所有须要沟通的中央,贯通职场人的工作全流程,近程办公形式的遍及让工作和协同能够更灵便地呈现在家里,在路上,办公室的集体工位以及不同类型的会议室里。钉钉平台通过挪动端买通了合作的各个场景,会议室场景为多人线下线上提供了极致的音视频合作体验,这种极致良好的体验会拉动必然的趋势。 然而,任何新兴的技术和模式的利用都须要经验理念遍及和习惯养成的过程,近程视频合作的利用也是一样。在疫情以前,中国的近程合作绝对寰球还处在一个比拟高级的阶段,而 2020 年近程合作需要的暴发和视频协同利用的遍及帮忙中国的企业用户开始向视频的合作形式转型。当习惯养成当前,这是一个不会逆转的趋势,大家回到线下的办公室和会议室,视频合作带来的效率晋升和对于差旅老本的升高会进一步促成整个企业向视频合作的形式转型。用户对于近程沟通中音视频的成果和智能合作体验的需要,将会进一步带动企业从集体端到会议室级视频合作解决方案部署的需要。因而在罗技看来,视频合作硬件和计划的市场需求还十分微小,而且会有越来越多的企业退出到这一数字化转型的过程中来。 挪动协同场景中,哪些技术最要害?阿里云视频云的布局如何?随着挪动办公成为一个不可逆的趋势,这类产品对音视频技术的要求逐步变高。阿里巴巴研究员、阿里云视频云负责人林昊示意,基于服务钉钉上近百万音视频合作企业用户,咱们发现在企业音视频合作方面,客户最关怀如下三点: 稳固牢靠、不卡顿一直线的根底体验。简略易用,随时随地的应用体验。全交融,反对语音及硬件设施对接,连接线下线上。针对如上三点,阿里云视频云在技术及解决方案上积淀了很多教训: a. 阿里云寰球网络基础架构,反对音视频的就近接入,同时基于视频云、达摩院在音视频编解码上的劣势,在弱网抗性、多端适配,端到端状态监控上都有本人独特的劣势。 b. 基于钉钉,将音视频带入业务流程,基于会前、会中、会后的整体合作场景设计。用户只需简略的几步操作,就能够实现预约、告诉、邀会、文字记要、同传、PPT 分享、会议管制乃至最初会议论断执行跟进等一整套合作链路。 c. 对于线下物理音视频合作场景的反对,除了云端联合的自研会议硬件(F1,阿里云视频云与罗技单干的 B1000)外,还包含与 Sip 规范会议硬件的对接,与 PBX 语音零碎的对接,咱们都做了欠缺的解决方案,阿里云的音视频能够间接与规范会议 MCU 级联,也能够实现与电话零碎的互通,实现如同振、号码暗藏、集体软电话等各种利用。 除了技术自身,从客户视角来看,不论是软件还是硬件都是一个综合的体验。陈进宇示意,对这类解决方案的最根本要求是听的清晰、看的高清、不掉线、不卡顿、入会简略、操作不便,并且可能拓展多元化需要,对于散会中的音视频能够展示高保真体验的要求越来越高;部署和治理以及运维既要简略灵便又要业余牢靠;随着 AI 技术的倒退和亲民化以及对于效率一直晋升的要求,大家潜在的需要开始凸显,利用 AI 语音技术实现会议记录小秘书,屏幕显示实时字幕,跨国会议的实时翻译,以前在科幻片外面的场景都将成为事实。 对于客户的反馈和期待,林昊谈到残缺的线下会议场景解决方案,从钉钉智能会议室管理系统(预约、申请、抢占、调配)到各类型的视频会议设施、无线投屏、会议室门禁信息板等均有欠缺的解决方案;打造会议室 IOT 治理平台,综合监控管制会议声光电空调新风等各设施状态,实现线下会议场景近程运维及治理,升高应用及保护老本;同时,做好与线下各会议设施的连贯,从 USB 状态 BYOD 的音视频设施到生态业余的音视频设施,都能够不便的对接互通;联结行业业余的会议 ISV 及 SI,基于客户理论应用场景打造业余对立的会管会控系统,满足客户客制化需要;基于达摩院及阿里云在 AI 上的积攒,包含会中的文档记录、人脸识别点名签到、主动翻译,图像增强等,将在上述的线下及线下会议场景中广泛应用,给用户更好的体验及了解。 视频会议广泛应用的明天,线下会议室还重要吗?软硬一体是外围和刚需吗?除了线上视频会议,线下会议室仍旧是一个无奈被代替的重要场景,只是会议不再是传统的上传下达式的单方面信息传递,而更多地会成为互动沟通和独特合作的空间场景。陈进宇示意,钉钉专一的是把所有场景里的人通过钉钉分割起来建设协同,罗技专一的是不同场景的人用钉钉连贯时都有最好的看见,听见,互动的硬件体感,软硬一体的视频合作计划将会成为线下会议室的标准配置。 从技术层面来说,线下物理会议空间的笼罩,离不开摄像头、麦克风、编解码器、业余导播台、音视频矩阵等这类业余的设施,能够说,良好的音视频体验来到硬件就是无本之木。而音视频软件的能力又决定了最终音视频的编码解决能力,传输稳定性、挪动端的适应性、业务性能的丰盛水平。来到了软件的硬件视频会议零碎,是很难实现挪动端、桌面端的大规模接入以及更多会议业务的联合,会议的整体体验也就成了无源之水。能够说软硬件在音视频协同解决方案中缺一不可。为了实现统一的入会体验,更好的会议成果,软硬一体的原生解决方案是最好的抉择。 将来,音视频合作场景会越来越多,线上与线下将越来越严密,也越来越无缝。一方面来自政府和国企,数字政府和智慧党建让合作更深刻政务办公,政府散会从传统的、复线基于业余物理会议场景的上传下达逐步演变为线上线下对立的多元、多方、多端交换。另一方面,咱们也看到,高性价比小型会议室解决方案的呈现,也推动着中小企业从 C 端通信工具转向抉择更为业余、高性价比、体验更好的会议工具。同时如室内凋谢空间、室外凋谢空间、集体家庭空间、共享办公空间的音视频合作,也是线下音视频合作的场景,置信这些场景会越来越多,这也是阿里云音视频会议后续会逐渐笼罩的场景。 直播间链接传送:https://www.yizhibo.com/l/Rvp... 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实际技术文章,在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云技术交换群,和作者一起探讨音视频技术,获取更多行业最新信息。

June 7, 2021 · 1 min · jiezi

关于云计算:干货收藏Calico-路由反射模式权威指南

1. 概述作为 Kubernetes 最长应用的一种网络插件,Calico 具备很强的扩展性,较优的资源利用和较少的依赖,相较于 Flannel 插件采纳 Overlay 的网络,Calico 能够通过三层路由的形式采纳性能更佳的 Underlay 网络,Calico 网络插件的转发效率是所有计划中较高的。 在应用 Calico 网络插件的理论生产环境当中,为了进步网络的性能和灵活性,须要将 K8S 的工作节点和物理网络中的 leaf 交换机建设 bgp 街坊关系,同步 bgp 路由信息,能够将 pod 网络的路由公布到物理网络中。Calico 给出了三种类型的 BGP 互联计划,别离是 Full-mesh、Route reflectors 和 Top of Rack (ToR)。 Full-mesh全互联模式,启用了 BGP 之后,Calico 的默认行为是在每个节点彼此对等的状况下创立残缺的外部 BGP(iBGP)连贯,这使 Calico 能够在任何 L2 网络(无论是私有云还是公有云)上运行,或者说(如果配了 IPIP)能够在任何不禁止 IPIP 流量的网络上作为 overlay 运行。对于 vxlan overlay,Calico 不应用 BGP。 Full-mesh 模式对于 100 个以内的工作节点或更少节点的中小规模部署十分有用,然而在较大的规模上,Full-mesh 模式效率会升高,较大规模状况下,Calico 官网倡议应用 Route reflectors。 Route reflectors如果想构建外部 BGP(iBGP)大规模集群,能够应用 BGP 路由反射器来缩小每个节点上应用 BGP 对等体的数量。在此模型中,某些节点充当路由反射器,并配置为在它们之间建设残缺的网格。而后,将其余节点配置为与这些路由反射器的子集(通常为冗余,通常为 2 个)进行对等,从而与全网格相比缩小了 BGP 对等连贯的总数。 ...

June 4, 2021 · 8 min · jiezi

关于云计算:使用-Cilium-作为网络插件部署-K8s-KubeSphere

Cilium 简介Cilium 是一个用于容器网络畛域的开源我的项目,次要是面向容器而应用,用于提供并通明地爱护应用程序工作负载(如应用程序容器或过程)之间的网络连接和负载平衡。 Cilium 在第 3/4 层运行,以提供传统的网络和平安服务,还在第 7 层运行,以爱护古代利用协定(如 HTTP, gRPC 和 Kafka)的应用。 Cilium 被集成到常见的容器编排框架中,如 Kubernetes 和 Mesos。 Cilium 的底层根底是 BPF,Cilium 的工作模式是生成内核级别的 BPF 程序与容器间接交互。区别于为容器创立 overlay 网络,Cilium 容许每个容器调配一个 IPv6 地址(或者 IPv4 地址),应用容器标签而不是网络路由规定去实现容器间的网络隔离。它还蕴含创立并施行 Cilium 规定的编排零碎的整合。 以上简介来源于 oschina对 Cilium 的性能比拟感兴趣的读者能够参考这篇文章: 最强 CNI 基准测试:Cilium 网络性能剖析 零碎要求Linux Kernel >= 4.9.17更多信息请查看 Cilium 零碎要求 环境以一台 Ubuntu Server 20.04.1 LTS 64bit 为例 nameiprolenode110.160.6.136etcd, master, worker下载安装包sudo wget https://github.com/kubesphere/kubekey/releases/download/v1.1.0/kubekey-v1.1.0-linux-64bit.deb应用 cilium 作为网络插件部署 KubeSphere1.装置 KubeKey sudo dpkg -i kubekey-v1.1.0-linux-64bit.deb2.生成配置文件 sudo kk create config --with-kubernetes v1.19.83.批改配置文件,将网络插件批改为 cilium留神将spec.network.plugin 的值批改为 cilium ...

June 4, 2021 · 2 min · jiezi

关于云计算:在云原生场景下构建企业级存储方案

引言随着云原生技术日益遍及的明天,在 Kubernetes 上运行无状态利用曾经十分成熟,平滑扩大能力也很强,但对于有状态的利用,数据须要长久化存储,这还有很大晋升的空间,面临着很多挑战。 云原生存储的挑战 上图是 CNCF 对于“在应用/部署容器的过程中遇到的挑战”做出的调查报告。依据报告的后果,能够总结出云原生存储遇到的挑战体现在以下几个方面: 易用性:存储服务部署、运维简单,云原生化水平低,短少与支流编排平台整合高性能:大量利用 IO 拜访,IOPS 需要高,低时延,性能成为利用运行效率瓶颈高可用:云原生存储曾经利用到生产环境,须要高牢靠/高可用,不能呈现单点故障敏捷性:PV 疾速创立、销毁、平滑的扩大/膨胀,PV 随 Pod 迁徙而疾速迁徙等常见云原生存储解决方案Rook-Ceph:Rook-Ceph 是一个能够提供 Ceph 集群治理能力的 Operator,应用底层云原生容器治理,调度和编排平台提供的性能来执行其职责。 OpenEBS:OpenEBS 存储控制器自身就运行在容器中。OpenEBS Volume 由一个或多个以微服务形式运行的容器组成。 劣势1.与云原生编排零碎的交融,具备很好的容器数据卷接入能力;2.齐全开源,社区较为沉闷,网络资源、应用材料丰盛,容易动手; 劣势Rook-Ceph 有余: 性能差:IO 性能、吞吐、时延等方面都体现欠佳,很难利用在高性能服务场景;保护老本高:尽管部署、入门简略,但组件多,架构简单,排错艰难,一旦运行中呈现问题解决起来十分辣手,须要有很强的技术团队加以保障;OpenEBS-hostpath 有余:没有高可用性能,单点故障;OpenEBS-zfs-localpv 有余:在磁盘上装置 zfs,而后在 zfs上 创立 vol,也是没有高可用性能; 因而多在企业内部测试环境,很少用于长久化要害利用数据,部署到生产环境中; NeonIO 为什么适宜云原生存储NeonIO 简介NeonIO 是一款反对容器化部署的企业级分布式块存储系统,可能给 Kubernetes 平台上提供动态创建(Dynamic Provisioning) 长久存储卷(Persistent Volume) 的能力,反对 Clone、Snapshot、Restore、Resize 等性能,NeonIO 的结构图如下: NeonIO 包含的服务组件如下: zk/etcd: 提供集群发现、分布式协调、选 master 等服务mysql:提供元数据存储服务,如 PV 存储卷的元数据center:提供逻辑治理服务,如创立 PV 卷,快照monitor: 提供监控服务,可能把采集监控指标裸露给 Promethusstore:存储服务,解决利用 IO 的性能portal:提供 UI 界面服务CSI:提供 csi 的规范 IO 接入服务上面从以下几个方面来看 NeonIO 为什么适宜云原生存储: ...

June 4, 2021 · 2 min · jiezi

关于云计算:阿里云江岑云原生在边缘形态下的升华

5月20-22日,第十三届中国零碎架构师大会(SACC2021)在云端进行网络直播,主题为“数字转型、架构重塑”。阿里云边缘云原生技术专家江岑,分享了阿里云在边缘云原生的摸索实际,并从应答技术挑战与零碎架构设计等方面论述产品外围竞争力,以翻新技术驱动业务倒退。 云原生倒退与现状 图片 随着云计算技术的成熟,大多数企业抉择云计算来疾速部署经营业务。5G规模商用,更是促成寰球数百亿的终端设备联网。客户对于低时延、大带宽的近端准实时计算需要将大大增加。边缘云计算市场规模的增长,一方面来自于核心业务的下沉边缘,另一方是各类边缘翻新业务场景的呈现和倒退,例如云游戏,智慧城市等。 江岑认为,企业业务零碎上云,无论是上核心云还是边缘云,大都会经验三个阶段: 自建IDC的迁徙,基于稳定性以及灾备等因素思考,不会对业务架构有大调整,大部分只应用最根底的云服务,如ECS, SLB, VPC等; 整体业务上云,从全面复用云的能力和提效降本的角度登程,随云而生的架构演进也逐渐开始灰度利用。 当所有就绪,业务开始大规模拥抱云原生。 而现阶段,很多上云业务曾经在大规模推动云原生化。 云原生概念最早来自CNCF云原生计算基金会,Google孵化的Kubernetes平台。CNCF成立于2015年底,已孵化了大量合乎云原生规范的优质我的项目,外围模块蕴含数据库、消息中间件、利用编排调度、CICD继续集成、RPC、 服务网格、容器服务、云原生网络等等。 当初,云原生技术曾经不局限于容器/Kubernetes畛域,逐步成为宽广云厂商中立的软硬件基础设施的规范架构。边缘计算是在最近3-5年内随着5G、物联网技术利用而逐渐衰亡的技术,其技术成熟度还远低于核心云计算,目前CNCF上波及边缘计算的我的项目还不多。随同着边缘场景以及配套能力的晋升,核心大量业务下沉到边缘,边缘翻新场景不断涌现,必然会在边缘侧催生合乎边缘特色的云原生技术。 边缘云原生演进面临的挑战 图片 在谈到云原生技术如何向边缘演进时,江岑提到了3个技术挑战: 从资源侧看,边缘不同于核心大规模集中式的布局,次要以分布式和高地区覆盖率为指标建设。除了核心规范的云服务器,在边缘侧还存在大量的异构资源,包含物联网设施、MEC、单干共建节点等等。云原生技术对部署环境是有明确要求的,因而须要对边缘侧海量的异构资源做灵便的适配。另外,边缘节点的特点是小而多,晋升资源复用率是要害,这就要求可能依据资源池化的能力和资源性能做灵便的弹性调度。 从技术能力来看,云边基础设施存在差别,云原生能力间接下沉利用到边缘时,除了须要提供等同于核心的性能指标、平安隔离、容灾自治、架构感知等能力,还须要不断完善云边以及边边高速通道建设等,进而晋升建设难度系数。 当资源适配、技术能力已具备时,放弃用户体验统一会面临很大的挑战。从用户视角来看,核心业务下沉过程势必是个漫长的过程,对于繁多业务核心和边缘可能处于长期并存的状态,云边的能力建设很可能存在不统一,大部分的不统一对于用户应该是无感的,所以如何包装产品,在老本、性能、性能、稳定性等各方面达到云边统一的体验,是极具挑战的。 阿里云边缘云原生体系建设 依靠遍布寰球2800+边缘云节点,阿里云面向用户提供平安、稳固、牢靠的边缘计算和内容散发减速服务,构建离用户最近的边缘云基础设施。单个节点是一个小型的IDC,规模在几台到几十台服务器不等。晚期边缘云节点建点策略是和CDN离开独立建点,导致资源无奈共享,短少业务。目前建设策略是推动CDN ON ENS资源交融生产,整合边缘算力资源,交融后也给资源的分时复用带来更大的可能性。 图片 CDN作为最成熟的边缘云利用场景,经验了长期的技术架构演进,其基础设施软硬件架构能够复用到边缘云技术中。源站通常为企业自建的服务器,规模及性能绝对于核心云是比拟无限的。在业务上线晚期能够失常运行,但随着业务的增长,面对海量的客户端申请,如果没有CDN,企业只能减少资源投入,否则可能会造成服务端的响应超时甚至服务瘫痪。而CDN通过多级缓存以及全局的DNS调度能力,使用户能就近拜访所需的资源(特地是图片、视频等动态资源),防止对源站带宽和服务器造成适度的压力。因为满足不同地区的用户就近接入,能够认为CDN人造具备低时延、全局大带宽的边缘云计算典型特点。撑持CDN的监控、数据智能、配置管理等零碎,具备规范的边缘海量数据散发、解决,以及和核心交互的能力,也将逐渐演进为边缘云原生的配套规范零碎。 图片 依据阿里云边缘云原生的能力模型定义可知:在资源侧,次要是将异构资源(蕴含传统物理机,云联节点,IoT/MEC设施,ARM阵列服务器等)进行并池云化,在这之上提供边缘云节点操作系统,将计算、存储、网络资源进行虚拟化,并联合容器/K8S规范云原生的能力进行模块化能力构建以及对应边缘规范生态延长输入社区,比方面向业务须要有全网全集群利用生命周期治理、编排公布的能力,对应到阿里云有定义边缘CRD operator EdgeWorkload提供能力,定义OAM编排扩大能力。面向平台管理员,像多集群治理,租户隔离,元数据管理等也是在边缘海量用户海量数据场景下也须要相应的能力定制。另外边缘存在大量分布式异构资源,如何最大化利用资源,须要依赖于全局的容器调度器联合业务相干的全局流量调度散发策略。弹性伸缩HPA/VPA的场景也是面向边缘分布式的解决方案。 阿里云领有遍布寰球各地的资源,须要对异构资源纳管模块定义分区域的布局策略,进行布局接入,围绕核心管控+边缘自治+多重缓存的形式进行开展。 思考边缘云的架构复杂度、海量节点数量、异构资源差异性等因素,阿里云通过不断完善零碎可观测性和强化Devops运维建设能力,来晋升零碎稳定性。 同时,阿里云边缘云原生具备异构交融广覆盖、云边体验一致性、规范云原生兼容、算力全域流动性等技术劣势。 典型边缘云业务利用 图片 晚期CDN节点架构次要是依照资源进行布局部署,2台LVS+小于4台管控机器,剩下都是缓存机器,属于布局后行的部署模式,资源闲置较多,并且也造成建设老本的节约。在全面推动CDN ON ENS边缘交融计算能够极大晋升资源利用效率。 智能终端上云,是将来IoT设施大规模接入很重要的场景,波及到典型的边缘全局容器调度和流量调度的协同。核心管控会当时依据预估的用户规模申请资源,接入集群,并将容器部署在边缘节点上,在用户申请建连时,依据预约义的流量调度策略,从核心管控获取边缘闲置容器,将用户设施和服务端容器进行绑定。当用户断连时,销毁重建新的容器供后续其它业务应用,防止数据透露。核心管控会实时的依据并发申请状况等外围指标进行动静的容器扩缩容。 核心下沉业务,核心具备规模化Region的数量是比拟无限的,当客户对提早十分敏感,首选是在就近边缘节点进行服务的部署和解决客户申请。为保障云边统一体验,业务中控系统须要同时获取核心和边缘的服务数据,再依据用户申请进行流量散发。这样既能够升高对于核心带宽老本和资源的压力,又能够晋升用户体验。 最初, 江岑示意,阿里云边缘云原生技术将不断完善调度、资源、协同等方面能力,面向行业客户以及合作伙伴提供最佳云原生利用体验,独特打造边缘云翻新利用。

June 3, 2021 · 1 min · jiezi

关于云计算:阿里云资深技术专家李克畅谈边缘云计算趋势与实践

简介: 2021年5月15日,以“置信边缘的力量”为主题的寰球边缘计算大会在深圳胜利召开。 阿里云资深技术专家李克,分享阿里云在边缘云计算的摸索和实际,如何为行业提供广覆盖、低成本、高牢靠的边缘基础设施。 2021年5月15日,以“置信边缘的力量”为主题的寰球边缘计算大会在深圳胜利召开。 阿里云资深技术专家李克,分享阿里云在边缘云计算的摸索和实际,如何为行业提供广覆盖、低成本、高牢靠的边缘基础设施。 Gartner依照地位不同划分3种计算场景,别离是Near Edge、Far Edge、Cloud,对应着终端计算、IDC计算和核心云计算。其中Near Edge是规范服务器或设施,在间隔端侧最近的中央,例如在工厂和园区,能够为任何Arm,X86设施;而Far Edge是规范的IDC节点,而Cloud是公共云或专有云服务,特色为资源集中、中心化治理。 边缘云计算是一种Far Edge的场景,次要是利用运营商的资源构建小型化的云节点,提供计算、网络、存储能力。 边缘云处在核心云和终端之间。起到承前启后的作用,一方面能够将核心计算下沉到边缘,另一方面也能够把端侧计算上移到边缘。 边缘云计算通过边缘节点的流量卸载,能够实现对5G流量的本地化解决和散发,防止海量流量对骨干网路的冲击,可能提供大带宽的解决方案。边缘云计算通过分布式架构,实现对海量终端高并发的分布式解决,深刻场景的本地化计算能力,将进一步晋升计算的效率。而边缘云计算人造的就近部署,也能满足5G低延时解决的场景化需要,提供10ms乃至于ms以内的响应时延。 除了业务场景上对边缘云计算的需要外,另外一个促使边缘场景疾速倒退的推动力是老本,核心机房的规模都很大,一次性的CAPEX和后续的OPEX老本都十分高,而且核心个别都是BGP带宽,而边缘节点,机器配置不必太高,节点规模也较小,个别几十台左右,网络也是复线接入,所以在老本上具备肯定的劣势。 阿里云领有遍布寰球的边缘云计算节点,边缘云计算具备分布式个性,节点数量和散布的广度决定了边缘云整体提供的场景丰盛度。同时阿里云可能十分不便地将合作伙伴的基础设施引入到阿里边缘云生态中,反对更多的本地场景落地。 数字孪生与物理终端的协同计算 新计算须要具备新的个性:业务在线化、数据精细化和数据疾速决策。 数据在线化是企业数据化转型的第一步,须要将业务进行数据化形容,提炼进去指标进行跟踪;数据精细化是数据分析肯定要足够细粒度,否则无奈发现其中的渺小变动,一般来讲须要细化到一个独立的设施和连贯;数据疾速决策是边缘计算的外围特色,实现人、事、物的疾速决策,比方依据用户行为,进行商品的举荐,依据某个设施的异样,疾速实现复原,让客户无感知。 边缘云计算可能提供足够的计算能力,通过对边缘算力的调度,基于物理终端接入地位、边缘节点地位和算力状态进行边缘算力与物理终端的匹配和协同调度,在物理世界和数字世界之间建设起映射,以最小的时延获取数据,最快的剖析和下发响应,让用户领有与设施本地操作统一的业务体验。 数据就近缓存解决 新存储指的是可能在边缘上存储和应用数据,边缘场景的数据特色是数据产生和生产个别具备本地化特色,所以须要在边缘上提供存储的解决方案。边缘云存储可能提供交融存储能力,即一台设施上同时反对块存储、文件存储和对象存储等能力,节点之间可实现主动的数据迁徙和备份。 大量的视频图像类数据都是在边缘上进行解决和存储的,如编解码,人脸车辆辨认,结构化的数据回存到核心,原始数据在边缘,当须要的时候能够间接在边缘进行检索。 通过这种形式,一方面使得数据处理变快,另一方面无效降低成本。 分布式节点的多边协同网络 基于边缘节点构建一张新型的传输网,具备平安、高质量、低成本和疾速容灾性。边缘云的网络分为三段: 第一个是边缘和设施之间,是一种网关的角色,可能反对平安、规范的接入形式;第二个是边缘和边缘之间,可能动静的选路布局和容灾调度,实现任意两点的最佳传输;第三个是边缘和核心之间,可能承诺大流量的场景,做好骨干网的流量布局。通过跟运营商严密单干,基于运营商的MEC节点、5G切片等外围能力,构建‘云-边-端’ 一体的交融网络。 李克通过2个具体场景解说了阿里云边缘云计算在实践中如何解决的业务痛点。 场景一是自在视角的在线赛事直播计划,在往年CUBA全明星赛直播过程中,观众能够在任意手机上自在拖拽视角,实现自在视角的观看体验。传统计划对设施硬件和带宽传输要求较高,须要同时下载和解决多路摄像头数据流,硬件老本高无奈推广,并能功耗高耗电快。而通过边缘计算节点ENS实现多路视频的近程渲染,缩小手机的解决工作以及下载量。场景二是云利用和云游戏通过边缘计算节点ENS来提供地位无感的服务接口,疾速创立一路设施,终端和设施之间通过音讯指令的形式进行近程操控。一方面,用户在升高设施的硬件老本,可能体验到大型的游戏;另一方面对于内容厂商能够疾速的推广新游戏和利用无需依赖硬件的芯片和存储能力,对于云计算厂商,也能够比拟好的进行资源复用,只对在线的终端才启动影子设施。目前在云游戏畛域,曾经撑持了PC端游和手游,向下对接各种异构资源,如GPU和ARM设施,向上提供了对立的资源和利用应用规范。阿里云一直开掘边缘云计算在垂直畛域中的场景化利用,推动各行业利用架构降级。已在智慧交通,公共事业畛域,新批发,新教育和智能家庭上都有了很好的落地实际。 多云协同的边缘云计算体系 在构建生态上,李克心愿通过一套残缺的生态,可能撑持各行各业的边缘落地。一方面,阿里云会踊跃拥抱云原生,提供规范的容器和k8s接口,制订利用的编排、服务注册和发现流程,让业务更加标准和不便的应用边缘云计算的能力;另一方面会和资源提供方做好生态单干,制订资源的对接规范,除了自建节点,将来还有大量的单干节点,以及第三方节点。通过这种多云交融的对接,能够实现资源的流动,在应答双十一类似的突发流动时能够有足够的弹性。目前阿里云已跟运营商在MEC节点上开展了深度单干,在某些区域已实现资源的互联互通。 演讲最初,李克表白了面向未来的神往:阿里云咱们心愿能和更多的行业合作伙伴一起,通过产品、技术、资源的深度交融,提供丰盛的边缘能力,撑持边缘利用场景利用,为客户继续发明价值。 原文链接本文为阿里云原创内容,未经容许不得转载。

June 3, 2021 · 1 min · jiezi

关于云计算:WebGL基础着色器基础知识

明天由字节跳动的"yancy"童鞋给大家重磅推出一篇WebGL的干货接下来让咱们开启奇幻旅程,进入 3D 的世界。 本文作者:yancy1. 意识3D首先咱们要介绍的是几个概念,这是咱们要进入到 3D 不可或缺的内容。认识一下它们吧。 1.1 视点,眼帘,指标点,上方向这几个概念在WebGL中属于最常见的内容。 视点:能够繁难的了解为眼睛,也叫观察点指标点:能够了解为咱们要看的物体(任何物体)上方向:头顶的方向。理论生存中,咱们的眼光总是以咱们的眼睛为起始点,达到咱们想要看到的物体,同时,随着咱们察看的角度不同,物体也会出现不一样的状态。以一张图阐明吧。如此几个内容,创立出了3D世界的根本显示模型,由此可见其重要水平。前面咱们也会说到如何在 WebGL 中设定这几个内容。也会有的小伙伴把视点称为相机,指标点称为画布。其实是一样的情理。依照本人的了解记忆就好。 1.2 可视范畴可视范畴指的是咱们所能看到的最大范畴。如:个别状况下咱们看不到本人身后的事物。家喻户晓,三维物体具备深度的概念。在咱们的了解中,深度就是 z 轴。尽管咱们能够将物体搁置在三维空间中的任何地位,然而在WebGL中,可视范畴之外的物体是不被绘制的,这也是为了节俭开销。 1.3 可视空间程度视角、垂直视角、可视深度 定义了可视空间的概念。可视空间分为两种。 正射投影:与物体的远近无关,通常用在建筑设计和建模上。透视投影:咱们平时察看的真实世界都是透视投影。更有深度的感觉。 1.3 着色器如果想渲染 3D 图形,就须要通过一系列的步骤,这些步骤称为渲染管线。在开发 WebGL 程序时,咱们就须要通过着色器语言跟GPU进行沟通,用来设定咱们须要渲染和显示的图形。由此可见:着色器是编写WebGL时最重要的一点(没有之一)。咱们之所以能生成并操作3D图像,都是因为着色器在起作用。WebGL中着色器分为两种。顶点着色器和片元着色器。 1.3.1 顶点着色器这里的顶点代表的是组成物体的每一个点。顶点着色器的性能次要是将地位数据通过矩阵变换、计算光照之后生成顶点色彩、变换纹理坐标。并将生成的数据输入到片元着色器。 1.3.2 片元着色器片元着色器的作用是将光栅化阶段生成的每个片元,计算出每个片元的最终元素。注:因为着色器内容比拟重要,这里咱们先引入这两个概念,先简略了解就能够,前面专门对着色器进行分享。 2. 绘制图形2.1 获取绘图上下文理解了第一大节的内容之后,咱们开始进入到WebGL开发实战中。还记得Canvas中第一步须要干什么吗?没错,须要获取 Canvas 元素和绘图上下文。WebGL 开发也不例外,也须要首先获取元素和绘图上下文。形如下方代码所示: 2.2 初始化着色器2.2.1. 编写着色器代码获取到绘图上下文之后,咱们须要初始化WebGL 的着色器了,着色器代码是以字符串的模式嵌入到渲染程序中,所以咱们须要编写两个着色器的字符串。两个着色器代码都是以字符串的模式存在,并在执行渲染时嵌入到渲染流程内。阐明: void main() {}: 创立一个主函数。gl_Position: 指定绘制的坐标,接管一个领有4个浮点重量的vec4数据。别离代表 x,y,z,w数据gl_PointSize: 示意要绘制图形的尺寸大小。gl_FragColor: 定义图形色彩,1.0 0.0 0.0 1.0 别离代表r g b a 2.2.2. 创立着色器当然,只是编写完着色器代码仍然不能实现渲染工作,接下来咱们就须要将着色器增加到渲染流程内 2.2.3. 着色器编译实现上述两步之后,咱们就须要将着色器代码增加到着色器中。看下例子。 2.2.4. 创立 program实现编译之后,咱们须要将着色器增加到渲染程序中。 2.2.5. 绘制图形实现上述步骤之后,就能够绘制咱们的图形了。这里咱们以一个点为例。在画布上绘制一个点进去。 gl.drawArrays(gl.POINTS, 0, 1);此时就能够关上页面,看到咱们绘制的这个点了。总结代码: 3. 渲染管线3.1 根底内容介绍WebGL 的渲染依赖底层 GPU 的渲染能力。所以 WebGL 渲染流程和 GPU 外部的渲染管线是相符的。渲染管线的作用是将3D模型转换为2维图像。 在晚期,渲染管线是不可编程的,叫做固定渲染管线,工作的细节流程曾经固定,批改的话须要调整一些参数。古代的 GPU 所蕴含的渲染管线为可编程渲染管线,能够通过编程 GLSL,着色器语言 来管制一些渲染阶段的细节。 ...

June 3, 2021 · 1 min · jiezi

关于云计算:gRPC学习之二GO的gRPC开发环境准备

欢送拜访我的GitHub这里分类和汇总了欣宸的全副原创(含配套源码):https://github.com/zq2599/blog_demosgRPC学习系列文章链接在CentOS7部署和设置GOGO的gRPC开发环境筹备初试GO版gRPC开发实战四类服务办法gRPC-Gateway实战gRPC-Gateway集成swagger本篇概览本文《gRPC学习》系列的第二篇,前文在CentOS7环境装好了GO,接下来要把gRPC开发环境筹备好,总的来说一共三步: 装置protocprotoc是编译工具,装置形式是下载二进制文件,间接复制粘贴以下命令执行即可:mkdir -p $GOPATH/bin \&& mkdir ~/temp-protoc-download \&& wget https://github.com/protocolbuffers/protobuf/releases/download/v3.14.0/protoc-3.14.0-linux-x86_64.zip -O ~/temp-protoc-download/protoc.zip \&& cd ~/temp-protoc-download \&& unzip protoc.zip \&& cp ./bin/protoc $GOPATH/bin/ \&& cd ~/ \&& rm -rf ~/temp-protoc-download执行<font color="blue">protoc --version</font>查看protoc装置是否胜利:[golang@centos7 ~]$ protoc --versionlibprotoc 3.14.0装置protoc-gen-go和grpc包遇到的问题实际证明,用<font color="blue">go get</font>命令装置protoc-gen-go和grpc包的时候常常提醒网络谬误,于是我写了个shell脚本,将protoc-gen-go和grpc包的源码从GitHub下载下来,在本地编译构建,达到<font color="blue">go get</font>装置雷同的成果;应用<font color="blue">git clone</font>命令下载源码比拟耗时(文件数量太多),因而我写的脚本是下载对应的源码包(zip文件),再解压,和git clone成果雷同然而耗时缩小很多;因而,接下来的操作是一个脚本实现protoc-gen-go和grpc包的装置; 装置protoc-gen-go和grpc包执行以下命令即可实现protoc-gen-go和grpc包的装置:curl -o install-grpc.sh \https://raw.githubusercontent.com/zq2599/blog_demos/master/files/install-grpc.sh \&& chmod a+x ./install-grpc.sh \&& ./install-grpc.sh控制台输入以下信息,无谬误,示意装置胜利:...install protoc-gen-gogo: downloading google.golang.org/protobuf v1.23.0install grpcclear resourceinstall finish在<font color="blue">$GOPATH/bin</font>目录可见protoc-gen-go:[golang@centos7 ~]$ cd $GOPATH/bin[golang@centos7 bin]$ lsprotoc protoc-gen-go至此,gRPC开发环境曾经筹备结束,下一篇能够开始实战了;装置脚本一览protoc-gen-go和grpc包的装置过程都在install-grpc.sh中实现,该脚本内容如下所示,可见都是些很简略的操作:下载源码、解压、构建 #!/bin/bashmkdir ~/temp-grpc-installecho "clear old files"rm -rf $GOPATH/src/google.golang.org/grpcrm -rf $GOPATH/src/golang.org/xrm -rf $GOPATH/src/google.golang.org/protobufrm -rf $GOPATH/src/github.com/golang/protobufrm -rf $GOPATH/src/google.golang.org/genprotoecho "create directory"mkdir -p $GOPATH/src/google.golang.org/mkdir -p $GOPATH/src/golang.org/xmkdir -p $GOPATH/src/github.com/golang/echo "1. grpc"cd ~/temp-grpc-installwget https://github.com/grpc/grpc-go/archive/master.zip -O grpc-go.zipunzip grpc-go.zip -d $GOPATH/src/google.golang.org/cd $GOPATH/src/google.golang.org/ mv grpc-go-master grpcecho "2. x/net"cd ~/temp-grpc-installwget https://github.com/golang/net/archive/master.zip -O net.zipunzip net.zip -d $GOPATH/src/golang.org/x/cd $GOPATH/src/golang.org/x/ mv net-master netecho "3. x/text"cd ~/temp-grpc-installwget https://github.com/golang/text/archive/master.zip -O text.zipunzip text.zip -d $GOPATH/src/golang.org/x/cd $GOPATH/src/golang.org/x/ mv text-master textecho "4. protobuf-go"cd ~/temp-grpc-installwget https://github.com/protocolbuffers/protobuf-go/archive/master.zip -O protobuf-go.zipunzip protobuf-go.zip -d $GOPATH/src/google.golang.org/ cd $GOPATH/src/google.golang.org/mv protobuf-go-master protobufecho "5. protobuf"cd ~/temp-grpc-installwget https://github.com/golang/protobuf/archive/master.zip -O protobuf.zipunzip protobuf.zip -d $GOPATH/src/github.com/golang/cd $GOPATH/src/github.com/golang/mv protobuf-master protobufecho "6. go-genproto"cd ~/temp-grpc-installwget https://github.com/google/go-genproto/archive/master.zip -O go-genproto.zipunzip go-genproto.zip -d $GOPATH/src/google.golang.org/cd $GOPATH/src/google.golang.org/mv go-genproto-master genprotoecho "7. x/sys"cd ~/temp-grpc-installwget https://github.com/golang/sys/archive/master.zip -O sys.zipunzip sys.zip -d $GOPATH/src/golang.org/x/cd $GOPATH/src/golang.org/xmv sys-master sysecho "install protoc-gen-go"cd $GOPATH/src/github.com/golang/protobuf/protoc-gen-go/go buildgo installecho "install grpc"cd $GOPATH/src/go install google.golang.org/grpcecho "clear resource"cd ~/rm -rf ~/temp-grpc-installecho "install finish"你不孤独,欣宸原创一路相伴Java系列Spring系列Docker系列kubernetes系列数据库+中间件系列DevOps系列欢送关注公众号:程序员欣宸微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界...https://github.com/zq2599/blog_demos

June 2, 2021 · 1 min · jiezi

关于云计算:工业智能汽车联合创新实验室发布-力促汽车工业融通发展

“二氧化碳排放力争于2030年前达到峰值,努力争取2060年前实现碳中和。”在“双碳”指标导向下,工业互联网如何施展关键作用,促成汽车工业交融翻新,成为业界摸索的重大课题。 5月28日,在“一带一路”工业互联网总部暨寰球技术创新核心年度发布会上,浪潮工业互联网联结中汽数据等“政产学研金服用”生态搭档,成立具备自主知识产权的工业智能(汽车)联结翻新实验室,打造基于“双碳”指标的“工业互联网+汽车”融通倒退产品体系,公布汽车工业融通倒退场景和实际,通过工业大数据,驱动汽车产业高质量倒退。 实验室公布打造软硬合一的产品体系 工业智能引领预测性将来。基于国家重大策略需要,工业智能(汽车)联结翻新实验室将聚焦汽车、电子等相干产业,发展工业智能基础性钻研,促成科研成果转化,施展从技术到产业的服务价值。 重庆市经济和信息化委员会副主任杨正华致辞时示意,重庆工业经济正逐渐实现产业链、翻新链、价值链重构与交融,心愿工业智能(汽车)联结翻新实验室会聚劣势资源,以科技翻新为基石,以汽车工业为突破口,赋能重庆制造业转型降级。 重庆两江新区治理委员会一级巡视员李光彩示意,工业智能(汽车)联结翻新实验室落地两江新区,将无力推动以工业互联网为代表的数字经济协同翻新。 发布会现场,工业智能(汽车)联结翻新实验室公布工业智能算法剖析平台系列产品,通过数据服务、算法服务和可视化工具,面向研发设计、生产制作、营销推广、售后服务等全流程场景,以“数据+常识”双驱动,助力企业智能决策。 https://cloud.inspur.com/indu...在浪潮工业互联网董事长肖雪看来,在“双碳”指标导向下,新一代信息通信技术与工业经济深度交融,将催生全新的工业生产方式与企业状态。工业智能(汽车)联结翻新实验室依靠汽车产业,以成渝双城经济圈汽车产业高质量协同倒退为方向,汇聚工业数据,打造数字化基础设施,让企业有能源、有节奏、有方向地深刻数字化网络化智能化革新。 场景利用开释工业数据的因素价值 2020年3月,工信部办公厅印发《对于推动工业互联网放慢倒退的告诉》,激励各地联合优势产业,增强工业互联网在汽车等国民经济重点行业的交融翻新。 发布会现场举办了“数字万象打算”生态单干签约,加码打造汽车、电子信息、配备机械等重点畛域的工业互联网交融产品。 在汽车智能化配备畛域,浪潮签约重庆超力高科,共建汽车工业数据融通翻新平台,通过碳计量设施汇聚汽车数据,赋能碳中和数据资产翻新。 在汽车物流及供应链畛域,浪潮与深圳前海粤十、重庆市冷藏冷链行业协会、重庆市商贸物流商会签约,以冷链特种车辆全程一直链的监管为切入点,通过标识解析体系,撑持冷链供应链一体化治理云平台产品,实现冷链物流企业、交易中心、食品加工企业的信息连同、流程优化、降本增效。 将来,浪潮工业互联网将立足重庆深厚的汽车工业根底,一直拓展工业智能(汽车)联结翻新实验室利用场景,推动汽车及相干产业融通翻新,全力为成渝双城经济圈及“一带一路”高质量倒退,注入新动能。

June 1, 2021 · 1 min · jiezi

关于云计算:重庆区块链公共服务平台渝快链20正式发布

5月28日上午,InspurWorld2021浪潮技术与利用峰会重庆站胜利举办。会上,重庆区块链公共服务平台——“渝快链”2.0降级公布,2021智博会区块链利用翻新大赛发表启动。 随同着以数据为要害因素的数字经济蓬勃发展,区块链作为新型基础设施,正成为新一轮经济建设的重要抓手。山城重庆,正在着力打造“智造重镇”和“智慧名城”,全面拥抱区块链技术与产业翻新倒退。 作为区块链产业翻新洼地,去年4月,重庆市大数据局、渝中区政府联结浪潮正式公布重庆区块链公共服务平台——“渝快链”1.0,依靠重庆电子政务云平台和私有云,在浪潮区块链IBS平台撑持下,联合城市大数据资源核心和企业运行数据,将区块链与人工智能、大数据、物联网等新一代信息技术交融翻新,利用混合云技术架构,打造新型区块链基础设施,为政府、企业用户和集体开发者,提供区块链引擎服务和开发服务。基于“渝快链”1.0撑持,2020线上智博会区块链利用翻新大赛得以胜利举办,来自寰球的200+支参赛队伍踊跃报名,推出60+开发我的项目,笼罩20+利用场景,吸引了泛滥优秀人才与优质我的项目落地重庆,进一步放慢了重庆倒退区块链产业的步调。 作为价值互联、信赖互联和产业互联的基础设施,为进一步晋升平台服务能力,重庆区块链公共服务平台——“渝快链”2.0降级公布,依靠“134”体系架构,着力晋升外围公共服务能力,构建“平台+生态”产业闭环。同时,2021智博会区块链利用翻新大赛也在大会现场发表正式启动。 重庆浪潮云链公司总经理商广勇示意,“渝快链”1.0次要提供基础设施服务,帮忙政府和企业搭建区块链根底环境,而“渝快链”2.0则重点强调互联互通,打造“134体系架构”,晋升外围公共服务能力——以一套分布式云架构为撑持底座,通过构建区块链赋能平台、主链平台、商用明码服务三大外围平台,可实现对国内外支流区块链底层技术平台的对立治理,提供包含基础设施服务、公共API服务、跨链协同服务以及“区块链+”交融服务在内的四类公共服务。全新降级后的“渝快链”2.0一方面能够为开发者提供封装后的区块链API服务,升高应用老本,另一方面也将以主链为中继,实现链与链之间的互联互通、跨链协同,同时通过将区块链平台与AI、物联网等平台进行深度交融,面向政府、企业和集体提供服务撑持。 此外,作为重庆市区块链利用翻新产业联盟理事长单位,浪潮也将联结泛滥开发、征询、服务等合作伙伴,充沛聚合区块链产业势能,整合区块链产业公共资源,以放慢区块链核心技术冲破和场景落地为己任,促成区块链产业因素流通,服务区域经济倒退,独特打造区块链产业翻新生态。

May 31, 2021 · 1 min · jiezi

关于云计算:初探可编程网关-Pipy

有幸加入了 Flomesh 组织的workshop,理解了他们的 Pipy 网络代理,以及围绕 Pipy 构建起来的生态。Pipy 在生态中,不止是代理的角色,还是 Flomesh 服务网格中的数据立体。 整顿一下,做个记录,顺便瞄一下 Pipy 的局部源码。 介绍上面是摘自 Github 上对于 Pipy 的介绍: Pipy 是一个轻量级、高性能、高稳固、可编程的网络代理。Pipy 外围框架应用 C++ 开发,网络 IO 采纳 ASIO 库。 Pipy 的可执行文件仅有 5M 左右,运行期的内存占用 10M 左右,因而 Pipy 非常适合做 Sidecar proxy。 Pipy 内置了自研的 pjs 作为脚本扩大,使得Pipy 能够用 JS 脚本依据特定需要疾速定制逻辑与性能。 Pipy 采纳了模块化、链式的解决架构,用程序执行的模块来对网络数据块进行解决。这种简略的架构使得 Pipy 底层简略牢靠,同时具备了动静编排流量的能力,兼顾了简略和灵便。通过应用 REUSE_PORT 的机制(支流 Linux 和 BSD 版本都反对该性能),Pipy 能够以多过程模式运行,使得 Pipy 不仅实用于 Sidecar 模式,也实用于大规模的流量解决场景。 在实践中,Pipy 独立部署的时候用作“软负载”,能够在低提早的状况下,实现媲美硬件的负载平衡吞吐能力,同时具备灵便的扩展性。 Pipy 的外围是音讯流处理器: Pipy 流量解决的流程: 外围概念流(Stream):Pipy管道(Pipeline)模块(Module)会话(Session)上下文(Context)<u>以下是集体浅见</u>: ...

May 31, 2021 · 3 min · jiezi

关于云计算:gRPC学习之一在CentOS7部署和设置GO

欢送拜访我的GitHubhttps://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等; 对于《gRPC学习》系列《gRPC学习》是欣宸最新创作的实战格调原创,旨在通过一系列实战操作与读者一起把握基于golang的gRPC开发基础知识; gRPC学习系列文章链接在CentOS7部署和设置GOGO的gRPC开发环境筹备初试GO版gRPC开发实战四类服务办法gRPC-Gateway实战gRPC-Gateway集成swagger对于gRPCgRPC 是一个高性能、开源和通用的 RPC 框架,面向挪动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本,别离是:grpc, grpc-java, grpc-go. 其中 C 版本反对 C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 反对.gRPC 基于 HTTP/2 规范设计,带来诸如双向流、流控、头部压缩、单 TCP 连贯上的多复用申请等特。这些个性使得其在挪动设施上体现更好,更省电和节俭空间占用。各个过程之间能够通过gRPC互相调用,如下图: 本篇概览作为《gRPC学习》系列的开篇,次要工作是确定环境信息、部署go并做好相干设置,为前面的开发做好筹备; 环境信息操作系统:CentOS Linux release 7.9.2009go版本:1.15.6对于帐号和权限为了靠近生产环境,本文的操作未应用root帐号,而是一个新建的帐号golang,新建账号时应用root帐号来操作,步骤如下: 我这里用的帐号和群组名为<font color="blue">golang</font>,用root账号执行如下操作:groupadd golang && useradd -d /home/golang -g golang -m golang执行命令<font color="blue">passwd golang</font>设置golang帐号的明码;还要给<font color="blue">golang</font>账号执行sudo的权限,执行以下命令,使得配置文件可写:chmod 777 /etc/sudoers接下来编辑<font color="blue">/etc/sudoers</font>,增加下图红框中的内容,而后保留退出: 去掉配置文件的可写权限:chmod 440 /etc/sudoers至此,新账号<font color="blue">golang</font>创立实现,接下来的操作都用此帐号;极速部署和配置golang下载、解压、设置,如果您感觉这些操作繁琐乏味,以下操作会让您省心一些: 更新利用:sudo yum update -y装置稍后会用到的利用:sudo yum install unzip tree wget -y执行以下命令即可实现所有部署工作:curl -o install-go.sh \https://raw.githubusercontent.com/zq2599/blog_demos/master/files/install-go.sh \&& chmod a+x ./install-go.sh \&& ./install-go.sh执行完上述命令后,控制台会输入相似上面的内容,可见hello.go文件能够被胜利执行,示意go环境部署胜利,并且输入的环境变量也是失常的:...5. create go source filepackage mainimport "fmt"func main() {fmt.Println("Hello world!")}6. run hello.goHello world!go1.15.6 install and check finished上述命令中的脚本<font color="blue">install-go.sh</font>,其次要内容如下: ...

May 31, 2021 · 1 min · jiezi

关于云计算:应用架构步入无服务器时代-Serverless技术迎来新发展

摘要:以“原生蓄力,云领将来”为主题的2021年云原生产业大会上,华为云Serverless函数服务产品经理分享了“华为云Serverless函数服务,让开发上云极简高效”的主题演讲。5月26日,以“原生蓄力,云领将来”为主题的2021年云原生产业大会在北京启幕,华为云Serverless函数工作流(FunctionGraph)通过了根底能力要求、平台可观测能力、服务性能、服务平安和服务计量准确性等五大类、20+项测试,以稳固、牢靠、高效的服务能力荣获可信云函数即服务能力认证。同时,在云原生2.0分论坛环节,华为云Serverless函数服务产品经理分享了“华为云Serverless函数服务,让开发上云极简高效”的主题演讲。华为云FunctionGraph 荣获可信云函数即服务能力认证 Serverless作为云原生技术倒退重要力量之一,开启了利用架构的“无服务器”时代,为架构设计、开发者编程带来了全新的思路。Serverless技术的衰亡,极大简化了云计算的编程模型,让开发人员无需关注服务器,聚焦利用翻新。 利用架构一直演进 Serverless 2.0 全方位承载高效利用开发利用复杂度的晋升和云计算的倒退一直推动利用架构、编程形式的继续演进。从最后的单体架构后期开发简略、疾速,随着零碎规模增大,因为架构耦合导致的无奈独立降级、演进等问题继续放大。架构开始朝着微服务演进并逐步成为支流,利用依照微服务粒度进行拆分,接口标准化,环境标准化,能够按天或周进行降级公布,帮忙利用实现了疾速迭代。服务架构给开发者带来了便当,但也带来了复杂度,用户仍然须要关注服务器配置、后端服务管等运维工作,无奈享受云带来的最大便当。 Serverless架构是在微服务架构根底上的进一步延长,依照业界通常的定义,Serverless = FaaS(Function as a Service) + BaaS(Backend as a Service)。相比微服务,FaaS将资源调度的粒度放大到函数,针对无状态、短时解决工作,通过函数式编程形式,进一步升高了利用开发门槛,缩短了利用上线周期。 但以后的FaaS,通常不适宜用于长时工作、大数据处理等工作,函数间通信时延性能较低,被称之为Serverless 1.0阶段。 到了Serverless 2.0阶段,将在此基础上大大扩大其利用范畴,全场景反对各种利用负载。其典型特色包含:能够反对长时运行的工作;内置数据系统,能够反对有状态函数,反对大数据处理;内置通信零碎,函数间能够通过总线进行高性能通信。 华为云Serverless函数工作流FunctionGraph,让开发聚焦利用翻新华为云在Serverless技术的钻研和实际过程中提出: Serverless作为云计算下半场的计算范式,须要解决通用利用开发、原有利用零碎无缝对接、反对异构硬件等问题,并且有齐备的工具链、云服务,能力让更多的开发者享受Serverless带来的红利。 华为云Serverless函数工作流FunctionGraph是一款带编排能力的函数计算服务,提供了界面化治理、一站式的函数开发上线性能,反对6大类语言、反对10+类的函数触发器类型;领有丰盛的触发器类型,通过事件触发集成多种云服务,满足不同场景需要;依据申请的并发数量主动调度资源运行函数,实现按需极速弹性;函数运行实例出现异常,零碎会启动新的实例解决后续的申请,实现秒级故障自愈。 基于华为云Serverless的多场景利用与实际落地Serverless架构所具备的IT资源可依据需要弹性伸缩的特点,从场景上大抵可分为以下几类: 类型一:单用处无状态类,典型的利用有小程序后端、Web后端、三方服务商对接等。这类利用应用函数编程能够极大简化开发流程,做到小时级交付。 类型二:事件驱动类,如实时的图片解决、实时的数据流解决、IoT的事件处理等。这是Serverless最典型的一类利用,特点是事件驱动+计算胶水层,计算胶水层的逻辑通过函数来实现。 类型三:弹性伸缩类利用,如视频转码、视频直播、热点事件推送等,这类利用的特色是通常无奈预知流量大小,须要基础设施可能做到底层资源无感,主动的疾速弹缩而不影响业务层的解决。 在华为云Serverless场景落地方面,已全面实现了在挪动端的利用实际。比方:在2020年疫情期间,华为负一屏基于Serverless架构实现了“新型肺炎疫情实时播报”利用一天上线,极大晋升了利用开发的敏捷性。 另外一个典型利用场景是对于视频解决中的Serverless实际,此场景中同一个视频直播流里须要插入多个AI特效渲染函数,函数间须要传递大量数据,在现有函数架构下须要通过屡次内部存储读写,而通用采纳状态内置的函数技术,将一次读写的拜访耗时从200ms升高到5ms,从而满足端到端业务时延要求。 在2019年伯克利公布的《Cloud Programming Simplified》瞻望中,提出Serverless将成为云计算的下一代默认计算范式。 对于云计算利用架构来说,“无服务器”时代的Serverless技术必将引领云计算下一个阶段,华为云亦将聚焦客户价值,聚力云原生2.0 Serverless解决方案,大幕开启,发明有限可能! 点击关注,第一工夫理解华为云陈腐技术~

May 29, 2021 · 1 min · jiezi

关于云计算:5-月-28-日-29-日阿里云峰会视频云专场直播预告

2021 阿里云峰会行将启幕,从 “全面上云” 到 “云上翻新”,开启云计算新纪元。 阿里云视频云 作为视频云行业的翻新引领者,继续致力于打造音视频数智化,一直延展新技术、发明新机会,重构泛滥行业和缔造新的物种,推动新内容新交互时代的到来。 2021 阿里云峰会视频云专场5 月 28 日 - 29 日,阿里云视频云三场论坛将带来全新的音视频解决方案、分享视频云低代码技术设计准则以及阿里云视频云智能媒体生产能力在重大项目中胜利的实践经验,帮忙客户在相干业务场景中晋升效率、降低成本、减少营收。 5月28日 优化音视频业务客户体验论坛直播地址:https://summit.aliyun.com/202... 5月29日 钉利用开发:人人都是工程师论坛直播地址:https://summit.aliyun.com/202... 5月29日 视觉AI开发平台及其行业利用论坛直播地址:https://summit.aliyun.com/202...

May 28, 2021 · 1 min · jiezi

关于云计算:Quarkus谁说-Java-不能用来跑-Serverless

想到这个题目的时候,我第一工夫想到的就是星爷的《唐伯虎点秋香》的这一幕。 当探讨起世界上最好的开发语言是什么的时候,Java 的粉丝们总会遇到这种场景: 吹:“Java 语法简略,容易上手!”黑:“Java 启动慢,性能差,耗资源!” 吹:“Java 有世界上最多的程序员!”黑:“Java 启动慢,性能差,耗资源!” 吹:“Java 生态好!”黑:“Java 启动慢,性能差,耗资源!” 吹:“滚!”明天咱们持续说说 Quarkus,应“云”而生的 Java 框架。明天算是第三篇了,没看过的同学能够回顾一下: Hello, Quarkus应"云"而生的 Java 框架 Quarkus:构建本机可执行文件上一篇的结尾预报:试试 Quarkus 在 ArgoCD 中的利用,看下 Serverless 上的应用体验。不过不想用 ArgoCD 了,因为这 workflow 这种场景切实体现不出 Quarkus 到底有多快。但又想做 Serverless,那就想到了 Knative Serving 了。 其实,还有一个起因是比拟懒,上次的镜像还能够间接拿来用。 TL;DR废话不多说,先上论断。Quarkus 与 Spring 首个申请的响应耗时:2.5s vs 5.7s。 注:为了疏忽拉取镜像的工夫差别,提前 pull 镜像。 验证环境筹备Kubernetes 1.18+ via minikubeIstio 1.9.2Knative 0.22.0Knative CLI (brew 装置)watch (brew 装置)环境的装置筹备参考官网的文档。 镜像资源镜像就应用上一篇文章构建的,但须要做下调整: docker tag quarkus/quarkus-getting-started:distroless dev.local/quarkus/quarkus-getting-started:distrolessdocker tag spring/spring-getting-started:latest dev.local/spring/spring-getting-started:latest注:knative 会疏忽 dev.local 镜像的预加载,不会在创立 knative service 的时候拉取。 ...

May 27, 2021 · 2 min · jiezi

关于云计算:混合云下的-Kubernetes-多集群管理与应用部署

本文是上海站 Meetup 中讲师李宇依据其分享内容梳理成的文章大家好,很快乐来到今天下午的 Meetup。我先简略做个自我介绍,我叫李宇,目前是 KubeSphere 的一名研发,次要负责多集群方向的工作,我明天带来的分享是混合云下的 Kubernetes 多集群治理与利用部署。KubeSphere 在开始做 v3.0之前,曾发动了一个社区用户调研,发现呼声最高的是反对多集群治理和跨云的利用部署,因而 KubeSphere 3.0 重点反对了多集群治理。 单集群下的 Kubernetes 架构 Kubernetes 外部分为 Master 和 Worker 两个角色。Master 下面有 API Server 负责 API 申请,Controller Manager 负责启动多个controller,继续协调申明式的 API 从 spec 到 status 的转换过程,Scheduler 则负责 Pod 的调度,Etcd负责集群数据的存储。Worker 则作为工作节点次要负责 Pod 的启动。 单集群下有许多场景是无奈满足企业需要的,次要分为以下几点。 物理隔离。只管 Kubernetes 提供了 ns 级别的隔离,你能够设置每个 Namespace 各自应用的 cpu 内存,甚至能够应用 Network Policy 配置不同 Namespace 的网络连通性,企业依然须要一个更加彻底的物理隔离环境,以此防止业务之间的相互影响。混合云。混合云场景下,企业心愿能够抉择多个私有云厂商和公有云解决方案,防止受限于繁多云厂商,升高肯定老本。利用异地多活。部署业务多个正本到不同 region 集群,防止单个 region 的断电造成利用的不可用状况,实现不把鸡蛋放在同一个篮子目标。开发/测试/生产环境 。为了辨别开发测试生产环境,把这些环境部署到不同的集群。可拓展性。进步集群的拓展性,冲破繁多集群的节点下限。其实最简略的形式就是应用多个 Kubeconfig 文件来别离治理不同的集群,前端调动屡次 API 即可同时部署业务,包含其余一些现有的其余产品也是这么做的,然而 KubeSphere 还是想以一种更加 Cloud Native 的形式去治理多个集群,于是 KubeSphere 先调研了一些已有的解决方案。 ...

May 27, 2021 · 2 min · jiezi

关于云计算:Kubernetes-上如何控制容器的启动顺序

去年写过一篇博客:管制 Pod 内容器的启动程序,剖析了 TektonCD 的容器启动管制的原理。 为什么要做容器启动顺序控制?咱们都晓得 Pod 中除了 init-container 之外,是容许增加多个容器的。相似 TektonCD 中 task 和 step 的概念就别离与 pod 和 container 对应,而 step 是依照程序执行的。此外还有服务网格的场景,sidecar 容器须要在服务容器启动之前实现配置的加载,也须要对容器的启动程序加以控制。否则,服务容器先启动,而 sidecar 还无奈提供网络上的反对。 事实 冀望 到了这里必定有同学会问,spec.containers[] 是一个数组,数组是有程序的。Kubernetes 也的确是依照程序来创立和启动容器,然而 容器启动胜利,并不示意容器能够对外提供服务。 在 Kubernetes 1.18 非正式版中曾在 Lifecycle 层面提供了对 sidecar 类型容器的 反对,然而最终该性能并没有落地。 那到底该怎么做? TL;DR笔者筹备了一个简略的 go 我的项目,用于模仿 sidecar 的启动及配置加载。 克隆代码后能够通过 make build 构建出镜像,如果你是用的 minikube 进行的试验,能够通过命令 make load-2-minikube 将镜像加载到 minikube 节点中。 应用 Deployment 的形式进行部署,间接用 Pod 也能够。 apiVersion: apps/v1kind: Deploymentmetadata: creationTimestamp: null labels: app: sample name: samplespec: replicas: 1 selector: matchLabels: app: sample strategy: {} template: metadata: creationTimestamp: null labels: app: sample spec: containers: - image: addozhang/k8s-container-sequence-sidecar:latest name: sidecar imagePullPolicy: IfNotPresent lifecycle: postStart: exec: command: - /entrypoint - wait - image: busybox:latest name: app imagePullPolicy: IfNotPresent command: ["/bin/sh","-c"] args: ["date; echo 'app container started'; tail -f /dev/null"]上面的截图中,演示了在 sample 命名空间中,pod 内两个容器的执行程序。 ...

May 27, 2021 · 3 min · jiezi

关于云计算:使用-Quarkus-和-MicroProfile-实现微服务特性

Quarkus 的文章之前写过三篇了,讲过了 Quarkus 的小而快。 Hello, Quarkus应"云"而生的 Java 框架 Quarkus:构建本机可执行文件谁说 Java 不能用来跑 Serverless?始终在酝酿写一篇 Quarkus 生态相干的,因为最近始终在忙 Meetup 的事件而搁浅。正好看到了这篇文章,就拿来翻译一下,补全云原生中的“微服务”这一块。 本文译自《Implementing Microservicilities with Quarkus and MicroProfile》 。 为什么要应用微服务个性?在微服务架构中,一个应用程序是由几个相互连接的服务组成的,这些服务一起工作来实现所需的业务性能。 因而,典型的企业微服务架构如下所示: 刚开始,应用微服务架构实现应用程序看起来很容易。 然而,因为有了单体架构没有一些新的挑战,因而做起来并不容器 举几个例子,比方容错、服务发现、扩展性、日志记录和跟踪。 为了解决这些挑战,每个微服务都应实现咱们在 Red Hat 所说的“微服务个性”。 [ ] 该术语是指除业务逻辑以外,服务还必须实现来解决的跨畛域关注点清单,如下图所示: 能够用任何语言(Java、Go、JavaScript)或任何框架(Spring Boot、Quarkus)实现业务逻辑,然而围绕业务逻辑,应实现以下关注点: API:可通过一组定义的 API 操作来拜访该服务。例如,对于 RESTful Web API,HTTP 用作协定。此外,能够应用诸如 Swagger 之类的工具来记录 API 。服务发现(Discovery):服务须要发现其余服务。 调用服务(Invocation):发现服务后,须要应用一组参数对其进行调用,并选择性地返回响应。 弹性(Elasticity):微服务架构的重要特色之一是每个服务都是弹性的,这意味着能够依据零碎的要害水平或以后的工作量等参数独立地进行缩放。(译者注:这里的弹性只是资源的弹性) 弹性(Resiliency):在微服务架构中,咱们在开发时应牢记失败,尤其是在与其余服务进行通信时。在单体利用中,整个应用程序处于启动或敞开状态。然而,当此应用程序合成为微服务体系结构时,该应用程序由多个服务组成,并且所有这些服务都通过网络互连,这意味着该应用程序的某些局部可能正在运行,而其余局部可能会失败。遏制故障对防止通过其余服务流传谬误很重要。弹性(或应用程序弹性)是应用程序/服务对问题做出反馈并依然提供最佳后果的能力。(译者注:这里的弹性与容错相干,对失败解决的弹性) 管道(Pipeline):服务应独立部署,而无需进行任何模式的编排。因而,每个服务应具备本人的部署管道。 身份验证(Authentication):对于微服务体系结构中的安全性的要害方面之一是如何对外部服务之间的调用进行身份验证/受权。Web 令牌(通常是令牌)是在外部服务中平安地示意申明的首选形式。 日志记录(Logging):在单体应用程序中,日志记录很简略,因为该应用程序的所有组件都在同一节点上运行。而后当初组件以服务的模式散布在多个节点上,因而,要领有残缺的日志记录视图,须要一个对立的日志记录零碎/数据收集器。 监控(Monitoring):掂量零碎的性能、理解应用程序的整体运行状况,以及在呈现问题时收回警报是放弃基于微服务的应用程序正确运行的要害方面。监控是控制应用程序的要害方面。 跟踪(Tracing):跟踪用于可视化程序的流程和数据进度。作为开发人员/运维人员,当咱们须要检查用户在整个应用程序中的行程时,这特地有用。 Kubernetes正在成为部署微服务的理论工具。这是一个用于自动化、编排、扩大和治理容器的开源零碎。 应用 Kubernetes 时,十个微服务个性中只有三个被涵盖。 服务发现 是通过 Kubernetes 服务的概念实现的。它提供了一种应用稳固的虚构 IP 和 DNS 名称将 Kubernetes Pod 分组(作为一个整体)的办法。发现服务只是应用 Kubernetes 的服务名作为 hostname 进行申请。 ...

May 27, 2021 · 6 min · jiezi

关于云计算:带你走进云原生技术云原生开放运维体系探索和实践

本文是云原生凋谢协同技术摸索与实际一阶段的总结和综述。 蚂蚁根底技术在过来3年多以来继续、深刻推动全面的云原生化技术演进,咱们将在线、离线计算资源装进了一台计算机,将服务体系通过 mesh 的思路和技术手段进行了下沉解耦,能够说比拟充沛的拥抱了云原生技术,并获取了其带来的技术红利。 当实现了资源、服务的云原生化,咱们发现在云原生根底能力之上的运维体系与云原生技术凋谢、共享的思路有较大的间隔,在技术体系上也与云原生技术申明式、白盒化的思路相悖,同时因为短少匹配的技术撑持,历史包袱等问题也成为了云原生运维难以真正代际演进的阻碍。明天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术摸索和实际。 规模化云原生运维摸索咱们先来回顾一下在蚂蚁实在的实际形式和面对的问题。首先,咱们来看看蚂蚁践行多年的经典运维中台,这类运维平台个别包含了控制器、业务模型、编排引擎、原子工作及管道,在蚂蚁这样的平台是一系列服务的汇合,他们较好的满足了集中式、标准化、低变更频率的利用公布及运维需要。但这种模式在实践中也存在着显著的有余。 首先对于非标准利用、利用个性化需要、高老本需要、非紧急需要、技改类需要,往往无奈较好的满足。在蚂蚁的实际中,非标运维需要、对外围利用模型及运维模型冲击较大的高老本革新需要、大量根底能力或运维性能的透出需要等长期无奈失去较好的满足,需要往往是正当的,是难以获得足够的优先级执行落地。在研发阶段,运维平台长期积攒了高复杂度的业务逻辑,批改测试波及跨零碎的长革新链路,同时根底能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力,特地是在产品 GUI、业务模型、编排引擎等变更热点上,受限于扩大机制能力有余,外部实际中甚至呈现过线上一直批改代码、公布服务以满足需要的状况。平台上线后,对立的质保和线上全链路性能验证同样面对较大的压力。对于最终的使用者,命令式按钮背地的黑盒计算透明度低,审计难,后果难预测,同时激情操作、操作界面不相熟等问题也始终影响着线上的稳定性。这些问题长期存在,咱们寄希望于代际的技术演进来解决这些问题。 当云原生根底服务逐步稳固后,对于本身场景不在运维平台治理范畴内的利用,研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度凋谢、高度可配置的特点,研发者能够自助、灵便、通明的申明式利用运行、运维需要,以利用粒度实现公布、运维操作。 用户通过 kustomize 等社区技术缩短了对接基础设施的门路,并通过如 velocity 等文本模板技术局部解决了动态 YAML 文件在较多变量时维度爆炸的问题,解决了默认值设定的问题,同时通过 code review 的形式进行多因子变更及评审。因为 Kubernetes 及其生态提供了面向资源、服务、运维、平安的横向能力,使得这种简略的形式可有很好的普遍性和适用性,通过对不同的 Kubernetes 集群 “播放” 这些数据即可实现对基础设施的变更,实质上是一种申明数据的流转。面向 git 仓库的研发形式和 gitops 流程反对对运维产品研发资源的诉求较低,往往能够比较简单的搭建起来,不强依赖产品研发资源投入。相比经典运维中台,这些益处清晰明确,但从工程视角毛病也非常明显。 首先 Kubernetes API 的设计较为简单,仅是 Kubernetes 原生提供的 low level API 就裸露了 500 多种模型,2000 多字段,场景上简直涵盖了基础设施应用层的方方面面,即便是业余同学也很难了解所有细节。其次这种形式的工程化水平很低,违反 DRY 准则,违反各团队职责能力高内聚低耦合的准则,即便在有肯定的工具反对的状况下,在外部的典型案例中一个多利用的 infra 我的项目依然保护了多达 5 万多行 YAML,同时因为团队边界造成的多个割裂的平台,用户需在多个平台间切换,每个平台的操作形式各异,加上跳板机黑屏命令,实现一次残缺的公布须要 2 天工夫。 因为低工程化水平的问题,各团队间协同依赖人肉拉群同步,最终 YAML 由多个团队定义的局部组合而成,其中一大部分属于 Kubernetes 及运维平台团队的定义,这些内容须要继续跟踪同步防止腐化,长期保护老本高。 KUSION: 云原生凋谢协同技术栈以上两种模式各有利弊,劣势和问题都比拟清晰。那么能不能既要也要呢,能不能在继承经典运维平台劣势的状况下,充分利用云原生技术带来的红利,打造一个凋谢、通明、可协同的运维体系? 带着这样的问题,咱们进行了摸索和实际,并创立了基于基础设施代码化思路的云原生可编程技术栈 Kusion。 大家都晓得 Kubernetes 提供了申明式的 low level API,提倡其上生态能力通过 CRD 扩大的形式定义并提供服务,整个生态遵循对立的 API 标准束缚,复用 API 技术和工具。Kubernetes API 标准提倡 low level API 对象松耦合、可复用,以反对 high level API 由 low level API “组合” 而成。Kubernetes 本身提供了利于开源流传的极简计划,并不包含 API 之上的技术和计划。 ...

May 26, 2021 · 4 min · jiezi

关于云计算:529-杭州站云原生-Meetup邀您观看线上同步直播

5 月 15 日在上海组织的云原生 Meetup,除了现场火爆、人数爆满之外,同步进行的线上直播也同样受到了宽广社区小伙伴的关注,在线观看直播人数足有千人之众。 为了能让更多的社区小伙伴可能参加到 Meetup 中,5 月 29 日杭州站云原生 Meetup 同样会连续线下 + 线上相结合的形式。如果因为工夫或者地区问题,您无奈到现场,但同时又想参加进来,在 Meetup 中学习和交换,观看线上的同步直播则是十分适合的形式。 本次咱们将会在青云官网直播间、“KubeSphere” 视频号、B 站以及“青云QingCloud” 视频号等多个平台进行同步直播。您能够抉择其中任一平台进行观看。 青云官网直播间和 “KubeSphere云原生” B 站平台将进行 4 轮抽奖,您能够在观看直播的同时,还有机会取得 KubeSphere 定制周边纪念品以及 Kubernetes 技术丛书。 另外,您还能够参加“分享有礼”流动。扫码后点击“邀请”分享海报,率领小伙伴一起参加线上直播。截止到 5 月 29 日 18:00 ,排行榜前 10 名的小伙伴将取得 KubeSphere 定制周边礼品。 所以,除了能够在线上观看各位技术大牛的分享之外,还能够参加有奖流动“争夺”精美礼品。机会难得,放松扫描下方海报中的二维码报名参加吧! 本文由博客一文多发平台 OpenWrite 公布!

May 25, 2021 · 1 min · jiezi

关于云计算:部署混合云环境的5大挑战

采纳混合云基础设施的企业将会优化老本,并提高效率。然而,这减少了在多个资源环境中抉择适合的工具集来交付端到端服务的复杂性。 云计算专家始终以来对私有云与公有云与外部部署数据中心之间孰好孰坏有着很多的争执,但这一后果曾经通过市场的倒退得出了论断。 从久远来看,获胜者是混合云。依据Flexera公司公布的一份名为《2020年云计算状态报告》,目前87%的企业都采纳了混合云。 钻研机构Gartner公司的考察数据也反对了这一点。然而,在采纳混合云的路线上却充斥了复杂性。Gartner公司钻研总监D. D. Mishra说,“采纳混合云基础设施的企业将会优化老本,并提高效率。然而,这减少了在多个资源环境中抉择适合的工具集来交付端到端服务的复杂性。” 如果企业想采纳混合云架构来满足本人的计算需要,须要意识到哪些挑战?如何确保中小企业的跨应用程序和工作负载在灵活性、移动性和易用性取得统一的收益?企业须要思考解决面临的5个问题: 01、图片迁徙 将负载从数据中心或私有云转移到混合云时,对于大多数企业来说,第一步或试点阶段最艰难。其次要的要求是要害工作应用程序应该持续无缝运行而不会中断。 此外,企业还须要确保自动化、开发和测试、监控零碎和数据库的相干工具和应用程序都迁徙到新零碎,或者找到相应的替换工具和应用程序。 企业的首席技术官或IT团队须要就以下方面做出决策: 与团队成员进行部署,或者取得托管服务提供商或内部参谋的帮忙。调整工作负载的经营要求,并从新计算经营收入。剖析要害业务应用程序的性能。抉择用于测试和开发的新平台。计算、网络和存储资源的容量布局和配置。针对基于生产的服务的外部/内部租户的财务计量和费用摊派。 02、图片老本 任何思考转向混合云的企业首席信息官都可能关注IT基础设施的老本优化。如果从外部部署数据中心或公有云迁徙,则能够正当地进行这种转变。然而,为了运行私有云生态系统而减少复杂性很难证实其无效。其遇到的问题包含: 容量利用率低于或高于预期。在某些工作负载中呈现了无奈意料的需要。疏忽了用于负载平衡、数据传输和劫难复原的经营老本。资源配置未按时勾销。须要包含多个云计算提供商提供的云服务以实现现有的性能或经营级别。 混合云使企业可能辨认预测、治理和配置中的异样,同时让企业抉择资本性支出或经营收入模型进行计费。寻找自助服务剖析和监督工具,这些工具可让企业治理部署并升高利用率和老本。 03、图片安全性 确保混合云的安全性是计算自身更繁琐、更敏感且更容易出错的过程之一。极大的灵活性带来了极大的不确定性,分布式私有云和公有云以及泛滥云计算供应商即便执行单个集中式安全性和合规性策略方面都会面临艰难,更不用说对它们的监督、配置和修补。 这些问题在多云环境中被放大,企业的云计算环境中可能就有这些破绽。因而,须要从可见性、管制和优化的角度来解决这些安全漏洞。以下是对于进步安全性的一些提醒: 在不同供应商的私有云和公有云之间传输数据时,数据最容易受到攻打。企业须要提防DDoS和中间人攻打。应用硬件安全模块(HSM)加强硬件,并尽可能包含原生软件加密。 如果企业的工作场合容许自带设施(BYOD)或近程工作,并且员工从多个近程地位登录到外部部署数据中心,则连贯到网络的每台设施都会加剧这种威逼。施行零信赖架构(该标准规定,所有用户必须在每次连贯时都必须对其进行验证,并且必须对所有设施进行验证),并采纳以起码特权形式授予的多因素身份验证和条件拜访。 认真查看与形成混合云环境的每个私有云和公有云供应商或托管服务提供商达成的服务水平协定(SLA)。其文档蕴含其服务条款和条件,以及对系统失常运行工夫和数据可用性的保障。须要企业的法律部门从新扫视,以便晓得在客户数据透露或其余可能影响企业名誉的事件中如何应答。 04、图片治理 能够必定的是,混合云比独立的私有云或数据中心要简单得多。因而,企业的次要指标应该是在整个环境中跨每个组件和云计算零碎的流程和操作的标准化。 依据RightScale公司公布的2020年云状态报告,云治理间断三年成为采纳云计算平台的所有企业面临的最大挑战,84%的受访者示意更加关注其混合云和多云部署中的治理。 通常状况下,加强的自动化和自助服务是解决治理问题的答案。现在,采纳先进的云计算治理平台,能够对混合基础设施的公有云和私有云组件中的数据、应用程序、安全策略和资源进行精密和全面的治理,通过在治理用户和特定于平台的服务之间创立一个对立的“繁多管制平台”形象层。 05、图片合规性 在医疗卫生和金融等行业中,合规性法规认为混合云环境的每个私有云或公有云都须要作为独立的零碎进行评估。这意味着企业须要从思考的初始阶段就布局数据存储、拜访和传输以及可用性、容量和劫难复原。 所有这些可能都要求对IT人员和部门负责人进行额定的培训,此外还须要从新培训特定于合规性的工具、应用程序和流程。企业还须要确保单干的云计算供应商的云服务合乎适当的行业标准,并领有恪守实用的政府法规所需的证书。 最初在合规性方面不要疏忽外部员工。每个拜访企业数据的不同级别和角色的人员都须要理解他们在公司网络上的工作和口头如何影响业务流动和听从的法规。 Gartner公司钻研副总裁Sid Nag说,“对策略云服务成绩的需要标记着企业向数字业务成绩的转变。因而,对云计算投资相干成绩的冀望也更高。” 企业越理解总体业务指标(以及组成IT基础设施的各种零碎如何帮忙实现这些指标),部署混合云模型的胜利机会就越大,因为这样就能够利用云计算技术的微小劣势来进步数字业务能力。 (起源:企业网D1Net)

May 24, 2021 · 1 min · jiezi

关于云计算:CNI-基准测试Cilium-网络性能分析

[](#understanding-cilium-network-performance) 原文链接:https://cilium.io/blog/2021/0... 作者:Thomas Graf 译者:罗煜、张亮,均来自KubeSphere 团队Thomas Graf 是 Cilium 的联结创始人,同时也是 Cilium 母公司 Isovalent 的 CTO 和联结创始人。此前 Thomas 曾先后在 Linux 内核的网络、平安和 eBPF 畛域从事了 15 年的开发工作。注:本文已获得作者自己的翻译受权 大家好! 随着越来越多的要害负载被迁徙到 Kubernetes 上,网络性能基准测试正在成为抉择 Kubernetes 网络计划的重要参考。在这篇文章中,咱们将基于过来几周进行的大量基准测试的后果探讨 Cilium 的性能特点。应宽广用户的要求,咱们也将展现 Calico 的测试后果,以便进行间接比照。 除了展现测试的后果数据外,咱们还将对容器网络基准测试这一课题进行更深刻的钻研,并探讨以下几个方面的问题: 吞吐量基准测试容器网络是否会减少开销打破常规:eBPF 主机路由(Host Routing)测量提早:每秒申请数Cilium eBPF 和 Calico eBPF 的 CPU 火焰图比照新连贯解决速率WireGuard 与 IPsec 加密开销比照测试环境测试后果汇总在详细分析基准测试及其数据之前,咱们先展现汇总的测试论断。如果您心愿间接理解测试细节并得出本人的论断,也能够跳过这一节的内容。 eBPF 起决定性作用:Cilium 在某些方面优于 Calico 的 eBPF 数据门路(Data Path),例如在 TCP_RR 和 TCP_CRR 基准测试中察看到的提早。此外,更重要的论断是 eBPF 显著优于 iptables。在容许应用 eBPF 绕过 iptables 的配置环境中,Cilium 和 Calico 的性能都显著优于不能绕过 iptables 的状况。 ...

May 24, 2021 · 4 min · jiezi

关于云计算:529-相约杭州云原生-Meetup-第二期杭州站开启报名

以容器技术和容器编排为根底的云原生利用,被越来越多的企业用户承受和应用,并且在生产环境中应用容器技术的比例逐年减少。KubeSphere 作为一款面向利用的开源容器混合云,通过 3 年的倒退和 10 个版本的迭代,播种了一百多位开源贡献者,超过十万次下载,并有数千名社区用户用 KubeSphere 作为企业容器云平台。 KubeSphere 之所以可能如此疾速倒退,得益于开源社区带来的人造劣势,以及社区里长期沉闷的用户、贡献者积极参与社区,帮忙推动产品和社区疾速成长,咱们保持认为 KubeSphere 开源社区的每一位用户和贡献者敌人都是 KubeSphere 生态中的重要组成部分。 为了跟社区新老朋友们零距离交换,咱们将联结 CNCF 和其余合作伙伴,从五月到七月,在上海、杭州、深圳、成都这四个城市别离为大家带来技术的交换与碰撞。2021 年继上海站首次 Meetup 火爆全场之后,咱们将仍旧连续 KubeSphere and Friends 的主题,于 5 月 29 日杭州为大家带来 Kubernetes and Cloud Native Meetup。 流动议程杭州站是往年 Kubernetes Meetup 的第二站,目前已根本确定讲师和议题。 工夫和地点流动工夫:5 月 29 日 13:00-18:00 签到工夫:5 月 29 日 13:30-14:00 流动地点:浙江省杭州市拱墅区丰潭路 430 号丰元国内大厦 A 座硬趣空间公开一层 流动报名杭州目前曾经开启招募,若您心愿获取教训,期待和各位极客交换,那就放松报名吧!地位无限,先到先得! 扫描下方二维码即可进入到报名页面进行报名,流动收费! 流动礼品本次流动特地定制了 KubeSphere 全套留念周边礼品:T恤、马克杯、留念徽章、帆布袋、口罩...... 礼物门票数量无限,赶快报名,手慢则无! 报名参加或者提交议题即可取得定制周边纪念品! 除了提供周边礼品之外,咱们还会赠送各种云原生相干的硬核书籍,有电子工业出版社提供的 《Kubernetes 生产化实际之路》:还有人民邮电出版社图灵教育提供的张磊大神的巨著《深刻分析 Kubernetes》:你认为只有这两套书吗?当然不是,本次 meetup 还会送出机械工业出版社华章公司提供的以下书籍:现场参加互动即可获取以上书籍奖品哟~ 提交主题分享您充斥了开发创意却无处施展吗?咱们曾经为您搭好舞台:Serverless、微服务、DevOps、开源、容器... 任何对于云原生和 KubeSphere 的观点、干货、技术实际、用户故事都是咱们社区十分欢送的。 ...

May 21, 2021 · 1 min · jiezi

关于云计算:报名开启阿里云线下Workshop让你玩转ECS-快速搭建云上博客

简介:想理解云计算的前世今生?零根底小白也想上手实际?想体验用ECS搭建云上博客?想结识更多对ECS感兴趣的开发小伙伴?想取得阿里云限量周边?5月30号阿里云ACE同城会北京会长张维带你玩转ECS,疾速搭建云上博客。为保障流动品质,仅限30名额,点击下方链接快来报名吧,手慢无! 想理解云计算的前世今生?零根底小白也想上手实际?想体验用ECS搭建云上博客?想结识更多对ECS感兴趣的开发小伙伴?想取得阿里云限量周边?5月30号阿里云ACE同城会北京会长张维带你玩转ECS,疾速搭建云上博客。为保障流动品质,仅限30名额,点击下方链接快来报名吧,手慢无! 流动工夫:5月30号(周日)13:30-16:30 流动地点:北京市 朝阳区 阿里核心·望京B座 1F-03 聚义堂 报名链接(仅限30人):https://hd.aliyun.com/form/523 Workshop请携带电脑参会! 流动流程13:00~14:00  签到 14:00~14:10  阿里云开发者社区介绍 14:10~15:00  相熟阿里云 ECS 核试验 15:00~15:50  搭建博客 15:50~16:10  发问与交换 16:10~16:30  抽奖-合影-流动完结 流动奖品  版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

May 21, 2021 · 1 min · jiezi

关于云计算:浪潮云洲链斩获20202021年度新一代信息技术创新产品殊荣

5月20日,赛迪参谋主办的2021 IT市场年会在北京举办。作为工业互联网畛域代表,浪潮云洲链斩获2020-2021年度新一代信息技术翻新产品殊荣。 IT市场年会是业界顶级盛会,从2000年至今已间断胜利举办21届。“2020-2021年度新一代信息技术”榜单评选活动,旨在推动新一代信息技术的实践、实际翻新,表彰获得卓著问题或者作出突出贡献的集体和个体。 浪潮独创将国家标识解析体系与区块链、商用明码技术交融,造成加强级标识解析体系服务平台——云洲链,其是浪潮云洲工业互联网平台的外围组成部分。 云洲链平台以标识解析为人、机、物互联的基石,以“一物一码”实现信息高度交融,聚焦企业倒退面临的问题,打造可信的数据自在流,向企业提供智能制作、流程优化、供应链金融等SaaS应用服务,推动建设企业大数据中心、工业大数据中心,助推制造业生产方式与企业状态改革。 目前,浪潮云洲链已构建起良好的产业生态,别离与中国信通院,标识解析重庆顶级节点、武汉顶级节点、上海顶级节点策略签约,共建工业互联网新生态。2021年4月,浪潮云洲链启动全面接入国家级区块链基础设施“星火·链网”。 将来,浪潮云洲链将依靠标识解析体系与新一代信息技术,深入利用,打造工业互联网新型基础设施,深度赋能智能制作与制造业高质量倒退。

May 20, 2021 · 1 min · jiezi