[DOC-1056] [DOC-1082] [YBA K8s] Immutable YBC and EA-GA K8s features

docs/content/stable/yugabyte-platform/anywhere-automation/yb-kubernetes-operator.md

@@ -283,8 +283,6 @@ The operator pod (with the YugabyteDB Anywhere instance) should have the IAM rol
 
 The IAM role used should be sufficient to access storage in S3.
 
-To enable IAM roles to access storage in 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](../../administer-yugabyte-platform/manage-runtime-config/).
-
 The storage config CR should have IAM as the credential source.
 
 ```yaml

docs/content/stable/yugabyte-platform/back-up-restore-universes/back-up-universe-data.md

@@ -110,7 +110,8 @@ YugabyteDB Anywhere universe backups are stored using the following folder struc
 ```output
 <storage-address>
   /sub-directories
-    /<universe-uuid>
+    /<univ_name>_<universe-uuid>
+     /<database-name>
       /<backup-series-name>-<backup-series-uuid>
         /<backup-type>
           /<creation-time>
@@ -122,7 +123,8 @@ For example:
 ```output
 s3://user_bucket
   /some/sub/folders
-    /univ-a85b5b01-6e0b-4a24-b088-478dafff94e4
+    /univ-univ_name-a85b5b01-6e0b-4a24-b088-478dafff94e4
+     /database1_name
       /ybc_backup-92317948b8e444ba150616bf182a061
         /incremental
           /20204-01-04T12: 11: 03
@@ -133,7 +135,8 @@ s3://user_bucket
 | :-------- | :---------- |
 | Storage address | The name of the bucket as specified in the [storage configuration](../configure-backup-storage/) that was used for the backup. |
 | Sub-directories | The path of the sub-folders (if any) in a bucket. |
-| Universe UUID | The UUID of the universe that was backed up. You can move this folder to different a location, but to successfully restore, do not modify this folder, or any of its contents. |
+| Universe name and UUID | The name of the universe and UUID that was backed up. You can move this folder to different a location, but to successfully restore, do not modify this folder, or any of its contents. |
+| Database or Keyspace name | The name of the Database or Keyspace that was backed up. |
 | Backup series name and UUID | The name of the backup series and YBA-generated UUID. The UUID ensures that YBA can correctly identify the appropriate folder. |
 | Backup type | `full` or `incremental`. Indicates whether the subfolders contain full or incremental backups. |
 | Creation time | The time the backup was started. |

docs/content/stable/yugabyte-platform/create-deployments/create-universe-multi-zone-kubernetes.md

@@ -179,8 +179,6 @@ To enable the GKE service account service at the provider level, refer to [Overr
 
 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 helm override with provider/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](../../administer-yugabyte-platform/manage-runtime-config/).
-
 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) 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:
@@ -208,7 +206,7 @@ tserver:
 
 #### ARM VMs
 
-{{<tags/feature/ea idea="1486">}}If you want to use ARM VMs, add the following overrides:
+If you want to use ARM VMs, add the following overrides:
 
 ```yaml
 # Point to the aarch64 image in case multi-arch is not available.
