后场思库OpenSkill开放注册 置顶

产品设计 OpenSkill 发表了文章 0 个评论 1746 次浏览 2020-10-21 00:01 来自相关话题

程序猿的世界很简单也很单纯,但是他们是一群有思想的人,世界那么大,在代码的海洋不断探索。后场思库OpenSkill是一个互联网技术极客平台,希望在这个平台汇集一批有想法有思想的程序员、设计师、测试、运维、区块链、极客、和未知技术探 ...查看全部

程序猿的世界很简单也很单纯,但是他们是一群有思想的人,世界那么大,在代码的海洋不断探索。

后场思库OpenSkill是一个互联网技术极客平台,希望在这个平台汇集一批有想法有思想的程序员、设计师、测试、运维、区块链、极客、和未知技术探索者,大家来自天南地北,有机会汇集一处,就是缘分,多一个朋友多一条路。

工作不是人生的全部,生活和家庭才是, 搬砖累了,工作累了,希望这里会成为你的思考栖息之地。

祝福有思想的你,交个朋友......

                                                  请加 空心菜 微信获取 注册邀请码

                                                               微信crhins

                                                           或扫描微信二维码:

d0f8ee74fd7712cc52eb12990fcd16c2.jpg

OpenSkill.cn内容发布原则:

1. 非常欢迎分享程序员故事、有趣味、开阔视野、创新思路的原创文章,不管是锦衣玉食还是馒头榨菜,有趣有料,宁缺毋滥。尊重用户,尊重用户的时间和注意力;

2. 发布的翻译文章要简洁清晰易懂,并附上原文链接;

3. 分享阅读的文章,请附上原文链接;

4. 支持原创文章,不允许未经授权转载别人的文章;

5. 做自己;

6. 不允许发布灌水充数的文章,毫无价值的文章;

7. 不允许发布涉及钱财的文章,比如赞助、捐助、乞讨、众筹、抽奖、贷款等;

8. 不允许发布纯广告营销、擦边球、灰黑违内容;

9. 不允许标题党;

10. 请务必遵守服务条款,违者永禁。

MySQL的三种复制模式

数据库 koyo 发表了文章 0 个评论 139 次浏览 2021-12-10 00:04 来自相关话题

MySQL支持的三种复制模式分别为: asynchronous 异步复制fully synchronous 全同步复制semi synchronous 半同步复制 ...查看全部

MySQL支持的三种复制模式分别为:


  1. asynchronous 异步复制
  2. fully synchronous 全同步复制
  3. semi synchronous 半同步复制

异步复制 (asynchronous replication)

原理:在异步复制中,master写数据到binlog且sync,slave request binlog后写入relay-log并flush disk
优点:复制的性能最好
缺点: master挂掉后,slave可能会丢失事务
代表:MySQL原生的复制

全同步复制 (fully synchronous replication)

原理:在全同步复制中,master写数据到binlog且sync,所有slave request binlog后写入relay-log并flush disk,并且回放完日志且commit
优点:数据不会丢失
缺点:会阻塞master session,性能太差,非常依赖网络
代表:MySQL Cluster

半同步复制 (semi synchronous replication)

1. 普通的半同步复制

原理: 在半同步复制中,master写数据到binlog且sync,且commit,然后一直等待ACK。当至少一个slave request bilog后写入到relay-log并flush disk,就返回ack(不需要回放完日志)
优点:会有数据丢失风险(低)
缺点:会阻塞master session,性能差,非常依赖网络,
代表:after commit, 原生的半同步



重点:由于master是在三段提交的最后commit阶段完成后才等待,所以master的其他session是可以看到这个提交事务的,所以这时候master上的数据和slave不一致,master crash后,slave数据丢失



2. 增强版的半同步复制(lossless replication)

原理: 在半同步复制中,master写数据到binlog且sync,然后一直等待ACK. 当至少一个slave request bilog后写入到relay-log并flush disk,就返回ack(不需要回放完日志)
优点:数据零丢失(前提是让其一直是lossless replication),性能好
缺点:会阻塞master session,非常依赖网络
代表:after sync, 原生的半同步



重点:由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的,所以这时候master上的数据和slave一致,master crash后,slave没有丢失数据



重要参数:
































