寫點東西吧,懒人。
· ☕ 1 分钟
Envoy源码分析之Dispatcher:https://developer.aliyun.com/article/659277
线程相关 Misc:
- Envoy进程由一个Main Thread和多个Worker Thread 组成
- 每个Main和Worker包含一个eventloop,所有的处理都是由eventloop触发开始
- Main负责xDS等功能,Worker负责处理连接和请求
- 当一个client向Envoy建立连接的时候,因为所有Worker的EventLoop都注册了listening fd(启用SO_PORTREUSE除外),会由内核决定分配给哪个Worker
- 当一个下游client连接到了Envoy,在保持连接不断的情况下,会和同一个Worker进行通讯
· ☕ 2 分钟
HTTP/1.1 Header Casing
When handling HTTP/1.1, Envoy will normalize the header keys to be all lowercase. While this is compliant with the HTTP/1.1 spec, in practice this can result in issues when migrating existing systems that might rely on specific header casing.
To support these use cases, Envoy allows configuring a formatting scheme for the headers, which will have Envoy transform the header keys during serialization.
- To configure this formatting on response headers, specify the format in the
http_protocol_options
. - To configure this for upstream request headers, specify the formatting in
http_protocol_options
in the cluster’sextension_protocol_options
.
Currently Envoy supports two mutually exclusive types of header key formatters:
· ☕ 2 分钟
config.core.v3.Http1ProtocolOptions
[config.core.v3.Http1ProtocolOptions proto]
|
|
-
allow_absolute_url
(BoolValue) Handle HTTP requests with absolute URLs in the requests. These requests are generally sent by clients to forward/explicit proxies. This allows clients to configure envoy as their HTTP proxy. In Unix, for example, this is typically done by setting the http_proxy environment variable.
· ☕ 1 分钟
Enable debug log by command line
https://projectcontour.io/docs/v1.10.0/troubleshooting/envoy-debug-log/
The envoy
command has a --log-level
flag that can be useful for debugging. By default, it’s set to info
. To change it to debug
, edit the envoy
DaemonSet in the projectcontour
namespace and replace the --log-level info
flag with --log-level debug
. Setting the Envoy log level to debug
can be particilarly useful for debugging TLS connection failures.
Enable debug log by API
列出 logger 名字:
· ☕ 2 分钟
https://www.envoyproxy.io/docs/envoy/latest/operations/performance
Performance¶
Envoy is architected to optimize scalability and resource utilization by running an event loop on a small number of threads. The “main” thread is responsible for control plane processing, and each “worker” thread handles a portion of the data plane processing. Envoy exposes two statistics to monitor performance of the event loops on all these threads.
-
Loop duration: Some amount of processing is done on each iteration of the event loop. This amount will naturally vary with changes in load. However, if one or more threads have an unusually long-tailed loop duration, it may indicate a performance issue. For example, work might not be distributed fairly across the worker threads, or there may be a long blocking operation in an extension that’s impeding progress.
· ☕ 3 分钟
Kernel
https://lwn.net/Articles/542629/
One of the features merged in the 3.9 development cycle was TCP and UDP support for the SO_REUSEPORT socket option; that support was implemented in a series of patches by Tom Herbert. The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems.
The basic concept of SO_REUSEPORT is simple enough. Multiple servers (processes or threads) can bind to the same port if they each set the option as follows:
· ☕ 2 分钟
Connection pooling
For HTTP traffic, Envoy supports abstract connection pools that are layered on top of the underlying wire protocol (HTTP/1.1, HTTP/2, HTTP/3). The utilizing filter code does not need to be aware of whether the underlying protocol supports true multiplexing or not. In practice the underlying implementations have the following high level properties:
HTTP/1.1
The HTTP/1.1 connection pool acquires connections as needed to an upstream host (up to the circuit breaking limit). Requests are bound to connections as they become available, either because a connection is done processing a previous request or because a new connection is ready to receive its first request. The HTTP/1.1 connection pool does not make use of pipelining so that only a single downstream request must be reset if the upstream connection is severed.
· ☕ 2 分钟
TLS ALPN
Force HTTP 1.1
https://www.tetrate.io/blog/envoy-and-istio-security-releases-june-2020/
Envoy versions can mitigate those vulnerabilities by disabling HTTP2 and allowing only HTTP/1.1 by setting http_connection_manager.codec_type
to “HTTP1
” and removing “h2
” from common_tls_context.alpn_protocols
.
For Istio:
|
|
HTTP 1.1 Upgrade header
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/upgrades#http-upgrades
· ☕ 3 分钟
HTTP Protocol Options
This extension may be referenced by the qualified name envoy.upstreams.http.http_protocol_options
extensions.upstreams.http.v3.HttpProtocolOptions
HttpProtocolOptions specifies Http upstream protocol options. This object is used in typed_extension_protocol_options, keyed by the name envoy.extensions.upstreams.http.v3.HttpProtocolOptions.
This controls what protocol(s) should be used for upstream and how said protocol(s) are configured.
This replaces the prior pattern of explicit protocol configuration directly in the cluster. So a configuration like this, explicitly configuring the use of HTTP/2 upstream:
· ☕ 8 分钟
Chart
A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
Directory structure
wordpress/
Chart.yaml # A YAML file containing information about the chart
LICENSE # OPTIONAL: A plain text file containing the license for the chart
README.md # OPTIONAL: A human-readable README file
values.yaml # The default configuration values for this chart
values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
charts/ # A directory containing any charts upon which this chart depends.
crds/ # Custom Resource Definitions
templates/ # A directory of templates that, when combined with values,
# will generate valid Kubernetes manifest files.
templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes
Pull: