首页 文章 精选 留言 我的

精选列表

搜索[HTTP/3],共10000篇文章
优秀的个人博客,低调大师

【从0到1学习边缘容器系列-3】应用容灾之边缘自治

导语:边缘计算模式下,云端的控制中心和边缘端的设备之间网络环境较复杂,网络质量差次不齐没有保障。用户往往希望在弱网环境下,边缘容器能提供高可用的业务能力。TKE 边缘容器团队在弱网环境下提出了边缘自治功能。本文着重介绍了边缘容器在弱网环境下为了保证业务高可用而做的工作。 问题背景 边缘计算使用的边缘设备数量庞大、分布全国各地,网络环境复杂,因特网、以太网、5G、WIFI 等形态均有可能。因此,云端的控制中心和边缘端的设备之间网络环境较复杂,网络质量差次不齐没有保障。 kubernetes 传统工作模式是所有组件 list-watch kube-apiserver,然后 reconcile 各种资源到期望状态。各节点的健康都强依赖于其与 kube-apiserver 通信的稳定。kubernetes 在传统的集群环境上工作很完美,因为大多数集群都能保证在一个局域网内。然而,在边缘计算的业务场景下,有一个稳定的网络环境着实是一件奢侈的事情。 在这样的背景下,如何保证边缘集群的业务高可用性以及服务高可用性?一直都是一个难题。为此我们腾讯云边缘容器团队(TKE@EDGE)设计了两个利器来专门啃下这块硬骨头,本篇将重点讲第一个利器——边缘自治。 (注:此文提到的网络环境,都是指节点与云端的网络环境,而不是业务运行所在环境。) 需求举例 我们来以一个常见的厂房模型来介绍一下用户在弱网环境下使用传统 kubernetes 遇到的问题以及 TKE 边缘容器团队在此类场景下提出的解决方案。 如上图所示,该案例采用的部署模式为:用户在腾讯云公有云上购买了几台 CVM 机器作为 master 节点,其上部署了 kube-apiserver、kube-controller-manager、kube-scheduler 三大组件。然后根据业务需求,为每一个厂房都创建多个边缘 worker 节点,部署 kubelet 和 kube-proxy 以及 dockerd。同厂房节点之间可以互相访问, 不同厂房节点网络不互通。比如两个分布在北京和广州的厂房的边缘节点虽然可以归属于同一个集群,但是它们之间的网络是不互通的。每个厂房内所有节点会通过公网连接至云端管控端,但是这个网络通道都属于不可靠的弱网环境。 厂房A在北京地区,厂房B在广州地区。二者之间是不能互通的。 用户通过 kubernetes 管理平台进行workload的管理,master 与 worker 节点所在的厂房之间的网络环境网络环境是不能保证的,可能弱网A断网,网络B仍然正常。用户在这样的场景下,提出了几个需求: 节点即使和 master 失联,节点上的业务能继续运行 保证如果业务容器异常退出或者挂掉,kubelet 能继续拉起 保证节点重启后,业务能继续重新被拉起来 用户在厂房内部署的是微服务,需要保证节点重启后,同一个厂房内的微服务可以访问 对于用户来说,这些诉求是他们的基本需求,也是其业务上云的关键因素。用户想要既享受 kubernetes 带来方便的管理运维,同时也要具备弱网环境下的容灾能力。这对传统标准 kubernentes 解决方案提出了挑战。 标准kubernetes处理方式 我们来温习一下标准的 kubernentes 下,如果节点断网失联并且发生异常重启的行为后,会出现哪些现象呢? 失联的节点状态置为 NotReady 或者 Unknown 状态 失联的节点上的业务进场异常退出后,容器可以被拉起 失联的节点上的 Pod IP 从 Endpoint 列表中摘除 失联的节点发生点重启后,容器全部消失不会被拉起 我们依次来看,首先,在传统的模式下,节点是否健康取决于节点上 kubelet 组件的心跳或者续租。如果网络断了,云端组件当然会认为节点是不可用状态。这个状态可以提示用户,该节点可能有异常,需要运维介入。同时,由于 kubelet 还在接管所有本机 Pod,即使业务容器异常退出,容器也是可以继续被拉起的。失联的节点上所有的 Pod ,它们的 IP 都会被从 Endpoint list 中摘除,导致微服务不能访问到这个节点,在传统 kubernentes 集群中,这是一个高可用的措施。但是在边缘集群内,这个“节点不可用=服务不可用”等式是否还成立呢?这个地方是需要探讨的,其实很多业务场景下,用户希望节点即使和云端断网,该节点上的 Pod 也要能继续对外提供服务。 因此我们团队认为,在边缘容器的场景下,单纯与云端网络失联是不能被粗暴地认为“服务不可用”的。为此我们特意设计了第二件利器——“分布式节点健康检查”插件,来解决这个痛点,该功能会在后续文章进行详细介绍。 下面重头戏来了,断网的节点重启一下,容器还会在吗?服务还可用吗?回答是,容器当然不在喽。而且容器不在了,服务肯定不能访问了。用户最关键的需求,显然在传统的 kubernentes 模式下,是不能满足的。 那么来看看我们边缘计算的利器——边缘自治功能能达到的效果吧。 TKE 的边缘自治效果 TKE 的边缘自治效果 节点会被置为 NotReady 或者 Unknown 状态,但是服务仍然可用 多节点断网情况下,Pod 业务正常运行,微服务能力正常提供 多节点断网情况下并重启后,Pod 会被重新拉起并正常运行 多节点断网情况下并重启后,所有的微服务可以被正常访问 我们为了达到最符合用户的效果,配合使用了分布式节点健康检查插件功能,来保证节点在断网情况下即使节点被置为NotReady 状态,但是服务还是继续可用。同时该节点上的 Pod 也不会在新的节点上重新拉起新的 Pod 副本。 我们在极端网络环境下,将运行业务的多个节点手动执行重启操作来模拟节点异常重启场景。节点重启之后,节点组件正常启动,之前的 Pod 也会被自动被拉起,并且运行正常,处于 Running 状态。 那服务以及网络呢?我们测试后发现,重启多个节点之后,我们在节点手动请求 Pod ip,可以访问成功;进入 Pod A 内部分别请求在同一个节点上的 Pod B 以及另一个节点上的 Pod C(需要同一个厂房环境),都可以访问成功;在 Pod A 解析 同一厂房的 Service A, 可以解析并成功。最后,在外部对于该厂房内部的服务进行请求,访问成功。 如此看来,边缘自治功能,有效解决了传统 kubernetes 在弱网环境下所不能解决的用户痛点。 原理简介 我们团队为边缘自治功能打磨了很久,涉及方面众多,修改以及设计的地方比较多,本文不太介绍具体代码实现细节。有兴趣的同学可以和TKE边缘容器同学共同进行学习探讨。在此我简单分享一些设计原理。 lite-apiserver机制 kubernetes 是典型的通过数据进行交互的架构。解决数据问题就能提供一个夯实的基础。所以弱网环境的边缘自治,首当其冲的,最最最需要解决的问题就是数据问题。 考虑到弱网、断网情况,需要保证节点的组件与云端组件“通信”,或者说让节点认为此时还是可以“通信”的。如上图所示,我们在边缘端加了一层镜像 lite-apiserver 组件。边缘节点上所有对 kube-apiserver 的请求都会发往 lite-apiserver,并由 lite-apiserver 转发到 kube-apiserver。对于边缘节点来说,lite-apiserver 提供的功能就是 kube-apiserver 一样,但是一方面 lite-apiserver 只对本节点有效,另一方面相比较标准的 kube-apiserver,我们对于 lite-apiserver 进行了裁剪,大幅度降低了其资源占用。我们在没有修改原生 kube-apiserver 的情况下,实现了。在网络通畅的情况下,lite-apiserver 组件对于节点组件来说是透明的。当网络异常情况,lite-apiserver 组件会把本节点需要的数据返回给节点上组件,保证节点组件不会受网络异常情况影响。 网络快照机制 OK,lite-apiserver 机制保证了断网情况下,节点也不会和“apiserver”失联。既然节点可以拉取到本节点对应的数据,那么业务 Pod 也就能够被 kubelet 成功拉起来。下一步就是解决 Pod 之间的互相访问的问题了。 在边缘容器场景下,考虑到适配性以及易用性,我们采用了 flannel 组件的 vxlan 模式作为网络解决方案。flannel 组件保证了跨节点之前的网络访问。节点上的flannel 以及每个 Pod 都有一些对应属于自己的网络信息,我们这里采用了网络快照机制,将专属于这些组件的网络信息定期快照,从而保证了断网环境下重启后网络可用。并且实现了同节点、跨节点 Pod 之间的网络互通。 DNS解决方案 用户业务对外正常提供服务,以及集群内微服务之间互相调用,这些问题都会涉及到域名解析。 如上图所示,在传统 kubernetes上,通过在集群中创建一个kube-dns deployment 来解决是来解决域名问题。但是边缘计算集群,所有节点可能是不在一个局域网,很可能是跨可用区的,各节点和 kube-dns 的访问无法保证,一个 kube-dns 的 deployment 不能满足边缘容器的需求。 在边缘容器场景下,采用 DaemonSet 方式部署kube-dns,保证每个节点都有可用的 kube-dns,同时修改每个节点上 kubelet 启动参数--cluster-dns,将其指向本机IP。这样就保证了,即使断网情况下,也能解析 kubernetes service 的域名。 总结而言就是 lite-apiserver 机制为基础, kube-proxy、flannel、kube-dns 以及网络快照机制保证了边缘容器集群在弱网环境下的网络可靠性。 适用场景 腾讯云边缘容器产品支持用户在云端通过 kubernetes 方式来管理边缘节点,支持管控平台与 work 节点网络环境分离,具备弱网环境下的容灾能力,支持用户自定义网络流量,并且所有核心组件都与开源 kubernentes 保持一致,目前已经支持 1.18 版本。 目前 TKE@EDGE 具备公有云和私有云两种产品形态,欢迎来官网体验使用边缘容器公有云产品( https://console.cloud.tencent.com/tke2/edge ),产品入口目前为白名单可见,请联系文章作者开通白名单。 后续计划 后续我们还会有一系列工作,来加强在弱网环境下的工作稳定性。 插件化改造。将边缘自治的解决方案改造为插件,提供给传统 kubernetes 某些业务来按需使用 支持完全去中心化 lite-apiserver,来协助 kube-apiserver 在弱网环境下业务的管理 写在最后 我们的解决方案对于原生使用 kubernetes 的方案和理念都有所不同,但是我个人认为紧跟业务脚步的产品以及技术才是最有价值的。个人技术能力有限,表达可能有疏漏,技术可能有错误,欢迎大家指出错误,共同进步。 这里欢迎更多有业务场景需要、感兴趣的同学使用、加入、体验,提需求,共优化。欢迎扫码加腾小云同学好友,一起进群讨论。 【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!

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

3分钟短文 | Laravel 根据关联模型条目数量排序,怎么做?

引言 在laravel中我们使用模型操作数据库表,同时使用 hasOne belongTo hasMany 等关联关系模型 建立不同模型之间的关联。对于简单的查询操作这完全应付的来。 可是现实的业务需求往往充满变数,今天我们就说一个需求, 根据关联模型的数量进行排序,应该如何写代码。 学习时间 我们用实例进行解释,首先是表结构,为了简化操作,只罗列出主要的字段。首先是 hackathons 表的两个字段: id name begins ends description 然后是 user 表的字段: id name 还有一个关联表 hackathon_user 字段: hackathons_id user_id 好了,基础数据已经建立,接着我们使用laravel的模型操作数据库表。首先声明 Hackathons 模型: class Hackathon extends Model { protected $fillable = ['name', 'begins', 'ends', 'description']; protected $table = 'hackathons'; public function owner() { return $this->belongsToMany('User', 'hackathon_owner'); } public function participants() { return $this->belongsToMany('User'); } public function type() { return $this->belongsToMany('Type'); } } 其中有一个 Type 模型因为与本文所讨论问题无关,因此不予列出。接着定义关联表的模型: class HackathonParticipant extends Model { protected $fillable = ['hackathon_id', 'user_id']; protected $table = 'hackathon_user'; public function user() { return $this->belongsTo('User', 'user_id'); } public function hackathon() { return $this->belongsTo('Hackathon', 'hackathon_id'); } } 这就是我们需要的基础类,接着说如何排序。如果不考虑性能问题,或者筛选出的数据量还不足以让我们考虑到性能问题, 那么可以先把结果数据集整个返回,然后使用 laravel collection 集合进行排序和操作。代码写起来像下面这样: $hackathons = Hackathon::with('participants')->get()->sortBy(function($hackathon) { return $hackathon->participants->count(); }); 注意在使用 get 获取所有的结果数据集之后,调用的是Collection类的 sortBy 方式,默认是升序排列。这个方法在数据量小的时候,没什么问题。 如果你的数据量很大,动辄几十万条,那么上面的 get 方法,万万是不能用的,这会大大地增加MySQL与服务器之间的数据传输压力。所以,我们需要在MySQL层面,尽量解决这个问题。 聚合查询也是关系型数据库的强项,所以我们需要的是把聚合查询用laravel实现出来。 laravel 5.3 及以上,我们可以使用 withCount 进行关联类的聚合查询了,代码只需一行: Hackathon::withCount('participants')->orderBy('participants_count', 'desc')->paginate(10); 注意laravel自动生成的统计类的字段名不能写错。 还有一种方法,就是不使用关联模型,而该用表连接,绕过模型定义的关联关系进行查询。我们直接贴出实现代码: $hackathons = Hackathon::leftJoin('hackathon_user','hackathon.id','=','hackathon_user.hackathon_id') ->selectRaw('hackathon.*, count(hackathon_user.hackathon_id) AS `count`') ->groupBy('hackathon.id') ->orderBy('count','DESC') ->paginate(5); 唯一需要注意的是 groupBy 的字段,与 select 所指定的聚合函数。 写在最后 本文通过三种方式实现了laravel中模型的聚合查询排序,其中两种是使用关联关系方式组合查询条件, 一种是直接表操作,使用左连接连接表数据。从写作方式和可维护上讲,我们推荐第二种;但对于业务特殊情况,比如数据库的索引,我们推荐第三种更接近原生的方式, 调优的SQL语句很有杀伤力! Happy coding :-) 我是@程序员小助手,持续分享编程知识,欢迎关注。 本文分享自微信公众号 - 程序员小助手(mql45ea)。 如有侵权,请联系 support@oschina.cn 删除。 本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

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