参数 评论 默认值 推荐值 是否动态
rpl_semi_sync_master_wait_for_slave_count 至少有N个slave接收到日志 1 1 dynamic
rpl_semi_sync_master_wait_point 等待的point AFTER_SYNC AFTER_SYNC dynamic
rpl_semi_sync_master_timeout 切换复制的timeout 1000(10s) 1000 (1s) dynamic
rpl_semi_sync_master_enabled 是否开启半同步 OFF ON dynamic
rpl_semi_sync_slave_enabled 是否开启半同步 OFF ON dynamic

如何开启lossless replication:


########semi sync replication settings########
plugin_dir=/usr/local/mysql/lib/plugin
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 1000

实践是检验真理的唯一标准

如何检验上述after_syncafter_commit, 如何检验上述原理的正确性。


InnoDB commit: 三阶段提交过程
A阶段: wite prepare log 写入Xid
B阶段: write binlog
C阶段: write commit log

测试点:master上当一个事务Waiting for semi-sync ACK from slave的时候,后来的事务是在A,B,C哪个阶段卡住呢?


0,RC模式

1. semi-sync C阶段等待

假设设置time-out=100000s,当事务一提交了一个大事务,在write commit log(C阶段)时候等待,
那么第二个事务在敲commit命令的时候,是卡在哪个阶段呢?是卡在 wite prepare log(A阶段)?还是write binlog(B阶段)?还是write commit log(C阶段)

测试:semi-sync vs loss-less semi-sync

【semi-sync】 C阶段等待
0, 开启事务1,然后在slave上执行stop slave,制造timeout的情况,让其阻塞。(Waiting for semi-sync ACK from slave)
1,在开启一个事务2,事务2插入一条特殊记录(XXXXX)。 (Waiting for semi-sync ACK from slave)
2,在开启一个事务3。
2.1,测试案例:这个时候,kill -9 mysqld,造成人为的mysql crash
3,假设卡在A阶段,那么事务3,肯定是看不到事务1,2写入的记录(XXXXX),且重启mysql后,事务2不会提交。
4,假设卡在C阶段,那么事务3,肯定是可以看见事务1,2写入的记录(XXXXX)。

经过测试:
1,是卡在C阶段,也就是说事务3是可以看见事务1,事务2的。
2,MySQL crash重启后,事务1,事务2的dml都已经提交成功,说明不是卡在A阶段

【loss-less semi-sync】B阶段等待

0, 开启事务1,然后在slave上执行stop slave,制造timeout的情况,让其阻塞。(Waiting for semi-sync ACK from slave)
1,在开启一个事务2,事务2插入一条特殊记录(XXXXX)。(Waiting for semi-sync ACK from slave)
2,在开启一个事务3
3,假设卡在A阶段,那么事务3,肯定是看不到事务1,2写入的记录(XXXXX),且重启mysql后,事务2不会提交。。
4,假设卡在B阶段,那么事务3,肯定是可以看见事务1,2写入的记录(XXXXX),且重启mysql后,事务1,2都会提交。。
5, 假设卡在C阶段,那么事务3,肯定是可以看见事务3写入的记录(XXXXX)。

经过测试:
1,是卡在B阶段,也就是说事务3,既看不见事务1的提交内容,也看不见事务2的提交内容,且重启mysql后,事务1,2都已经提交。。
2,MySQL crash重启后,事务1,事务2的dml都已经提交成功,说明不是卡在A阶段。

性能
semi-sync vs lossless semi-sync 的性能对比


根据以上的测试,可以得知,lossless只卡在B阶段,普通的semi-sync是卡在C阶段。
lossless的性能远远好于普通的semi-sync,即(after_sync 优于 after_commit)
因为lossless 卡在B阶段的时候可以堆积事务,可以在C阶段进行group commit。
普通的semi-sync,卡在C阶段,事务都已经commit了,并没有堆积的过程。


CAP理论:



一致性【C】
可用性【A】
分区容忍性【P】
理论:CAP 三者不可兼得,必须要牺牲一个


分区,是一定存在的,不是你想不要就不要的。所以,这里只剩下两种组合


CP 牺牲可用性



这种做法,就是保留强一致性,牺牲可用性
案例:可以将rpl_semi_sync_master_timeout设置成一个无限大的值,比如:100天,那么master和slave就强一致了,但是可用性就大打折扣


AP 牺牲一致性



这种做法,就是保留高可用性,牺牲一致性
案例:比如原生的异步复制就是这样咯。可以快速做到切换,但是一致性就没有保障


