Ingresses
An ingress is the main point of entry to your cluster from the public internet. By default, Release configures an Nginx ingress for your cluster, and in many cases, you can use it with the default settings. For advanced cases, you can configure your ingress in your Application Template file, along with your other environment settings.
Some common cases where you might need to configure your ingress manually include:
- Setting specific cookie configuration, such as expiration times.
- Setting affinity sessions or "stickiness" to ensure visitors are predictably served by the same nodes.
- Changing the default buffer sizes and timeout parameters to serve larger files.
Usually, incoming requests are served by any available node. This means that subsequent requests by the same visitor might be served by different nodes. For many applications, this doesn't matter, as all nodes are running exactly the same application code. If you perform A/B testing or are rolling out a feature gradually to all users, it might be important that users have a consistent experience, even across multiple visits.
In these cases, you can configure affinity in your ingress settings. This creates a pairing between unique visitors and specific nodes by setting a random cookie for each new visitor. Returning visitors will automatically share the cookie along with their request, and your ingress will direct them to the same node they were previously served by.
In the diagram below, the visitor automatically sends the previously randomly generated cookie on their second visit, allowing the ingress to say they should be served by node 1 again.
Affinity cookie
You can customize exactly how specific situations are handled by setting
affinity_mode to either balanced or persistent. If you are too strict about always assigning users to specific nodes, you can lose the advantages of running a cluster in the first place. For example, the node might be down or overloaded. By using balanced, some users might be reassigned to other nodes if the cluster is scaled up. By using persistent, users will always be given their assigned node until the cookie expires.An example of setting up your ingress with cookie-based affinity is shown below, which will ensure that all users are served by the same node for 24 hours. If a request fails, then the affinity will be ignored and the user will be served by a healthy node.
ingress:
affinity: "cookie"
affinity_mode: "persistent"
session_cookie_name: "custom-cookie-name"
session_cookie_path: "/"
session_cookie_max_age: 86440
session_cookie_change_on_failure: true
By default, the ingress is optimized to serve many smaller files to many different users. This works well for most web applications that consist of many pages and other resources such as JavaScript, CSS, and images. If your application serves larger files, you'll probably want to configure the ingress buffers and timeouts.
With larger buffers, the ingress will do more of the work, buffering data received from the application. This means that you can serve your users in fewer total requests, but with the tradeoff of putting more stress on the hardware responsible for your ingress.
An example of an ingress configured to serve larger web requests is shown below.
ingress:
proxy_body_size: 30m
proxy_buffer_size: 64k
proxy_buffering: true
proxy_buffers_number: 4
proxy_max_temp_file_size: 1024m
proxy_read_timeout: "180"
proxy_send_timeout: "180"
This creates a larger temporary file, so that the ingress can store data locally even if the buffer sizes are exceeded. It also sets longer timeouts of three minutes, and creates more buffers to read the initial parts of the response from the application servers.
Last modified 3mo ago