Docker+k8s容器云建设中常见难点分析.docx

上传人:王** 文档编号:1129847 上传时间:2024-04-02 格式:DOCX 页数:11 大小:82.69KB
下载 相关 举报
Docker+k8s容器云建设中常见难点分析.docx_第1页
第1页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第2页
第2页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第3页
第3页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第4页
第4页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第5页
第5页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第6页
第6页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第7页
第7页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第8页
第8页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第9页
第9页 / 共11页
Docker+k8s容器云建设中常见难点分析.docx_第10页
第10页 / 共11页
亲,该文档总共11页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《Docker+k8s容器云建设中常见难点分析.docx》由会员分享,可在线阅读,更多相关《Docker+k8s容器云建设中常见难点分析.docx(11页珍藏版)》请在优知文库上搜索。

1、随着云计算、DeVOPS和微服务应用架构的发展,容器云成为IT的主要基础设施平台之一。以DOCker为代表的容器技术,是目前有效的应用交付模式之一;以Kubernetes为代表的容器编排技术,是目前流行的应用部署方案。云平台的基础设施、DeVc)PS的工程体系和微服务应用架构是IT技术转型的底座。而容器云又是这个底座下的一块基石。下面几个问题是在DOCker+K8S容器云建设过程中,最常被问起和需要解决的难点问题。1、企业是应该选择原生的DOCker还是定制化的DOCker,比如胖容器/富容器?【问题描述】Docker是当前企业在进行容器化时首选的容器技术,但是原生的DOCker在实际使用的过

2、程中,特别是在传统虚机运维到容器化运维的过渡中,会碰到以下类似问题:1、如何SSh登录到容器,像登录虚机那样,可以通过SSh进行管理2、对于普通用户来说,如何从容器中拷贝文件到外部3、虚机中一般会配置定时任务,在容器中如何实现4、虚机中一般会安装各种agent,容器中怎么去安装若企业直接采用原生的Docker,那么以上问题是比较棘手的。因此企业在容器技术选型上,是否应该为了最大程度兼容虚机运维模式,对DoCker进行定制化改造,满足实际需求呢?是使用原生还是定制就要看企业实力了。一一般的企业不会去动原生的东西,不愿意将人力花在这个方面。很多企业是通过应用的改造来适配容器化的方案,包括运维上的问

3、题。4个问题:1dockerexec可以进入容器,如果是k8s或者ocp,还有有相应的叩i2、方便拷贝的方式第一个容器中应用产生的文件目录挂载到本地;第二个使用相应的命令如dockercp;也许你说的不仅限一些简单场景,其实都是有方法的,不仅以上两种3、容器中也是可以使用Crontab定时任务操作的4、agent的功能要先说清楚,如果上k8s或者OCp,一个POd可以完成你要说的内容。如果仅仅是用docker,根据功能需要应该也是有方法的。1dockerexec可以满足要求2、最直接就是挂在本地磁盘存储到容器上3、可以考虑一下,定时调度起一个DOCker执行任务4、主要是这些Agent是用来干

4、什么的?DOCker实例本来就是作为一种一次性的,不可变的运行实例,传统虚拟机的那个操作Agent,不符合容器的设计理定制化最大的问题在于,目前技术升级比较快,一旦定制,就锁定在几个版本了,后续升级维护工作量会很大。2、容器云平台选型及如何制定相关的标准和规范探讨?【问题描述】在引入容器平台时,需先了解当前主流的容器平台技术和成熟产品,然后制定相关的标准和规范。具体如下:1、想了解当前主流容器平台如何选型?2、除了资金成本,容器平台后期的使用和运维需要如何考虑,目前公司自己对容器平台的开发能力不在,运维人员需要具体具备哪些能力,运维与开发如何协作,投入运维人员的规模如何估算?3、容器平台早期实

5、施的过程中需要做哪些规划,避免哪些坑?1现在的容器平台,基本都是基于KUberneteS做的产品化,最基本的功能上没有太大的差别,主要是看一些附加的能力,如云管工具,对IaaS的支持还有安全,对开发人员的友好性这些方面。选型是还要考虑厂商的支持能力,还有就是厂商在开源社区的影响力等。具体的功能性能对比没有做过,每个厂商都会提供,综合对比一下。2、不考虑自己开发和增量开发,后期的运维主要就是容器平台的日常运维(监控,告警处理和问题定位等),还有容器平台属于更新比较快的产品,平台升级和补丁也会比普通应用多。运维人员对LinUX的基础,自动化脚本能力要求比较高。3、这边真没有什么规则,如果说有,就是

