• 关于

    外部中断控制如何安装

    的搜索结果

问题

企业运营对DevOps的「傲慢与偏见」

忆远0711 2019-12-01 21:32:29 9823 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 39926 浏览量 回答数 17

回答

2014年12月第2周 1)SLB植入cookie和SLB重写cookie有什么区别? cookie植入,表示直接由SLB系统来分配和管理对客户端进行的cookie植入操作,用户在进行配置时 需要指定会话保持的超时时间; cookie重写,表示SLB系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操 作,便于用户识别和区分自定义的cookie名称 http://help.aliyun.com/doc/view/13510025.html?spm=0.0.0.0.vwbsGF 2)SLB有没有对外提供API接口,因为我想做到用程序自动去控制SLB的操作? SLB api您可以参考http://help.aliyun.com/view/13621674.html? spm=5176.7114037.1996646101.1.9RoTFM&pos=1 3)使用slb怎么实现数据的单向同步和双向同步? 单向同步可以使用rsync,双向同步的话rsync需要借用别的服务来实现,如unison+inotify。 4)slb的vip是否可以实现远程登录? slb 的vip无法实现远程登录。 5)slb的带宽是所有后端ECS服务器的带宽总和吗? 不是,使您购买的slb实例带宽。 6)slb健康检查机制是什么? 用户开启健康检查功能后,当后端某个ECS健康检查出现问题时会将请求转发到其他健康检查正常的 ECS上,而当该ECS恢复正常运行时,SLB会将其自动恢复到对外或对内的服务中。 针对7层(HTTP协议)服务,SLB系统的健康检查机制为:默认通过SLB的后端系统来向该ECS应用服务 器配置的缺省首页发起http head请求(缺省通过在服务监听配置中指定的后端ECS端口进行访问), 返回200 OK后将视为后端ECS运行正常,否则视为后端ECS运行异常。如果用户用来进行健康检查的页 面并不是应用服务器的缺省首页,那么需要用户指定相应的URI。如果用户对http head请求限定了 host字段的参数,那么需要用户指定相应的URL。用户也可以通过设定健康检查的频率、健康阈值和 不健康阈值来更好的控制健康检查功能。 针对4层(TCP协议)服务,SLB系统的健康检查机制为:默认通过在服务监听配置中指定的后端ECS端 口发起访问请求,如果端口访问正常则视为后端ECS运行正常,否则视为后端ECS运行异常。 当用户后端ECS健康检查异常后,SLB系统会将该ECS的转发权重设置为0,从而确保新的连接不会再被 转发到该ECS上,而已经建立的连接的请求却不会被直接断掉。 针对可能引起健康检查异常的排查思路点击这里查看。 关于健康检查的参数配置,提供如下参考建议: 响应超时时间:5秒 健康检查间隔:2秒 不健康阈值:3 健康阈值:3 7)权重设置为0怎么办? 权重为0的服务器将无法提供服务。 8)健康检查异常的排查思路? 参考http://help.aliyun.com/doc/view/13510029.html?spm=0.0.0.0.Oa9Ezv ------------------------- 12月份第3周1)轮询与最小连接数方式的区别是什么?当前SLB支持轮询和最小连接数2种模式的转发规则。“轮询模式”会将外部和内部的访问请求依序分发给后端ECS进行处理,而“最小连接数模式”会将外部和内部的访问请求分发给当前连接数最小的一台后端ECS进行处理。2)SLB支持redis的主备?目前我们的SLB不支持主备模式(冷备),只支持"轮询"和"最小连接数"两种负载模式。关于SLB的原理您可以参阅如下博文:http://blog.aliyun.com/149 基于ECS的redis搭建,您可以参阅论坛中其它用户的分享案例:http://bbs.aliyun.com/read/161389.html3)负载均衡的多台服务器之间文件会不会自动同步?slb是不会自动同步的,需要您自行配置。4)四层和七层检查的区别是什么?如果是4层(TCP)配置,健康检查只是简单的TCP握手,不会真正去访问您的业务。但对于7层(HTTP)配置,会发HTTP请求(类似于正常访问),并根据返回状态码判断服务状态(2XX表示服务正常)。5)我有多个slb,之前一个slb由于被攻击被黑洞给屏蔽了外部请求,是否可以在slb 并屏蔽后 能够自动将请求分发到另外的slb?由于攻击导致屏蔽外部请求的话,slb没有自动切换的方法的。6)目前slb是否可以设置黑名单?暂不支持。7)我的slb实例控制台显示是停止,为什么?需要给监听的端口设置带宽才能正常。  8)我使用了 SLB那么ESC 需要购买带宽吗?不需要的。但如需要管理ECS,则可购买少些的带宽如1M来管理。9)slb变更计费方式需要多久才能生效?变更和计费将在第二日零点后生效。10)私网SLB的使用,是如何收费的呢?私网slb是不收取费用的。 ------------------------- 12月第4周1)最近用slb后打开网页老出现503 和504错误?一般都是从ECS获取站点信息等异常导致的。您首先先确保源站都可以正常的访问。2)slb检查时突然发现SLB监听错误,怎么回事?配置的健康检查的域名为空,检查的路径是/index.html,目前查看服务器中只有站点c绑定了空主机头,且站点目录下有index.html,而此站点是停止状态,现已帮您启用,查看服务器的健康检查状态已经正常。3)我想使用slb搭建一个负载均衡,后端使用windows服务器,想咨询一下后端服务器是否需要进行什么特别配置呢?另外使用了slb后,后端还能否得到用户的真实IP地址呢,要不要进行什么特殊配置才可以得到后端用户的真实IP。后端服务器的操作系统和web环境最好保持一致,硬件配置上没有什么特别的,4层tcp是可以直接获得前端用户访问的真实地址的,7层http需要在后端web服务端设置一下,参考http://help.aliyun.com/view/13502961.html?spm=5176.7114037.1996646101.1.oRpnOM&pos=14)slb支持https吗?slb您可以通过TCP协议配置443端口的方式来实现,但是安全证书需要保存在您的后端ECS上。5)健康检查后续是否提供多个域名?健康检查只支持一个域名。6)我想关闭负载均衡的健康检查,请问如何配置?4层tcp是无法关闭健康检查的,7层http可以在控制台关闭。健康检查是不会消耗您服务器的资源的,因为slb都是通过内网ip来进行健康检查。7)如何在BLS上 限制单个IP 禁止访问 我的网站呢?SLB暂时不支持设置屏蔽用户端IP。 ------------------------- Re:Re负载均衡SLB常见咨询问题(持续连载) 引用第2楼517449116于2014-12-17 15:54发表的 Re负载均衡SLB常见咨询问题(持续连载) : 如果开启健康检查,健康检查异常的话,是不是就不会给这个异常的ECS分发? [url=http://bbs.aliyun.com/job.php?action=topost&tid=188736&pid=596806][/url] 异常的话不会在分发。 ------------------------- 2015年1月第1周1)有2台ECS起名叫A和B做SLB,A权重设的100 B权重设的0.请问.当A死机时,SLB是否会转到权重是0的B上?如果有一台设置为0,永远都不会有请求转发到此服务器上,即使权重100的宕机也不会转发到0权重的。2)会话保持的选择?开启会话保持功能后,SLB会把来自同一客户端的访问请求分发到同一台后端ECS上进行处理。针对7层(HTTP协议)服务,SLB系统是基于cookie的会话保持。针对4层(TCP协议)服务,SLB系统是基于IP地址的会话保持。3)用nagios或zabbix监控网络带宽,是否可以监控 slb的流量?nagios或zabbix,cacti是要要被监控端安装snmp或者相关agent ,slb不支持安装这些,所以无法通过这条监控软件进行监控。您可以在slb的控制台里面进行查看流量等相关信息。4)用了负载均衡后升级带宽,是不是只用在负载上面升级就可以了,ECS是不是不用在升级了?SLB与后端服务器是经过内网通信,所以如果业务量增加,您对SLB的带宽调整就行,不需要对服务器ECS进行带宽的升级。 ------------------------- 2015年1月第2周 1)SLB到期之后,会对SLB有关联的云主机怎么处理?云主机还没到期的前提下  我想把网站域名解析到SLB上 如果SLB到期了 会影响到我的网站服务么? 云服务器是不会有什么影响的,会自动又变成单独的云服务器可以供您使用的。但是如果您的域名是解析到SLB上,那么会影响到您的站点访问的。服务器上不会有其他的问题感谢您的支持。 2)当SLB 状态为停止的时候 还计算费用吗?停止后公网slb会收取实例费用。SLB价格总览参考:http://help.aliyun.com/view/11108234_13502923.html?spm=0.0.0.0.kBLsVA 3)做了SLB负载均衡,四层和7层负载均衡是否都走slb带宽? 都走slb带宽。 4)我想 移除 slb下的ecs(用作其他用途),请问在移除的时候是否会影响被负载到这台 ecs上的服务的使用 ,也是说slb这是是怎么处理的? 您可以将要移除的主机的权重更改为0 ,这样默认就不会在分发到权重为0的主机上,这个时候您可以移除该主机。但要确保您的另外一台服务器可以承受所有的访问。 5)SLB实例如何释放? 您需要登录管理控制台点击负载均衡。查询您之前创建的实例在哪个节点下,然后释放您的实例。 6)SLB按照小时的带宽计费, 是否需要每小时调整?比如我可否按照一个比较高的上限, 比如3G,然后每个小时按照该小时的峰值进行独立计费呢?   在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。http://help.aliyun.com/view/13502923.html?spm=5176.7114037.1996646101.3.67L5dm&pos=2;SLB目前最大带宽是1000Mbps 7)SLB可以限制每个ip的访问频率吗?(工单1F684MN)slb不支持这样配置的。 8)为什么我设置SLB健康检查间隔为5S,但却每秒都有很多请求?因为用于健康检查的服务ip不止一个,每秒中都会有不同的内网ip进行健康检查,健康检查是通过内网方式,不会消耗您后端服务器的资源,您可以将健康检查间隔阈值跳大些,这样监测频率会降低很多。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年1月第3周) 2015年1月第3周 1.发现很多100.97.0.0/16 的ip段扫描,给我服务器带来很大压力,怎么办? 100.97.0.0/16 是我们slb的健康检查服务ip段,如果给服务器带来较大压力,请调整健康检查的设置;健康检查的话 1)调低检查频率 2)设置检查静态文件,而不是默认首页或者动态文件 3)设置一个不记录日志的virtualhost,专门用于健康检查。 2)SLB里的带宽 和后面对应服务器的带宽有什么关联关系?比如SLB我设置了带宽为10M, 但是我后 面2台服务器购买的带宽都只有2M, 这种情况带宽以哪个为准? 如果您设置的是常规7层slb负载均衡,那么网站访问所使用的带宽,都将通过slb而不需要消耗云服 务器的带宽,但是云服务器本身的系统更新,以及您更新网站等等也是需要带宽的,因此您保留2M 即可。 3)采用流量计费方式的话带宽是否没有限制? SLB按流量计费最大的带宽是1G。 4)请问我如何获得一个外网SLB期所对应的内网IP呢?比如现在我有一个外网SLB下挂了一个ECS, 而ECS的iptables里我想做一些配置,针对来自于这个SLB的请求做一个判断,我需要知道这个外网 SLB的内网IP。 目前SLB与后端通过如下地址段进行交互: 10.158.0.0/16 10.159.0.0/16 100.97.0.0/16 您可以针对上述地址段做相关配置。 5)如何确保SLB后端的多台ECS之间的数据同步呢? 目前,有很多类似的工具可以实现服务器之间的数据同步,比如:rsync。具体使用及选择,还请通 过其他途径获得更多的介绍资料及指导信息。您也可以将您的ECS配置成无状态的应用服务器,而数 据和文件统一存放在RDS和OSS服务上。 ------------------------- 2015年1月第4周1.为什么我的SLB实例突然消失了?请检查您的SLB服务是否设置了自动释放时间导致。2.我想关掉负载均衡,怎么操作?您直接登录到阿里云管理控制台——slb负载均衡——实例中查询创建的slb服务,后方有“释放”的按钮,您直接释放即可。3. 我现在有两个阿里账号里面都有ECS,我能不能在一个slb里面配置不同阿里云账户下的ECS?目前只能将同一账户下的服务器添加到SLB中,无法跨账户添加。4.ECS做负载均衡需要用户做额外的配置吗?可以参考http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5973987。5. 云服务器上做数据库负载均衡如何实现,需要购买什么产品 ?文件服务器能否做负载均衡,比如10台文件服务器,包括读写这种的  ?1)数据库集群,用slb理论上是可以做的,但是如果您需要集群级别的数据库,建议使用我们的RDS。2)文件服务器也可以负载均衡,使用slb在均衡,保持会话,但是有一个问题是后端文件同步的,需要您自行同步,如 rsync。6.看SLB的说明是支持ddos的防护的,请问下,SLB的防护的峰值是多少,超过峰值黑洞时间是多少?这个与slb所在地区有关,和ecs的防御阀值是一样的,黑洞时间也是2.5小时。7. slb第七层是基于haproxy还是nginx还是tengine实现的?使用tengine实现的。8.7层和4层 SLB的超时时间是多少?7层超时时间是60s,4层超时时间是900s。9.负载均衡健康检查请求数量太多,怎么回事?因为slb前端机器是一组机器,所以健康检查请求较多,请您不要担心,集群内的每台服务都会对您的健康按照您设定的频率去做健康检查:您可以按照上述方法去优化您的健康检查项,看似请求量很大,但是对您资源消耗很少的,有2个建议给您:1)扩大健康检查的频率2)将检查页面配置为静态页面。这样请求消耗的资源会节省。10. SLB配置中的最小连接数是基于什么样判断?SLB会自动判断 当前ECS 的established 来判断是否转发。 ------------------------- 2015年2月第1周1)我想了解下SLB按流量计费是不是每小时需要扣0.02元?按量付费,国内节点配置费用是按照0.02/小时。流量单独计费。按带宽计费:采取按小时计费,以日结算(运行未满一日,按照当日实际使用小时数*当日开通的最高带宽的天价格/24)。如果您使用SLB实例的时间不足一小时,按一小时收费。2)请问健康检查发的什么请求? head 还是 get?head请求。3)SLB最大连接数如何来设置?目前暂不支持设置最大连接数限制。4)SLB 后端有两个服务器HA1和HA2,为什么我将HA1的权重设置成0,SLB的健康检查就有告警呢?slb四层的话,只要权重设置为0,那么健康检查就是显示异常。 ------------------------- 2015年2月第3周1)负载均衡SLB的实例防攻击防御是多少?我们有云盾的防御黑洞策略,比如以杭州节点的slb,其最高防御的流量阈值为5G,当最大流量超过5G,您的slb vip则会被加入到黑洞中,触发黑洞会使ecs或者slb正常使用中断2.5小时,这个您可以通过云盾管理控制台查看到这个说明。2) 我其他机房的服务器能添加到你们的负载均衡SLB中吗?不可以的,slb使用的是内网和后端的ECS互联,无法直接添加非阿里云主机的服务器,且slb后端的ecs需要使用同一节点的主机。3)负载均衡服务支持的最大负载均衡实例数目多少?总体峰值可支持每秒新建链接数大约多少?SLB对于后端服务器的数目是没有限制的。对于总体峰值每秒新建连接数是没有限制的。但是因为SLB前端是云盾服务,所以最大值取决于云盾中您配置的请求数。您可以查看云盾看到具体的值。4)SLB按量计费为什么需要设置带宽峰值?如果不设置带宽峰值,遇到攻击等情况,可能流量打的非常高的,带宽流量峰值您可以在slb控制台设置。5)在SLB控制面板看到的流入流量,要比后端服务器的eth0的income流量小很多, 请问slb的流入流量是否应该等于后端服务器的内网网卡入流量吗?不等于的,后端的eth0包括了slb的流量,还有其他的流量,包括ecs直接的内网通信等。slb只做转发,不处理请求的,slb通过内网转发到ecs。6)SLB中的月账单 是指我们拥有所有的 SLB 实例的计费呢,还是单独的某个 SLB 的计费?月账单是指您不同类型产品,截止当前日期内月内消费计费额度的,是所有SLB产品的。您也可以通过账单明细进行查询具体信息的。 ------------------------- 2014年2月第4周1)10.159.63.55,这个内网ip,总是恶意访问我们网站?SLB系统除了会通过系统服务器的内网IP将来自外部的访问请求转到后端ECS上之外,还会对ECS进行健康检查(前提是您已经开启了这一功能)和对您的SLB服务进行可用性监控,这些访问的来源都是由SLB系统发起的,具体包含的IP地址段是:杭州、青岛、北京、深圳节点SLB系统IP地址段:10.159.0.0/16,10.158.0.0/16和100.97.0.0/16,为了确保您对外服务的可用性,请确保对上述地址的访问配置放行规则。2)slb计费方式变更需要多久,业务会受到影响么?变更计费方式与变更配置说明1、支持用户在按使用流量和按公网带宽2种计费方式间切换;2、支持按固定带宽方式计费的用户灵活变更带宽配置;3、在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如:用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。4、按固定带宽方式计费变更带宽配置即时生效,带宽计费取自然日内用户开通的最高带宽。5、对客户业务不会造成影响;3)负载均衡能将我的外部非阿里云服务器和ECS服务器放到一块?目前负载均衡SLB仅支持阿里云ECS,无法支持外部非阿里云服务器。4)slb是否有连接数限制,需要大量终端一直与平台保持长连接,阿里云能提多少长连接?SLB没有并发连接数限制的,slb是转发请求不做处理,实际连接数还要跟您后端的处理能力有关。 ------------------------- 2015年3月第1周1)调整权重会对SLB已经有的正常连接有影响吗?目前调整权重会对调整权重的这台主机已有的连接产生影响,会有连接卡主,卡住时间由健康检查配置的时间决定。2)slb是否支持UDP协议?目前SLB暂不支持UDP协议。3)现在TCP四层负载均衡的出口带宽受ECS机器的出口带宽限制吗?slb和ECS之间走的是内网流量,带宽是不受限制的。4)如果没有外网ip, 是否可以用slb的4层转发 ?没有带宽4层SLB也是可以使用的。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年3月第1周) 2015年3月第2周 1)SLB变更计费方式并支付成功后无法添加配置? SLB在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效查看您今天变更过一 次计费方式,开始时间:2015-03-09 00:00:00。原按使用流量计费,在2015-03-09 00:00:00后变更为按固定带宽计 费,带宽峰值: 2Mbps。同时在您新的计费方式生效之前,您是无法对该SLB进行修改配置的。 2)我的账户怎么欠费¥7.88,这是怎么回事? 查看您有使用负载均衡slb业务,在slb产品的账单欠费,请您登陆用户中心-消费记录-账单明细中查看 记录。 3)如何屏蔽健康检查探测的日志记录? 关闭或者屏蔽对test.php访问日志的方式: 在站点配置文件中添加内容: location ~ /test.php { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 注: 1、对test.php的location必须要放置在对php|php5处理前,否则会因为先被进行全局匹配导致无法生效。 2、还可以用另一种方案实现: a、在后端服务器中单独为用于健康检查的页面建立一个站点; b、关闭这个站点的日志记录: location ~ .*\.(php|php5)?$ { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 3、如果检查页面是其他格式,比如test.html,可以采用如下方式进行屏蔽: location ~ /test.html { access_log off; } 4.我想问下SLB的固定带宽,10M是不是上行和下行最大都能达到10M? 固定带宽指的是下行带宽最大达到10M,上行带宽没有限制。上行带宽指的是SLB的入流量(上行),就是进入SLB的 流量。带宽指的是SLB的出流量(下行),就是SLB对外发生给客户端的流量。 5.一般配置SLB的时候有个权重0到100,是如何选择数值的? 权重需要您根据后端机器的配置进行选择比如AB两台机器性能一致就分别设置50,这样请求就会在这两台机器上轮询 ,不同权重决定请求分发的分配。 ------------------------- 2015年3月第3周1)公网的SLB和ECS之间的流量是否收费?不收费。2) 想做SLB+两台ECS,附件OSS,程序Discuz。但是不知道如何实现?slb要求后端的两台ecs数据是一致的,为了保持数据的一致性,建议共享存数和数据,静态文件放置到oss里,数据库文件走自己搭建的主从或者,连接同一台rds。3)按流量计算是否需要设置峰值?按流量计费不需要设置峰值的。4)如何建一个子帐号来管理负载均衡SLB?子账户无法管理负载均衡服务。

