--- title: "Install YugabyteDB Anywhere" url: "https://docs.yugabyte.com/stable/yugabyte-platform/install-yugabyte-platform/install-software/kubernetes/" --- # Install YugabyteDB Anywhere Install YugabyteDB Anywhere software in your Kubernetes environment. Install YugabyteDB Anywhere in a Kubernetes environment For higher availability, you can install additional YugabyteDB Anywhere instances, and configure them later to serve as passive warm standby servers. See [Enable High Availability](/stable/yugabyte-platform/administer-yugabyte-platform/high-availability/ "Enable High Availability") for more information. - [On-premises and public clouds](/stable/yugabyte-platform/install-yugabyte-platform/install-software/installer/) - [Kubernetes](/stable/yugabyte-platform/install-yugabyte-platform/install-software/kubernetes/) For information on installing YugabyteDB Anywhere on OpenShift, refer to [Install YugabyteDB Anywhere on OpenShift](/stable/yugabyte-platform/install-yugabyte-platform/install-software/openshift/ "Install YugabyteDB Anywhere on OpenShift"). For information on using the YugabyteDB Kubernetes Operator to install YugabyteDB Anywhere and manage universes, refer to [YugabyteDB Kubernetes Operator](/stable/yugabyte-platform/anywhere-automation/yb-kubernetes-operator/ "YugabyteDB Kubernetes Operator"). ## Install YugabyteDB Anywhere You install YugabyteDB Anywhere on a Kubernetes cluster as follows: 1. Create a namespace by executing the following `kubectl create namespace` command: ```sh kubectl create namespace yb-platform ``` 2. Apply the YugabyteDB Anywhere secret that you obtained from Yugabyte Support by running the following `kubectl create` command: ```sh kubectl create -f yugabyte-k8s-secret.yml -n yb-platform ``` Expect the following output notifying you that the secret was created: ```output secret/yugabyte-k8s-pull-secret created ``` 3. Run the following `helm repo add` command to clone the [YugabyteDB charts repository](https://charts.yugabyte.com/ "YugabyteDB charts repository"): ```sh helm repo add yugabytedb https://charts.yugabyte.com ``` A message similar to the following should appear: ```output "yugabytedb" has been added to your repositories ``` To search for the available chart version, run the following command: ```sh helm search repo yugabytedb/yugaware --version 2026.1.2 ``` The latest Helm chart version and application version is displayed via the output similar to the following: ```output NAME CHART VERSION APP VERSION DESCRIPTION yugabytedb/yugaware 2026.1.2 2026.1.2.0-b137 YugaWare is YugaByte Database's Orchestration a... ``` 4. Run the following `helm install` command to install the YugabyteDB Anywhere (`yugaware`) Helm chart: ```sh helm install yw-test yugabytedb/yugaware --version 2026.1.2 -n yb-platform --wait ``` You can enable TLS by following instructions provided in [Configure TLS](#configure-tls "Configure TLS"). 5. Use the following command to check the service: ```sh kubectl get svc -n yb-platform ``` The following output should appear: ```output NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE yw-test-yugaware-ui LoadBalancer 10.111.241.9 34.93.169.64 80:32006/TCP,9090:30691/TCP 2m12s ``` 6. Use the following command to check that all the pods have been initialized and are running: ```sh kubectl get pods -n yb-platform ``` The following output should appear: ```output NAME READY STATUS RESTARTS AGE yw-test-yugaware-0 4/4 Running 0 12s ``` Note that even though the preceding output indicates that the `yw-test-yugaware-0` pod is running, it does not mean that YugabyteDB Anywhere is ready to accept your queries. If you open the load balancer IP `34.93.169.64:80` and see an error (such as 502), it means that `yugaware` is still being initialized. You can check readiness of `yugaware` by executing the following command: ```sh kubectl logs --follow -n yb-platform yw-test-yugaware-0 yugaware ``` An output similar to the following would confirm that there are no errors and that the server is running: ```output [info] AkkaHttpServer.scala:447 [main] Listening for HTTP on /0.0.0.0:9000 ``` If YugabyteDB Anywhere fails to start for the first time, verify that your system meets the installation requirements, as per [Hardware requirements (Kubernetes)](/stable/yugabyte-platform/prepare/server-nodes-hardware/ "Hardware requirements (Kubernetes)"). See [Install and upgrade issues on Kubernetes](/stable/yugabyte-platform/troubleshoot/install-upgrade-issues/kubernetes/ "Install and upgrade issues on Kubernetes") to troubleshoot the problem. ## Customize YugabyteDB Anywhere You can customize YugabyteDB Anywhere on a Kubernetes cluster in a number of ways, such as by specifying the values on CLI or passing a YAML file to the `helm install` command, as follows: ```sh helm install yw-test yugabytedb/yugaware \ --version 2026.1.2 \ -n yb-platform \ --values yba-values.yaml \ --wait ``` You can copy the preceding code block into a file called `yba-values.yaml` and then install YugabyteDB Anywhere using this command. Alternatively, you can pass the values using the `--set key=value` flag. For more information, see [Customizing the chart before installing](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing "Customizing the chart before installing"). It is recommend to use a values file and store it in a version control system. If you are looking for a customization which is not listed, you can view all the supported options and their default values by running the `helm show values yugabytedb/yugaware --version 2026.1.2` command and copying the specific section to your own values file. Do not change useYugabyteDB When customizing the Helm chart, note that `useYugabyteDB` should always be set to `false`. *This is the chart default and must not be changed*. ### Customize the creation of an internal service account By default, the Helm chart will attempt to create a service account that has certain ClusterRoles listed [here](https://github.com/yugabyte/charts/blob/master/stable/yugaware/templates/rbac.yaml#L166 "here"). These roles are used to do the following: 1. Enable YugabyteDB Anywhere to collect resource metrics such as CPU and memory from the Kubernetes nodes. 2. Create YugabyteDB deployments in new namespaces. To customize this behavior (and potentially lose some functionality), you can set the `serviceAccount` value to a pre-existing service account that you've already created. It is recommended that you at least grant this service account the cluster roles listed in the "required to scrape" section of the [RBAC configuration file](https://github.com/yugabyte/charts/blob/master/stable/yugaware/templates/rbac.yaml#L166 "RBAC configuration file"), along with a namespace admin role. To completely disable this behavior, set the `rbac.create` value to false. Note that without the ability to create new namespaces, YugabyteDB Anywhere must be [configured with a pre-created namespace](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/#configure-region-and-zones "configured with a pre-created namespace"). ### Specify custom container registry If you have pushed the container images to a custom registry as mentioned in [Pull and push YugabyteDB Docker images to private container registry](/stable/yugabyte-platform/prepare/server-nodes-software/software-kubernetes/#pull-and-push-yugabytedb-docker-images-to-private-container-registry "Pull and push YugabyteDB Docker images to private container registry"), set the registry address, as follows: ```yaml # yba-values.yaml image: commonRegistry: "gcr.io/mycustomregistry" ``` If the registry requires authentication, then create a pull secret and pass the name as follows: ```yaml # yba-values.yaml image: commonRegistry: "gcr.io/mycustomregistry" pullSecret: "mycustomregistry-pull-secret" ``` ### Configure load balancer By default, a load balancer is created to enable access to YugabyteDB Anywhere. You can configure an internal load balancer, configure a DNS name, or disable the load balancer altogether. #### Disable the load balancer To access YugabyteDB Anywhere by other means (such as port-forwarding, different gateway or ingress solutions, and so on) you can disable the load balancer by changing the service type to `ClusterIP`, as follows: ```yaml # yba-values.yaml yugaware: # other values… service: type: "ClusterIP" ``` If you plan to access YugabyteDB Anywhere via port-forwarding, you need to set `tls.hostname`, as follows: ```yaml # yba-values.yaml tls: hostname: "localhost:8080" ``` For more information, see [Set a DNS name](#set-a-dns-name "Set a DNS name"). Use the kubectl `port-forward` command to access the interface locally, as follows: ```sh # For TLS. Available at https://localhost:8080 kubectl port-forward -n yb-platform svc/yw-test-yugaware-ui 8080:443 # For non-TLS. Available at http://localhost:8080 kubectl port-forward -n yb-platform svc/yw-test-yugaware-ui 8080:80 ``` #### Set up an internal load balancer You can add annotations to the YugabyteDB Anywhere service to create an internal load balancer instead of a publicly-accessible one. Because every cloud provider has different annotations for doing this, refer to the following documentation: - For Google Cloud, see [Internal load balancing in GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing "Internal load balancing in GKE"). - For Azure, see [Internal load balancer in AKS](https://docs.microsoft.com/en-us/azure/aks/internal-lb "Internal load balancer in AKS"). - For AWS, see [EKS load balancing](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html "EKS load balancing") and [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#lb-scheme "AWS load balancer controller"). - For other providers, see [Internal load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer "Internal load balancer"). For example, for a GKE cluster, you would add the following to your values file: ```yaml # yba-values.yaml yugaware: service: # other values… annotations: networking.gke.io/load-balancer-type: "Internal" ``` For an EKS cluster, you would use the following: ```yaml # yba-values.yaml yugaware: service: # other values… annotations: # used by builtin load balancer controller of Kubernetes service.beta.kubernetes.io/aws-load-balancer-internal: "true" # required if using AWS load balancer controller service.beta.kubernetes.io/aws-load-balancer-scheme: "internal" ``` #### Set a DNS name If you want to access YugabyteDB Anywhere via a domain or localhost, you need to set the `tls.hostname` field to ensure that the correct Transport Layer Security (TLS) and Cross-Origin Resource Sharing (CORS) settings are used, as follows: ```yaml # yba-values.yaml tls: hostname: "yba.example.com" ``` Similarly, if you want to access YugabyteDB Anywhere from multiple domains or you have a complex reverse-proxy setup, you can add those domains to CORS configuration, as follows: ```yaml # yba-values.yaml yugaware: # other values… additionAllowedCorsOrigins: - "yba-east.example.com" - "yba-test.example.com" ``` ### Configure TLS You can configure YugabyteDB Anywhere to use TLS. #### Enable TLS Add the following lines to your values file to enable TLS: ```yaml # yba-values.yaml tls: enabled: true ``` The Helm chart will create a self-signed certificate for you. #### Use a custom TLS certificate You can use a custom TLS certificate instead of using the default self-signed certificate. Set the value of `certificate` and `key` to the base64-encoded string value of the certificate and the key, as follows: ```yaml # yba-values.yaml tls: enabled: true certificate: "LS0tLS1CRUdJTiBDRVJUSUZJQ..." key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0t..." ``` #### Use cert-manager You can use [cert-manager](https://cert-manager.io/ "cert-manager") to issue and renew the TLS certificate for the YugabyteDB Anywhere UI. Before enabling this option, ensure that cert-manager is installed and running on your Kubernetes cluster. For more information, refer to [Install cert-manager](/stable/yugabyte-platform/prepare/server-nodes-software/software-kubernetes/#install-cert-manager "Install cert-manager"). Set `tls.hostname` to the DNS name you use to access YugabyteDB Anywhere. The Helm chart uses this value as the certificate common name. To have the Helm chart create a self-signed Issuer and issue a certificate with cert-manager, add the following to your values file: ```yaml # yba-values.yaml tls: enabled: true hostname: "yba.example.com" certManager: enabled: true genSelfsigned: true ``` To use an existing ClusterIssuer, set `genSelfsigned` to `false`, enable `useClusterIssuer`, and provide the ClusterIssuer name: ```yaml # yba-values.yaml tls: enabled: true hostname: "yba.example.com" certManager: enabled: true genSelfsigned: false useClusterIssuer: true clusterIssuer: "cluster-ca" ``` To use an existing namespace-scoped Issuer, set `genSelfsigned` to `false`, leave `useClusterIssuer` as `false`, and provide the Issuer name: ```yaml # yba-values.yaml tls: enabled: true hostname: "yba.example.com" certManager: enabled: true genSelfsigned: false useClusterIssuer: false issuer: "yugaware-ca" ``` You can optionally customize certificate duration, renewal window, and key settings under `tls.certManager.configuration`. Note This configuration manages the TLS certificate for the YugabyteDB Anywhere UI. To use cert-manager for universe (node) certificates, refer to [Add cert-manager certificates](/stable/yugabyte-platform/security/enable-encryption-in-transit/add-certificate-kubernetes/ "Add cert-manager certificates"). #### Change TLS versions When using TLS with YugabyteDB Anywhere, you can change the supported TLS versions, as follows: ```yaml # yba-values.yaml tls: enabled: true # other values… sslProtocols: "TLSv1.2 TLSv1.3" ``` The value is passed to Nginx frontend as [ssl\_protocols](https://nginx.org/r/ssl_protocols "ssl_protocols") operational directive. ### Control placement of YugabyteDB Anywhere pods The Helm chart allows you to control the placement of the pods when installing YugabyteDB Anywhere in your Kubernetes cluster via `nodeSelector`, `zoneAffinity`, and `toleration`. When you are using these constraints, ensure that you are following recommendations provided in [Hardware requirements](/stable/yugabyte-platform/prepare/server-nodes-hardware/ "Hardware requirements"). For more information about pod placement, see [Assigning pods to nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ "Assigning pods to nodes"). #### nodeSelector The Kubernetes `nodeSelector` field provides the means to constrain pods to nodes with specific labels, allowing you to restrict the placement of YugabyteDB Anywhere pods on a particular node, as demonstrated by the following example: ```yaml # yba-values.yaml nodeSelector: kubernetes.io/hostname: "node-name-1" ``` #### zoneAffinity Kubernetes provides a flexible `nodeAffinity` construct to constrain the placement of pods to nodes in a given zone. When your Kubernetes cluster nodes are spread across multiple zones, you can use this command to explicitly place the YugabyteDB Anywhere pods on specific zones, as demonstrated by the following example: ```yaml # yba-values.yaml zoneAffinity: - us-west1-a - us-west1-b ``` #### tolerations Kubernetes nodes could have taints that repel pods from being placed on it. Only pods with a toleration for the same taint are permitted. For more information, see [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ "Taints and Tolerations"). For example, if some of the nodes in your Kubernetes cluster are earmarked for experimentation and have a taint `dedicated=experimental:NoSchedule`, only pods with the matching toleration will be allowed, whereas other pods will be prevented from being placed on these nodes: ```yaml # yba-values.yaml tolerations: - key: "dedicated" operator: "Equal" value: "experimental" effect: "NoSchedule" ``` Note that tolerations do not guarantee scheduling on the tainted nodes. To ensure that the YugabyteDB Anywhere pods use a dedicated set of nodes, you need to use [nodeSelector](#nodeselector "nodeSelector") along with taints and tolerations to repel other pods. ### Modify resources You can modify the resource requests and limits set for the various components of YugabyteDB Anywhere, including CPU and memory resources, as follows: ```yaml # yba-values.yaml yugaware: # other values… resources: requests: cpu: "4" memory: "5Gi" # optionally set limits limits: cpu: "5" memory: "8Gi" ``` For more information, see [Memory resources](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/ "Memory resources") and [CPU resources](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/ "CPU resources"). Similarly, you can modify the values for Prometheus and PostgreSQL containers which are part of the chart, as follows: ```yaml # yba-values.yaml prometheus: # other values… resources: requests: cpu: "2" memory: "6Gi" postgres: # other values… resources: requests: cpu: "1.5" memory: "2Gi" ``` ### Run containers as non-root Starting in YugabyteDB Anywhere v2026.1.2, YugabyteDB Anywhere Docker images are STIG-compliant and hardened. These images now ship with a non-root user (UID: 10001) as the default. OpenShift This section does not apply to OpenShift. OpenShift always runs YugabyteDB Anywhere containers as non-root and enforces that policy itself, not through `securityContext`. Do not set or modify `securityContext` on OpenShift; doing so can cause the containers to fail. For OpenShift, see [Install YugabyteDB Anywhere on OpenShift](/stable/yugabyte-platform/install-yugabyte-platform/install-software/openshift/ "Install YugabyteDB Anywhere on OpenShift"). The PostgreSQL containers always run as non-root. In versions earlier than v2026.1.2, set the following values to run the remaining containers as non-root: ```yaml securityContext: enabled: true ``` This is the default starting in v2026.1.2. If you upgrade a non-OpenShift installation to v2026.1.2 or later and you haven't pinned a user in `securityContext`, the pods migrate to the non-root user from the image. Disabling `securityContext` is not enough to keep running as root, because the image itself no longer defaults to root. To keep running as root on a non-OpenShift installation, add the following to your values file before you upgrade: ```yaml securityContext: enabled: true runAsNonRoot: false runAsUser: 0 ``` ### Set pod labels and annotations Kubernetes resources, such as pods, can have additional metadata in the form of labels and annotations. These key-value pairs are used by other tools such as Prometheus. You can add labels and annotations to the YugabyteDB Anywhere pods as follows: ```yaml # yba-values.yaml yugaware: # other values… pod: annotations: sidecar.istio.io/proxyCPU: "200m" labels: sidecar.istio.io/inject: true prometheus.io/scrape: true ``` ### Specify custom storage class The storage class used by YugabyteDB Anywhere pods can be changed, along with the size of the volume, by using the following values: ```yaml # yba-values.yaml yugaware: storageClass: "custom-sc" storage: "200Gi" ``` You should use a storage class that has been configured based on recommendations provided in [Hardware requirements (Kubernetes)](/stable/yugabyte-platform/prepare/server-nodes-hardware/ "Hardware requirements (Kubernetes)"). In addition, it is recommended to set a large initial storage size, because resizing the volumes later is challenging. ## Enable FIPS Available in YugabyteDB Anywhere v2026.1.1.0 and later. You can install YugabyteDB Anywhere in FIPS-compliant mode on Kubernetes. To enable FIPS, add the following to your values file when you install YugabyteDB Anywhere: ```yaml # yba-values.yaml yugaware: fips: enabled: true ``` After YugabyteDB Anywhere is installed in FIPS mode, create a Kubernetes provider configuration and create universes as usual. Universes are deployed with FIPS enabled automatically. Keep the following limitations in mind: - FIPS-enabled YugabyteDB Anywhere is only supported in Kubernetes environments. - Only the Kubernetes cloud provider supports FIPS-compliant universes. - A FIPS-enabled YugabyteDB Anywhere always creates FIPS-enabled universes. You can't create a non-FIPS universe from a FIPS-enabled YugabyteDB Anywhere. - You can't upgrade an existing YugabyteDB Anywhere installation or an existing universe to become FIPS-compliant. Only greenfield deployments are supported. ## Enable GKE service account-based IAM If you are using Google Cloud Storage (GCS) for backups, you can enable GKE service account-based IAM (GCP IAM) so that Kubernetes universes can access GCS. Before enabling GCP IAM, ensure you have the prerequisites. Refer to [GCP IAM](/stable/yugabyte-platform/prepare/cloud-permissions/cloud-permissions-nodes-gcp/#gke-service-account-based-iam-gcp-iam "GCP IAM"). To enable GCP IAM, provide the following additional Helm values during installation to a version which supports this feature (v2.18.4 or later): - serviceAccount: Provide the name of the Kubernetes service account you created. Note that this service account should be present in the namespace being used for the YugabyteDB pod resources. - [nodeSelector](#nodeselector "nodeSelector"): Pass a node selector override to make sure YugabyteDB Anywhere pods are scheduled on the GKE cluster's worker nodes which have a metadata server running. ```yaml yugaware: ....serviceAccount: nodeSelector: ....iam.gke.io/gke-metadata-server-enabled: "true" ``` ## Delete the Helm installation of YugabyteDB Anywhere To delete the Helm installation, run the following command: ```sh helm uninstall yw-test -n yb-platform ```