6、尽量各层解耦,选择主流的技术路线。选型还要看企业实际情况、实际需求而来,既然容器的引擎是docker,集群编排靠k8s,其实不同服务商大家优缺点可能不太一样。但核心就是容器及k8s,其他的外围生态、服务质量,产品公司服务的可持续性,服务商自身技术等都决定最后的选择。建议可以多找几家了解一下他们产品,最好能够逐一进行PoC需要关注的点:第一就是规划,你的容器是直接部署在baremetal上还是虚拟机上,因为虚拟化软件本身就有10%-20%对于硬件的消耗,因为容器本身消耗理论值在5%以内。第二就是你对于容器网络的选择,网络将是你在使用容器时候的一个很大的一个坑。比如Vxlan等技术由于对于数据包的

7、反复封装会导致网络性能下降,kube-proxy默认使用的iptables在条目过多的情况下性能也是衰减的,当然要结合你的部署架构。第三就是你的存储,是通过传统FC-SAN,还是通过NFS、还是对象存储等等方式,如果是网络存储这将影响你的数据读取速度。第四就是你的微服务的设计和拆分。第五就是你的CI/CD的设计。第五就看你们在建设的时候的需求了,如果你需要对象存储,你可能还需要选择ceph,如果你选择ABteSt、蓝绿部署、或是灰度发布那么就考验发布方案和编排能力了。会不会写dockerfile、会不会写ClePIoyment.yaml,jenkinsfile,这些可能需要和开发团队、IT领导

8、,服务商一起去探讨,如果需要引入代码审核,安全扫描等。事前的规划很重要:关键是上容器有没有最好相应的准备,业务类型是什么,稳态还是敏态,是否频繁变化;有没有做好做的技术储备和技术积累,不光是人;有没有做好团队重塑的准备。产品能力不是唯一的维度:容器云的上线,跟微服务有千丝万缕的联系,不是简单产品的堆砌,更是需要大量服务的结合。最重要的是要结合自身的实际情况,谨慎一点没大错!3、KUbeneteS在金融多安全域的环境中,架构规划问题?【问题描述】金融行业网络架构中存在多安全域的设计,kubenetes在多安全域网络隔离的情况下,每个安全域都部署一套k8s集群吗?生产环境k8s集群中calico有

9、哪些网络控制策略最佳实践?理论上来说各个安全域的网络时隔离的,如果部署一套k8s集群,所有的node节点和master节点是联通的,node直接默认也是联通的。可以每个安全域部署一套k8s集群,使用同一的容器管理平台,这是k8s多集群管理。CaIiCO是k8s其中一个网络插件,其他还有flannel、OVS等不同的网络插件,生产使用哪一种网络插件需根据自身业务需求选择。其实不需要这么复杂,比如分了互联网区、中间业务区、核心业务区,k8s集群有6个node节点,可以两个放互联网、两个放中间业务,两个放核心业务,比如master节点都在OA区,只要将master跟着6个node网络上能通即可,不需

10、要node间都能互相访问,一个集群也是可以的。calico是可以解决集群内外访问的问题,但是随着需要访问集群的外部节点的增加,那运维成本就很高了。可以使用ingress类似的解决方案。4、容器云平台建设难点之网络如何选择?如果选SDN网络,那么SDN网络实现方案又应该如何选择?【问题描述】容器网络如何选择?容器云平台的网络一直是一个技术难题,是采用SDN网络还是桥接到Underlay网络;如果使用SDN网络,那么多的SDN网络实现方案,如何选择?优先考虑公司整个网络扁平化,互联互通,这样对应用改造成本要小很多,即基于公司原来的网络打通来进行。如果容器的应用是一个相对独立的服务,可以考虑Over

