> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/dataos-operator/provision-data-plane/azure-ui.md).

# Azure (UI)

Use the guided Provision BYOC Dataplane flow in the DataOS UI to provision a Data Plane on an existing Azure Kubernetes Service (AKS) cluster. Complete five short screens, and then DataOS assembles, validates, and applies the Data Plane configuration.

To create a Data Plane through the DataOS CLI, follow the [Azure provisioning guide](/operate/v1/dataos-operator/provision-data-plane/azure.md).

## Before you begin

You need an existing DataOS Instance and Super User and Operator access to the Tenant where you want to provision the Data Plane.

{% hint style="info" %}
The provisioning flow installs DataOS onto infrastructure that already exists. You provision the Kubernetes cluster, the PostgreSQL server, and the databases; the flow collects the connection and access details it needs to use them. Your cloud infrastructure team typically owns the cluster, node pools, and PostgreSQL server, so confirm with them before you continue.
{% endhint %}

## Provision the Data Plane

1. Sign in to your DataOS Instance.
2. Go to **Instance Admin → Dataplanes**.
3. Select **+ Provision Dataplane**.

The provisioning wizard consists of the following steps:

1. [Prerequisites](#id-1-prerequisites)
2. [Identity](#id-2-identity)
3. [Cluster Access](#id-3-cluster-access)
4. [Node Pool](#id-4-node-pool)
5. [PostgreSQL](#id-5-postgresql)

Use **Next** and **Back** to navigate between the steps. The Data Plane is not created until you select **Create Dataplane** on the final step.

### 1. Prerequisites

The first screen provides a checklist of the infrastructure and access required to provision the Data Plane. Ensure that the following are available before continuing.

#### Kubernetes cluster

* A dedicated Kubernetes cluster to host the Data Plane.
* Administrative access to the cluster.
* Sufficient node-pool capacity for the DataOS components.
* A kubeconfig for the cluster.

The kubeconfig must be Base64-encoded before you provide it in the [Cluster Access](#id-3-cluster-access) step.

{% hint style="warning" %}
**Security.** Treat the kubeconfig as a sensitive infrastructure credential. Do not commit it to source control or share it through unsecured channels. Use your organization's approved secret-management mechanism to store and manage it.
{% endhint %}

<details>

<summary>Generate the kubeconfig</summary>

If you already have a valid kubeconfig with the required cluster access, you can use it directly.

For an AKS cluster, use the Azure CLI to write cluster credentials into your kubeconfig.

1. Sign in and select your subscription:

```bash
az login
az account set --subscription <subscription-id>
```

2. Fetch the cluster credentials:

```bash
az aks get-credentials --resource-group <resource-group> --name <cluster-name> --admin
```

The `--admin` flag writes a non-interactive kubeconfig, so the DataOS Instance can reach the AKS API without an interactive login.

3. Verify that the resulting kubeconfig can access the cluster:

```bash
kubectl get nodes
```

</details>

<details>

<summary>Encode the kubeconfig</summary>

Encode the kubeconfig as a single-line Base64 value before pasting it into the UI.

kubectl config view --minify --flatten | base64 | tr -d '\n'kubectl config view --minify --flatten | base64 -w 0\[Convert]::ToBase64String(  \[Text.Encoding]::UTF8.GetBytes(    (kubectl config view --minify --flatten | Out-String)  ))

</details>

#### PostgreSQL

Provide an existing PostgreSQL server with the required databases already created. The current flow requires two databases:

* **System Health database:** used for Data Plane health tracking.
* **Vesta database:** used as the Vesta state store.

Keep the connection details and the credentials for both databases ready. You provide them in [Step 5](#id-5-postgresql).

Select **Next**.

### 2. Identity

Define the identity of the Data Plane.

* **Data Plane ID:** The stable identifier for the Data Plane across DataOS.
  * Required. Maximum 30 characters.
  * Must remain stable after creation. It generates Data Plane domain names.
  * Use `<instance-name>-<purpose>-dp-01`, such as `pacific-azure-dp-01`.
* **Description:** A short description of the Data Plane's purpose or environment.
  * Required. Maximum 200 characters.
  * Example: `Production Data Plane for the analytics environment`.

{% hint style="warning" %}
Choose the Data Plane ID carefully. According to the current provisioning flow, the ID is permanent and cannot be changed after creation because it is used to generate Data Plane domain names.
{% endhint %}

Select **Next**.

### 3. Cluster Access

Provide the information required for DataOS to access your existing Kubernetes cluster.

* **Cloud Service Provider:** `Azure`.
* **Network Type:** `Tunnel`. Fixed and not editable. The Data Plane establishes an outbound encrypted connection to the DataOS Instance, so this flow requires no inbound connection to the cluster.
* **Kubeconfig:** The Base64-encoded kubeconfig prepared in [Step 1](#id-1-prerequisites).

Select **Next**.

### 4. Node Pool

Specify the node selector labels used to schedule DataOS components on the appropriate nodes.

The default selector is:

* **`dataos.io/purpose`:** `core-kernel`

Keep this selector unchanged unless your DataOS deployment requirements specify otherwise. The DataOS installer uses this selector when scheduling the core kernel components. If the selector does not match the labels available on the target nodes, the affected pods may remain in the `Pending` state.

If your cluster requires additional selector labels, use **+ Add** to provide them.

Select **Next**.

### 5. PostgreSQL

Provide the connection details for the PostgreSQL server, then the name, username, and password for each of the two databases from [Step 1](#id-1-prerequisites).

* **Connection:** Host and Port. Port defaults to `5432`.
* **System Health database:** Database Name, Username, and Password.
* **Vesta database:** Database Name, Username, and Password.

Select **Create Dataplane** to start provisioning.

***

## What happens during provisioning

After you submit the configuration, DataOS validates the submitted information and starts the Data Plane installation.

The current provisioning flow performs the following operations:

1. The DataOS Instance uses the supplied kubeconfig to establish access to the Kubernetes API and installs `dataos-manager` on the cluster.
2. `dataos-manager` retrieves the required installation manifests and installs the DataOS components.
3. A tunnel client running in the cluster establishes an outbound encrypted connection to the DataOS Instance through the configured network path.
4. Once the connection is established, the DataOS Instance registers and manages the Data Plane through the tunnel.

The kubeconfig is used for the DataOS Instance-to-cluster management path and is not part of Data Plane data traffic.

## Verify the Data Plane

After provisioning starts, the Data Plane appears on the Dataplanes page with its current provisioning status.

You can also verify the Data Plane using the CLI:

```bash
dataos-ctl domain get -a
```

{% hint style="info" %}
If the output shows <mark style="color:$success;">`workpiece-forge-kernel: success`</mark>, the infrastructure setup is complete.
{% endhint %}

For deeper installation troubleshooting, inspect the `dataos-manager` logs from the Kubernetes cluster:

```bash
kubectl logs -n <instance_name>-0-dsm dataos-manager-0 -f
```

***

## Troubleshooting

<details>

<summary>Authentication or cluster-access failure</summary>

If provisioning fails because the DataOS Instance cannot access the Kubernetes cluster:

* Verify that the kubeconfig is valid and has not expired.
* Confirm that the associated identity has the required Kubernetes RBAC permissions.
* Regenerate the kubeconfig with `az aks get-credentials --admin` and re-encode it as Base64.
* Verify that the Kubernetes API endpoint is reachable from the DataOS Instance. In production the AKS API server is often restricted to authorized IP ranges.

</details>

<details>

<summary>Kubeconfig validation fails</summary>

The provisioning flow expects a Base64-encoded kubeconfig, not the raw YAML file.

Regenerate the encoded value using the command in [Step 1](#id-1-prerequisites) and ensure that the value is pasted without unintended line breaks.

</details>

<details>

<summary>Pods remain <code>Pending</code></summary>

Verify that:

* The target nodes have the required `dataos.io/purpose: core-kernel` label.
* The node pool has sufficient capacity.
* The configured node selectors match the labels on the target nodes.

</details>

<details>

<summary>Tunnel does not establish</summary>

Outbound egress to the Cloudflare tunnel edge is blocked, or DNS resolution is failing. The tunnel connects to `region1.v2.argotunnel.com` and `region2.v2.argotunnel.com` on port `7844`: UDP (QUIC) primary, TCP `7844` as fallback. If your firewall uses TLS inspection or SNI-based filtering, allow the SNI hostname pattern `*.cftunnel.com`. The tunnel client retries automatically once egress is restored.

</details>

<details>

<summary>Database connection errors</summary>

Confirm that both databases already exist on the PostgreSQL server, that the supplied users can connect to them, and that the AKS cluster's egress reaches the host and port.

</details>

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/v1/dataos-operator/provision-data-plane/azure-ui.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.