阅读分享:https://henduan.com/FJHU5

什么是Redis,Redis有什么特点和优势?

数据库 OS小编 回复了问题 2 人关注 1 个回复 187 次浏览 2021-12-01 13:09 来自相关话题

安可产业名录和国产化替代

运维 chris 发表了文章 0 个评论 566 次浏览 2021-11-30 15:52 来自相关话题

关于国家信息化安全可靠工程随着信息安全问题日益突出,信息安全已上升至国家战略,自主可控,国产化替代已成为历史趋势。2019年开始我国信息、网安领域企业逐渐发力“安全可靠工程”,安全可靠工程战略意义在于证明我国具有安全可靠关键系统、关键应 ...查看全部

关于国家信息化安全可靠工程

随着信息安全问题日益突出,信息安全已上升至国家战略,自主可控,国产化替代已成为历史趋势。2019年开始我国信息、网安领域企业逐渐发力“安全可靠工程”,安全可靠工程战略意义在于证明我国具有安全可靠关键系统、关键应用及关键软硬件产品的研发集成能力,能够初步实现对国外信息技术产品的全方位替代,在新的历史起点上构建起网络安全的“铜墙铁壁”。在党政办公及国家重要信息系统推进国产化替代,实现安全可靠、自主可控,保障国家信息安全的工作已全面展开。

安可名录

安全可靠技术和产业联盟主要成员单位包括联盟理事和联盟会员两大类。
其中联盟理事(19家)又分为:集成厂商(10家)、测试厂商(4家)、互联网厂商(3家)和高等院校(2家)四大类。

集成厂商(10家)包括:
华宇软件、神州航天软件、东华软件、东软集团、航天信息、浪潮软件集团、神州信息、太极股份、同方股份、中国软件

测试机构(4家)包括:
国家工业信息安全发展研究中心、中国电子技术标准化研究院、工业和信息化部电子第五研究所、中国电子信息产业发展研究院

互联网厂商(3家)包括:
阿里云、金山软件、华为技术

高等院校(2家)包括:
北京航空航天大学、北京理工大学

联盟会员则包含:芯片厂商(7家)、集成厂商(12家)、整机厂商(8家)、操作系统厂商(9家)、数据库厂商(6家)、中间件厂商(3家)、流版签厂商(7家)、外设固件厂商(3家)、安全厂商(6家)、网络厂商(3家)、互联网厂商(2家)、存储厂商(5家)和应用软件厂商(2家)共十二大类。


芯片厂商(7家)包括:
上海兆芯(X86)、东土军悦(交换机芯片、东土科技)、国科微(安防、存储、物联网芯片)、盛科网络(交换机芯片、中国电子、振华科技)、天津飞腾(ARM、中国长城、振华科技)、上海高性能集成电路设计中心(Alpha、申威)、龙芯中科(MIPS)

集成厂商(12家)包括:
百得科技、华胜天成、中软信息(中国软件)、广东省信息工程公司、中科软、南威软件、太极信息(太极股份)、烽火信息(烽火通信)、万达信息、中软系统(中国软件)、中科九洲、长城软件(中国软件)

整机厂商(8家)包括:
上海仪电智通、联想长风、华胜天成、长城科技(中国长城)、宝德网络、曙光信息(中科曙光)、百信信息、北京计算机技术及应用研究所(航天二院706所)

操作系统厂商(9家)包括:
中科方德(兆芯)、一铭软件、湖南麒麟信安(中国软件)、天津麒麟(中国软件)、思普投资(X86)、深之度、普华基础软件(中国电科)、航天国盛(航天科技)、中标软件(中国软件)

数据库厂商(6家)包括:
武汉达梦(中国软件)、神舟通用(航天科技)、人大金仓(太极股份)、南大通用、恒辉信达、瀚高基础软件

中间件厂商(3家)包括:
金蝶天燕中间件、东方通、中创软件

流版签厂商(7家)包括:
金格科技(电子签章)、方正国际软件(电子文档)、书生电子(启明星辰、安全文档)、数科网维(版式OFD)、航天福昕(文档OFD)、安证通(电子签章)、永中软件(office,办公软件)

外设固件厂商(3家)包括:
立思辰(文件管理)、中电科技(中国电子、BIOS等)、光电通信(传真机)

安全厂商(6家)包括:
星网锐捷(通信、安全)、中孚信息(安全保密)、安宁创新(邮件、消息)、中安网脉(密码、存储)、海泰方圆(密码、安全)、卫士通(密码、芯片、系统)

