> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/sovereign-cloud-stack/4.-scs-container-registry-harbor/4.4-high-availability-and-upgrading.md).

# 4.4 High Availability and Upgrading

## High Availability (HA)

**Minimize Downtime** — HA ensures that if one component fails, others can continue to serve requests. This is crucial for CI/CD pipelines, Kubernetes deployments, or runtime environments that pull images continuously.

**Scalability and Load Distribution** — HA setups allow scaling Harbor horizontally, distributing load across multiple instances of the API, job-service, or registry components. This leads to faster response times and a more resilient service under heavy usage (e.g. during large image pushes or massive cluster rollouts).

**Harbor HA architecture**

* **Core Services** — Core is stateless and can be scaled horizontally; handles the REST API, user management, and the UI backend. Multiple replicas can be fronted by a load balancer.
* **Jobservice** — used for async background tasks: garbage collection, replication, scanning. Uses Redis.
* **Redis** — central to HA operation: message queues, cache, job tracking. Should be deployed with Redis Sentinel or a clustered Redis setup.
* **Registry** — the Docker image registry component. Stateless, but relies on shared storage for image layers — needs a persistent volume accessible to all replicas (e.g. NFS, S3).
* **Database (PostgreSQL)** — stores all metadata (projects, users, settings, etc.). Must be deployed in HA mode.
* **Load Balancer** — routes traffic to the core, portal, jobservice, and registry components. Can be a simple NGINX ingress or an external L4/L7 load balancer.

### Trying out HA deployment in KinD

Create a multi-node KinD cluster:

```bash
cat <<EOF > kind-multinode.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker
EOF
kind create cluster --name ha-test-cluster --config ./kind-multinode.yaml
```

Install flux:

```bash
flux install
```

Deploy needed operators for certificates, ingress, postgres and redis:

```bash
kubectl apply -k k8s-harbor/operators/
```

Create redis and postgres clusters:

```bash
./k8s-harbor/envs/public-ha/redis/redis-secret.bash # pwgen needs to be installed
kubectl apply -k k8s-harbor/envs/public-ha/redis/
kubectl apply -k k8s-harbor/envs/public-ha/postgres/
```

Get the ports on localhost on which ingress is accessible:

```bash
kubectl get svc -n ingress-nginx
curl http://localhost:32634
```

Generate secrets and install:

```bash
./k8s-harbor/base/harbor-secrets.bash # pwgen and htpasswd need to be installed
./k8s-harbor/envs/public-ha/swift-secret.bash <username> <password>
kubectl apply -k k8s-harbor/envs/public-ha/
```

Simulate a node going down:

```bash
docker pause <container_id>
```

**Assignments:** (1) create an HA deployment of the Harbor registry; (2) verify functionality and access; (3) push an image into the registry; (4) simulate one of the nodes going down and verify accessibility.

## Upgrading Harbor

**Harbor upgrade strategies**

* Always back up before upgrading.
* Step-by-step upgrade is necessary because of possible DDL changes in the Harbor database. Core executes migration scripts automatically on upgrade — if migrations fail, the whole helm upgrade process may fail. Migrations can also be run in a pre-update hook via `enableMigrateHelmHook`.

**Helm upgrade process** — backup; download the new chart; configure it to the same values as the old one; `helm upgrade`. Handle downtime and rollback carefully.

### Hands-on example with KinD

Backup first. Download the latest version of the Harbor helm chart:

```bash
helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar
```

Modify `values.yaml` to your actual deployment values. Install the newer version under a name:

```bash
helm install release_1 harbor/
```

**Assignments:** (1) upgrade one of the instances created in previous assignments to the newest Harbor version; (2) verify functionality, access and image presence.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/sovereign-cloud-stack/4.-scs-container-registry-harbor/4.4-high-availability-and-upgrading.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.