contour
contour copied to clipboard
projectcontour
Envoy memory optimization: do better filter_chain_match organization
Contour creates a filter_chain_match with a single FQDN in server_names for every FQDN. It also provides TLS delegation which we use heavily. The problem is that the same tls_context and filters are copied in each filter_chain.
We reorganized filter_chain_match creation to aggregate server_names that reference the same secret name and saw a memory reduction of 40+ GiB to ~250 MiB in Envoy
This non-optimal construction of filter_chain_match plus #1635 plus https://github.com/envoyproxy/envoy/issues/7923 came together to cause our months-long issue of Envoy being oom-killed
Forgot to mention: you might think it's better to aggregate FQDNs by cert content (i.e. a digest), or inspect the cert and aggregate by Common Name. The latter was our first approach but it was confounded by https://github.com/envoyproxy/envoy/issues/6767
aggregate by Common Name
What about Subject Alternative Names? That aggregation could get tricky.
There's also a corner case for different certs issued for the same names by different PKIs (think internal/enterprise CAs).
Thank you for your issue.
We reorganized filter_chain_match creation to aggregate server_names that reference the same secret and saw a memory reduction of 40+ GiB to ~250 MiB in Envoy
Would you be willing to contribute that change to the project?
On Sat, 5 Oct 2019 at 02:54, Dharma Bellamkonda [email protected] wrote:
There's also a corner case for different certs issued for the same names by different PKIs (think internal/enterprise CAs).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/projectcontour/contour/issues/1636?email_source=notifications&email_token=AAABYA5CU4OTSM4ZH7WSWHDQM5YN7A5CNFSM4I5R5HV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMIJZA#issuecomment-538477796, or mute the thread https://github.com/notifications/unsubscribe-auth/AAABYAZZFI4GIXJX65JNABDQM5YN7ANCNFSM4I5R5HVQ .
FYI, we organized the filter chains differently in 1.4 to enforce SNI binding semantics. This strongly binds a SNI server name to the corresponding routes, but I expect that this has some negative effect on Envoy resources, since there are now more HttpConnectionManagers.