qilu 2019-12-02 01:15:34 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

概述 本文主要介绍无法远程登录Linux实例的案例和排查方法。 详细信息 本文主要通过如下2个方面解决无法远程登录Linux实例的问题。 常见报错案例 排查方法 常见报错案例 SSH无法远程登录Linux实例的常见案例如下所示,可根据实际报错信息选择不同的方案进行排查和处理。 PAM安全框架 Linux系统环境配置 SSH服务及参数配置 SSH服务关联目录或文件配置 SSH服务密钥配置 PAM安全框架 Linux系统的PAM安全框架可以加载相关安全模块,对云服务器的账户策略、登录策略等进行访问控制。如果相关配置存在异常,或触发了相关策略,就可能会导致SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:pam_listfile(sshd:auth): Refused user root for service sshd SSH登录时出现如下错误:requirement “uid >= 1000” not met by user “root” SSH登录时出现如下错误:Maximum amount of failed attempts was reached SSH登录时出现如下错误:login: Module is unknown Linux系统环境配置 Linux内的系统环境,比如中毒、账户配置、环境变量配置等,如果出现异常,也可能会导致SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:ssh_exchange_identification: read: Connection reset by peer 中毒导致SSH服务运行异常,出现如下错误:fatal: mm_request_send: write: Broken pipe SSH启动时出现如下错误:main process exited, code=exited SSH连接时出现如下错误:pam_limits(sshd:session):could not sent limit for ‘nofile’ SSH连接时出现如下错误:pam_unix(sshdsession) session closed for user SSH连接时出现如下错误:error Could not get shadow infromation for root SSH服务及参数配置 SSH服务的默认配置文件为/etc/ssh/sshd_config。配置文件中的相关参数配置异常,或启用了相关特性或策略,也可能会导致 SSH登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:Disconnected:No supported authentication methods available SSH登录时出现如下错误:User root not allowed because not listed in SSH登录时出现如下错误:Permission denied, please try again SSH登录时出现如下错误:Too many authentication failures for root SSH启动时出现如下错误:error while loading shared libraries SSH启动时出现如下错误:fatal: Cannot bind any address SSH启动时出现如下错误:Bad configuration options 云服务器ECS Linux SSH启用UseDNS导致连接速度变慢 Linux实例中由于SELinux服务开启导致SSH远程连接异常 SSH服务关联目录或文件配置 SSH服务基于安全性考虑,在运行时,会对相关目录或文件的权限配置、属组等进行检查。过高或过低的权限配置,都可能会引发服务运行异常,进而导致客户端登录失败。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:No supported key exchange algorithms SSH启动时出现如下错误:must be owned by root and not group or word-writable SSH服务密钥配置 SSH服务采用非对称加密技术,对所传输的数据进行加密。客户端及服务端会交换和校验相关密钥信息的有效性。根据不同报错信息,可参见如下常见案例进行解决。 SSH登录时出现如下错误:Host key verification failed SSH服务的公私钥异常导致无法SSH登录Linux实例 排查方法 若常见报错案例没有解决问题,可以参考如下流程排查问题。 检查CPU负载、带宽及内存使用情况 客户端排查 中间网络 网络检查 端口检查 安全组检查 示例 提示: 以下操作在CentOS 6.5 64位操作系统中进行过测试,在其他Linux发行版中可能存在差异,具体情况请参阅对应Linux发行版的官方文档。 客户端SSH连接Linux实例是运维操作的主要途径。通过管理终端可以用于临时运维操作,或者在客户端SSH登录异常时,用于问题排查和分析。 下图为SSH登录关联因素示意图。由此可见,通过SSH无法远程登录Linux实例时,可能涉及的关联因素较多。 检查CPU负载、带宽及内存使用情况 确认是否存在CPU负载过高的情况,如果存在,则参考本步骤解决问题,如果不存在,则执行下一步步骤。 提示:您无法主动监控系统内部的程序运行状态,但是可以借助云监控进行查看。 登录云监控控制台,依次选择 主机监控 > 进程监控。 查看应用运行情况,排除CPU负载过高的原因,如何查看CPU负载问题,请参见Linux系统ECS实例CPU使用率较高的排查思路。 提示:在某个时间段CPU负载过高可能导致远程连接失败,建议您查询程序或者实例资源是否不满足现有要求。 无法远程连接可能是公网带宽不足导致的,具体排查方法如下。可通过续费ECS实例,然后重启实例解决。详情参见手动续费或者自动续费。 登录ECS管理控制台。 找到该实例, 单击 管理 进入 实例详情 页面,查看网络监控数据。 检查服务器带宽是否为“1k”或“0k”。如果购买实例时没有购买公网带宽,后来升级了公网带宽,续费的时候没有选择续费带宽,带宽就会变成“1k”。 远程连接输入用户密码登录后,不能正常显示桌面直接退出,也没有错误信息。这种情况可能是服务器内存不足导致的,需要查看一下服务器的内存使用情况。具体操作如下。 使用控制台远程连接功能登录到Linux实例。 查看内存使用情况,具体请参考Linux系统的ECS实例中如何查看物理CPU和内存信息,确认内存不足后,请参考Linux服务器内存消耗过高进行处理。 客户端排查 客户端无法正常登录时,先使用不同的SSH客户端基于相同账户信息进行登录测试。如果能正常登录,则判断是客户端配置问题,需要对客户端配置或软件运行情况做排查分析。关于如何使用客户端SSH登录Linux实例,您可以参考远程连接Linux实例。 步骤一:使用管理终端登录实例 无论何种原因导致无法远程连接实例,请先尝试用阿里云提供的远程连接功能进行连接,确认实例还有响应,没有完全宕机,然后再按原因分类进行故障排查。 登录云服务器管理控制台,单击左侧导航栏中的 实例,然后在目标实例右侧单击 远程连接。 在首次连接或忘记连接密码时,单击 修改远程连接密码,修改远程连接的密码。 然后通过远程连接密码连接实例。 步骤二:检查客户端本地网络是否异常 确认是否存在用户本地无法连接外网的故障。 如果存在,则检查网卡驱动,如果存在异常,则重新安装。使用管理终端登录实例,查看/etc/hosts.deny文件,查看是否存在拦截IP,如果存在则删除此IP配置即可。 如果不存在,则执行下一步步骤。 步骤三:重启实例 在确保登录密码正确的情况下,确认之前是否曾重置过密码。检查重置实例密码后是否未重启实例,如果存在实例密码修改记录,但无重启实例记录,则参考以下操作步骤重启实例。 登录ECS管理控制台,单击左侧导航栏中的 实例。 在页面顶部的选择对应的地域,目标实例右侧单击 更多 > 实例状态 > 重启,再单击 确认 即可。 中间网络 中间网络包括网络检查和端口检查。 网络检查 无法正常远程连接Windows实例时,需要先检查网络是否正常。 用其他网络环境中,不同网段或不同运营商)的电脑连接对比测试,判断是本地网络问题还是服务器端的问题。如果是本地网络问题或运营商问题,请联系本地IT人员或运营商解决。如果是网卡驱动存在异常,则重新安装。排除本地网络故障后进行下一步检查。 在客户端使用ping命令测试与实例的网络连通性。 网络异常时,请参考网络异常时如何抓取数据包进行排查。 当出现ping丢包或ping不通时,请参考使用ping命令丢包或不通时的链路测试方法进行排查。 如果出现间歇性丢包,ECS实例的网络一直处于不稳定状态时,请参考使用ping命令测试ECS实例的IP地址间歇性丢包进行解决。 系统内核没有禁ping的情况下,使用ping命令测试ECS服务器,发现网络不通,请参考Linux系统的ECS中没有禁PING却PING不通的解决方法。 端口检查 网络检查正常后,进一步检查端口是否正常。 使用管理终端登录实例,执行如下命令,编辑SSH配置文件。 vi /etc/ssh/sshd_config 找到“#port 22”所在行,检查默认端口22是否被修改,且前面的“#”是否删除,如果没有删除,可以把前面的“#”删除,然后将22改为其它的端口,再保存退出即可。 注:服务监听能使用的端口范围为0到65535,错误配置监听端口会导致远程桌面服务监听失败。 执行如下命令,重启SSH服务。 /etc/init.d/sshd restart 注:也可执行如下命令,重启SSH服务。 service sshd restart 使用Python自带的Web服务器用于临时创建新的监听端口进行测试。 python -m SimpleHTTPServer [$Port] 如果登录方式改变或者ECS安全组规则中未放行修改后的端口号,则参考如下步骤放行修改后的端口。 注:ECS的安全组规则中默认放行22端口。修改了远程桌面的端口后,需要在安全组规则中放行修改后的端口号。 登录ECS管理控制台。 找到该实例,单击 管理 进入 实例详情 页面,切换到 本实例安全组 标签页,单击 配置规则。 在安全组规则页面,单击 添加安全组规则。 在弹出的页面中,端口范围 输入修改后的远程桌面端口号。授权对象 输入客户端的公网IP地址。比如修改后的远程桌面端口号为2222,则 端口范围 应输入“2222/2222”。填写完成后,单击 确定。 通过上一步获取的端口,参考如下命令,进行端口测试,判断端口是否正常。如果端口测试失败,请参考使用ping命令正常但端口不通时的端口可用性探测说明进行排查。 telnet [$IP] [$Port] 注: [$IP]指Linux实例的IP地址。 [$Port]指Linux实例的SSH端口号。 系统显示类似如下,比如执行telnet 192.168.0.1 22命令,正常情况下,系统会返回服务端中SSH的软件版本号。 安全组检查 检查安全组配置,是否允许远程连接的端口。 参考查询安全组规则,查看安全组规则。如果远程连接端口没有进行配置,则参考Linux实例启用SSH服务后设置对应的安全组策略配置。 确认是否存在无法ping通ECS实例,在排除Iptables和网卡IP配置问题且回滚系统后,仍然无法ping通。可能是ECS实例安全组默认的公网规则被删除,则需要重新配置ECS实例的安全组公网规则,具体操作请参见ECS实例安全组默认的公网规则被删除导致无法ping通。如果不存在,则继续下一步骤检查。 示例 如果根据前述问题场景进行排查和处理后,还是无法正常登录。则建议按照如下步骤逐一排查和分析。 使用不同的客户端SSH及管理终端做对比访问测试,判断是否是个别客户端自身配置或软件运行问题所致。 参阅中间网络问题相关说明,测试网络连通性。 参阅管理终端,登录云服务器,在客户端进行访问测试的同时,执行如下命令,查看相关日志。 tailf /var/log/secure 参考如下命令, 比如ssh -v 192.168.0.1 命令,获取Linux环境中详细的SSH登录交互日志。 ssh -v [$IP] 通过管理终端登录Linux实例,参考如下步骤,检查SSH服务运行状态。 执行如下命令,检查服务运行状态。 service sshd status service sshd restart 正常情况下会返回SSH服务的运行状态及进程PID,系统显示类似如下。 [root@centos ~]# service sshd status openssh-daemon (pid 31350) is running... [root@centos ~]# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] 执行如下命令,检查服务监听状态。 netstat -ano | grep 0.0.0.0:22 正常情况下会返回相应端口监听信息,系统显示类似如下。 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0/0) 通过管理终端登录Linux实例,执行如下命令。如果能正常登录,则推断是系统防火墙或外部安全组策略等配置异常,导致客户端登录失败。 ssh 127.0.0.1 若用阿里云提供的远程连接功能仍无法成功连接实例,请尝试重启实例。重启操作会使实例停止工作,从而中断业务,请谨慎执行。 提示:重启实例前,需给实例创建快照,用于数据备份或者制作镜像。创建快照的方法请参见创建快照。 登录ECS管理控制台,单击左侧导航栏中的 实例。 在页面顶部的选择对应的地域,在目标实例右侧单击 更多 > 实例状态 > 重启,再单击 确认 即可。

