前言随着前端项目的增多，越来越多的动静态资源会分开部署。对于分离部署，往往会涉及代理转发的问题。私网项目主要采用nginx+docker+k8s部署方式，本文主要分享一些相关项目实践过程的踩坑过程和回顾思考。背景公司云环境提供对象存储服务（ps：类似腾讯云的对象存储COS），但出于安全考虑，整个环境基于内网系统，其https证书未经过相关CA机构认证，但是专网自助服务项目会涉及到让客户访问公网的问题。对于没有CA认证的https，浏览器会给出警告，需要用户点击确认。用户体验极差。为此，在部署的时候，决定对静态服务进行代理转发，整个解决方案就变成了nginx1（纯前端应用）和nginx2（静态服务转发）的负载代理问题。测试小姐姐来找我们提bug的时候，我们经常回复：“这里不错，你可以试试refreshing（重启）”[手动狗头]，这其实是环境一致性的问题。对于前端工程来说，解决环境一致性问题其实是运维中比较普遍的问题。常见的解决方案包括云IDE和统一配置文件。这里借用搭建脚手架时dll的思路。通过Aconfig.json会在每次解析服务器请求后配置相应的url。生产环境使用nginx，开发环境使用dev.proxy.jsconfig.json{"IS_NGINX":1,"API":{"TGCOS":{"alias":"/tgcos/","url":"http://bfftest.default.service.local:8148/tgcos/"}}}dev.proxy.jsmodule.exports={'/tgcos/':{目标:'http://172.24.131.166:8148'}}nginx1.conf(纯前端应用)server{location/tgcos/{proxy_passhttp://bfftest.default.service.local:8148/tgcos/;}}nginx2.conf（静态服务代理转发）server{location/{proxy_passhttp://cos.zz-hqc.cos.tg.ncmp.unicom.local/}location/tgcos/{proxy_passhttp://cos.zz-hqc.cos.tg.ncmp.unicom.local/}}问题：这里配置代理后，转发的服务在webpack中重启Passedone层，所以在代理的时候，发现会少一层转发，此时会找不到代理地址。解决方法是将根目录代理到同一个cos地址。虽然丑，但是可??以解决k8s域名问题在部署过程中，由于k8内部的ip漂移问题，希望可以利用k8内部的dns域名修复代理转发的域名k8s中dns常用的插件有两个，分别是：KubeDNS和CoreDNS。在Kubernetes1.12之后，CoreDNS成为其默认的DNS服务器。它的配置可以在/etc/resolv.conf中修改。主要有三个配置关键字nameserver定义了DNS服务器的IP地址。search定义域名的搜索列表。当数。在查询域名小于options.ndots的值时，会依次匹配列表中的每个值。options定义了域名搜索的配置信息。我们输入看一下它的resolv.confnameserver11.254.0.10搜索default.svc.cluster.localsvc.cluster.localcluster.localoptionsnodts:5这里我没有做其他操作，所以正常应该是可以用的就是默认的k8sdnspolicy，即使用默认的ClusterFirst策略问题：正常情况下应该可以找到对应的域名，但是结果没有找到，所以考虑是不是端口映射问题k8s端口映射问题k8s作为优雅分发资源调度框架，其优秀的架构设计可以对不同的核心对象（如：Pod、Service、RC）进行调度和操作，整个k8s架构，通过命令行kubectl来操作APIServer，使用其封装好的API来操作和访问For权限控制、注册、etcd等行为，下层使用Scheduler和ControllerManager实现对资源的调度和管理能力。这里通过kubeproxy来实现整个服务的代理能力，从而实现反向代理和负载均衡。这里在前端编写的yaml配置了service和deploymentapiVersion:v1kind:Servicemetadata:name:bffspec:ports:-port:80selector:app:bff---apiVersion:app/v1kind:Deploymentmetadata:name:bfflabels：app：bffspec：副本：1个选择器：matchLabels：app：bff模板：metadata:labels:app:bffspec:containers:-name:bffimage:harbor.dcos.ncmp.unicom.local/fe/bff:1.0imagePullPolicy:Alwaysports:-containerPort:80问题：这里创建clb的时候我们恢复一个再次服务。新配置的8148端口和之前yaml中写的80端口不一样。如果单纯的通过ip搜索，没有找不到的问题，但是因为是通过dns搜索的，前面部分k8s里面默认的dns策略是ClusterFirst策略，所以会出现两个名字不匹配的情况和端口不匹配。本质上，两个服务同时调度同一个pod中的资源。前端工程小结稳定生产是前端工程的重要考虑因素。我们不仅要考虑工程相关基础设施的传统前端部分，还要准确控制性能监控、日志收集等问题，跟踪链路。当然，这些也需要前端多了解后端、云和容器化相关的内容。未来的前端开发可能会朝着“端+云”的模式发展。做全方位的学习，是未来大前端的必由之路。让我们互相鼓励吧！！！参考IPVS从入门到掌握kube-proxy实现原理。KubeDNS和CoreDNS使用CoreDNS来处理DNS污染。写这个K8S架构我花了10个小时来分析四层和七层负载均衡的区别。
