Configuring Ingress Endpoints
The previous steps explain how to install Arize and access the UI with a local port-forward. However to expose Arize to the broader organization, a secure HTTPs endpoint must be created.
arize-app.<my-organization-domain>
/
internalendpoints-app
443
Ingress Endpoints with GCP
First review the Terraform documentation in ./terraform/README.md
as it includes parameters
required to create static IP addresses. Re-apply the Terraforms if necessary. Static IP addresses
are preferred as they allow a future rebuild of the cluster without impacting DNS entries.
Make a copy of the example file below.
Review the following annotation to confirm that they align with the desired static IPs. If using the provided terraforms, these names already align with the name specified in terraform.
Replace the placeholder hostname/domain name with the domain available in your organization. This domain name must be added to your DNS server and map to the static IP addresses mentioned above.
If configured correctly, the DNS server will resolve the domain to the correct IP address.
Use nslookup
to verify.
Apply the manifest.
Wait for a few minutes and verify the state of the ingress.
The ingressMode
parameter may need to be set correctly in values.yaml
in order to work
with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in
the Ingress Controllers
section.
From a web browser enter https://arize-app.<my-organization-domain>
to verify the access. Note
that GCP may initially return an SSL error until the HTTPs certificate has been validated.
If that is the case, check back 30 minutes later. Make sure to add these parameters tovalues.yaml
and apply the changes.
Ingress Endpoints with AWS
Since TLS termination is required, a Layer 7 ALB is the recommended option for AWS. The ALB can be created automatically by AWS when a Kubernetes Ingress resource is created and the AWS Load Balancer Controller is deployed.
A few notes about the AWS Load Balancer Controller:
It requires public networks, Internet Gateway and routes in order to get an external IP.
Private subnets need the label "kubernetes.io/role/internal-elb" for subnet discovery
Public subnets need the label "kubernetes.io/role/elb" for subnet discovery
Make a copy of the example file below.
Edit the following annotations. For a public endpoint use "internet-facing". Change the certificate annotation to point to a valid certificate.
Apply the manifest.
Wait for a few minutes and verify the state of the ingress.
The ingressMode
parameter may need to be set correctly in values.yaml
in order to work
with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in
the Ingress Controllers
section.
In some environments the external-dns.alpha.kubernetes.io/hostname
annotation can be used to
automatically create a DNS entry in Route 53. If another DNS system is used, collect the elb
address from the ingress resource and request a DNS entry to be added mapping arize-app.<my-organization-domain>
to the elb address.
If configured correctly, the DNS server will resolve the domain to the correct IP address.
Use nslookup
to verify.
From a web browser enter https://arize-app.<my-organization-domain>
to verify the access.
Make sure to add these parameters to values.yaml
and apply the changes.
Ingress Endpoints with Azure
The Azure AGIC does not currently support GRPC. For this reason Arize recommends using a Network Load Balancer and terminate TLS at the Arize pods.
Make a copy of the example files below and review its content.
Apply the manifest.
Wait for a few minutes and verify the state of the service.
Create a DNS entry pointing your desired domain/hostname (example: arize-app.<my-organization-domain>
) to the IP address of the Network Load Balancer. If using self-signed certificates or a certificate is not available, create a certificate corresponding to your domain using:
Load the signed or self-signed certificate into Arize by updating values.yaml
:
The ingressMode
parameter may need to be set correctly in values.yaml
in order to work
with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in
the Ingress Controllers
section.
From a web browser enter https://arize-app.<my-organization-domain>
to verify the access.
Make sure to add these parameters to values.yaml
and apply the changes.
Ingress Endpoints with OpenShift
The OpenShift ingress controller configures an underlying HAProxy component. For proper GRPC operation certain settings on the OpenShift routes are required. Additionally, to enable HTTP/2 support, the following command should be executed for the target Ingress Controller (either a specific one or the default). This annotation can also be applied via the console UI's under Administration -> CustomResourceDefinitions -> IngressController -> Instances -> default. If HTTP/2 is not enabled, gRPC clients may encounter errors such as: Cannot check peer: missing selected ALPN property* or *Selected ALPN Protocol: None.
In the values.yaml
file, the Arize ingressMode
should be set to openshift
. Important: This configuration must be applied before creating any routes, as OpenShift references the resulting appProtocol on the Arize ports during route creation. Specifically, for internal HTTP/2 ports, the appProtocol is set to h2c, indicating the use of HTTP/2 without TLS.
From the OpenShift console UI as an Administrator use Create Route
from the Networking/Routes panel and enter the following data in the arize namespace Project to create the endpoints. Use Secure Route enabled
and TLS termination Edge
on each route. OpenShift does not allow a wildcard certificate with GRPC/HTTP2 protocols and therefore it is recommend to create a non-wildcard certificate on the arize-app
route or to create second arize-api
for API functions.
arize-app.<my-organization-domain>
/
internalendpoints-app
443
Wildcard or non-wildcard
arize-api.<my-organization-domain>
/
internalendpoints-app
443
Non-wildcard
If using TLS termination Edge
is not an option, a fallback method is to use a single passthrough
route and mount the certificate at the pods using these parameters:
Ingress Controllers
For GRPC protocols like OTLP and flightserver, the ingressMode
parameter may need to be set correctly in values.yaml
in order to work with certain ingress controllers or if a user desires to port-forward to the service for testing.
Here are the recommended settings:
Controller / Load Balancer
ingressMode
internalEndpointsAppTlsCert / internalEndpointsAppTlsKey
GCP
tls (default)
N/A
AWS ALB
tls (default)
N/A
Azure NLB
tls (default)
Custom certificate
Istio
istio
N/A
OpenShift - Edge
openshift
N/A
OpenShift - Pass-through
tls
Custom certificate
Local port-forward
notls
N/A
TLS Termination at Arize Pods (NLB)
tls
Custom certificate
More details on working with an OpenShift ingress controller are found in the OpenShift sections.
Last updated
Was this helpful?