学院网站建设项目概述怎么自己在电脑上做网站

学院网站建设项目概述,怎么自己在电脑上做网站,内江网站seo,搜索设置 网站前言 之前使用nginx-ingress-controller来记录后端真实ip#xff0c;但是有位老哥说了#xff0c;我没有用nginx-ingress-controller#xff0c;而是用的原生nginx#xff0c;这时候又当如何记录后端真实ip的问题呢 环境准备 nginx: upstream backend_ups {server backend-…前言之前使用nginx-ingress-controller来记录后端真实ip但是有位老哥说了我没有用nginx-ingress-controller而是用的原生nginx这时候又当如何记录后端真实ip的问题呢环境准备nginx:upstream backend_ups { server backend-service:10000; } server { listen 80; listen [::]:80; server_name localhost; location /test { proxy_pass http://backend_ups; } }apiVersion: apps/v1 kind: Deployment metadata: name: nginx-test namespace: default spec: selector: matchLabels: app: nginx-test template: metadata: labels: app: nginx-test spec: containers: - image: registry.cn-beijing.aliyuncs.com/wilsonchai/nginx:latest imagePullPolicy: IfNotPresent name: nginx-test ports: - containerPort: 80 protocol: TCP volumeMounts: - mountPath: /etc/nginx/conf.d/default.conf name: nginx-config subPath: default.conf - mountPath: /etc/nginx/nginx.conf name: nginx-base-config subPath: nginx.conf volumes: - configMap: defaultMode: 420 name: nginx-config name: nginx-config - configMap: defaultMode: 420 name: nginx-base-config name: nginx-base-config --- apiVersion: v1 kind: Service metadata: name: nginx-test namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx-test type: NodePortbackend:apiVersion: apps/v1 kind: Deployment metadata: name: backend namespace: default spec: replicas: 2 selector: matchLabels: app: backend template: metadata: labels: app: backend spec: containers: - image: backend-service:v1 imagePullPolicy: Never name: backend ports: - containerPort: 10000 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: backend-service namespace: default spec: ports: - port: 10000 protocol: TCP targetPort: 10000 selector: app: backend type: ClusterIP部署完毕检查一下▶ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-6d4cdd4c68-mqzgj 1/1 Running 0 6m3s 10.244.0.64 wilson none none backend-6d4cdd4c68-qjp9m 1/1 Running 0 6m5s 10.244.0.66 wilson none none nginx-test-b9bcf66d7-2phvh 1/1 Running 0 6m20s 10.244.0.67 wilson none none▶ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE backend-service ClusterIP 10.105.148.194 none 10000/TCP 5m nginx-test NodePort 10.110.71.55 none 80:30785/TCP 5m2s现在的架构大概是这个样子尝试访问一下nginx▶ curl 127.0.0.1:30785/test i am backend in backend-6d4cdd4c68-qjp9m已经反向代理到后端再看看nginx日志10.244.0.1 - - [04/Dec/2025:07:27:17 0000] GET /test HTTP/1.1 200 10.105.148.194:10000 40 - curl/7.81.0 -不出意外的其中10.105.148.194是backend-service的ip并非是pod ip在nginx配置中upstream的配置是backend-service使用了k8s的service做了负载均衡所以在nginx这层无论如何也是拿不到后端pod的ip的现在需要在真正负载均衡那一层把日志打开就可以看到转发的real server了iptables如果用的是iptables做的转发那就需要复习一下iptables的转发原理了当包进入网卡之后就进入了PREROUTING其次进入路由根据目的地址就分为两个部分进入本机走INPUT随后进入更高层的应用程序处理非本机的包进入FORWARD再进入POSTROUTING规则探索我们来看看具体的规则首先先检查PREROUTING就发现了k8s添加的链表KUBE-SERVICES▶ sudo iptables -L PREROUTING -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */ ...继续检查KUBE-SERVICES发现了很多service的规则▶ sudo iptables -L KUBE-SERVICES -t nat Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-W67AXLFK7VEUVN6G tcp -- anywhere 10.110.71.55 /* default/nginx-test cluster IP */ KUBE-SVC-EDNDUDH2C75GIR6O tcp -- anywhere 10.98.224.124 /* ingress-nginx/ingress-nginx-controller:https cluster IP */ KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 10.96.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 10.96.0.10 /* kube-system/kube-dns:metrics cluster IP */ KUBE-SVC-ZZAJ2COS27FT6J6V tcp -- anywhere 10.105.148.194 /* default/backend-service cluster IP */ KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 10.96.0.1 /* default/kubernetes:https cluster IP */ KUBE-SVC-CG5I4G2RS3ZVWGLK tcp -- anywhere 10.98.224.124 /* ingress-nginx/ingress-nginx-controller:http cluster IP */ KUBE-SVC-EZYNCFY2F7N6OQA2 tcp -- anywhere 10.101.164.9 /* ingress-nginx/ingress-nginx-controller-admission:https-webhook cluster IP */ KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 10.96.0.10 /* kube-system/kube-dns:dns cluster IP */找到目标servicebackend-service对应的链规则KUBE-SVC-ZZAJ2COS27FT6J6V继续检查▶ sudo iptables -L KUBE-SVC-ZZAJ2COS27FT6J6V -t nat Chain KUBE-SVC-ZZAJ2COS27FT6J6V (1 references) target prot opt source destination KUBE-MARK-MASQ tcp -- !10.244.0.0/16 10.105.148.194 /* default/backend-service cluster IP */ KUBE-SEP-GYMSSX4TMUPRH3OB all -- anywhere anywhere /* default/backend-service - 10.244.0.64:10000 */ statistic mode random probability 0.50000000000 KUBE-SEP-EZWMSI6QFXP3WRHV all -- anywhere anywhere /* default/backend-service - 10.244.0.66:10000 */这里已经有明显的结论了有2条链对应的了两个pod再深入检查其中一条链KUBE-SEP-GYMSSX4TMUPRH3OB▶ sudo iptables -L KUBE-SEP-GYMSSX4TMUPRH3OB -t nat Chain KUBE-SEP-GYMSSX4TMUPRH3OB (1 references) target prot opt source destination KUBE-MARK-MASQ all -- 10.244.0.64 anywhere /* default/backend-service */ DNAT tcp -- anywhere anywhere /* default/backend-service */ tcp to:10.244.0.64:10000从这里的规则能够知晓进入KUBE-SEP-GYMSSX4TMUPRH3OB会进行DNAT转换把目标的ip转换成10.244.0.64那同理可知另外一条链会将目标ip转换成10.244.0.66。所以我们只需要在这个地方加入日志记录就可以 追踪对端的ip是哪个了sudo iptables -t nat -I KUBE-SEP-GYMSSX4TMUPRH3OB 1 -j LOG --log-prefix backend-service-pod: --log-level 4 sudo iptables -t nat -I KUBE-SEP-EZWMSI6QFXP3WRHV 1 -j LOG --log-prefix backend-service-pod: --log-level 4来看下整体的效果▶ sudo iptables -L KUBE-SEP-GYMSSX4TMUPRH3OB -t nat Chain KUBE-SEP-GYMSSX4TMUPRH3OB (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix backend-service-pod: KUBE-MARK-MASQ all -- 10.244.0.64 anywhere /* default/backend-service */ DNAT tcp -- anywhere anywhere /* default/backend-service */ tcp to:10.244.0.64:10000 wilson.chai-ubuntu [ 17:18:03 ] /usr/src/trojan ▶ sudo iptables -L KUBE-SEP-EZWMSI6QFXP3WRHV -t nat Chain KUBE-SEP-EZWMSI6QFXP3WRHV (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix backend-service-pod: KUBE-MARK-MASQ all -- 10.244.0.66 anywhere /* default/backend-service */ DNAT tcp -- anywhere anywhere /* default/backend-service */ tcp to:10.244.0.66:10000都已经做了对应的日志记录了开始测试请求nginxcurl 127.0.0.1:30785/test查看日志tail -f /var/log/syslog | grep backend-service Dec 4 17:17:30 wilson kernel: [109258.569426] backend-service-pod: INcni0 OUT PHYSINveth1dc60dd3 MAC76:d8:f3:a1:f8:1b:a2:79:4b:23:58:d8:08:00 SRC10.244.0.70 DST10.105.148.194 LEN60 TOS0x00 PREC0x00 TTL64 ID64486 DF PROTOTCP SPT51596 DPT10000 WINDOW64860 RES0x00 SYN URGP0什么为什么DST依然显示的是10.105.148.194问题解决再次查看链规则在日志记录的时候还没有做DNAT所以DST依然是service ip但是如果将LOG规则写在DNAT之后那DNAT匹配之后就不会再进入LOG那依然不能记录▶ sudo iptables -L KUBE-SEP-GYMSSX4TMUPRH3OB -t nat Chain KUBE-SEP-GYMSSX4TMUPRH3OB (1 references) target prot opt source destination LOG all -- anywhere anywhere LOG level warning prefix backend-service-pod: KUBE-MARK-MASQ all -- 10.244.0.64 anywhere /* default/backend-service */ DNAT tcp -- anywhere anywhere /* default/backend-service */ tcp to:10.244.0.64:10000还是要回到iptables的工作原理我们的请求先进入PREROUTING链再进入FORWARD链最后进入POSTROUTING链请求进入在PREROUTING中已经进行了DNAT的转换那其实就可以在后面两个链表中记录日志。这里选择在POSTROUTING中记录日志iptables -t nat -I POSTROUTING -p tcp -d 10.244.0.64 -j LOG --log-prefix backend-service: iptables -t nat -I POSTROUTING -p tcp -d 10.244.0.66 -j LOG --log-prefix backend-service: ▶ sudo iptables -L POSTROUTING -t nat Chain POSTROUTING (policy ACCEPT) target prot opt source destination LOG tcp -- anywhere 10.244.0.66 LOG level warning prefix backend-service: LOG tcp -- anywhere 10.244.0.64 LOG level warning prefix backend-service: ...在测试一次Dec 4 17:33:23 wilson kernel: [110211.770728] backend-service: IN OUTcni0 PHYSINveth1dc60dd3 PHYSOUTvetha515043b SRC10.244.0.70 DST10.244.0.64 LEN60 TOS0x00 PREC0x00 TTL64 ID59709 DF PROTOTCP SPT33454 DPT10000 WINDOW64860 RES0x00 SYN URGP0 Dec 4 17:33:24 wilson kernel: [110213.141975] backend-service: IN OUTcni0 PHYSINveth1dc60dd3 PHYSOUTveth0a8a2dd3 SRC10.244.0.70 DST10.244.0.66 LEN60 TOS0x00 PREC0x00 TTL64 ID54719 DF PROTOTCP SPT33468 DPT10000 WINDOW64860 RES0x00 SYN URGP0iptables小结这个测试验证了用linux的iptables规则依然可以追踪每一条请求的链路并且回顾了iptables的工作原理以及探索了k8s基于iptables的转发规则的原理但是这里有几个问题一旦pod的ip变化那日志规则也要改变这在pod随时变化的环境中需要大量精力维护新增k8s node 节点依然需要手动添加规则这也需要大量维护这个方法涉及到了根本的转发规则一旦处理不当错误的增删改将导致不可预知的风险甚至集群由此崩溃所以这种方法是不太能够在生产环境当中使用的在这里做了详细的分析只是为了证明我们的思路没错只要在负载均衡那一层进行日志记录就能拿到real serveripvsipvs 是内核转发并不会记录访问日志但是依然可以使用 iptables的方法来记录就是在POSTROUTING链上记录日志如果k8s的转发模式是ipvs并不意味着只需要用ipvs就可以完成转发工作它需要ipvs与iptables共同协作才能完成内置于Linux内核中的核心技术模块它工作在Netfilter框架的INPUT之前的hook点当请求的目标ip是ipvs的vip时ipvs就会接入工作将数据包“劫持”过来然后进行规则匹配并修改比如进行DNATTCP 10.105.148.194:10000 rr - 10.244.0.73:10000 Masq 1 0 0 - 10.244.0.74:10000 Masq 1 0 0如果修改后的目标ip就是本机ip那ipvs就直接交给上层应用程序处理如果修改后的目标ip不是本机ip那该数据包会重新进入路由然后通过FORWARDPOSTROUTING转发出去小结本文复习了linux传统的知识点iptables与ipvs的工作原理并且详细讨论了如果不加任何插件的情况下使用操作系统自带的追踪方式查看后端真实的pod但是这些都不适合在生产环境使用因为它太底层了日常的操作不应该去操作底层的配置就算要用也应该做一些自动化的脚 本或者插件封装一次才能使用在不使用nginx-ingress-controller或者我想记录服务间转发的真实pod有没有可以直接使用的插件或者组件帮我们完成这个工作呢答案肯定是有的那这就是下一期的内容敬请期待联系我联系我做深入的交流至此本文结束在下才疏学浅有撒汤漏水的请各位不吝赐教…