1934890530796658 2020-03-26 09:52:57 0 浏览量 回答数 0

回答

Go 的优势在于能够将简单的和经过验证的想法结合起来,同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧,作者认为,Go 语言具备的所有这些优点,将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大,如果将所有因素都纳入考虑,没有其他语言能够像 Go 语言一样“全面开花”,在大型软件工程方面,尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的,长期以来,他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前,Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后,在编译器和垃圾收集方面拥有数十年的经验。有太多次,他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是,他们开始着手创建新的编程语言,将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下,在包含数千万行代码的大型代码库上进行协作时,就会发生真正令人痛苦的问题。这样会导致一些问题,如下: 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有,混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等,他们需要了解代码库,但也具备广泛的编码经验。依赖于许多外部库或运行时,其中一些不再以原始形式存在。在代码库的生命周期中,每行代码平均被重写 10 次,被弄得千疮百痍,而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题,有时会以使小型工程变得更麻烦为代价,例如,代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能,如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式,机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式,从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是,Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言,只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码,以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的,避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而,在其生命周期中,人们阅读代码的时间却远远超过最初编写代码所需的时间(100 倍)。例如,审查、理解、调试、更改、重构或重用代码。在查看代码时,往往只能看到并理解其中的一小部分,通常不会有完整的代码库概述。为了解释这一点,Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说,这使得错误处理编写起来更加繁琐,但是也更容易理解。 简单易学 Go 是如此的小巧而简单,以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验,培训用不了一个星期(相比于掌握其他语言需要几个月),初学者就能够理解 Go 专家编写的代码,并为之做出贡献。为了方便吸引更多的用户,Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行,允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作,而不是个人的自我表达。 在 Go(和 Python)中,所有的语言特性都是相互正交和互补的,通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题,你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时,国骂会更少,而且人们的工作可以更好地融合在一起,从而形成了一致的整体,人人都为之感到自豪,并乐于工作。这还避免了大型工程的问题,如: 开发人员认为良好的工作代码很“混乱”,并要求在开始工作之前进行重写,因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/e64418f1455d46aaacfdd03fa949f16d.png) 简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言(Java、JavaScript、Python、Ruby、C、C++)都是 20 世纪 80 年代到 21 世纪初设计的,当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的,并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现,而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式,如 Actor 模型,但是总有多个可用选项,结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核,软件必须并行化才能高效运行。Go 是在多核处理器时代编写的,并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言,计算机系统接收数据,对其进行处理(通常要经过几个步骤),然后输出结果数据。例如,Web 服务器从客户端接收 HTTP 请求,并将其转换为一系列数据库或后端调用。一旦这些调用返回,它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例: 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供(几乎无限的)并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的,因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来,面向对象的使用富有成效,并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法,并记住了这些知识。它保留了好的部分,如封装、消息传递等。Go 还避免了继承,因为它现在被认为是有害的,并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言(Java、JavaScript、Python、Ruby)都是在互联网成为当今无处不在的计算平台之前设计的。因此,这些语言的标准库只提供了相对通用的网络支持,而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的,当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题: 碎片化:总是有多个选项实现相同的功能。 膨胀:库常常实现的不仅仅是它们的用途。 依赖地狱:库通常依赖于特定版本的其他库。 未知质量:第三方代码的质量和安全性可能存在问题。 未知支持:第三方库的开发可能随时停止支持。 意外更改:第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢,但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式,但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响: 集中讨论重要主题: 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在, 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码,但如果其他人按照自己喜欢的方式格式化了代码,这么做很招人烦。 自动代码更改并不会打乱手写代码的格式,例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时,通常会有几个相互竞争的格式标准。例如,JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用,也可以只使用其中的一个。但许多 JS 项目并没有采用它们,因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中,因此只有一个标准,每个人都在使用它。 快速编译 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/8a76f3f07f484266af42781d9e7b8692.png) 对于大型代码库来说,它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java,与 Haskell、Scala 或 Rust 等更复杂的语言相比,它们的编译速度相对较快。尽管如此,当编译大型代码库时,即使是少量的缓慢也会加剧编译的延迟,从而激怒开发人员,并干扰流程。Go 的设计初衷是为了提高编译效率,因此它的编译器速度非常快,几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈,还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单,因此它被移植到许多平台,如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言(Java、JavaScript、Python 等)不同,Go 二进制文件不需要启动或预热的时间,因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外,Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码,每次运行程序时,它们还会加载大型且高度复杂的基础架构,以进行编译和优化程序。如此一来,它们的启动时间就变慢了,并且还占用了大量内存(数百兆字节)。而 Go 进程的开销更小,因为它们已经完全编译和优化,只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中,以及在开发过程中,这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈,同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍,这是因为它无需包含编译器、JIT,以及更少的运行时基础架构的原因。这些特点,在部署大型应用程序时很重要。想象一下,如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样?如果使用 Node/JVM 时,我们的 Docker 注册表就必须提供 100 个 docker 镜像,每个镜像 200MB,那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下,如果我们想每天部署 100 次的话,如果使用 Go 服务,那么 Docker 注册表只需提供 10 个 docker 镜像,每个镜像只有 20MB,共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署,从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件,并无需安装特定版本的 JVM、Node 或 Python 运行时;也不必将库下载到生产服务器上,更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是,只是将 Go 二进制文件放到服务器上,它就会在那里运行,而不用关心服务器运行的是什么。前面所提到的那些,唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库,并将所有相关代码下载(供应)到自己的代码库中。这样做有很多好处: 在使用第三方代码之前,我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样,是我们应用程序的一部分,应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方(包括私有 Git repos)获取第三方库,你就能永久拥有它们。 经过验收后,编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码,这也并不足为奇。 即使软件包存储库速度变慢,或托管包不复存在,部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易,并且可从它们带来的许多性能和安全性改进中获益。同时,由于 Go 二进制文件包含了它们需要的所有依赖项,因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件,而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中,文档对于使软件可访问性和可维护性非常重要。与其他特性类似,Go 中的文档简单实用: 由于它是嵌入到源代码中的,因此两者可以同时维护。 它不需要特殊的语法,文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中,因此每个人都使用它们。 Go linter 需要导出元素的文档,以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时,那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化,使系统更为健壮、可靠、高效,并具有开放式开发的优势,如来自许多行业的广泛支持,多个大型实体和许多用户的支持,以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然,Go 也并非完美无缺,每种技术选择都是有利有弊。在决定选择 Go 之前,有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念(如 HTTP 2 Server push 等)方面处于行业领先地位,但与 JVM 生态系统中的第三方库相比,用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素,Go 团队非常谨慎,只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后,Go 团队正在谋划对语言进行一系列更大的改进,作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿,但支持硬实时需要没有垃圾收集的技术,例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则,虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时,这些准则可能会使大型工程项目免于许多痛苦。总的来说,正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里,用于大型软件开发项目的绝佳选择。

