首页 文章 精选 留言 我的

精选列表

搜索[思考模型],共10000篇文章
优秀的个人博客,低调大师

中钢李红:传统企业大数据实施路径思考

大数据是什么?数据、技术、思维、资源、财富、能力。 在中钢集团信息管理部总经理李红多年的信息化经验看来,制造业之前都在解决流程、管理等效率问题。而现如今大数据不仅在数字化转型的过程中发挥着重要作用,同时也在重塑企业的发展竞争格局。 中钢集团信息管理部总经理李红 大数据成为转型升级的新动能 大数据是新一代信息技术、网络技术、管理技术和应用技术等综合发展的产物,具有鲜明的技术驱动特征。大数据已经在各大行业得到应用,在金融、通信、政府、零售、制造行业应用更为深入。 传统制造业正结合“十三五”规划,积极研究制定贯彻落实“中国制造2025”、“互联网+”和“大数据”的战略措施。 在中国制造2025战略与大数据战略的融合发展下,大数据作为转型的动力,已经成为企业新资源、新资产、新财富、新的竞争力。 推进数字化转型的途径和挑战 互联网公司是最先从IT进入到DT时代,传统企业则希望运用大数据进行数字化转型,实现创新发展,这个过程带来了5方面变化: “数据”被重新定义:从信息——知识——资产企业形态和概念的转变:许多企业都想变成“数字企业”数字价值的转变:成为企业的新资源、新财富、新的核心竞争力信息化使命的变化:从“建设系统改善管理”到“完善数据挖掘价值”CIO职能的变化:从“首席信息官”到“首席数据官” 同时企业数字化转型还面临了一些挑战,企业信息化基础薄弱,信息系统少、技术落后,管理停留在手工式录入,业务靠线下式运营;企业数据结构不合理,“烟囱式”系统、“孤岛式”数据较为普遍;企业发展定位不明、管理目标不清,对“数据转型”缺乏明确需求;企业发展观念落后,经营混乱,管理粗放,不具备数字化转型的基础条件。 发掘大数据价值需要融合创新 企业需要认识到数据的价值,但结构化数据分析和利用对数据质量要求较高,需要做到准确、及时和完整,但实际上达到这种要求难度很大。 而大数据不再是传统意义的数据,其带来了全新的价值提升,优化和改善传统企业的管理模式、业务模式和技术结构。 大数据同时也在重塑企业发展模式和竞争格局,在应用层面促使企业经营管理的触角向全产业链延伸,重构企业的供应链和价值链,在未来物联网将是大数据价值新发力点。 画外音: 在我邀约李总参加成都大数据应用大会时,他就和我说之前一直在分享智能制造的话题,其实制造业最应该关注的还是大数据。 在会上,李总和前央视主播,现找钢网高级副总裁兼首席战略官郎永淳寒暄了很久。这也让我深深感受到钢铁行业早已不是原来的“傻大黑粗”,他们怀抱着开放的态度,运用云计算、大数据等新技术正在实现互联网化的轻巧转身。 原文发布时间为:2016-7-14 本文作者:王聪彬 本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网

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

变革早已始:对平台开发的一些思考