网络厂商(3家)包括:
紫光集团(从芯到云)、迈普通信(中国电子、网络设备)、仰联信通(交换机)

互联网厂商(2家)包括:
拓尔思、恒生电子

存储厂商(5家)包括:
滕凌科技(存储)、亚细亚智业(存储灾备)、同有科技(存储)、鲸鲨软件(存储)、鼎甲科技(中国电子、灾备)

应用软件厂商(2家)包括:
慧点科技(太极股份、管理软件)、华电园技术(办公自动化)

国产化软硬件资源

应用软件
监控国产数据库:达梦数据库、南大通用、人大金仓、神舟通用;

大数据产业下,对金融、电信、航空、制造等行业影响非常明显,其中国产数据库的作用被不断提升,担负起捍卫国家信息安全和技术的重任。
监控国产中间件:东方通、中创、金碟等中间件;

中间件一直是基础软硬件发展中不可缺少的一环,占居重要的地位。2018年以来本土中间件加快进入电信、金融、政府等行业,由东方通作为开拓者和领导者,中创、宝兰德等追其后。


操作系统
监控中标麒麟、银河麒麟、深度科技、红旗、中兴新支点等操作系统;

在持续的贸易战背景下,由于我们受到了外国的管控,操作系统等核心技术一度面临被限制使用的局面,于是国产操作系统被推到了风口浪尖。


硬件资源
监控国产服务器:华为、曙光、H3C、联想、浪潮;
国产服务器发展已将近二十载,二十载潮起潮落,国产服务器已涌现出联想、曙光、浪潮、华为等一批民族品牌。现在国产服务器已抢占更多服务器市场份额。

监控国产存储设备:华为、曙光、H3C、同有、浪潮;


网络资源
监控国产网络设备:华为、H3C、仰联、TP-LINK、ZTE中兴、锐捷等;

监控国产安全设备:天融信、启明星辰、绿盟、网康、趋势科技、山石网科等;
中国最核心的网络安全设备大部分依赖于进口,不具有强大的防御与反击能力,安全问题依然严峻。单靠技术无法抑制网络安全事件增长。核心网络设备国产化是解决这一问题最好的办法。



应用环境
兼容国产数据库:达梦数据库、南大通用、人大金仓、神舟通用;

兼容国产中间件:东方通、中创、金碟等中间件;


硬件环境


兼容国产服务器:华为、曙光、H3C、联想、浪潮;
兼容国产 CPU:龙芯、飞腾、海思、鲲鹏、展讯通信;

系统环境
兼容国产操作系统:中标麒麟、银河麒麟、深度科技、红旗、中兴新支点;

Oracle JDK和Open JDK有什么区别?

回复

编程 OS小编 回复了问题 1 人关注 1 个回复 219 次浏览 2021-11-30 11:58 来自相关话题

常见的JVM厂商有哪些

回复

编程 OS小编 回复了问题 1 人关注 1 个回复 249 次浏览 2021-11-29 09:30 来自相关话题

Kubernetes中的容器编排和应用编排

云原生 OS小编 发表了文章 0 个评论 185 次浏览 2021-11-27 17:06 来自相关话题

众所周知,Kubernetes 是一个容器编排平台,它有非常丰富的原始的 API 来支持容器编排,但是对于用户来说更加关心的是一个应用的编排,包含多容器和服务的组合,管理它们之间的依赖关系,以及如何管理存储。 在这个领域,Kub ...查看全部

众所周知,Kubernetes 是一个容器编排平台,它有非常丰富的原始的 API 来支持容器编排,但是对于用户来说更加关心的是一个应用的编排,包含多容器和服务的组合,管理它们之间的依赖关系,以及如何管理存储。


在这个领域,Kubernetes 用 Helm 的来管理和打包应用,但是 Helm 并不是十全十美的,在使用过程中我们发现它并不能完全满足我们的需求,所以在 Helm 的基础上,我们自己研发了一套编排组件……


什么是编排

不知道大家有没仔细思考过编排到底是什么意思? 我查阅了 Wiki 百科,了解到我们常说的编排的英文单词为 “Orchestration”,它常被解释为:


  • 本意:为管弦乐中的配器法,主要是研究各种管弦乐器的运用和配合方法,通过各种乐器的不同音色,以便充分表现乐曲的内容和风格。
  • 计算机领域:引申为描述复杂计算机系统、中间件 (middleware) 和业务的自动化的安排、协调和管理。

