.. _deployment_to_kubernetes:

Deployment to Kubernetes
=========================

The ``ska-oso-oet`` Helm chart will deploy the application with environment variables from a ConfigMap and an
Ingress rule.

The ``ska-oso-oet-umbrella`` Helm chart will deploy the ``ska-oso-oet`` chart and all its dependencies, namely the ODA and SKUID.

To deploy the charts, the standard SKAO make targets are used - for example ``make k8s-install-chart``

Support for multiple subarrays
--------------------------------

The OET is designed so that an instance is deployed for each subarray. The application requires the ``SUBARRAY_ID`` environment
variable to be set, and then the OET instance is fixed to only execute an observation against that subarray.

The OET chart will deploy as many instances as the Helm value ``global.subarray_count`` specifies. For each subarray, the chart deploys
a StatefulSet with the ``SUBARRAY_ID`` environment variable, a Service and an Ingress rule. The OET API URL includes the subarray ID
and requests are then routed to the correct OET instance matching this URL in the Ingress rules.

ODA Connection and Secret Management
-------------------------------------

The application uses the ``PGPASSWORD`` environment variable which is injected in the chart from a Kubernetes
Secret. The Secret resource should pull the value from Vault on creation, using the standard VaultStaticSecret.

By default, the ``ska-oso-oet`` chart will create a Secret that contains the ODA password for use by the application, without
the need for any user configuration.

To use a different Secret, set the ``.Values.global.oda.postgres.secret.existingSecret`` value with the Secret name.

See :doc:`configuration` for more details on the ODA connection.

Using a Secret for the full Postgres connection
................................................

The chart is configured in such a way that it pulls the ``PG_`` environment variables from a ConfigMap and the ``PGPASSWORD`` from a Secret (as the host, etc
are dynamic and can't be pulled from Vault).

However, if the ``ska-oso-oet`` application is connecting to an externally managed Postgres, and a Secret is available in the namespace with the full ``PG_``
variables, these will be taken over the ConfigMap if the Secret is passed via ``.Values.global.oda.postgres.secret.existingSecret``.