在 2012年的时候,我在豆瓣做 Douban App Engine ( a.k.a DAE)。那时候我遇到了一个问题,就是如何隔离 Engine 的 Runtime 和应用本身的 Runtime,如果不学 GAE 那样大规模 Mock Python 的话,无论怎么做隔离性上终究不会太完美。 在 2013年春节过后,DAE 在豆瓣内部已经支撑起多数服务和应用,而我也因为职业规划准备离职去穿越亚洲,这时候一个叫 Docker 的虚拟化方案进入了我的视野。回想起 2012年我遇到的隔离性问题的,当时的我立刻被这个方案给吸引住了,即便在战火纷飞的阿富汗腹地,也靠着仅有的当地网络关注着这个项目的状态。 从我个人来看,随着业务的增长服务也会被逐步拆分,为了提高整体的服务器利用率和调度效率,平台自动化将会是一种比较好的选择。对应用耦合的,一般称为 PaaS,平台即服务,如果对硬件耦合的,一般称为 IaaS,基础设施即服务。如果纯粹靠 PaaS,隔离性上会比较让人担忧,如果是完全的 IaaS,过重的 overhead 会使得硬件利用率达不到预期以至于成本的失控。有些开源项目结合 IaaS 和 PaaS 去做自动化平台在我看来也不是一个很好的选择,毕竟公司千千万万,业务技术线也不能一概而论,二次开发也需要考虑平衡硬件和人力成本。所以我觉得一个好的平台应该做到严谨的隔离,无痛的扩展,简单的部署,可靠的支撑等几个方面,同时也不能损耗太多的性能,并且能易于上层的开发,降低公司成本。Docker 本身是个不错的基础技术,在隔离性和性能上取得了较好的平衡,相比之下 VM 虽然隔离很严谨,相对性能就损耗比较高了。并且 Docker 提供了一系列适合二次开发的 API,可以方便的低成本的做出一个适合公司本身自己技术栈的自动化平台,这对于很多发展型的公司而言那是极好的。 随着时间的推移,在容器方面我们也看到了很多后来者对于 Docker 的挑战,如 CoreOS 带来的 rocket,如有着更高隔离性的 Hyper 等。但在目前来说,我认为 Docker 的地位短时间来说很难被改变。一来大多数的公司主要以 Docker 作为基础组件构建对内的自动化平台,对更高层次的内核安全性需求没那么强烈,另外一方面基于 Docker API 的周边组件也趋于成熟,短期内其他竞品没那么完备的生态环境。随着 Docker 本身母公司的其他产品诸如 Docker Machine,Docker Swarm 等的成熟,以及业界第三方的产品如 Kubernetes 和 Mesos 等,Docker 在集群编排和调度领域的优势还会进一步扩大。 我依稀记得 2014年我来到芒果TV开始搞 Docker 相关自动化平台时的情景,虽然当时 Docker 在业内很火,但是实际上在公司内部使用的还是太少,太多公司只是用其做做实验性质的测试和体验。在 2015 年初始,新浪和腾讯两家的分享引爆了国内的容器圈,使用 Docker 作为其服务器集群调度和编排的公司如雨后春笋般冒了出来。同时 Docker 本身也在不断的进化,如 1.5 引入的 stats 接口,如 1.7 引入的日志模式,如 1.8 引入的 Volume,Docker 虽然不完美但已经足矣胜任生产环境下大规模使用。而未来即将到来的 libnetwork 等技术,也将会在 SDN 这块带来新的变革。 我不好说未来一定会怎样,是 Docker 胜出亦或是其他技术,但 Docker 所引发的这个趋势,将会在未来的一段日子里面,不断的影响着平台层面的开发人员。变革,早已开始。 本文作者:彭哲夫 来源:51CTO

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

对我国域名系统安全问题的思考