有只黑白猫 2020-01-07 14:11:38 0 浏览量 回答数 0

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构,然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。  当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。  1.Kubernetes的一些理念:  用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。  保证系统总是按照用户指定的状态去运行。  不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。  那些需要担心和不需要担心的事情。  更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。  对于Kubernetes的架构,可以参考官方文档。  大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。  看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在Kubernetes的未来版本中解决。  2.Kubernetes的主要特性  会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限,只能简单一些了。  另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。  1)网络  Kubernetes的网络方式主要解决以下几个问题:  a.紧耦合的容器之间通信,通过Pod和localhost访问解决。  b.Pod之间通信,建立通信子网,比如隧道、路由,Flannel、OpenvSwitch、Weave。  c.Pod和Service,以及外部系统和Service的通信,引入Service解决。  Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。  注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖PodIP;通过Service环境变量或者DNS解决。  2)服务发现及负载均衡  kube-proxy和DNS,在v1之前,Service含有字段portalip和publicIPs,分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp,而在serviceport定义列表里,增加了nodePort项,即对应node上映射的服务端口。  DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。  注意:kube-proxy在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。  3)资源管理  有3个层次的资源限制方式,分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持,比如Docker对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。  资源管理模型-》简单、通用、准确,并可扩展  目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。  4)高可用  主要是指Master节点的HA方式官方推荐利用etcd实现master选举,从多个Master中得到一个kube-apiserver保证至少有一个master可用,实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。  一张图帮助大家理解:  也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver同一时间只能有一套运行。  5)rollingupgrade  RC在开始的设计就是让rollingupgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。  通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback当前正在执行的upgrade操作。  同样,Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。  6)存储  大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。  Docker也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。  创建一个带Volume的Pod:  spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。  emptyDir随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源(比如本地Docker)。  gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。  awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。  rbd-RadosBlockDevice-Ceph  secret用来通过KubernetesAPI向Pod传递敏感信息,使用tmpfs(aRAM-backedfilesystem)  persistentVolumeClaim-从抽象的PV中申请资源,而无需关心存储的提供方  glusterfs  iscsi  gitRepo  根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的:)  7)安全  一些主要原则:  基础设施模块应该通过APIserver交换数据、修改系统状态,而且只有APIserver可以访问后端存储(etcd)。  把用户分为不同的角色:Developers/ProjectAdmins/Administrators。  允许Developers定义secrets对象,并在pod启动时关联到相关容器。  以secret为例,如果kubelet要去pull私有镜像,那么Kubernetes支持以下方式:  通过dockerlogin生成.dockercfg文件,进行全局授权。  通过在每个namespace上创建用户的secret对象,在创建Pod时指定imagePullSecrets属性(也可以统一设置在serviceAcouunt上),进行授权。  认证(Authentication)  APIserver支持证书、token、和基本信息三种认证方式。  授权(Authorization)  通过apiserver的安全端口,authorization会应用到所有http的请求上  AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。  8)监控  比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。  Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。  注意:heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 答案来源网络,供您参考

