当前位置: 首页 > 知识库问答 >
问题:

在负载均衡器中添加自定义报头到HTTP请求

唐永春
2023-03-14

我在openshift容器平台上部署了一个容器化应用程序/服务,其中包含istio服务网格。在istio虚拟服务yaml中,我想验证http请求是否有头(对于ex:version)和值v1。我在虚拟服务yaml中添加了下面的配置,用于验证头文件。但我正在寻找可用的选项,使用loadbalancer/ingress/openshif route等将此头插入HTTP请求中,因为我的istio ingressgateway服务是使用ClusterIp部署的。我使用openshift路线将外部流量发送到ingressgateway。请分享向http请求添加标题的可能方法

  http:
    - match:
        - headers: # Match header
            version: # header that we decided for dark release
              exact: v1 # exact match


 

共有2个答案

陶柏
2023-03-14

应该可以使用类似virtualService的服务

spec:  
  hosts:  
  - "example.com"  
  gateways:  
  - your-gateway  
  http:  
  -   
    name: remove-headers  
    headers:  
      request:  
        remove:  
        - yourHeader  

但我不能让它工作。如果可以,请分享:)

范豪
2023-03-14

您可以使用特使过滤器来实现这一点。

在“特使过滤器”下面,将名为customer id的请求头添加到所有通过istio入口网关的请求中。如果有人想使用,我还对响应头的代码进行了注释。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: lua-filter
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
            subFilter:
              name: "envoy.router"
    patch:
      operation: INSERT_BEFORE
      value:
       name: envoy.lua
       typed_config:
         "@type": "type.googleapis.com/envoy.config.filter.http.lua.v2.Lua"
         inlineCode: |
            function envoy_on_request(request_handle)
                request_handle:headers():add("customer-id", "alice")
            end
           # function envoy_on_response(response_handle)
           #     response_handle:headers():add("customer-id", "alice")
           # end

我用过YAML来测试它,它可能对测试上面的过滤器很有用。

  • 如果你使用上面的过滤器与alice头然后所有的请求去nginx-v1
  • 如果您使用上面的bob头过滤器,那么所有请求都将转到nginx-v2
  • 如果你删除这个过滤器,那么nginx-v1和nginx-v2之间是50/50
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v1
spec:
  selector:
    matchLabels:
      run: nginx1
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx1
        app: frontend
    spec:
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx1 > /usr/share/nginx/html/index.html"]

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v2
spec:
  selector:
    matchLabels:
      run: nginx2
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx2
        app: frontend
    spec:
      containers:
      - name: nginx2
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx2 > /usr/share/nginx/html/index.html"]



---

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: frontend
spec:
  ports:
  - name: http-front
    port: 80
    protocol: TCP
  selector:
    app: frontend

---

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gatewayx
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginxvirt
spec:
  hosts:
  - '*'
  gateways:
  - gatewayx
  http:
  - name: "route-1"
    match:
    - headers:
        customer-id:
          exact: alice
    route:
    - destination:
        host: nginx
        subset: v1
  - name: "route-2"
    match:
    - headers:
        customer-id:
          exact: bob
    route:
    - destination:
        host: nginx
        subset: v2
  - route:
    - destination:
        host: nginx

---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: nginxdest
spec:
  host: nginx
  subsets:
  - name: v1
    labels:
      run: nginx1
  - name: v2
    labels:
      run: nginx2
 类似资料:
  • 使用AWS,我想: 通过多个不同的IP发送http请求 不使用代理发送此请求 使用弹性负载平衡器和自动校准组发送 将这些请求从一个实例发送到自动缩放组中的多个实例 这几个实例中的每一个都将不同的IP分配给传入的请求,以便在其IP中输出请求 我该怎么做?是否需要设置负载平衡器,以便通过http请求发送?我希望每个http请求都有不同的IP地址。

  • 目标是在一个简单的堆栈中包含 HTTP/2 支持:在多个 EC2 实例中部署的 Web 应用程序是启用了 PROXY 协议策略 (SSL:443 ➝ TCP:80) 的传输级 CLB,以便卸载 SSL/TLS 并平衡传入的 HTTPS 流量。 PROXY协议的几个原因:(1)地理定位逻辑的执行;(2)执行简单的访问控制规则;(3)日志记录。所有这些功能都需要访问可靠的(即不可轻易伪造的)客户端IP

  • 问题是,我还想将HTTP访问重定向到HTTPS,然后我试图添加一个规则将80重定向到443,因此它将落入第一个规则(443到8080)并使用证书,但它不起作用。在网上研究,我发现我应该在我的。htacess文件中添加一些行,但也不起作用。我认为这不是我的解决方案,因为所有HTTPS的东西都在AWS端,有没有一种方法可以只通过AWS将HTTP重定向到HTTPS而不改变服务器?

  • 负载均衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载均衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载均衡服务通常是由专用软体和硬件来完成。 负载均衡最重要的一个应用是利用多台服务器提供单一服务,这种方案有

  • 负载均衡包括负载均衡实例、访问控制及证书。 实例 负载均衡实例是一个运行的负载均衡服务,通过设置的虚拟IP接收流量并将其转发分配给后端服务器。 访问控制 访问控制用于设置访问负载均衡的IP白名单或IP黑名单。 证书 当在负载均衡实例上配置HTTPS监听转发来自HTTPS协议的请求时,需要配置证书。

  • 一个简单的负载均衡的示例,把www.domain.com均衡到本机不同的端口,也可以改为均衡到不同的地址上。> http { : upstream myproject { : server 127.0.0.1:8000 weight=3; : server 127.0.0.1:8001; : server 127.0.0.1:8002; : server 127.0.0.1:8003; : }