NGINX Ingress Controller Configuration
If you use NGINX as an ingress controller and the datasource agent reports a HTTP 413 error message, it is likely that NGINX is limiting the datasource traffic. Increase the allowed maximum body size by adding
nginx.org/client-max-body-size: "50m" to the Ingress.
For more information about NGINX body size limit, see github.com/nginxinc/kubernetes-ingress#21.
Configure a Second Ingress
When dealing with a large amount of traffic, it can be helpful to scale the inbound DAS
gateway service. Generally, Styra recommends doing so by increasing the number of replicas
gateway Deployment, as the corresponding Service will automatically distribute traffic between the available Pods. Some customers have, however, expressed a desire to
have traffic related to OPA status and discovery be handled by a different inbound URL than all other DAS traffic. To make this possible, there are options in
values.yaml that allow
the user to deploy a secondary ingress.
The secondary ingress feature is only recommended when the customer requires that status and discovery traffic be handled by a secondary DAS URL. Please consult your Customer Architect when determining if this feature is necessary for your use case.
The following moficiations to
values.yaml are required to enable a secondary ingress:
- Set the value of
featureFlags.custom.SECONDARY_INGRESS_URLto the desired Fully Qualified Domain Name (FQDN) or IP address
values.yaml configuration should resemble the following:
# add secondary ingress gateway to report status and discovery
# the k8s service can be configured via `gatewaySecondary`
In addition, the customer must make sure to configure the desired DNS record with their DNS registrar of choice.
Use a NodePort as Ingress
If you have issues in configuring a load balancer or Ingress, then you can change the
gateway-public service to use a
NodePort type within
- name: http
Be sure to set the
ingress_url value in
settings.yaml appropriately for your
NodePort service configuration, for example,