问问小秘 2019-12-02 02:13:31 0 浏览量 回答数 0

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构,然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。  当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。  1.Kubernetes的一些理念:  用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。  保证系统总是按照用户指定的状态去运行。  不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。  那些需要担心和不需要担心的事情。  更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。  对于Kubernetes的架构,可以参考官方文档。  大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。  看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在Kubernetes的未来版本中解决。  2.Kubernetes的主要特性  会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限,只能简单一些了。  另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。  1)网络  Kubernetes的网络方式主要解决以下几个问题:  a.紧耦合的容器之间通信,通过Pod和localhost访问解决。  b.Pod之间通信,建立通信子网,比如隧道、路由,Flannel、OpenvSwitch、Weave。  c.Pod和Service,以及外部系统和Service的通信,引入Service解决。  Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。  注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖PodIP;通过Service环境变量或者DNS解决。  2)服务发现及负载均衡  kube-proxy和DNS,在v1之前,Service含有字段portalip和publicIPs,分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp,而在serviceport定义列表里,增加了nodePort项,即对应node上映射的服务端口。  DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。  注意:kube-proxy在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。  3)资源管理  有3个层次的资源限制方式,分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持,比如Docker对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。  资源管理模型-》简单、通用、准确,并可扩展  目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。  4)高可用  主要是指Master节点的HA方式官方推荐利用etcd实现master选举,从多个Master中得到一个kube-apiserver保证至少有一个master可用,实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。  一张图帮助大家理解:  也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver同一时间只能有一套运行。  5)rollingupgrade  RC在开始的设计就是让rollingupgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。  通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback当前正在执行的upgrade操作。  同样,Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。  6)存储  大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。  Docker也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。  创建一个带Volume的Pod:  spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。  emptyDir随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源(比如本地Docker)。  gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。  awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。  rbd-RadosBlockDevice-Ceph  secret用来通过KubernetesAPI向Pod传递敏感信息,使用tmpfs(aRAM-backedfilesystem)  persistentVolumeClaim-从抽象的PV中申请资源,而无需关心存储的提供方  glusterfs  iscsi  gitRepo  根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的:)  7)安全  一些主要原则:  基础设施模块应该通过APIserver交换数据、修改系统状态,而且只有APIserver可以访问后端存储(etcd)。  把用户分为不同的角色:Developers/ProjectAdmins/Administrators。  允许Developers定义secrets对象,并在pod启动时关联到相关容器。  以secret为例,如果kubelet要去pull私有镜像,那么Kubernetes支持以下方式:  通过dockerlogin生成.dockercfg文件,进行全局授权。  通过在每个namespace上创建用户的secret对象,在创建Pod时指定imagePullSecrets属性(也可以统一设置在serviceAcouunt上),进行授权。  认证(Authentication)  APIserver支持证书、token、和基本信息三种认证方式。  授权(Authorization)  通过apiserver的安全端口,authorization会应用到所有http的请求上  AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。  8)监控  比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。  Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。  注意:heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!

