--- title: "Configure Kubernetes overrides" url: "https://docs.yugabyte.com/stable/yugabyte-platform/scale-deployments/edit-helm-overrides/" --- # Configure Kubernetes overrides Configure Helm chart overrides for Kubernetes universes in YugabyteDB Anywhere. If your universe uses Kubernetes, you can set Helm chart overrides when you [create the universe](/stable/yugabyte-platform/create-deployments/create-universes-wizard/ "create the universe"), and modify them later for an existing universe. To change storage class or volume count on a running universe (v2026.1.0.0 or later), use [Full move for Kubernetes universes](/stable/yugabyte-platform/scale-deployments/kubernetes-full-move/ "Full move for Kubernetes universes") instead. For provider-level overrides, refer to [Overrides](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/#overrides "Overrides"). ## Configure overrides ### During universe creation When creating a universe, optionally use the **Helm Overrides** (or **Kubernetes Overrides**) section as follows: 1. Click **Add Kubernetes Overrides** to open the **Kubernetes Overrides** dialog. 2. Using the YAML format (which is sensitive to spacing and indentation), specify the universe-level overrides for YB-Master and YB-TServer, as per the following example: ```yaml master: podLabels: service-type: 'database' ``` 3. Optionally, click **Add Availability Zone** to add availability zone overrides, which only apply to pods that are deployed in that specific availability zone. For example, to define overrides for the availability zone us-west-2a, you would click **Add Availability Zone** and use the text area to insert YAML in the following form: ```yaml us-west-2a: master: podLabels: service-type: 'database' ``` If you specify conflicting overrides, YugabyteDB Anywhere uses the following order of precedence: universe availability zone-level overrides, universe-level overrides, provider overrides. 4. Select **Force Apply** if you want to override any previous overrides. 5. Click **Validate and Save**. If there are any errors in your overrides definitions, a detailed error message is displayed. You can correct the errors and try to save again. To save your Kubernetes overrides regardless of any validation errors, select **Force Apply**. ### Edit overrides on an existing universe To edit Kubernetes overrides on an existing universe, navigate to the universe and do the following: 1. [New UI](/stable/yugabyte-platform/yba-overview/#new-experience) Click **Settings > Advanced**, and under **Helm Overrides** click **Add Helm Overrides** or **Edit**. [Classic UI](/stable/yugabyte-platform/yba-overview/#new-experience) Click **Actions > Edit Kubernetes Overrides**. This displays the **Kubernetes Overrides** dialog. 2. Complete the dialog using the same YAML format and options described in [During universe creation](#during-universe-creation "During universe creation"). For examples of typical overrides, see [Override examples](#override-examples "Override examples"). ## Override examples ### GKE service account If you want to enable [GKE service account-based IAM](/stable/yugabyte-platform/prepare/cloud-permissions/cloud-permissions-nodes-gcp/#gke-service-account-based-iam-gcp-iam "GKE service account-based IAM") for backup and restore using GCS at the universe level, add the following overrides: ```yaml tserver: serviceAccount: nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true" ``` If you don't provide namespace names for each zone/region during [provider creation](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/ "provider creation"), add the names using the following steps: 1. Add the Kubernetes service account to the namespaces where the pods are created. 2. Follow the steps in [Upgrade universes for GKE service account-based IAM](#upgrade-universes-for-gke-service-account-based-iam "Upgrade universes for GKE service account-based IAM") to add the annotated Kubernetes service account to pods. To enable the GKE service account service at the provider level, refer to [Overrides](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/#overrides "Overrides"). ### EKS service account In AWS, you can attach a service account to database pods; the account can then be used to access storage. The service account used for the database pods should have annotations for the IAM role. The service account to be used can be applied to the DB pods as a Helm override with provider- or universe-level overrides. The IAM role used should be sufficient to access S3 storage. To enable IAM roles for S3, set the **Use S3 IAM roles attached to DB node for Backup/Restore** Universe Configuration option (config key `yb.backup.s3.use_db_nodes_iam_role_for_backup`) to true. Refer to [Manage runtime configuration settings](/stable/yugabyte-platform/administer-yugabyte-platform/manage-runtime-config/ "Manage runtime configuration settings"). For more information, refer to [Enable IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html "Enable IAM roles for service accounts") in the AWS documentation. If you want to enable EKS service account-based IAM for backup and restore using S3 at the universe level, add the following overrides: ```yaml tserver: serviceAccount: ``` To enable the EKS service account service at the provider level, refer to [Overrides](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/#overrides "Overrides"). ### Readiness probes If you want to enable [readiness probes](/stable/deploy/kubernetes/single-zone/oss/helm-chart/#readiness-probes "readiness probes"), add the following overrides: ```yaml master: readinessProbe: enabled: true tserver: readinessProbe: enabled: true ``` ### Run as root This override does not apply to OpenShift. OpenShift always runs YugabyteDB pods as non-root and enforces that policy itself, not through `podSecurityContext`. Starting in YugabyteDB v2026.1.2, YugabyteDB Docker images are STIG-compliant and hardened, and run as a non-root user by default. If you upgrade a non-OpenShift universe that does not pin a user in `podSecurityContext`, the pods migrate to the non-root user from the image. To keep running as root on a non-OpenShift universe, add the following overrides before you upgrade: ```yaml podSecurityContext: enabled: true runAsNonRoot: false runAsUser: 0 ``` For more information, see [Run as non-root](/stable/yugabyte-platform/configure-yugabyte-platform/kubernetes/#run-as-non-root "Run as non-root"). ### ARM VMs If you want to use ARM VMs, add the following overrides: ```yaml # Point to the aarch64 image in case multi-arch is not available. Image: tag: 2026.1.2.0-b137-aarch64 # Add a nodeSelector to deploy universe to arm64 nodes in the cluster nodeSelector: kubernetes.io/arch: arm64 # For each master and tserver add tolerations for any taints that might be # present on the nodes. These taints can be added by default by the # managed k8s provider or by the cluster administrator master: tolerations: - key: kubernetes.io/arch operator: Equal value: aarch64 effect: NoSchedule - key: kubernetes.io/arch operator: Equal value: arm64 effect: NoSchedule - key: arch operator: Equal value: aarch64 effect: NoSchedule tserver: tolerations: - key: kubernetes.io/arch operator: Equal value: aarch64 effect: NoSchedule - key: kubernetes.io/arch operator: Equal value: arm64 effect: NoSchedule - key: arch operator: Equal value: aarch64 effect: NoSchedule ``` ## Create common YB-TServer service for zones By default, each zone has its own YB-TServer service, and you can use this service to connect to the universe. Optionally, you can create an additional highly available common service across all zones as follows. Note that this requires all the zone deployments to be in the same namespace. 1. Set the following Kubernetes overrides to add the universe-name label on the YB-TServer pods. You can do this when you [create the universe](#during-universe-creation "create the universe") or by [editing overrides](#edit-overrides-on-an-existing-universe "editing overrides") on an existing universe. ```yaml tserver: podLabels: universe-name: yb-k8s ``` 2. Save the following to a file named `yb-tserver-common-service.yaml`. You can customize the service type, annotations, and the label selector as required. ```yaml # yb-tserver-common-service.yaml apiVersion: v1 kind: Service metadata: name: yb-k8s-common-tserver labels: app.kubernetes.io/name: yb-tserver # annotations: # networking.gke.io/load-balancer-type: "Internal" spec: type: ClusterIP selector: app.kubernetes.io/name: yb-tserver # This value should match with the value from step 1. universe-name: yb-k8s ports: # Modify the ports if using non-standard ports. - name: tcp-yql-port port: 9042 - name: tcp-ysql-port port: 5433 ``` 3. Run the following command to create the service in the universe's namespace (`yb-prod-yb-k8s` in this example). ```sh $ kubectl apply -f yb-tserver-common-service.yaml -n yb-prod-yb-k8s ``` After the service YAML is applied, in this example you would access the universe at `yb-k8s-common-tserver.yb-prod-yb-k8s.svc.cluster.local`. For connecting to Kubernetes universes, refer to [Connect to a universe](/stable/yugabyte-platform/create-deployments/connect-to-universe/ "Connect to a universe"). ## Create a common load balancer service for YB-Masters/YB-TServers In v2.17 and later, newly created multi-zone universes are deployed in a single namespace by default. This can lead to duplication of load balancer services as a separate load balancer is created for each zone. To prevent creating extra load balancers, you can create a common load balancer service for YB-Masters and YB-TServers that spans all the zones in a namespace. For scenarios involving multi-namespaces or clusters, a distinct service is created for each namespace, maintaining the flexibility needed for complex deployments while avoiding unnecessary resource allocation. ### Enable the common load balancer By default, the load balancer service is created per zone. You can change this behavior by [configuring Helm overrides](#configure-overrides "configuring Helm overrides") during universe creation, or by enabling a global runtime configuration option. You can explicitly define the service scope with the values as "AZ" or "Namespaced" when you configure Helm overrides as follows: ```yaml serviceEndpoints: - name: "yb-master-ui" type: LoadBalancer # Can be AZ/Namespaced scope: "AZ" annotations: {} clusterIP: "" ## Sets the Service's externalTrafficPolicy externalTrafficPolicy: "" app: "yb-master" loadBalancerIP: "" ports: http-ui: "7000" - name: "yb-tserver-service" type: LoadBalancer # Can be AZ/Namespaced scope: "AZ" annotations: {} clusterIP: "" ## Sets the Service's externalTrafficPolicy externalTrafficPolicy: "" app: "yb-tserver" loadBalancerIP: "" ports: tcp-yql-port: "9042" tcp-yedis-port: "6379" tcp-ysql-port: "5433" ``` For services without an explicitly defined scope in Helm overrides, the default service scope (Namespaced) is used. Keep in mind the following: - Scope Utilization: Services with a defined scope will adhere to that scope, as long as it's supported. - Namespaced scope: For Namespaced-scoped services, a service lifecycle is tied to the lifecycle of the universe. - Namespace deletion: When a namespace is deleted, all services associated with that namespace that were created by Helm are removed as well. - Service configuration changes: Existing services can have their serviceType, ports, and annotations updated. ### Migrating service type from AZ to Namespaced scope After creating a service scope, you can't change it directly. To migrate a service from an AZ scope to a Namespaced scope, do the following: 1. Create a new service: Use Helm overrides to add a new service with the desired Namespaced scope. 2. Migrate clients. Gradually switch clients over to the new Namespaced service to ensure they function correctly without disrupting operations. 3. Remove the old Service. After confirming that all clients are using the new service, update the Helm overrides again to remove the old AZ scoped service. ### Limitations - Unsupported in YugabyteDB Helm chart versions before v2024.2. - Unsupported for upgrading universes created prior to v2.18.6.0 and v2.20.2.0. - Enable exposing service is disabled. ### Examples To create a universe with Namespaced scope services by default, do the following: 1. When you [configure Helm overrides](#configure-overrides "configure Helm overrides"), use serviceEndpoint overrides without explicitly defining scope, or define scope as "Namespaced": ```yaml serviceEndpoints: - name: "yb-master-ui" type: LoadBalancer annotations: {} clusterIP: "" ## Sets the Service's externalTrafficPolicy externalTrafficPolicy: "" app: "yb-master" loadBalancerIP: "" ports: http-ui: "7000" ``` Note that irrespective of the default scope, you can add any scope to the services using Helm overrides, provided that the database version supports the scope. For example, if you create a universe that has "AZ" as the default scope, you can add a "Namespaced" scope as follows: ```yaml serviceEndpoints: - name: "yb-tserver-service" type: LoadBalancer annotations: {} clusterIP: "" ## Sets the Service's externalTrafficPolicy externalTrafficPolicy: "" app: "yb-tserver" loadBalancerIP: "" ports: tcp-yql-port: "9042" tcp-yedis-port: "6379" tcp-ysql-port: "5433" - name: "yb-tserver-service-ns" type: LoadBalancer # Can be AZ/Namespaced scope: "Namespaced" annotations: {} clusterIP: "" ## Sets the Service's externalTrafficPolicy externalTrafficPolicy: "" app: "yb-tserver" loadBalancerIP: "" ports: tcp-yql-port: "9042" tcp-yedis-port: "6379" tcp-ysql-port: "5433" ``` ## Upgrade universes for 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 upgrading a universe for 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 upgrade an existing universe to use GCP IAM, do the following: 1. Upgrade YugabyteDB to a version that supports the feature (2.18.4 or later). For more details, refer to [Upgrade the YugabyteDB software](/stable/yugabyte-platform/manage-deployments/upgrade-software/ "Upgrade the YugabyteDB software"). 2. Using the steps in [Edit overrides on an existing universe](#edit-overrides-on-an-existing-universe "Edit overrides on an existing universe"), apply the following overrides. - 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](/stable/yugabyte-platform/install-yugabyte-platform/install-software/kubernetes/#nodeselector "nodeSelector"): Pass a node selector override to make sure that the YugabyteDB pods are scheduled on the GKE cluster's worker nodes that have a metadata server running. ```yaml tserver: serviceAccount: nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true" ```