以互联网为基础的信息网络是进行国家信息化建设和实现国家信息化战略的基础设施,域名系统是互联网上大部分服务和应用正常运转和实施的基石,是互联网上最为关键的基础网络服务之一,事关互联网乃至国家的稳定和安全,是国家信息化建设的重中之重。 通过对域名系统的攻击和利用可以造成巨大危害。伊拉克顶级域名失效事件、利比亚国家顶级域名失效事件等都表明,对域名系统的控制已成为一个有效的网络空间作战手段,可以在非常时期,瘫痪一个国家网络,造成信息孤岛,失去信息优势,丧失战争的主动权。域名系统已成为网络空间作战的重要目标。 我国域名系统由于根域名服务器的不可控和域名系统本身的脆弱性,存在巨大的安全隐患。近年来,更是事件频发,对我互联网使用以及国家社会、政治、经济都造成了巨大的影响。因此域名系统相关问题已成为制约我国互联网发展的重要因素。 互联网域名系统简介 域名系统最主要的作用是完成对域名的解析,即把为便于记忆、用来标识互联网上某台计算机或一组计算机的名称,翻译转换为与其对应的IP地址域名系统是非常重要的互联网基础服务。如果没有域名系统,互联网上绝大多数应用,如网页浏览、电子邮件收发,就会因不知道通信对象具体物理地址,而无法正常使用。 域名系统DNS(Domain Name System)是由主机名解析方案发展出来的一种新的名字的解析机制。DNS域是一种分布式的层次结构系统,包括一个根域,以空标签(“”)表示。根域的下一级是顶级域,如中国是cn,美国是us,日本是jp.在顶级域名下,还可以再根据需要定义次一级的域名,如在我国的顶级域名cn下又设立了com、net等。图1为一个域名体系典型层次结构。 域名根服务器由美国政府授权的互联网名称与数字分配机构(ICANN)负责管理。为了提高域名解析效率,ICANN在全球部署了591台根服务器及镜像,他们每个都被赋予A到M共13个标号中的一个。其中,全球唯一的主根服务器设置在美国,标号为A,由美国Verisign公司负责运维管理;在北京部署有5台根服务器镜像,编号为L的有两台,编号为F、I、J的各一;在香港部署A、F、I、L、J共5台根服务器镜像。所有编号相同的根服务器都采用同一个IP地址,通过任播(Anycast)技术实现就近访问。标号为B至M的辅助根服务器及镜像定期从主根服务器同步更新全球域名信息,为全球互联网用户提供域名解析服务。 域名系统安全问题 从域名解析过程可以看出,当本地域名服务器缓存不能直接提供域名对应的IP地址时,解析过程必须经过域名根服务器或其镜像服务器。而所有辅根服务器及其镜像需定期从主根服务器同步更新全球域名信息。从技术上看,只需删除主根域名服务器的相关记录,使其国家顶级域名失效,即可实现让一个国家从互联网上消失。 当前,全球互联网域名系统中,唯一的主根服务器设在美国,美国政府授权ICANN(The Internet Corporation for Assigned Names and Numbers,互联网名称与数字地址分配机构)进行控制;12个辅根服务器中9个设在美国,其他3个分别设在英国、瑞典和日本。由于其他根服务器及镜像的域名信息均复制于主根服务器,因此美国事实上控制了全球所有国家和地区的域名解析,具备将一个国家从互联网上“抹去”的能力和条件。 一旦与某国发生冲突,美国在技术上完全可以停止对该国域名的解析,使其网站无法被外界访问。据报道,伊拉克战争期间,美国终止了伊拉克国家顶级域名。IQ的解析[2];在塔利班政权统治阿富汗时期,美国将阿富汗国家顶级域名。AF的管理权授予前流亡政府;2004年4月,由于对顶级域名管理权问题发生分歧,导致利比亚国家顶级域名。LY瘫痪[4],利比亚从互联网上“消失”了3天。 当前针对域名系统的攻击手段多种多样,总结起来主要包括以下三类: 一是分布式拒绝服务攻击(DDOS)。由于域名系统协议存在体系开放、无认证、无连接和无状态等特点,使其更易受到分布式拒绝服务攻击。针对域名系统的分布式拒绝服务攻击主要采用基于正常域名请求、反弹式、大流量阻塞等三种途径。 二是DNS欺骗攻击,通过技术手段向缓存域名服务器注入非法域名解析记录,当用户向被攻击的缓存域名服务器提交域名请求时,将会返回攻击者预先设定的IP地址。 三是域名劫持攻击[3],攻击者控制域名管理密码和域名管理邮箱后,将该域名的NS纪录指向到攻击者可以控制的DNS服务器,然后通过在该DNS服务器上配置相应域名纪录,使用户访问该域名时,实际指向攻击者预先设定的主机。 我国域名系统的安全现状分析 我国域名管理呈现三层体系架构。从2002年起,国务院下发了《中国互联网域名管理办法》、《中国互联网域名体系公告》等一系列指导性文件,规范了我国域名注册和管理工作,目前已形成由工业和信息化部主管的域名管理和注册三层体系架构。 第一层是域名注册管理机构,由中国互联网信息中心(CNNIC)负责运行和维护CN域根服务器,授权监督管理各域名注册服务机构; 第二层是域名注册服务机构,目前经过CNNIC授权的有上百家,负责面向用户和代理机构受理和审核域名申请; 第三层是域名注册代理机构,在域名注册服务机构的授权范围内接受域名申请。在具体的域名解析服务方面,主要依靠域名解析服务商、域名托管商等商业机构进行,他们负责具体提供域名解析相关的设施和各类服务。 由于美国对互联网域名系统的实际控制,使得我国域名系统始终处于不自主、不可控的威胁之下。如果美国对我域名系统实施类似针对伊拉克、利比亚等国家攻击手段,造成的后果也将非常严重。 通过对CN域的屏蔽,将使所有互联网用户无法访问CN域。虽然可通过获取国内根服务器镜像控制权或者构建替代根域名服务器等应急措施,勉强维持国内用户对CN域的访问能力,但实现难度大,且只能临时被动应对,无法全面解决问题。一旦CN域从因特网上“消失”,将给我国公众网络带来严重后果,造成巨大经济损失和社会影响。 根据2014 年3 月发布的《中国域名服务及安全现状报告》,自2010 年5 月到2014年2 月之间,影响较大的域名攻击事件多达二十余起,波及域名体系的各个层级。相比网络欺诈和病毒攻击等手段,域名系统故障的攻击手段更为隐蔽且防范难度也越大,影响范围更大、损失也更为惨重。其中,影响较大的有2009年发生的“暴风影音事件”、2010年发生的“百度域名劫持事件”、2013年发生的“CN域名攻击事件”,以及2014年1月21日发生的“国内大范围域名解析故障”等。 提高我国域名系统安全性的几点建议 加强国家网络空间安全的战略谋划 互联网安全是国家战略层面的问题,必需高度重视。 一是尽快制定网络空间国家安全战略。树立网络空间自主、自控、自强的战略意识,加强网络空间安全的战略筹划和顶层设计,制定切实可行的网络空间国家安全战略和规划。 二是建立健全互联网安全防护的体制机制。加强国内网络运维、研制和使用等各部门之间的交流与合作,充分利用军地各方力量,提高互联网安全防护和应急处置能力。 三是积极参与国际互联网治理。联合立场相近国家,倡导多边、民主、透明的互联网治理机制,打破美对域名等互联网关键系统的控制,鼓励和支持我企业和非政府机构加入互联网治理相关国际组织,在互联网治理相关国际规则制定中争夺话语权。 增强国家域名系统的安全防护能力 一是建立互联网安全应急替代机制。针对当前互联网受制于人的局面,研究建立切实可行的应对机制,以提升互联网的安全性。尤其针对域名系统,为防止CN域被根服务器删除,应主动应对,建立根服务器替代机制,保障国内用户对CN域的正常访问。 二是开展应急演练,以军民融合的方式,进行国家甚至国际级的网络应急响应演练,摸清域名系统影响底数、验证应急响应技术和机制,增强全民应对意识和水平。 以网络技术发展为契机,抢占先机 一是充分利用全球下一代网络发展契机,建立新框架。我应在发展部署IPv6、物联网的同时,通过一系列创新途径,积极参与新网络体制下域名解析体系的构建,在下一代互联网建设中抢占先机,建立创新的网络协议体系和标准规范,构建有利于我国的域名系统架构; 二是充分利用新型网络应用的发展,降低对现有域名体系的依赖,研究利用层叠网等新的网络应用架构,在现有框架内,构建网中网,使上层应用网络有自己的域名和寻址机制,从而降低风险。 作者:佚名 来源:51CTO

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

