Use a third-party ingress controller
Use a third-party ingress controller
Use a third-party ingress controller
By default, Astro Private Cloud comes built-in with a default ingress controller to provide access to Astro services running in the cluster. The default ingress controller can co-exist with any other ingress controllers on the cluster.
Using the default ingress controller is the best choice for most organizations, but you might need to use a pre-existing ingress controller exclusively due to regulatory and compliance requirements. This guide provides steps for configuring your own ingress controller to use with the Astronomer platform.
To use a third-party ingress-controller with Astro Private Cloud:
*.{BASE_DOMAIN} or the following specific hostnames:Control Plane components
app.BASE_DOMAINdeployments.BASE_DOMAINhouston.BASE_DOMAINgrafana.BASE_DOMAINprometheus.BASE_DOMAINalertmanager.BASE_DOMAINData Plane components
<Dataplane_Prefix>.BASE_DOMAINregistry.<Dataplane_Prefix>.BASE_DOMAINcommander.<Dataplane_Prefix>.BASE_DOMAINprometheus.<Dataplane_Prefix>.BASE_DOMAINprom-proxy.<Dataplane_Prefix>.BASE_DOMAINelasticsearch.<Dataplane_Prefix>.BASE_DOMAINFor a control mode installation:
app.BASE_DOMAINhouston.BASE_DOMAINgrafana.BASE_DOMAINprometheus.BASE_DOMAINFor a data mode installation:
deployments.DOMAIN_PREFIX.BASE_DOMAINregistry.DOMAIN_PREFIX.BASE_DOMAINprometheus.DOMAIN_PREFIX.BASE_DOMAINelasticsearch.DOMAIN_PREFIX.BASE_DOMAINIf the certificates of the third-party ingress controller are signed by a private certificate authority:
If a private certificate authority is used to sign the certificate contained in the global.tlsSecret value in your values.yaml file, the third-party ingress controller must recognize the CA signing global.tlsSecret as valid. Typically, this is done by either:
global.tlsSecret with a private CA that’s already trusted by the custom ingress controller (typically the same CA used to sign the certificates being used by the ingress controller).global.tlsSecret.To complete this setup, you need to supply your own ingress controller. Astronomer fully supports the following ingress controllers:
If you want to use an ingress controller that isn’t listed here, contact your Astronomer representative.
If not using OpenShift, skip this step.
OpenShift’s standard ingress controller restricts hostname use to a single namespace, which isn’t a compatible setting with Astro Private Cloud. You can disable this setting for the default IngressController instance using the following command:
Alternatively, see Use OpenShift Ingress Sharding to create an additional Ingress instance with the required routeAdmission policy. For more information, including information about security implications for multi-tenant clusters, see the OpenShift Ingress operator documentation.
OpenShift clusters with multi-tenant isolation enabled need to explicitly allow traffic from the ingress controller’s namespace to services associated with ingresses in other namespaces.
Additionally, you must configure Astronomer to explicitly declare the SSL termination policy for the ingress resources it manages.
To do so, add the following configuration to your values.yaml file:
Don’t deploy this change at this time as later steps of this document walk you through making additional required changes to values.yaml.
Only Ingress objects with the annotation route.openshift.io/termination: "edge" are supported for generating routes in OpenShift 4.11 and later. Other termination types are no longer supported for automatic route generation.
If you’re on an older version of OpenShift, route creation should be done manually.
For more information, see the OpenShift documentation on configuring network policy.
astronomer-tls secret for replicationMost third-party ingress controllers require the secret name to be replicated into each Airflow namespace. This name can be custom-set in your global configs, but the following examples use the secretName, astronomer-tls.
Annotate the secret and set "astronomer.io/commander-sync" to platform=<astronomer platform release name>. For example:
Enable authSidecar and disable the Astronomer integrated ingress controller.
If you’re using an nginx ingress controller, add the following configuration to your values.yaml file:
This setting disables Nginx’s maximum allowed upload size, which prevents HTTP 413 (Request Entity Too Large) error and allows the Astro CLI to properly deploy Dags to Astro Private Cloud’s internal registry.
If you’re using a Traefik ingress controller, add the following configuration to your values.yaml file:
Depending on the version of Traefik, upgrading from using the default ingress controller to a Traefik controller might cause issues. If you are upgrading a platform that used the built-in ingress controller, manually delete the Astronomer Platform Ingress objects in the Astronomer Platform namespace before updating your values.yaml file. You can do so using the following commands:
Contour ships with support for WebSockets disabled by default. To use a Contour ingress controller, explicitly enable WebSocket support for the APC API’s /ws prefix by creating an HTTPProxy object in the Astronomer platform namespace. To do so:
Create a file named proxy.yaml and add the following to it:
Apply the file to your platform namespace:
Depending on the version of Contour, upgrading from using the default ingress controller to a Contour controller might cause issues. If you are upgrading a platform that used the built-in ingress controller, manually delete the Astronomer Platform Ingress objects in the Astronomer Platform namespace before updating your values.yaml file. You can do so using the following commands:
See Required Environment Configuration for OpenShift.
If performing a new installation, skip this step and don’t apply changes until the install guide instructs you to do so.
If this is an existing installation, apply your updated configuration using the following command: