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

《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或