@@ -252,6 +250,73 @@ tserver:
       effect: NoSchedule
 ```
 
+## Deploy immutable YB Contoller (YBC)
+
+{{<tags/feature/ea idea ="1264">}}By default, YugabyteDB Anywhere deploys YBC on Kubernetes universes by copying the YBC package from YugabyteDB Anywhere to the database pods and extracting it. While this approach ensures a stable YBC version, it has some limitations:
+
+- Does not follow Kubernetes standards for container processes
+- Performs package copy operations on running containers
+- If a Persistent Volume Claim (PVC) gets deleted or replaced, YBC may not be available until YugabyteDB Anywhere detects the issue and re-uploads YBC (for example, before a backup operation if YBC ping failures are detected)
+
+For deployments following strict Kubernetes practices, or when you want YBC to be automatically available even after PVC replacement, you can enable **Immutable YBC**. With this feature, YBC is baked into the YugabyteDB image and runs as a native process alongside `yb-master` and `yb-tserver`, similar to other database processes.
+
+{{< note title="Important considerations" >}}
+
+When immutable YBC is enabled:
+
+- The YBC version is tied to the YugabyteDB version and is upgraded only when you perform a [software upgrade](../../manage-deployments/upgrade-software/). YBC will not automatically follow the latest stable YugabyteDB Anywhere version.
+- YBC flags are mounted on the TServer pod as a Kubernetes secret, instead of copying the flag file from YugabyteDB Anywhere to the database pods.
+
+{{< /note >}}
+
+### Enable YBC immutability
+
+**For new universes:**
+
+Set the `useYbdbInbuiltYbc` field in the `userIntent` object of the primary cluster when sending the Create Universe API request. An example API request is as follows:
+
+```sh
+curl --request POST \
+  --url https://<yugabyte-platform-url>/api/v1/customers/<customer-uuid>/universes \
+  --header 'Accept: application/json' \
+  --header 'Content-Type: application/json' \
+  --header 'X-AUTH-YW-API-TOKEN: <api-token>' \
+  -d '{
+    "clusters": [{
+      "userIntent": {
+        "universeName": "my-k8s-universe",
+        "provider": "<provider-uuid>",
+        "providerType": "kubernetes",
+        "useYbdbInbuiltYbc": true,
+        // ... other required fields
+      }
+    }]
+  }'
+```
+
+For more information, refer to the [Create Universe API documentation](https://api-docs.yugabyte.com/docs/yugabyte-platform/4548b5e5061a8-create-universe-clusters).
+
+**For existing universes:**
+
+Use the Kubernetes Toggle Immutability API to switch Immutable YBC on or off. To enable the feature, an example API request is as follows:
+
+```sh
+curl --request POST \
+  --url https://<yugabyte-platform-url>/api/v1/customers/<customer-uuid>/universes/<universe-uuid>/upgrade/k8s_immutable_ybc \
+  --header 'Accept: application/json' \
+  --header 'Content-Type: application/json' \
+  --header 'X-AUTH-YW-API-TOKEN: <api-token>' \
+  -d '{"useYbdbInbuiltYbc": true}'  # Set to false to disable Immutable YBC
+```
+
+Replace:
+- `<yugabyte-platform-url>` with your YugabyteDB Anywhere URL
+- `<customer-uuid>` with your customer UUID
+- `<universe-uuid>` with your universe UUID
+- `<api-token>` with your API token
+
+Set `useYbdbInbuiltYbc` to `true` to enable Immutable YBC, or `false` to disable it and revert to the package copy approach.
+
 ## Examine the universe and connect to nodes
 
 The universe view consists of several tabs that provide different information about this universe.
@@ -326,7 +391,7 @@ After the service YAML is applied, in this example you would access the 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 (currently {{<tags/feature/ea>}}) for YB-Masters and YB-TServers that spans all the zones in a namespace.
+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.
 
@@ -367,9 +432,7 @@ serviceEndpoints:
       tcp-ysql-port: "5433"
 ```
 
-For services without an explicitly defined scope in Helm overrides, the default service scope (Namespaced) is used, provided you set the **Default service scope for K8s universe** Global runtime configuration option (config key `yb.universe.default_service_scope_for_k8s`) to true. The configuration flag defines the default service scope for the universe if the scope is not explicitly defined in the service overrides.
-
-Refer to [Manage runtime configuration settings](../../administer-yugabyte-platform/manage-runtime-config/). Note that only a Super Admin user can modify Global runtime configuration settings, and you cannot modify this service scope during universe creation.
+For services without an explicitly defined scope in Helm overrides, the default service scope (Namespaced) is used.
 
 Keep in mind the following:
 
@@ -396,8 +459,6 @@ After creating a service scope, you can't change it directly. To migrate a servi
 
 To create a universe with Namespaced scope services by default, do the following:
 
-1. Set the **Default service scope for K8s universe** Global runtime configuration option (config key `yb.universe.default_service_scope_for_k8s`) to true.
-
 1. When you [configure Helm overrides](#helm-overrides), use serviceEndpoint overrides without explicitly defining scope, or define scope as "Namespaced":
 
     ```yaml