kubernetes 中的容器设置透明代理,自动在 HTTP 请求头中注入 Pod 信息

Tags: kubernetes  nginx  gateway 

本篇目录

说明

因为选用的 Kubernetes 的网络方案原因,Pod 内的程序访问集群外部的服务时,源 IP 会被转换成 Node 的 IP。

集群外部的服务或者网关层获取不到 Pod 本身的信息,会给故障排查增加一些困难,网关层基于源 IP 的功能,譬如限速,也会受到影响。 要求集群内的客户端发送请求时带上 Pod 信息是比较困难的,最好用技术手段偷偷实现。

研究了一下,可以通过基于 nginx 的透明代理实现。

采用的技术

就是在 Pod 内用 nginx 实现透明代理, 找了下 正向代理、反向代理、透明代理 的区别,这里采用的用户无感知的方式更贴近透明代理的概念,同时也是正向代理。

技术原理:

  1. 使用 nginx 实现本地透明代理

参考了 istio 的实现:

  1. istio是怎样强行代理Pod的进出请求的?
  2. 服务网格/ServiceMesh 项目 istio 的流量重定向、代理请求过程分析

使用方法

相关配置已经打包成镜像 lijiaocn/nginx-tranproxy:0.1(docker-nginx-tranproxy),可以用 sidecar 的方式部署或者以 lijiaocn/nginx-tranproxy:0.1 为 base 镜像制作业务容器的镜像。

lijiaocn/nginx-tranproxy 的使用方法:

$ docker run --rm -it  lijiaocn/nginx-tranproxy:0.1 -h
Usage: entrypoint.sh
-h/--help        print this usage
-P/--port port   proxy traffic to this port, this option can repeat
                 eg: -P 80 -P 8080
-H/--header      headers add by tranproxy, this option can repeat
                 eg: -H header1:value1 -H header2:value2
-N/--nameserver  nameserver used by tranproxy, this option can repeat
                 eg: -N 114.114.114.114 -N 8.8.8.8
                 default value is nameservers in /etc/resolve.conf

--Set-Forwarded-For   tranproxy will add X-Forwarded-For header
                      if value is not provided, use env PODIP
                      if env PODIP is empty, use primary nic ip
--Set-Client-Hostname tranproxy will add X-Client-Hostname header
                      if value is not provided, get by command hostname
-- cmd arg arg...     execute cmd at last, may be empty

SideCar 的方式

在 Pod 中添加一个名为 nginx-tranproxy 的 SideCar 容器,和名为 tail 的业务容器共用网络设置:

... 省略 ...
containers:
# 业务容器
- image: lijiaocn/alpine-tool:0.1
  name: tail
  args:
  - tail
  - -f
  - /dev/null
  imagePullPolicy: IfNotPresent
... 省略 ...
- image: lijiaocn/nginx-tranproxy:0.1
  args:
  - -P
  - "80"
  - -P
  - "8080"
  - -N
  - "114.114.114.114"
  - -N
  - "8.8.8.8"
  - --Set-Forwarded-For
  - default
  - --Set-Client-Hostname
  - default
  - -H
  - tranproxy:true
  env:
  - name: PODIP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP
  imagePullPolicy: Always
  name: nginx-tranproxy
  resources: {}
  securityContext:
    capabilities:
      add:
      - NET_ADMIN

完整的 yaml 文件是 usage-sidecar-mode.yaml,tail 容器是一个什么也不做的业务容器。

在 nginx-tranproxy 容器中可查看设置的 iptables 规则:

~ # iptables-save
# Generated by iptables-save v1.6.2 on Mon Nov 18 02:43:17 2019
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:60]
:POSTROUTING ACCEPT [2:120]
:LOCAL_PROXY - [0:0]
-A OUTPUT -p tcp -j LOCAL_PROXY
-A LOCAL_PROXY -m owner --uid-owner 100 -j RETURN
-A LOCAL_PROXY -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
-A LOCAL_PROXY -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 8080
COMMIT
# Completed on Mon Nov 18 02:43:17 2019

在 nginx-tranproxy 容器或者业务容器(tail)中发起的到 80/8080 的 http 请求会被添加 http 头,譬如访问 echo 服务 时返回下面的结果:

/ # curl 172.17.0.21:8080

Hostname: echo-597d89dcd9-m84tq

Pod Information:
	-no pod information available-

Server values:
...省略...

Request Headers:
	accept=*/*
	connection=close
	host=172.17.0.21:8080
	user-agent=curl/7.61.1
	
	...透明代理添加的请求头,和 nginx-tranproxy 的运行参数对应....
	tranproxy=true
	x-client-hostname=tail-with-nginx-tranproxy-59d8b5f4f9-ptpq2
	x-forwarded-for=172.17.0.28

Request Body:
	-no body in request-

InOne 方式

InOne方式(生造的词..)就是把 nginx 透明代理和业务系统打包在一起,lijiaocn/nginx-tranproxy:0.1 镜像是一个很好的 base 镜像,它的 entrypoint.sh 脚本支持追加要执行的命令,譬如:

containers:
- image: lijiaocn/nginx-tranproxy:0.1
  args:
  - -P
  - "80"
  - -P
  - "8080"
  - -N
  - "114.114.114.114"
  - -N
  - "8.8.8.8"
  - --Set-Forwarded-For
  - default
  - --Set-Client-Hostname
  - default
  - -H
  - tranproxy:true
  - --
  # -- 后面是在容器内运行的服务的启动命令,这里用 tail 模拟
  - tail
  - -f
  - /dev/null
  env:
  - name: PODIP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP

--之后是业务系统的启动命令,这种方式可以少用一个 sidecar 容器,完整的 yaml 文件:usage-together-mode.yaml

参考

  1. 李佶澳的博客
  2. 图解正向代理、反向代理、透明代理
  3. 使用 nginx 实现本地透明代理
  4. istio是怎样强行代理Pod的进出请求的?
  5. 服务网格/ServiceMesh 项目 istio 的流量重定向、代理请求过程分析
  6. docker-nginx-tranproxy
  7. 用 echoserver 观察代理/转发效果
  8. usage-together-mode.yaml

kubernetes

  1. kubernetes 使用:多可用区、Pod 部署拓扑与 Topology Aware Routing
  2. kubernetes 扩展:Cloud Controller Manager
  3. kubernetes 准入:操作合法性检查(Admission Control)
  4. kubernetes 鉴权:用户操作权限鉴定(Authorization)
  5. kubernetes 认证:用户管理与身份认证(Authenticating)
  6. kubernetes 开发:代码生成工具
  7. kubernetes 扩展:operator 开发
  8. kubernetes 扩展:CRD 的使用方法
  9. kubernetes configmap 热加载,inotifywatch 监测文件触发热更新
  10. kubernetes 扩展:扩展点和方法(api/cr/plugin...)
  11. kubernetes 调度组件 kube-scheduler 1.16.3 源代码阅读指引
  12. kubernetes 代码中的 k8s.io 是怎么回事?
  13. 阅读笔记《不一样的 双11 技术,阿里巴巴经济体云原生实践》
  14. kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502
  15. ingress-nginx 的限速功能在 nginx.conf 中的对应配置
  16. kubernetes 中的容器设置透明代理,自动在 HTTP 请求头中注入 Pod 信息
  17. kubernetes ingress-nginx 的测试代码(单元测试+e2e测试)
  18. kubernetes ingress-nginx http 请求复制功能与 nginx mirror 的行为差异
  19. kubernetes 基于 openresty 的 ingress-nginx 的状态和配置查询
  20. kubernetes ingress-nginx 0.25 源代码走读笔记
  21. kubernetes ingress-nginx 的金丝雀(canary)/灰度发布功能的使用方法
  22. kubernetes 操作命令 kubectl 在 shell 中的自动补全配置
  23. kubernetes 组件 kube-proxy 的 IPVS 功能的使用
  24. kubernetes initializer 功能的使用方法: 在 Pod 等 Resource 落地前进行修改
  25. kubernetes 版本特性: 新特性支持版本和组件兼容版本
  26. kubernetes API 与 Operator: 不为人知的开发者战争(完整篇)
  27. kubernetes 1.12 从零开始(七): kubernetes开发资源
  28. kubernetes 1.12 从零开始(六): 从代码编译到自动部署
  29. kubernetes 网络方案 Flannel 的学习笔记
  30. kubernetes 1.12 从零开始(五): 自己动手部署 kubernetes
  31. kubernetes 1.12 从零开始(四): 必须先讲一下基本概念
  32. kubernetes 1.12 从零开始(三): 用 kubeadm 部署多节点集群
  33. kubernetes 1.12 从零开始(二): 用 minikube 部署开发测试环境
  34. kubernetes 1.12 从零开始(一): 部署环境准备
  35. kubernetes 1.12 从零开始(零): 遇到的问题与解决方法
  36. kubernetes 1.12 从零开始(初): 课程介绍与官方文档汇总
  37. kubernetes 集群状态监控:通过 grafana 和 prometheus
  38. 一些比较有意思的Kubernetes周边产品
  39. Borg论文阅读笔记
  40. kubelet下载pod镜像时,docker口令文件的查找顺序
  41. kubernetes 的 Client Libraries 的使用
  42. kubernetes的网络隔离networkpolicy
  43. kube-router的源码走读
  44. kubernetes 跨网段通信: 通过 calico 的 ipip 模式
  45. kubernetes的调试方法
  46. kubernetes 与 calico 的衔接过程
  47. 怎样理解 kubernetes 以及微服务?
  48. kubernetes中部署有状态的复杂分布式系统
  49. kubernetes的apiserver的启动过程
  50. kubernetes的api定义与装载
  51. kubernetes的federation部署,跨区Service
  52. kubernetes的编译、打包、发布
  53. kubernetes的第三方包的使用
  54. kubernetes的Storage的实现
  55. kubernetes 的 Apiserver 的 storage 使用
  56. kubernetes的Controller-manager的工作过程
  57. kubernetes的Client端Cache
  58. kubernetes 的 Apiserver 的工作过程
  59. kubernetes的CNI插件初始化与Pod网络设置
  60. kubernetes的Pod变更过程
  61. kubernetes的kubelet的工作过程
  62. kuberntes 的 Cmdline 实现
  63. kubernetes的Pod内挂载的Service Account的使用方法
  64. kubernetes的社区资源与项目参与方式
  65. kubernetes的Kube-proxy的转发规则分析
  66. kubernetes的基本操作
  67. kubernetes在CentOS上的集群部署
  68. kubernetes在CentOS上的All In One部署
  69. 怎样选择集群管理系统?

nginx

  1. nginx 带有时效的 Secure Url(加密链接)的配置方法
  2. kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502
  3. kubernetes 中的容器设置透明代理,自动在 HTTP 请求头中注入 Pod 信息
  4. 使用 nginx 作反向代理,启用 keepalive 时,遇到 502 错误的调查过程
  5. Nginx学习笔记(三): Nginx性能调优
  6. Nginx学习笔记(二): Nginx配置文件细节
  7. Nginx学习笔记(一): 学习资料与配置文件格式
  8. API网关Kong学习笔记(一): Nginx、OpenResty和Kong入门,基础概念和安装部署

gateway

  1. 公众号文章同步: istio 的目标是去掉中心化网关吗?
  2. kubernetes 中的容器设置透明代理,自动在 HTTP 请求头中注入 Pod 信息
  3. kubernetes ingress-nginx http 请求复制功能与 nginx mirror 的行为差异
  4. 开源的api网关gloo的源代码粗略阅读
  5. 基于Envoy的ApiGateway/Ingress Controller项目梳理(总结)
  6. 基于Envoy的ApiGateway/Ingress Controller项目梳理(四): Istio
  7. 基于Envoy的ApiGateway/Ingress Controller项目梳理(三): Gloo
  8. 基于Envoy的ApiGateway/Ingress Controller项目梳理(二): Contour
  9. 基于Envoy的ApiGateway/Ingress Controller项目梳理(一): Ambassador
  10. nginx、kong、enovy代理转发功能的性能测试结果对比

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接,合作请加微信lijiaocn或者发送邮件: [email protected],备注网站合作

友情链接:  系统软件  程序语言  运营经验  水库文集  网络课程  微信网文  发现知识星球