{"@attributes":{"version":"2.0"},"channel":{"title":"Emissary-ingress on ","link":"https:\/\/emissary-ingress.dev\/","description":"Recent content in Emissary-ingress on ","generator":"Hugo","language":"en","item":[{"title":"Header-based routing","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/headers\/","description":"

Emissary can route to target services based on HTTP headers with the headers<\/code> and regex_headers<\/code> specifications. Multiple mappings with different annotations can be applied to construct more complex routing rules.<\/p>\n

The headers<\/code> annotation<\/h2>\n

The headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. Emissary will only allow requests that match the specified header<\/code>: value<\/code> pairs to reach the target service.<\/p>\n

Example<\/h3>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span>  <\/span>headers<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>x-quote-mode<\/span>:<\/span> <\/span>backend<\/span>\n<\/span><\/span><\/span>    <\/span>x-random-header<\/span>:<\/span> <\/span>datawire<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will allow requests to \/backend\/ to succeed only if the x-quote-mode header has the value backend and the x-random-header has the value datawire<\/code>.<\/p>"},{"title":"Header-based routing","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/headers\/","description":"
Emissary can route to target services based on HTTP headers with the headers<\/code> and regex_headers<\/code> specifications. Multiple mappings with different annotations can be applied to construct more complex routing rules.<\/p>\n
The headers<\/code> annotation<\/h2>\n
The headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. Emissary will only allow requests that match the specified header<\/code>: value<\/code> pairs to reach the target service.<\/p>\n
Example<\/h3>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span>  <\/span>headers<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>x-quote-mode<\/span>:<\/span> <\/span>backend<\/span>\n<\/span><\/span><\/span>    <\/span>x-random-header<\/span>:<\/span> <\/span>datawire<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will allow requests to \/backend\/ to succeed only if the x-quote-mode header has the value backend and the x-random-header has the value datawire<\/code>.<\/p>"},{"title":"Header-based routing","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/headers\/","description":"
Emissary can route to target services based on HTTP headers with the headers<\/code> and regex_headers<\/code> specifications. Multiple mappings with different annotations can be applied to construct more complex routing rules.<\/p>\n
The headers<\/code> annotation<\/h2>\n
The headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. Emissary will only allow requests that match the specified header<\/code>: value<\/code> pairs to reach the target service.<\/p>\n
Example<\/h3>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span>  <\/span>headers<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>x-quote-mode<\/span>:<\/span> <\/span>backend<\/span>\n<\/span><\/span><\/span>    <\/span>x-random-header<\/span>:<\/span> <\/span>datawire<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will allow requests to \/backend\/ to succeed only if the x-quote-mode header has the value backend and the x-random-header has the value datawire<\/code>.<\/p>"},{"title":"Migration Matrix","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/install\/migration-matrix\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/install\/migration-matrix\/","description":"\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
There are currently multiple paths for upgrading Emissary, depending on what version you’re currently\nrunning, what you want to be running, and whether you installed Emissary using Helm or YAML.<\/p>\n
(To check out if you installed Emissary using Helm, run helm list --all-namespaces<\/code> and see if\nEmissary is listed. If so, you installed using Helm.)<\/p>\n\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
If you installed Emissary using Helm<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
If you installed Emissary manually by applying YAML<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>"},{"title":"Migration Matrix","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/install\/migration-matrix\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/install\/migration-matrix\/","description":"\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
There are currently multiple paths for upgrading Emissary, depending on what version you’re currently\nrunning, what you want to be running, and whether you installed Emissary using Helm or YAML.<\/p>\n
(To check out if you installed Emissary using Helm, run helm list --all-namespaces<\/code> and see if\nEmissary is listed. If so, you installed using Helm.)<\/p>\n\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
If you installed Emissary using Helm<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
If you installed Emissary manually by applying YAML<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>"},{"title":"Migration Matrix","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/install\/migration-matrix\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/install\/migration-matrix\/","description":"\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
There are currently multiple paths for upgrading Emissary, depending on what version you’re currently\nrunning, what you want to be running, and whether you installed Emissary using Helm or YAML.<\/p>\n
(To check out if you installed Emissary using Helm, run helm list --all-namespaces<\/code> and see if\nEmissary is listed. If so, you installed using Helm.)<\/p>\n\n  Read the instructions below<\/b> before making any changes to your cluster!\n<\/Alert>\n
If you installed Emissary using Helm<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
If you installed Emissary manually by applying YAML<\/h2>\n\n  \n      \n          \n      \n          \n          \n          \n          \n          \n          \n          \n          
If you’re running.<\/th>\n          You can upgrade to<\/th>\n      <\/tr>\n  <\/thead>\n  
Emissary 3.9<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.8.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 3.7.X<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.5<\/td>\n          Emissary 3.10<\/a><\/td>\n      <\/tr>\n      
Emissary 2.4.X<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 2.0.5<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary 1.14<\/td>\n          Emissary 2.5<\/a><\/td>\n      <\/tr>\n      
Emissary prior to 1.14<\/td>\n          Emissary 1.14<\/a><\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>"},{"title":"Add request headers","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/add-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/add-request-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each request that is passed to a service.<\/p>\n
The add_request_headers<\/code> attribute<\/h2>\n
The add_request_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Add request headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/add-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/add-request-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each request that is passed to a service.<\/p>\n
The add_request_headers<\/code> attribute<\/h2>\n
The add_request_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Add request headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/add-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/add-request-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each request that is passed to a service.<\/p>\n
The add_request_headers<\/code> attribute<\/h2>\n
The add_request_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Add response headers","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/add-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/add-response-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each response that is returned to the client.<\/p>\n
The add_response_headers<\/code> attribute<\/h2>\n
The add_response_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Add response headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/add-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/add-response-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each response that is returned to the client.<\/p>\n
The add_response_headers<\/code> attribute<\/h2>\n
The add_response_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Add response headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/add-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/add-response-headers\/","description":"
Emissary can add a dictionary of HTTP headers that can be added to each response that is returned to the client.<\/p>\n
The add_response_headers<\/code> attribute<\/h2>\n
The add_response_headers<\/code> attribute is a dictionary of header<\/code>: value<\/code> pairs. The value<\/code> can be a string<\/code>, bool<\/code> or object<\/code>. When it is an object<\/code>, the object should have a value<\/code> property, which is the actual header value, and the remaining attributes are additional envoy properties.<\/p>\n
Envoy dynamic values %DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%<\/code> and %PROTOCOL%<\/code> are supported, in addition to static values.<\/p>"},{"title":"Remove request headers","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/remove-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/remove-request-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the upstream from the request.<\/p>\n
The remove_request_headers<\/code> attribute<\/h2>\n
The remove_request_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_request_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- authorization<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key authorization<\/code>.<\/p>"},{"title":"Remove request headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/remove-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/remove-request-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the upstream from the request.<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_request_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- authorization<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key authorization<\/code>.<\/p>"},{"title":"Remove request headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/remove-request-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/remove-request-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the upstream from the request.<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_request_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- authorization<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key authorization<\/code>.<\/p>"},{"title":"Remove response headers","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/remove-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/headers\/remove-response-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the client in the response (e.g. default x-envoy-upstream-service-time<\/code>).<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_response_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- x-envoy-upstream-service-time<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key x-envoy-upstream-service-time<\/code>.<\/p>"},{"title":"Remove response headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/remove-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/headers\/remove-response-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the client in the response (e.g. default x-envoy-upstream-service-time<\/code>).<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_response_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- x-envoy-upstream-service-time<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key x-envoy-upstream-service-time<\/code>.<\/p>"},{"title":"Remove response headers","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/remove-response-headers\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/headers\/remove-response-headers\/","description":"
Emissary can remove a list of HTTP headers that would be sent to the client in the response (e.g. default x-envoy-upstream-service-time<\/code>).<\/p>\n
Mapping example<\/h2>\n
---<\/span>\n<\/span><\/span><\/span><\/span>apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Mapping<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>quote-backend<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>prefix<\/span>:<\/span> <\/span>\/backend\/<\/span>\n<\/span><\/span><\/span>  <\/span>remove_response_headers<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>- x-envoy-upstream-service-time<\/span>\n<\/span><\/span><\/span>  <\/span>service<\/span>:<\/span> <\/span>quote<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
will drop the header with key x-envoy-upstream-service-time<\/code>.<\/p>"},{"title":"Introduction to the Mapping Resource","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/intro-mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/intro-mappings\/","description":"
Quick example<\/h2>\n
At its core a Mapping<\/code> resource maps a resource<\/code> to a service<\/code>:<\/p>\n\n  \n      \n          \n      \n          \n          \n          
Required attribute<\/th>\n          Description<\/th>\n      <\/tr>\n  <\/thead>\n  
name<\/code><\/td>\n          is a string identifying the Mapping<\/code> (e.g. in diagnostics)<\/td>\n      <\/tr>\n      
prefix<\/code><\/a><\/td>\n          is the URL prefix identifying your resource<\/a><\/td>\n      <\/tr>\n      
service<\/code><\/a><\/td>\n          is the name of the service<\/a> handling the resource; must include the namespace (e.g. myservice.othernamespace<\/code>) if the service is in a different namespace than Emissary<\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
These resources are defined as Kubernetes Custom Resource Definitions. Here’s a simple example that maps all requests to \/httpbin\/<\/code> to the httpbin.org<\/code> web service:<\/p>"},{"title":"Introduction to the Mapping Resource","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/intro-mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/intro-mappings\/","description":"
Emissary is designed around a declarative, self-service management model<\/a>. The core resource used to support application development teams who need to manage the edge with Emissary is the Mapping<\/code> resource.<\/p>\n\n  Remember that Listener<\/code> and Host<\/code> resources are\n   required<\/b> for a functioning Emissary installation that can route traffic!\n  Learn more about Listener<\/code><\/a>.\n  Learn more about Host<\/code><\/a>.\n<\/Alert>\n
Quick example<\/h2>\n
At its core a Mapping<\/code> resource maps a resource<\/code> to a service<\/code>:<\/p>\n\n  \n      \n          \n      \n          \n          \n          
Required attribute<\/th>\n          Description<\/th>\n      <\/tr>\n  <\/thead>\n  
name<\/code><\/td>\n          is a string identifying the Mapping<\/code> (e.g. in diagnostics)<\/td>\n      <\/tr>\n      
prefix<\/code><\/a><\/td>\n          is the URL prefix identifying your resource<\/a><\/td>\n      <\/tr>\n      
service<\/code><\/a><\/td>\n          is the name of the service<\/a> handling the resource; must include the namespace (e.g. myservice.othernamespace<\/code>) if the service is in a different namespace than Emissary<\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
These resources are defined as Kubernetes Custom Resource Definitions. Here’s a simple example that maps all requests to \/httpbin\/<\/code> to the httpbin.org<\/code> web service:<\/p>"},{"title":"Introduction to the Mapping Resource","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/intro-mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/intro-mappings\/","description":"
Emissary is designed around a declarative, self-service management model<\/a>. The core resource used to support application development teams who need to manage the edge with Emissary is the Mapping<\/code> resource.<\/p>\n\n  Remember that Listener<\/code> and Host<\/code> resources are\n   required<\/b> for a functioning Emissary installation that can route traffic!\n  Learn more about Listener<\/code><\/a>.\n  Learn more about Host<\/code><\/a>.\n<\/Alert>\n
Quick example<\/h2>\n
At its core a Mapping<\/code> resource maps a resource<\/code> to a service<\/code>:<\/p>\n\n  \n      \n          \n      \n          \n          \n          
Required attribute<\/th>\n          Description<\/th>\n      <\/tr>\n  <\/thead>\n  
name<\/code><\/td>\n          is a string identifying the Mapping<\/code> (e.g. in diagnostics)<\/td>\n      <\/tr>\n      
prefix<\/code><\/a><\/td>\n          is the URL prefix identifying your resource<\/a><\/td>\n      <\/tr>\n      
service<\/code><\/a><\/td>\n          is the name of the service<\/a> handling the resource; must include the namespace (e.g. myservice.othernamespace<\/code>) if the service is in a different namespace than Emissary<\/td>\n      <\/tr>\n  <\/tbody>\n<\/table>\n
These resources are defined as Kubernetes Custom Resource Definitions. Here’s a simple example that maps all requests to \/httpbin\/<\/code> to the httpbin.org<\/code> web service:<\/p>"},{"title":"Advanced Mapping configuration","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/mappings\/","description":"
Emissary is designed so that the author of a given Kubernetes service can easily and flexibly configure how traffic gets routed to the service. The core abstraction used to support service authors is a mapping, which maps a target backend service to a given host or prefix. For Layer 7 protocols such as HTTP, gRPC, or WebSockets, the Mapping<\/code> resource is used. For TCP, the TCPMapping<\/code> resource is used.<\/p>\n
Emissary must<\/em> have one or more mappings defined to provide access to any services at all. The name of the mapping must be unique.<\/p>"},{"title":"Advanced Mapping configuration","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/mappings\/","description":"
Emissary is designed so that the author of a given Kubernetes service can easily and flexibly configure how traffic gets routed to the service. The core abstraction used to support service authors is a mapping, which maps a target backend service to a given host or prefix. For Layer 7 protocols such as HTTP, gRPC, or WebSockets, the Mapping<\/code> resource is used. For TCP, the TCPMapping<\/code> resource is used.<\/p>\n
Emissary must<\/em> have one or more mappings defined to provide access to any services at all. The name of the mapping must be unique.<\/p>"},{"title":"Advanced Mapping configuration","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/mappings\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/mappings\/","description":"
Emissary is designed so that the author of a given Kubernetes service can easily and flexibly configure how traffic gets routed to the service. The core abstraction used to support service authors is a mapping, which maps a target backend service to a given host or prefix. For Layer 7 protocols such as HTTP, gRPC, or WebSockets, the Mapping<\/code> resource is used. For TCP, the TCPMapping<\/code> resource is used.<\/p>\n
Emissary must<\/em> have one or more mappings defined to provide access to any services at all. The name of the mapping must be unique.<\/p>"},{"title":"Ambassador module defaults","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/defaults\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/topics\/using\/defaults\/","description":"
If present, the ambassador Module<\/code> can define a set of defaults that will automatically be applied to certain resources:<\/p>\n
apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Module<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>ambassador<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>config<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>defaults<\/span>:<\/span>\n<\/span><\/span><\/span>      <\/span>class1<\/span>:<\/span>           <\/span># This is a class. Different resource types will look in different classes.<\/span>\n<\/span><\/span><\/span>        <\/span>key1<\/span>:<\/span> <\/span>value1   <\/span> <\/span># Within a class, you can set different keys.<\/span>\n<\/span><\/span><\/span>        <\/span>key2<\/span>:<\/span> <\/span>value2<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>class2<\/span>:<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>top_key1<\/span>:<\/span> <\/span>value1 <\/span> <\/span># If a key isn't found in a resource's class, the system will look in the<\/span>\n<\/span><\/span><\/span>      <\/span>top_key2<\/span>:<\/span> <\/span>value2 <\/span> <\/span># toplevel defaults dictionary for it.<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
Mapping<\/h3>\n
Currently, only the Mapping<\/code> resource uses the defaults<\/code> mechanism. Mapping<\/code> looks first for defaultable resources in the httpmapping<\/code> class, including:<\/p>"},{"title":"Ambassador module defaults","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/defaults\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/topics\/using\/defaults\/","description":"
If present, the ambassador Module<\/code> can define a set of defaults that will automatically be applied to certain resources:<\/p>\n
apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Module<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>ambassador<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>config<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>defaults<\/span>:<\/span>\n<\/span><\/span><\/span>      <\/span>class1<\/span>:<\/span>           <\/span># This is a class. Different resource types will look in different classes.<\/span>\n<\/span><\/span><\/span>        <\/span>key1<\/span>:<\/span> <\/span>value1   <\/span> <\/span># Within a class, you can set different keys.<\/span>\n<\/span><\/span><\/span>        <\/span>key2<\/span>:<\/span> <\/span>value2<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>class2<\/span>:<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>top_key1<\/span>:<\/span> <\/span>value1 <\/span> <\/span># If a key isn't found in a resource's class, the system will look in the<\/span>\n<\/span><\/span><\/span>      <\/span>top_key2<\/span>:<\/span> <\/span>value2 <\/span> <\/span># toplevel defaults dictionary for it.<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
Mapping<\/h3>\n
Currently, only the Mapping<\/code> resource uses the defaults<\/code> mechanism. Mapping<\/code> looks first for defaultable resources in the httpmapping<\/code> class, including:<\/p>"},{"title":"Ambassador module defaults","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/defaults\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/topics\/using\/defaults\/","description":"
If present, the ambassador Module<\/code> can define a set of defaults that will automatically be applied to certain resources:<\/p>\n
apiVersion<\/span>:<\/span> <\/span>getambassador.io\/v3alpha1<\/span>\n<\/span><\/span><\/span><\/span>kind<\/span>:<\/span>  <\/span>Module<\/span>\n<\/span><\/span><\/span><\/span>metadata<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>name<\/span>:<\/span>  <\/span>ambassador<\/span>\n<\/span><\/span><\/span><\/span>spec<\/span>:<\/span>\n<\/span><\/span><\/span>  <\/span>config<\/span>:<\/span>\n<\/span><\/span><\/span>    <\/span>defaults<\/span>:<\/span>\n<\/span><\/span><\/span>      <\/span>class1<\/span>:<\/span>           <\/span># This is a class. Different resource types will look in different classes.<\/span>\n<\/span><\/span><\/span>        <\/span>key1<\/span>:<\/span> <\/span>value1   <\/span> <\/span># Within a class, you can set different keys.<\/span>\n<\/span><\/span><\/span>        <\/span>key2<\/span>:<\/span> <\/span>value2<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>class2<\/span>:<\/span>\n<\/span><\/span><\/span>        <\/span>...<\/span>\n<\/span><\/span><\/span>      <\/span>top_key1<\/span>:<\/span> <\/span>value1 <\/span> <\/span># If a key isn't found in a resource's class, the system will look in the<\/span>\n<\/span><\/span><\/span>      <\/span>top_key2<\/span>:<\/span> <\/span>value2 <\/span> <\/span># toplevel defaults dictionary for it.<\/span>\n<\/span><\/span><\/span><\/code><\/pre><\/div>
Mapping<\/h3>\n
Currently, only the Mapping<\/code> resource uses the defaults<\/code> mechanism. Mapping<\/code> looks first for defaultable resources in the httpmapping<\/code> class, including:<\/p>"},{"title":"Quick Start","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/quick-start\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/quick-start\/","description":"
We recommend using Helm<\/strong> to install Emissary.<\/p>\n
Installing if you’re starting fresh<\/h3>\n
If you are already running Emissary and just want to upgrade, DO NOT FOLLOW\nTHESE DIRECTIONS.<\/strong> Instead, check out “Upgrading from an earlier Emissary”\nbelow.<\/p>\n
If you’re starting from scratch and you don’t need to worry about older CRD\nversions, install using --set enableLegacyVersions=false<\/code> to avoid install\nthe old versions of the CRDs and the conversion webhook:<\/p>\n
helm install emissary-crds \\\n<\/span><\/span><\/span><\/span> --namespace emissary --create-namespace \\\n<\/span><\/span><\/span><\/span> oci:\/\/ghcr.io\/emissary-ingress\/emissary-crds-chart --version=<\/span>3.10.0 \\\n<\/span><\/span><\/span><\/span> --set enableLegacyVersions<\/span>=<\/span>false<\/span> \\\n<\/span><\/span><\/span><\/span> --wait\n<\/span><\/span><\/code><\/pre><\/div>
This will install only v3alpha1 CRDs and skip the conversion webhook entirely.\nIt will create the emissary<\/code> namespace for you, but there won’t be anything\nin it at this point.<\/p>"},{"title":"Quick Start","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/quick-start\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/quick-start\/","description":"
We recommend using Helm<\/strong> to install Emissary. If you really need to\nwork directly with YAML, use helm template<\/code> to generate the YAML\nmanifests you need.<\/p>\n
Installing Emissary<\/h2>\n
Installing Emissary is a two-step process: first, you install the Custom\nResource Definitions (CRDs) that Emissary uses to configure itself, and\nthen you install Emissary itself. There are two different paths here,\ndepending on whether you’re installing Emissary for the first time, or\nupgrading from an earlier version where you’re using older versions of\nthe CRDs.<\/p>"},{"title":"Quick Start","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/quick-start\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/quick-start\/","description":"
We recommend using Helm<\/strong> to install Emissary. If you really need to\nwork directly with YAML, use helm template<\/code> to generate the YAML\nmanifests you need.<\/p>\n
Installing Emissary<\/h2>\n
Installing Emissary is a two-step process: first, you install the Custom\nResource Definitions (CRDs) that Emissary uses to configure itself, and\nthen you install Emissary itself. There are two different paths here,\ndepending on whether you’re installing Emissary for the first time, or\nupgrading from an earlier version where you’re using older versions of\nthe CRDs.<\/p>"},{"title":"Why Emissary?","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/why-ambassador\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/why-ambassador\/","description":"
Emissary gives platform engineers a comprehensive, self-service edge stack for managing the boundary between end-users and Kubernetes. Built on the Envoy Proxy<\/a> and fully Kubernetes-native, Emissary is made to support multiple, independent teams that need to rapidly publish, monitor, and update services for end-users. A true edge stack, Emissary can also be used to handle the functions of an API Gateway, a Kubernetes ingress controller, and a layer 7 load balancer (for more, see this blog post<\/a>).<\/p>"},{"title":"Why Emissary?","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/about\/why-ambassador\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/about\/why-ambassador\/","description":"
Emissary gives platform engineers a comprehensive, self-service edge stack for managing the boundary between end-users and Kubernetes. Built on the Envoy Proxy<\/a> and fully Kubernetes-native, Emissary is made to support multiple, independent teams that need to rapidly publish, monitor, and update services for end-users. A true edge stack, Emissary can also be used to handle the functions of an API Gateway, a Kubernetes ingress controller, and a layer 7 load balancer (for more, see this blog post<\/a>).<\/p>"},{"title":"Why Emissary?","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/about\/why-ambassador\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/about\/why-ambassador\/","description":"
Emissary gives platform engineers a comprehensive, self-service edge stack for managing the boundary between end-users and Kubernetes. Built on the Envoy Proxy<\/a> and fully Kubernetes-native, Emissary is made to support multiple, independent teams that need to rapidly publish, monitor, and update services for end-users. A true edge stack, Emissary can also be used to handle the functions of an API Gateway, a Kubernetes ingress controller, and a layer 7 load balancer (for more, see this blog post<\/a>).<\/p>"},{"title":"Features and Benefits","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/features-and-benefits\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/features-and-benefits\/","description":"
In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).<\/p>\n
As such, the Emissary is designed to be used by both developers and operators.<\/p>\n
Self-Service via Kubernetes Annotations<\/h2>\n
Emissary is built from the start to support self-service<\/em> deployments – a developer working on a new service doesn’t have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.<\/p>"},{"title":"Features and Benefits","link":"https:\/\/emissary-ingress.dev\/docs\/4.0\/about\/features-and-benefits\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.0\/about\/features-and-benefits\/","description":"
In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).<\/p>\n
As such, the Emissary is designed to be used by both developers and operators.<\/p>\n
Self-Service via Kubernetes Annotations<\/h2>\n
Emissary is built from the start to support self-service<\/em> deployments – a developer working on a new service doesn’t have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.<\/p>"},{"title":"Features and Benefits","link":"https:\/\/emissary-ingress.dev\/docs\/4.1\/about\/features-and-benefits\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/4.1\/about\/features-and-benefits\/","description":"
In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).<\/p>\n
As such, the Emissary is designed to be used by both developers and operators.<\/p>\n
Self-Service via Kubernetes Annotations<\/h2>\n
Emissary is built from the start to support self-service<\/em> deployments – a developer working on a new service doesn’t have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.<\/p>"},{"title":"Frequently Asked Questions","link":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/faq\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/emissary-ingress.dev\/docs\/3.10\/about\/faq\/","description":"
General<\/h2>\n
Why Emissary?<\/h3>\n
Kubernetes shifts application architecture for microservices, as well as the\ndevelopment workflow for a full-cycle development. Emissary is designed for\nthe Kubernetes world with:<\/p>\n
Emissary is designed around a declarative, self-service management model<\/a>. The core resource used to support application development teams who need to manage the edge with Emissary is the Mapping<\/code> resource.<\/p>\n\n  Remember that Listener<\/code> and Host<\/code> resources are\n   required<\/b> for a functioning Emissary installation that can route traffic!\n  Learn more about Listener<\/code><\/a>.\n  Learn more about Host<\/code><\/a>.\n<\/Alert>\n
The remove_response_headers<\/code> attribute<\/h2>\n
The remove_response_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n
The remove_response_headers<\/code> attribute<\/h2>\n
The remove_response_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n
The remove_response_headers<\/code> attribute<\/h2>\n
The remove_response_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n
The remove_request_headers<\/code> attribute<\/h2>\n
The remove_request_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n
The remove_request_headers<\/code> attribute<\/h2>\n
The remove_request_headers<\/code> attribute takes a list of keys used to match to the header.<\/p>\n
remove_request_headers<\/code> can be set either in a Mapping<\/code> or using ambassador Module defaults<\/code><\/a>.<\/p>\n