前言

随着前端我的项目的增大，越来越多时候会把动动态资源进行拆散部署，对于拆散部署时经常波及到代理转发的问题，专网我的项目次要应用 nginx + docker + k8s 的部署形式，本文次要分享一些相干我的项目的实际过程的踩坑历程及回顾思考。

背景

公司云环境提供了对象存储服务（ps：相似于腾讯云的对象存储COS），但出于平安思考，整个环境都是基于内网的零碎，其https的证书并未进行相干的CA机构认证，但专网自服务项目会波及到在公网让客户拜访的问题，浏览器对于没有CA认证的https会给出正告，须要用户进行点击确认，用户体验极差，出于此思考，在部署时候决定对动态服务进行代理转发，整个计划就变成了 nginx1(纯前端利用) 和 nginx2(动态服务转发) 的负载代理问题

案例

环境一致性问题

在开发过程中，常常会呈现环境的问题，当测试小姐姐来向咱们提bug时候，咱们常常的回复是：”在我这儿是好的啊，你在刷新（重启）一下试试“[手动狗头]，这其实实质就是环境一致性的问题，对前端工程化来说，解决环境一致性问题其实是运维中一个比拟常见的问题，常见的有云端IDE及对立配置文件等来解决，这里咱们在构建脚手架的时候借鉴了dll的思维，通过一个config.json将配置每次从服务端申请下来解析后对url进行相应的配置，生产环境下走nginx，开发环境下走dev.proxy.js

  • config.json
{    "IS_NGINX": 1,    "API" : {        "TGCOS": {            "alias": "/tgcos/",            "url": "http://bfftest.default.service.local:8148/tgcos/"        }    }}
  • dev.proxy.js
module.exports = {    '/tgcos/': {        target: 'http://172.24.131.166:8148'    }}
  • nginx1.conf (纯前端利用)
server {    location /tgcos/ {        proxy_pass http://bfftest.default.service.local:8148/tgcos/;    }}
  • nginx2.conf (动态服务代理转发)
server {    location / {        proxy_pass http://cos.zz-hqc.cos.tg.ncmp.unicom.local/    }    location /tgcos/ {        proxy_pass http://cos.zz-hqc.cos.tg.ncmp.unicom.local/    }}
问题：这里配置了代理之后，在webpack中因为转发的服务又从新传了一层，因此在代理的时候发现会少一层转发，这时就会找不到代理的地址，解决办法是将根目录也代理到同一个cos的地址上，尽管俊俏然而能够解决问题

k8s域名问题

在部署过程中，因为k8外部的ip漂移问题，因此心愿可能应用k8外部的dns域名将代理转发的域名固定住。k8s中的dns有两个罕用的插件，即：KubeDNS和CoreDNS，在Kubernetes 1.12之后，CoreDNS成为其默认的DNS服务器，其配置在/etc/resolv.conf能够进行批改，次要有三个配置的关键字

  • nameserver 定义DNS服务器的IP地址
  • search 定义域名的搜寻列表，当查问域名中蕴含.的数量少于options.ndots的值时，会顺次匹配列表中的每个值
  • options 定义域名查找时的配置信息

咱们进入启动的Pod中看一下它的resolv.conf

nameserver 11.254.0.10search default.svc.cluster.local svc.cluster.local cluster.localoptions nodts:5

这里我没有做其余的操作，因此失常来说应该是能够应用的是默认的k8s的dns策略，即应用默认的ClusterFirst的策略

问题：失常来说应该可能找到对应的域名，后果却没有找到，因此思考是不是端口的映射问题

k8s端口映射问题

k8s作为一个优雅的分布式资源调度框架，其优良的架构设计能够对不同的外围对象（例如：Pod，Service，RC）进行调度和操作，整个k8s架构，通过命令行kubectl操作API Server，利用其包装的api去操作拜访权限管制、注册、etcd等行为，其上层通过Scheduler和Controller Manager来实现调度和治理资源的能力，这里整个service的代理能力是通过kube proxy来实现的，从而实现反向代理和负载平衡

这里在前端写的yaml里配置了service和deployment

apiVersion: v1kind: Servicemetadata:  name: bffspec:  ports:     - port: 80  selector:    app: bff---apiVersion: app/v1kind: Deploymentmetadata:  name: bff  labels:    app: bffspec:  replicas: 1  selector:    matchLabels:      app: bff  template:    metadata:      labels:        app: bff    spec:      containers:      - name: bff        image: harbor.dcos.ncmp.unicom.local/fe/bff:1.0        imagePullPolicy: Always        ports:        - containerPort: 80
问题：这里在创立clb的时候会从新再简历一个service，配置的新的8148端口和之前yaml里写的80端口是不一样的，如果单纯的只是通过ip进行查找是不存在找不到的问题，然而因为是通过dns进行查找，在上一部分中k8s外部默认的dns策略是ClusterFirst的策略，因此这里会呈现两个名称和端口恰好没有对上的情况，实质上是两个service同时调度了同一个pod中的资源

总结

前端工程的稳固生产作为前端工程化的重要考量因素，咱们不仅要思考传统的前端局部工程化相干基建，同时也要对性能监控、日志收集等问题定位做到精准管制，链路追踪，当然这些也须要前端懂得更多后端、云及容器化相干的内容，将来前端倒退可能会朝着”端+云“的模式倒退，做好全方位的学习才是将来大前端的必由之路，共勉！！！

参考

  • IPVS从入门到精通kube-proxy实现原理
  • KubeDNS 和 CoreDNS
  • 应用 CoreDNS 来应答 DNS 净化
  • 我花了10个小时，写出了这篇K8S架构解析
  • 四层、七层负载平衡的区别