11、layo规模不大的情况下一些开源网络组件可以考虑采用。calico、bgp、ingress、nginx等都是可以的1、calico将集群内与集群外网络打通,但是随着集群外访问集群内的节点越来越多,运维难度会加大2、bgp需配置内部路由协议,性能上有损耗3、ingress、nginx道理类似,将需要被外部访问的应用使用这两个组件外部负载进到集群内部4、hostnetwork方式5、nodeport方式如何选择要根据自身IT架构及监管要求定了关于SDN还是UndeHay,如果你是自建的,一定不会选用SDN,成本啊,兄弟们!Cisco去年要给我们搭建个ACI,一个交换机就是1万多,如果是银行钱多没有

12、关系,中小企业资金紧张加上疫情,哪会选择。VMware的NST-G我们也用过,有bug,这个PKS每个月都会有一次“月经”,每次网络存储全堵死,IO基本龟速,厂商派人解决了大半年,连交换机都换了都没有解决,结果赔了3台服务器,帮我们全换成普通的VCentoSDN听上去美好,现实很骨感,当然如果你有钱并愿意试错,又追求新技术,当然也是没问题的。比如阿里云、腾讯云这些公有云,基本必然是SDN,人家有钱有人,来填坑。所以,一般公司Underlay就可以了,加上Kubernetes自己的calico,fannel,或cattle,一般都没问题,就是网络上没有硬隔离,没有客户化的东东,但我们可以用公有云

13、的啊,自己去建,多费钱。1 .既然是说容器云平台建设,肯定已经有了网络基础设施,那不考虑数据中心级别的SDN方案。只考虑在已有的网络建设成果上建设。2 .不用迷信商业方案,无论是开源还是商业方案,大家都得遵守k8s的Cni接口。不建议在容器网络方案中寄托太多的功能,如网络限速、安群策略等等。3 .考虑目前主机层面大都可以保障二层是通的。最简单方案方案可以选flannelo目前flannel发展到现在,己经支持vxlan模式下启用DR网络了,通俗讲,就是同一子网下,走hostgw,宿主机充当软路由,性能接近裸网,垮子网的情况走VXlan。即兼顾了性能,又考虑了可扩展性。另外flannel目前也重

14、点优化了大规模容器云的路由表或arp占用过多问题,做到了:每扩展一个主机只增加一个路由项、一个fdb项、一个arp项。4.如果考虑容器网络隔离和安全策略的话(其实没必要,网络隔离,可以从项目级别来设置调度策略做到物理隔离),可以考虑Canal网络方案,他是CaIiCo和flannel的结合体。关于容器网络的建设思路:容器网络发展到现在,已经是双雄会的格局。双雄会其实指的就是Docker的CNM和GOogIe、CoreOSKUbereneteS主导的CNI。首先明确一点,CNM和CNl并不是网络实现,他们是网络规范和网络体系,从研发的角度他们就是一堆接口,你底层是用FIannel也好、用Cali

15、CO也好,他们并不关心,CNM和CNl关心的是网络管理的问题。网络需求调研发现,业务部门主要关注以下几点:1、容器网络与物理网络打通;2、速度越快越好;3、改动越少越好;4、尽可能少的风险点。容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式协议栈层级:二层比较好理解,在以前传统的机房或虚拟化场景中比较常见,就是基于桥接的ARP+MAC学习,它最大的缺陷是广播。因为二层的广播,会限制节点的量级;三层(纯路由转发),协议栈三层一般基于BGP,自主学习整个机房的路由状态。它最大的优点是它的IP穿透性,也就是说只要是基于这个IP的网络,那此网络就可以去穿越。显而易见,它的规模是非常有优

16、势,且具有良好的量级扩展性。但在实际部署过程中,因为企业的网络大多受控。比如,有的企业网络的BGP是基于安全考虑不给开发者用或者说企业网络本身不是BGP,那这种情况下你就受限了;协议栈二层加三层,它的优点是能够解决纯二层的规模性扩展问题,又能解决纯三层的各种限制问题,特别是在云化VPC场景下,可以利用VPC的跨节点三层转发能力。穿越形态:这个与实际部署环境十分相关。穿越形态分为两种:Underlay、OverlayoUnderlay:在一个较好的可控的网络场景下,我们一般利用Underlayo可以这样通俗的理解,无论下面是裸机还是虚拟机,只要整个网络可控,容器的网络便可直接穿过去,这就是UnderlayoOverlay:Overlay在云化场景比较常见。OVerlay下面是受控的VPC网络,当出现不属于VPC管辖范围中的IP或

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 管理/人力资源 > 咨询培训

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!