An ingress is the main point of entry to your cluster from the public internet. By default, ReleaseHub 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.
You can customize exactly how specific situations are handled by setting
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.
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.
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.