每日一博 | 一次网络不通 “争吵” 引发的思考

为啥争吵,吵什么? "你到底在说什么啊,我K8s的ecs节点要访问clb的地址不通和本地网卡有什么关系..." 气愤语气都从电话那头传了过来,这时电话两端都沉默了。过了好一会传来地铁小姐姐甜美的播报声打断了刚刚的沉寂「乘坐地铁必须全程佩戴口罩,下一站西湖文化广场...」。 pod需要访问clb的443的监听, 但是如果是集群内(集群内后面都指的K8s的节点或者POD)访问就会出现如下报错Connection refused: 所以就捋了一下客户链路如下: 具体现象是什么 无论是节点node还是pod里访问192.168.1.200:443都是不通的,但是访问192.168.1.200:80却是正常的。同时集群外的ECS192.168.3.100访问192.168.1.200:443和192.168.1.200:80都是正常的。 进一步分析看看 CLB1的IP192.168.1.200被绑定到了K8s的node节点的kube-ipvs0网卡上,这个是一张dummy 网卡,参考dummy interface。由于 SVC1 是LoadBalancer类型的,同时复用了这个CLB1,关联endpoint是POD1192.168.1.101:80,那么就可以解释为何访问192.168.1.200:80是正常,是由于kube-proxy根据SVC1的配置创建ipvs规则同时挂载了可被访问的后端服务。而集群里访问192.168.1.200:443都是不通的,因为IP被绑定到dummy网卡后,就不会再出节点去访问到CLB1,同时没有443对应ipvs规则,所以直接是拒绝的。 这个时候如果节点里没有ipvs规则(ipvs优先于监听)但是又能访问通的话, 可以检查一下是否本地有监听0.0.0.0:443的服务,那么这个时候所有网卡IP+443都能通,但是访问的是本地服务,而不是真正的CLB后端的服务。 是否有办法解决呢 最建议的方式 最好的方式拆分, 集群内和集群外的服务分开两个CLB使用。 阿里云svc注解的方式 SVC1使用这个注解http://service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname,进行占位,这样就不会绑定CLB的IP到kube-ipvs0的网卡上,集群内访问CLB的IP就会出集群访问CLB,但是需要注意如果监听协议为TCP或UDP,集群内访问CLB IP时将会存在回环访问问题。详细信息,请参见客户端无法访问负载均衡CLB[1]。 需要CCM版本在 v2.3.0及以上版本才支持这个注解, 具体参考:通过Annotation配置传统型负载均衡CLB [2] demo: apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: "${your_service_hostname}" name: nginx-svc namespace: default spec: ports: - name: http port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 集群内访问 ExternalTrafficPolicy 策略有影响吗? 我们都知道K8s的nodeport和loadbalancer模式是可以调整外部流量策略的,那么图中的「外部策略为Local/Cluster,所有集群节点创建IPVS规则是有区别的」该如何解释呢, 以及集群内访问nodePort/CLBIP的时候会发生什么。 以下都是针对svc的internalTrafficPolicy都是Cluster或者缺省的情况,这个ServiceInternalTrafficPolicy特性在1.22的K8s中默认开启,具体参考service-traffic-policy [3] 此处我们只讨论ipvs TrafficPolicy Local在Kubernetes 从1.22升级到1.24的行为变化。 Kubernetes 1.24 IPVS的变化 以下均以kube-proxy的IPVS模式为例: 当externalTrafficPolicy为Cluster模式或缺省的时候,ipvs规则里的nodePort/CLBIP后端会挂载所有的Endpoint的IP,这时候集群内访问会丢失源IP,因为节点会做一层SNAT。 当externalTrafficPolicy是Local的时候 当节点上有对应service的Endpoint的时候,ipvs规则里的nodePort/CLBIP后端只挂载自己节点的Endpoint的IP,集群内访问会保留源IP。 当节点上没有对应service的Endpoint的时候 在1.24之前的版本是会挂空的后端的,集群内访问会拒绝。 在1.24之后的K8s集群里,当节点上没有对应service的Endpoint的时候,ipvs规则里的nodePort/CLB IP后端会挂载所有的Endpoint的IP,这时候集群内访问会丢失源IP,因为节点会做一层SNAT。社区调整了Local策略后端服务的规则挂载策略,具体参考社区PR[4]。 https://github.com/kubernetes/kubernetes/pull/97081/commits/61085a75899a820b5eebfa71801e17423c1ca4da 集群外访问SLB 集群外访问SLB的话,CCM只会挂载Local类型的节点,情况跟1.24 kubernetes前一样,这里不做过多阐述,请见上面连接。 集群外访问NodePort 1.24 Kubernetes之前版本 访问有Endpoint的节点的NodePort,可以通,可以保留源IP Nginx分布在cn-hongkong.10.0.4.174和cn-hongkong.10.0.2.84节点。 从外部10.0.3.72节点访问有后端pod所在节点的cn-hongkong.10.0.2.84的30479端口,可以访问。 cn-hongkong.10.0.0.140节点上是有相关的IPVS的规则的,但是只有该节点上后端Pod IP。 通过conntrack表可以到,这是由于在cn-hongkong.10.0.0.140节点上,相关的链路被dnat,最后是由pod cn-hongkong.10.0.2.84节点上的 的nginx-7d6877d777-tzbf7 10.0.2.87返回源,所有的相关转化都在该节点上,所以TCP四层建连可以成功。 访问没有Endpoint的节点的NodePort,不能通,因为节点上没有相关的ipvs转发规则 从外部10.0.3.72节点访问无后端pod所在节点的cn-hongkong.10.0.0.140的30479端口,不可以访问。 查看该cn-hongkong.10.0.0.140节点,并没有相关的ipvs转发规则,所以无法进行dnat,访问会失败。 1.24 Kubernetes版本之后(含) 访问有Endpoint节点的NodePort,可以通,可以保留源IP 访问没有Endpoint节点的NodePort: terway ENIIP or host网络:不通 Nginx分布在cn-hongkong.10.0.2.77和cn-hongkong.10.0.0.171 节点。 从外部10.0.3.72节点访问无后端pod所在节点的cn-hongkong.10.0.5.168的30745端口,可以看到,访问失败。 cn-hongkong.10.0.5.168节点上是有相关的IPVS的规则的,并且会把所有的后端Pod IP加到IPVS规则中。 通过conntrack表可以到,这是由于在cn-hongkong.10.0.5.168节点上,相关的链路被dnat,最后是由pod cn-hongkong.10.0.2.77节点上的nginx-79fc6bc6d-8vctc 10.0.2.78返回源,源在接受这个链路后,会发现和自己的五元组不匹配,直接丢弃,三次握手必然失败,所以建连失败。 flannel网络:可以通,但是保留不了源IP Nginx分布在cn-hongkong.10.0.2.86。 从外部访问cn-hongkong.10.0.4.176的31218端口,可以访问成功。 cn-hongkong.10.0.4.176记录了src是10.0.3.72,并做了dnat为172.16.160.135,期望它返回给10.0.4.176的58825端口。 后端ep所在节点cn-hongkong.10.0.2.86,conntrack表记录了src是10.0.4.176,sport是58825。所以可以看到应用pod是记录的源IP是10.0.4.176,丢失了源IP。 集群内访问SLB或者NodePort 1.24 Kubernetes之前版本 有Endpoint的节点上访问,可以通,可以保留源IP Nginx分布在ap-southeast-1.192.168.100.209和ap-southeast-1.192.168.100.208节点,ap-southeast-1.192.168.100.210节点没有Nginx pod。 从集群任意节点(本例就在209节点)访问有后端pod所在节点的ap-southeast-1.192.168.100.209的NodePort 31565端口,可以访问。 从有后端pod所在节点ap-southeast-1.192.168.100.209访问SLB 8.222.252.252 的80端口,可以访问。 ap-southeast-1.192.168.100.209节点上是有NodePort 和SLB 的IPVS的规则的,但是只有该节点上后端Pod IP。 通过conntrack表可以到,这是由于在ap-southeast-1.192.168.100.209 节点上,相关的链路被dnat,最后是由pod 在ap-southeast-1.192.168.100.209 节点上的 的nginx-7d6877d777-2wh4s 192.168.100.222返回源,所有的相关转化都在该节点上,所以TCP四层建连可以成功。 没有Endpoint的节点上访问,不能通,因为节点上没有相关的ipvs转发规则 从集群任意节点(本例就在210节点)访问没有后端pod所在节点的ap-southeast-1.192.168.100.210 的NodePort 31565端口或者SLB,不可以访问。 也进一步证实,集群内访问关联svc的SLB不出节点,即使SLB有其他监听端口,访问SLB其他端口也会拒绝。 查看该ap-southeast-1.192.168.100.210 节点,并没有相关的ipvs转发规则,所以无法进行dnat,访问会失败。 1.24 Kubernetes版本之后(含) 有Endpoint节点上访问,可以通,可以保留源IP 与上文的1.24 Kubernetes之前版本集群内访问一致,可以参考上文描述。 没有Endpoint节点上访问: Nginx分布在cn-hongkong.10.0.2.77和cn-hongkong.10.0.0.171节点,所以在没有Nginx的cn-hongkong.10.0.4.141节点上测试。 分别有以下几种情况: terway或后端为hostNetwork 节点访问的通 NodePort(源 IP 是 ECS IP,不需要做 SNAT),无法保留源IP 可以看到没有Endpoint的节点的NodePort 110.0.4.141:30745 的IPVS 的规则添加的Nginx的所有后端POD nginx-79fc6bc6d-8vctc 10.0.2.78 和 nginx-79fc6bc6d-j587w 10.0.0.172。 集群内节点自身访问没有后端pod所在节点的cn-hongkong.10.0.4.141 的NodePort 30745/TCP端口,可以访问。 通过conntrack表可以到,在cn-hongkong.10.0.4.141节点上,相关的链路被dnat,最后是由后盾Nginx pod nginx-79fc6bc6d-8vctc 10.0.2.78返回源。 而在nginx-79fc6bc6d-8vctc 10.0.2.78 所在的节点cn-hongkong.10.0.2.77上的conntrack表记录的是10.04.141访问10.0.2.78,并期望10.0.2.78直接返回10.0.4.141的的39530端口。 集群内有endpoint 节点访问没有后端pod所在节点的ap-southeast-1.192.168.100.131 的NodePort 32292端口,不可以访问,与上文1.24 Kubernetes版本之后(含) 集群外访问一致,可以参考上文描述。 节点访问不通 SLB IP(源 IP 是 SLB IP,没有人做 SNAT) 可以看到没有Endpoint的节点的SLB IP 的IPVS 的规则添加的Nginx的所有后端POD nginx-79fc6bc6d-8vctc 10.0.2.78 和 nginx-79fc6bc6d-j587w 10.0.0.172。 没有Endpoint的节点上访问 SLB 47.243.247.219,访问确是超时。 通过conntrack表可以到,在没有ep的节点访问SLB的IP,可以看到期望的是后端pod返回给SLB IP。而SLB IP 在节点上已经被kube-ipvs虚拟占位了,所以没有做snat,造成无法访问。 flannel并且后端为普通pod,可以访问通,但是保留不了源IP Nginx分布在cn-hongkong.10.0.2.86。 在cn-hongkong.10.0.4.176访问SLB 47.242.86.39 是可以访问成功的。 cn-hongkong.10.0.4.176节点的conntrack表可以看到是src和dst都是47.242.86.39,但是期望的是 nginx pod172.16.160.135 返回给 10.0.4.176 的54988端口,47.242.86.39 snat成10.0.4.176。 后端ep所在节点cn-hongkong.10.0.2.86,conntrack表记录了src是10.0.4.176,sport是54988。所以可以看到应用pod是记录的源IP是10.0.4.176,丢失了源IP。 相关链接: [1] 客户端无法访问负载均衡CLB https://help.aliyun.com/document_detail/55206.htm [2] 通过Annotation配置传统型负载均衡CLB https://www.yuque.com/r/goto?url=https%3A%2F%2Fhelp.aliyun.com%2Fzh%2Fack%2Fack-managed-and-ack-dedicated%2Fuser-guide%2Fadd-annotations-to-the-yaml-file-of-a-service-to-configure-clb-instances [3] service-traffic-policy https://kubernetes.io/zh-cn/docs/concepts/services-networking/service-traffic-policy/ [4] 社区PR https://github.com/kubernetes/kubernetes/pull/97081/commits/61085a75899a820b5eebfa71801e17423c1ca4da 作者: 郑明泉、余凯 点击立即免费试用云产品 开启云上实践之旅! 原文链接 本文为阿里云原创内容,未经允许不得转载

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

