根据响应位置标头重写HTTP请求-Istio

时间:2019-03-02 00:02:44

标签: proxy kubernetes istio envoyproxy

说明:

通过virtual_service向上游的Istio(1.0.6)代理发出请求。服务正在响应标头 newuri httpStatus 代码,即307-我知道重定向应该通过指定302和位置标头来实现。但是我想基于http错误进行重定向处理。 我尝试将 envoyFilters 与lua一起使用,但是所有功能都与流处理(请求/响应标头mod)有关,而不是重写或转发请求。

所以请求路径如下:

  • 客户端正在发出请求,即卷曲http://foo/path
  • 代理正在将请求转发到上游
  • 上游正在使用以new_uri即http://blabla/path2作为值的自定义标头进行响应
  • 响应头中存在标头时,它对new_uri提出新请求
  • 客户看到来自new_uri的回复

谢谢

1 个答案:

答案 0 :(得分:0)

如果您有预定义的上游主机列表,则可以考虑查看Envoy Retry plugin。通过这种机制,您可以确定可以与某些特定的重试条件retry_on相关联的Hosts predicates的列表:即特定的HTTP错误代码;和重试序列号num_retries,因此在重试次数达到重试次数后,Envoy重试策略将从retry_host_predicate定义的列表中选择下一个主机。

{
  "retry_on": "...",
  "num_retries": "{...}",
  "per_try_timeout": "{...}",
  "retry_priority": "{...}",
  "retry_host_predicate": [],
  "host_selection_retry_max_attempts": "...",
  "retriable_status_codes": []
}

在其他情况下,如果事先不知道您的重定向主机,则最好找到一种方法,以便在应用程序级别应用适当的逻辑,因为大多数HTTP代理都是以响应处理程序同步执行的方式设计的,即,响应处理程序正在运行时,将在同一线程中调度其他任何事件。只要响应处理程序仅处理内存中已经存在的数据并且不等待远程服务就可以了。但是,如果您从响应处理程序发出网络请求,则整个线程将被阻塞,并且在远程服务答复之前绝对不会执行任何操作,这将导致性能下降。