Chrome 中的恶意扩展窃取个人资料,已被下载超 3 千万次

安全公司 Awake 报告了 111 个恶意或假冒的 Chrome 扩展程序。通过这些问题插件,攻击者可以成功窃取来自用户的隐私数据。截止 2020 年 5 月,这些恶意扩展程序已经被下载超过 3200 万次。 Awake 安全威胁研究团队发布了一份研究报告指出,其发现了一个大规模的全球监视活动。在该活动中,攻击者可利用 Internet 域注册和浏览器功能的性质,来监视和窃取来自多个地区和行业细分市场的用户的数据。研究表明,此犯罪活动是由单个 Internet 域注册商:CommuniGal Communication Ltd. (GalComm)促进的。 报告称,作为一个域名注册商,GalComm 利用用户的信任启用了这一恶意活动。目前,该恶意活动已在 Awake 检查的一百多个网络中被发现。Awake 在报告中指出,在通过 GalComm 注册的 26079 个可访问的域名中,有 15160 个域名为恶意或可疑。 Awake方面称,仅在过去的三个月中,其就收获了 111 个使用 GalComm 域的恶意或假冒 Chrome 扩展程序。这些扩展名可以截取屏幕截图、读取剪贴板、获取存储在 cookie 或参数中的凭据令牌,以及获取用户的击键(例如密码)等。 引诱安装恶意 Chrome 扩展程序的示例 截止 2020 年 5 月,这 111 个恶意扩展下载次数已达到 32,962,951 次。Awake表示,该公司已与 Google 合作,着手从 Chrome 网上应用店中删除这些扩展程序。 针对此事,GalComm 负责人 Moshe Fogel在与路透社的通信中则指出,“GalСomm 不参与任何恶意活动,可以说恰恰相反,我们与执法和安全机构合作,尽我们所能防止”。在Awake Security 发表报告并列出所有可疑域名后, Moshe Fogel也表示这些域名使用情况几乎都不活跃,并会继续调查其他域名。 有关报告的更多详细信息可查看:https://awakesecurity.com/blog/the-internets-new-arms-dealers-malicious-domain-registrars/

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

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

优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Sublime Text

Sublime Text

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

用户登录
用户注册