自动化离线交付在云原生的应用和思考

作者:京东科技 王晓飞 前言 本文不谈论具体的技术和方案,在对于每一个产品来讲,都有其特殊性存在。单一的产品解决方法并不适合所有的产品。但是我们可以提供一种思路,一种通用方法,甚至我们曾经在某个技术点走的弯路,旨在为各位在离线设计上有更多的案例可循。 对离线的理解 相对于公网应用,可以从公共镜像仓库拉取镜像,比如Dockerhub,各大云厂商的公共镜像仓库。二进制编译文件,软件包也非常方便的从github,各种yum源中获取。此时应用无论是部署,交付,生产都处于完全流程。那么离线就是用户环境是私有云,专有云用户的生产环境无法访问这些公开资源,并且从安全角度来讲,并不能保证其生产安全。在离线环境交付大型生产项目,一般要有成熟的基础设置(yum源,镜像仓库,chart仓库,NTP服务等) 解决离线交付会减少SRE和交付团队试错成本,排障成本。并且在一定程度上能够保持交付环境的一致性。这里举一个场景例子: 我们在K8S集群时,会依赖特定的内核版本,那么离线交付工具会自动化的进行内核升级,并且按照统一的配置进行下发。 这样一来,整个环境的所有OS的内核版本,配置全部保持一致。 插拔式设计 插拔式设计在现代架构设计并不陌生,所以离线交付中需要考虑插拔式设计。有诸多可以看到的好处是对已有代码架构侵入不多,完全可以依据交付需求进行开关。 比如以下代码完全是判断开关才进行工作: 还有一种重要的考虑点是:数据解藕,即离线设计的实现不能对元数据进行强以来,元数据应该以配置或者模版的方式,在离线真正运行是动态读取。 并且能够依据不同的元数据(配置或者模版)进行执行行为的改变。 依赖感知 依赖模块感知 离线交付是一个链条,需要上下模块感知,并且动态修改配置的方式,传递离线的配置信息。 比如:A模块需要获取一个镜像,那么在离线模式下,A模块应该能够感知到离线,并且自动变更获取镜像的地址,指向离线仓库。 系统自动适配 在实际生产中,往往要兼容不同的OS或者平台,那么在离线设计时要进行充分的考虑,离线要能够做到自动识别OS或者平台,自动的适配合适的离线包。 下图展示了,我们在生产中进行分类的方法: 全自动化离线设计 离线的设计,对于用户或者终端来讲,他们并不关心,主要是交付方为了提升生产效率进行的行为。所以需要在模块与模块之间,组件与组件之间进行无缝对接。 形成全自动化流程。 比如:A,B,C都依赖离线,那么当离线开启时,A,B,C模块都能够根据离线的上下文信息自动修改,并且能够做到不中断。 下图中展示了完整的离线设计流程,流程虽然复杂,但是大多数都使用了流水线。并且在真正实现的部分,又可以做到流程化。 对于用户来讲,无需感知这些。 重在流程设计 离线本身不是独立的流程存在,整个离线需要在以下方面进行设计和实现: 1. 文档和培训,用于离线交付的使用手册以及指导手册; 2. 离线包的制作全自动化,使用流水线功能将离线包构建,版本控制,发行就行全自动化控制,减少人工参与; 3. 交付团队和SRE团队可以快速的获取离线包。 结论 1. 离线交付是在ToB,ToG中非常常见的交付方式; 2. 离线交付理念应该融资在整个架构设计中,而不是将它看成独立的模块功能; 3. 尽可能的使用自动化维护整个离线包;

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

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

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册