有趣的是 “Orchestration” 的标准翻译应该为“编配”,而“编排”则是另外一个单词 “Choreography”,为了方便大家理解, 符合平时的习惯,我们还是使用编排 (Orchestration) 来描述下面的问题。至于“编配 (Orchestration)” 和 “编排(Choreography)” 之争,这里有一篇文章,有兴趣可以看一下 。http://www.infoq.com/cn/news/2008/09/Orchestration


Kubernetes 容器编排技术

当我们在说容器编排的时候,我们在说什么?


在传统的单体式架构的应用中,我们开发、测试、交付、部署等都是针对单个组件,我们很少听到编排这个概念。而在云的时代,微服务和容器大行其道,除了为我们显示出了它们在敏捷性,可移植性等方面的巨大优势以外,也为我们的交付和运维带来了新的挑战:我们将单体式的架构拆分成越来越多细小的服务,运行在各自的容器中,那么该如何解决它们之间的依赖管理,服务发现,资源管理,高可用等问题呢?


在容器环境中,编排通常涉及到三个方面:


  • 资源编排 - 负责资源的分配,如限制 namespace 的可用资源,scheduler 针对资源的不同调度策略;
  • 工作负载编排 - 负责在资源之间共享工作负载,如 Kubernetes 通过不同的 controller 将 Pod 调度到合适的 node 上,并且负责管理它们的生命周期;
  • 服务编排 - 负责服务发现和高可用等,如 Kubernetes 中可用通过 Service 来对内暴露服务,通过 Ingress 来对外暴露服务。

在 Kubernetes 中有 5 种经常会用到的控制器来帮助我们进行容器编排,分别是 Deployment, StatefulSet, DaemonSet, CronJob, Job


在这 5 种常见资源中,Deployment 经常被作为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 可以指定在选定的 Node 上跑,每个Node 上会跑一个副本,它有一个特点是它的Pod的调度不经过调度器,在Pod 创建的时候就直接绑定NodeName;最后一个是定时任务,它是一个上级控制器,和 Deployment 有些类似,当一个定时任务触发的时候,它会去创建一个 Job,具体的任务实际上是由 Job 来负责执行的。他们之间的关系如下图:

一个简单的例子
我们来考虑这么一个简单的例子,一个需要使用到数据库的 API 服务在 Kubernetes 中应该如何表示:

客户端程序通过 Ingress 来访问到内部的 API Service, API Service 将流量导流到 API Server Deployment 管理的其中一个 Pod 中,这个 Server 还需要访问数据库服务,它通过 DB Service 来访问 DataBase StatefulSet 的有状态副本。由定时任务 CronJob 来定期备份数据库,通过 DaemonSet 的 Logging 来采集日志,Monitoring 来负责收集监控指标。

容器编排的困境

Kubernetes 为我们带来了什么?
通过上面的例子,我们发现 Kubernetes 已经为我们对大量常用的基础资源进行了抽象和封装,我们可以非常灵活地组合、使用这些资源来解决问题,同时它还提供了一系列自动化运维的机制:如 HPA, VPA, Rollback, Rolling Update 等帮助我们进行弹性伸缩和滚动更新,而且上述所有的功能都可以用 YAML 声明式进行部署。

困境
但是这些抽象还是在容器层面的,对于一个大型的应用而言,需要组合大量的 Kubernetes 原生资源,需要非常多的 Services, Deployments, StatefulSets 等,这里面用起来就会比较繁琐,而且其中服务之间的依赖关系需要用户自己解决,缺乏统一的依赖管理机制。

应用编排

什么是应用?
一个对外提供服务的应用,首先它需要一个能够与外部通讯的网络,其次还需要能运行这个服务的载体 (Pods),如果这个应用需要存储数据,这还需要配套的存储,所以我们可以认为:

应用单元 = 网络 + 服务载体 +存储

那么我们很容易地可以将 Kubernetes 的资源联系起来,然后将他们划分为 4 种类型的应用:

  • 无状态应用 = Services + Volumes + Deployment
  • 有状态应用 = Services + Volumes + StatefulSet
  • 守护型应用 = Services + Volumes + DaemonSet
  • 批处理应用 = Services + Volumes + CronJob/Job

