1
0
Fork 0
mirror of https://github.com/arangodb/kube-arangodb.git synced 2024-12-15 17:51:03 +00:00
kube-arangodb/docs/scaling.md

46 lines
1.9 KiB
Markdown

# Scaling your ArangoDB deployment
The ArangoDB Kubernetes Operator allows easily scale the number of DB-Servers and Coordinators up or down as needed.
The scale up or down, change the number of servers in the custom resource.
E.g., change `spec.dbservers.count` from `3` to `4`.
Then apply the updated resource using:
```bash
kubectl apply -f {your-arango-deployment}.yaml
```
Inspect the status of the custom resource to monitor the progress of the scaling operation.
**Note: It is not possible to change the number of Agency servers after creating a cluster**.
Make sure to specify the desired number when creating CR first time.
## Overview
### Scale-up
When increasing the `count`, operator will try to create missing pods.
When scaling up, make sure that you have enough computational resources / nodes, otherwise pod will be stuck in Pending state.
### Scale-down
Scaling down is always done one server at a time.
Scale down is possible only when all other actions on ArangoDeployment are finished.
The internal process followed by the ArangoDB operator when scaling down is as follows:
- It chooses a member to be evicted. First, it will try to remove unhealthy members or fall-back to the member with
the highest `deletion_priority` (check [Use deletion_priority to control scale-down order](#use-deletion_priority-to-control-scale-down-order)).
- Making an internal calls, it forces the server to resign leadership.
In case of DB servers it means that all shard leaders will be switched to other servers.
- Wait until server is cleaned out from the cluster.
- Pod finalized.
#### Use deletion_priority to control scale-down order
You can use `.spec.deletion_priority` field in `ArangoMember` CR to control the order in which servers are scaled down.
Refer to [ArangoMember API Reference](/docs/api/ArangoMember.V1.md#specdeletionpriority-integer) for more details.