牧明 2019-12-02 02:16:53 0 浏览量 回答数 0

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构, 然后从网络、 资源管理、存储、服务发现、负载均衡、高可用、rolling upgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。 当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解 Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。 1.Kubernetes的一些理念: 用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。 保证系统总是按照用户指定的状态去运行。 不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。 那些需要担心和不需要担心的事情。 更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。 对于Kubernetes的架构,可以参考官方文档。 大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。 看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在 Kubernetes 的未来版本中解决。 2.Kubernetes的主要特性 会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性 -> 由于时间有限,只能简单一些了。 另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。 1)网络 Kubernetes的网络方式主要解决以下几个问题: a. 紧耦合的容器之间通信,通过 Pod 和 localhost 访问解决。 b. Pod之间通信,建立通信子网,比如隧道、路由,Flannel、Open vSwitch、Weave。 c. Pod和Service,以及外部系统和Service的通信,引入Service解决。 Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。 注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖Pod IP;通过Service环境变量或者DNS解决。 2) 服务发现及负载均衡 kube-proxy和DNS, 在v1之前,Service含有字段portalip 和publicIPs, 分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp 通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp, 而在service port 定义列表里,增加了nodePort项,即对应node上映射的服务端口。 DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取Kubernetes API获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain, "tenx.domain"是提前设置的主域名。 注意:kube-proxy 在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service 的endpints 或者 Pods上。Kubernetes官方也在修复这个问题。 3)资源管理 有3 个层次的资源限制方式,分别在Container、Pod、Namespace 层次。Container层次主要利用容器本身的支持,比如Docker 对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。 资源管理模型 -》 简单、通用、准确,并可扩展 目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的scheduler plugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。 4)高可用 主要是指Master节点的 HA方式 官方推荐 利用etcd实现master 选举,从多个Master中得到一个kube-apiserver 保证至少有一个master可用,实现high availability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。 一张图帮助大家理解: 也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver 同一时间只能有一套运行。 5) rolling upgrade RC 在开始的设计就是让rolling upgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。 通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback 当前正在执行的upgrade操作。 同样, Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。 6)存储 大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes 的 Volume就是主要来解决上面两个基础问题的。 Docker 也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。 创建一个带Volume的Pod: spec.volumes 指定这个Pod需要的volume信息 spec.containers.volumeMounts 指定哪些container需要用到这个Volume Kubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。 emptyDir 随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持 RAM-backed filesystemhostPath 类似于Docker的本地Volume 用于访问一些本地资源(比如本地Docker)。 gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平台上可用。 awsElasticBlockStore 类似于GCE disk 节点必须是 AWS EC2的实例 nfs - 支持网络文件系统。 rbd - Rados Block Device - Ceph secret 用来通过Kubernetes API 向Pod 传递敏感信息,使用 tmpfs (a RAM-backed filesystem) persistentVolumeClaim - 从抽象的PV中申请资源,而无需关心存储的提供方 glusterfs iscsi gitRepo 根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的 :) 7)安全 一些主要原则: 基础设施模块应该通过API server交换数据、修改系统状态,而且只有API server可以访问后端存储(etcd)。 把用户分为不同的角色:Developers/Project Admins/Administrators。 允许Developers定义secrets 对象,并在pod启动时关联到相关容器。 以secret 为例,如果kubelet要去pull 私有镜像,那么Kubernetes支持以下方式: 通过docker login 生成 .dockercfg 文件,进行全局授权。 通过在每个namespace上创建用户的secret对象,在创建Pod时指定 imagePullSecrets 属性(也可以统一设置在serviceAcouunt 上),进行授权。 认证 (Authentication) API server 支持证书、token、和基本信息三种认证方式。 授权 (Authorization) 通过apiserver的安全端口,authorization会应用到所有http的请求上 AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。 8)监控 比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的container metrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。 Kubernetes集群范围内的监控主要由kubelet、heapster和storage backend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。 注意: heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 此答案来源于网络,希望对你有所帮助。

养狐狸的猫 2019-12-02 02:13:33 0 浏览量 回答数 0

问题

【javascript学习全家桶】934道javascript热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:22 6202 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板