我们来重新审视一下之前的例子:

应用层面的四个问题
通过前面的探索,我们可以引出应用层面的四个问题:

  • 应用包的定义
  • 应用依赖管理
  • 包存储
  • 运行时管理

在社区中,这四个方面的问题分别由三个组件或者项目来解决:


  • Helm Charts: 定义了应用包的结构以及依赖关系;
  • Helm Registry: 解决了包存储;
  • HelmTiller: 负责将包运行在 Kubernetes 集群中。

Helm Charts
Charts 在本质上是一个 tar 包,包含了一些 yaml 的 template 以及解析 template 需要的 values, 如下图:templates 是 Golang 的 template 模板,values.yaml 里面包含了这个 Charts 需要的值。

Helm Registry
用来负责存储和管理用户的 Charts, 并提供简单的版本管理,与容器领域的镜像仓库类似这个项目是开源的。( https://github.com/caicloud/helm-registry)


Tiller


  • 负责将 Chart 部署到指定的集群当中,并管理生成的 Release (应用);
  • 支持对 Release 的更新,删除,回滚操作;
  • 支持对 Release 的资源进行增量更新;
  • Release 的状态管理;
  • Kubernetes下属子项目(https://github.com/kubernetes/helm) 。


Tiller 的缺陷


  1. 没有内建的认知授权机制,Tiller 跑在 kube-system 分区下,拥有整个集群的权限;
  2. Tiller 将 Release 安装到 Kubernetes 集群中后并不会继续追踪他们的状态;
  3. Helm+Tiller的架构并不符合 Kubernetes 的设计模式,这就导致它的拓展性比较差;
  4. Tiller 创建的 Release 是全局的并不是在某一个分区下,这就导致多用户/租户下,不能进行隔离;
  5. Tiller 的回滚机制是基于更新的,每次回滚会使版本号增加,这不符合用户的直觉。

Release Controller

为了解决上述的问题,我们基于 Kubernetes 的 Custom Resource Definition 设计并实现了我们自己的运行时管理系统 – Release Controller, 为此我们设计了两个新的 CRD – Release 和 Release History。


Release 创建
当 Release CRD 被创建出来,controller 为它创建一个新的 Release History, 然后将 Release 中的 Chart 和 Configuration 解析成 Kubernetes 的资源,然后将这些资源在集群中创建出来,同时会监听这些资源的变化,将它们的状态反映在 Release CRD 的 status 中。

Release 更新
当用户更新 Release 的时候,controller 计算出更新后的资源与集群中现有资源的 diff, 然后删除一部分,更新一部分,创建一部分,来使得集群中的资源与 Release 描述的一致,同时为旧的 Release 创建一份 Release History。

Release 回滚和删除
用户希望回滚到某一个版本的 Release, controller 从 Release History 中找到对应的版本,然后将 Release 的 Spec 覆盖,同时去更新集群中对应的资源。当 Release 被删除后,controller 将它关联的 Release History 删除,同时将集群中的其他资源一并删除。

架构图

这样的设计有什么好处?


  • 隔离性:资源使用 Namespace 隔离,适应多用户/租户;
  • 可读性:Release Controller 会追踪每个 Release 的子资源的状态;
  • 版本控制:你可以很容易地会退到某一个版本;
  • 拓展性:整个架构是遵循 Kubernetes 的 controller pattern,具有良好的可扩展性,可以在上面进行二次开发;
  • 安全性:因为所有的操作都是基于 Kubernetes 的 Resource,可以充分利用 Kubernetes 内建的认证鉴权模块,如 ABAC, RBAC 。

总而言之,编排不仅仅是一门技术也是一门艺术!谢谢!
分享阅读原文链接:https://mp.weixin.qq.com/s/zHlS2cQEHzRea_bqKpNA9A

JDK和JVM有啥区别?

回复

编程 OS小编 回复了问题 1 人关注 1 个回复 315 次浏览 2021-11-09 00:04 来自相关话题

漏洞风险评估CVSS介绍

运维 koyo 发表了文章 0 个评论 335 次浏览 2021-11-06 17:29 来自相关话题

什么是CVSS通用弱点评价体系(CVSS)是由NIAC开发、FIRST维护的一个开放并且能够被产品厂商免费采用的标准。利用该标准,可以对弱点进行评分,进而帮助我们判断修复不同弱点的优先等级。 C ...查看全部

什么是CVSS

通用弱点评价体系(CVSS)是由NIAC开发、FIRST维护的一个开放并且能够被产品厂商免费采用的标准。利用该标准,可以对弱点进行评分,进而帮助我们判断修复不同弱点的优先等级。


CVSS(Common Vulnerability Scoring System),即”通用漏洞评分系统”,是一个”行业公开标准,其被设计用来评测漏洞的严重程度,并帮助确定所需反应的紧急度和重要度”。


它的主要目的是帮助人们建立衡量漏洞严重程度的标准,使得人们可以比较漏洞的严重程度,从而确定处理它们的优先级。CVSS得分基于一系列维度上的测量结果,这些测量维度被称为量度(Metrics)。漏洞的最终得分最大为10,最小为0。


得分7~10的漏洞通常被认为比较严重,得分在4~6.9之间的是中级漏洞,0~3.9的则是低级漏洞。


CVSS系统包括三种类型的分数:基本分数、暂时分和环境分。


基本得分临时得分通常由安全产品卖主、供应商给出,因为他们能够更加清楚的了解漏洞的详细信息;


环境得分通常由用户给出,因为他们能够在自己的使用环境下更好的评价该漏洞存在的潜在影响。


所以应该是基于漏洞库的扫描, 需要预先知道该漏洞的威胁值?


就是说漏洞应该预先有脆弱性等级,系统的安全性评估是综合各个漏洞来进行的?


CVSS 2.0 计算方法: 通用漏洞评估方法CVSS 3.0 计算公式及说明 - caya - 博客园 (cnblogs.com)


一些指标具有不确定性和复杂性,会导致完全的定量分析困难。3个客观性指标和11个主观性指标。下一步:指标量化(客观性指标量化和主观性指标量化)。


CVSS评分计算方法

A. 基本评价(Base Metric)

基本评价指的是该漏洞本身固有的一些特点及这些特点可能造成的影响的评价分值


































序号 要素 可选值 评分
1 攻击途径 (AccessVector) 本地/远程 0.7/1.0
2 攻击复杂度(AccessComplexity) 高/中/低 0.6/0.8/1.0
3 认证(Authentication) 需要/不需要 0.6/1.0
4 机密性(Conflmpact) 不受影响/部分/完全 0/0.7/1
5 完整性(integlmpact) 不受影响/部分/完全 0/0.7/1
6 可用性(Availlmpact) 不受影响/部分/完全 0/0.7/1
7 权值倾向 平均/机密性/完整性/可用性 各0.333/权值倾向要素0.5另两个0.25

基础评价 = 四舍五入(10 * 攻击途径 攻击复杂度 认证 ((机密性 机密性权重) + (完整性 完整性权重) + (可用性 可用性权重)))


B.生命周期评价(Temporal Metric)

是针对最新类型漏洞(如: 0day漏洞)设置的评分项,因此SQL注入漏洞不用考虑


因此这里也列举出三个与时间紧密关联的要素如下:


















序号 要素 可选值 评分
1 可利用性 未证明/概念证明/功能性/完全代码 0.85/0.9/0.95/1.0
2 修复措施 官方补丁/临时补丁/临时解决方案/无 0.87/0.90/0.95/1.0
3 确认程度 不确认/未经确认/已确认 0.9/0.95/1.0

生命周期评价 =四舍五入(基础评价 可利用性 修复措施 * 未经确认)


C.环境评价(Environmental Metric)

每个漏洞会造成的影响大小都与用户自身的实际环境密不可分,因此可选项中也包括了环境评价,这可以由用户自评。(用户扫描配置时填写)














序号 要素 可选值 评分
1 危害影响程度 无/低/中/高 0/0.1/0.3/0.5
2 目标分布范围 无/低/中/高(0/1-15%/16-49%/50-100%) 0/0.25/0.75/1.0

环境评价 = 四舍五入<(生命周期评价 + [(10 -生命周期评价) *危害影响程度]) *目标分布范围>


评分与危险等级













序号 评分 危险等级
1 [0,4]
2 [4,7]
3 [7,10]

KVM里面如何是指NAT端口转发

DevOps koyo 回复了问题 2 人关注 1 个回复 344 次浏览 2021-10-22 17:44 来自相关话题

更多话题 >>

热门话题

更多用户 >>

热门用户

koyo

13 个问题, 22 次赞同

空心菜

0 个问题, 108 次赞同