mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-19 14:12:52 +00:00
Florian ForsterandGitHub
413f8ba585
This pull request significantly expands and restructures the Kubernetes deployment documentation for Zitadel. It introduces detailed, task-focused guides for installation, configuration, ingress, and database setup, replacing the previous minimal documentation. The new docs provide comprehensive instructions and best practices for deploying Zitadel on Kubernetes using Helm, including security, scaling, and high availability considerations. The most important changes are: **Documentation Restructuring and Overview** - Added a new `index.mdx` providing an overview of the Zitadel Helm chart, architecture, prerequisites, and quick links to relevant resources and next steps. - Removed the old minimal Kubernetes deployment page and replaced it with a structured, multi-page documentation set. **Installation and Setup** - Added an `installation.mdx` guide with step-by-step instructions for preparing prerequisites, creating Kubernetes secrets, configuring `values.yaml`, installing the Helm chart, and verifying the deployment. **Configuration and Best Practices** - Added a `configuration.mdx` guide covering Helm chart configuration options, including replica count, container images, security contexts, external domain setup, secrets management, scaling, autoscaling, pod disruption budgets, and anti-affinity rules. **Ingress and Database Configuration** - Added an `ingress.mdx` guide detailing how to configure Kubernetes ingress resources for Zitadel and Login containers, including TLS termination and certificate management. - Added a `database.mdx` guide explaining how to connect Zitadel to PostgreSQL with various TLS/security options and how to manage database credentials and certificates using Kubernetes secrets.
149 lines
2.8 KiB
Plaintext
149 lines
2.8 KiB
Plaintext
---
|
|
title: Operations
|
|
sidebar_label: Operations
|
|
---
|
|
|
|
|
|
|
|
This guide covers day-2 operations for Zitadel on Kubernetes.
|
|
|
|
## Upgrades
|
|
|
|
### General Upgrade Process
|
|
|
|
1. Review the release notes for your target version
|
|
2. Back up your database
|
|
3. Update your `values.yaml` with any required changes
|
|
4. Upgrade the Helm release:
|
|
|
|
```bash
|
|
helm repo update
|
|
helm upgrade my-zitadel zitadel/zitadel --values values.yaml --version <target-version>
|
|
```
|
|
|
|
5. Monitor the upgrade. Watch the pods:
|
|
|
|
```bash
|
|
kubectl get pods --watch
|
|
```
|
|
|
|
Check the Helm release status:
|
|
|
|
```bash
|
|
helm status my-zitadel
|
|
```
|
|
|
|
## Scaling
|
|
|
|
### Manual Scaling
|
|
|
|
Adjust the replica count in your values:
|
|
|
|
```yaml
|
|
replicaCount: 3
|
|
```
|
|
|
|
Or scale directly:
|
|
|
|
```bash
|
|
kubectl scale deployment my-zitadel --replicas=3
|
|
```
|
|
|
|
### Horizontal Pod Autoscaler
|
|
|
|
Enable HPA for automatic scaling based on resource utilization:
|
|
|
|
```yaml
|
|
zitadel:
|
|
autoscaling:
|
|
enabled: true
|
|
minReplicas: 2
|
|
maxReplicas: 10
|
|
targetCPUUtilizationPercentage: 80
|
|
targetMemoryUtilizationPercentage: 80
|
|
```
|
|
|
|
This creates an HPA that:
|
|
- Maintains at least 2 replicas
|
|
- Scales up to 10 replicas
|
|
- Targets 80% CPU and memory utilization
|
|
|
|
View HPA status:
|
|
|
|
```bash
|
|
kubectl get hpa
|
|
```
|
|
|
|
Get detailed HPA information:
|
|
|
|
```bash
|
|
kubectl describe hpa my-zitadel
|
|
```
|
|
|
|
### Resource Requests and Limits
|
|
|
|
Configure appropriate resource allocations:
|
|
|
|
```yaml
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 256Mi
|
|
limits:
|
|
cpu: 1000m
|
|
memory: 1Gi
|
|
```
|
|
|
|
**Recommendations by deployment size:**
|
|
|
|
| Size | CPU Request | CPU Limit | Memory Request | Memory Limit |
|
|
|------|-------------|-----------|----------------|--------------|
|
|
| Small (dev) | 100m | 500m | 256Mi | 512Mi |
|
|
| Medium | 250m | 1000m | 512Mi | 1Gi |
|
|
| Large | 500m | 2000m | 1Gi | 2Gi |
|
|
|
|
### Pod Disruption Budget
|
|
|
|
Ensure availability during voluntary disruptions by using `minAvailable`:
|
|
|
|
```yaml
|
|
podDisruptionBudget:
|
|
enabled: true
|
|
minAvailable: 1
|
|
```
|
|
|
|
Alternatively, use `maxUnavailable`:
|
|
|
|
```yaml
|
|
podDisruptionBudget:
|
|
enabled: true
|
|
maxUnavailable: 1
|
|
```
|
|
|
|
This ensures at least one pod remains available during node drains, upgrades, or other voluntary disruptions.
|
|
|
|
### Database Scaling Considerations
|
|
|
|
When scaling Zitadel horizontally, ensure your PostgreSQL database can handle the increased connection load:
|
|
- Each Zitadel pod opens multiple connections
|
|
- Consider using PgBouncer for connection pooling
|
|
- Monitor database connection usage
|
|
|
|
Example connection pooling setup with PgBouncer:
|
|
|
|
```yaml
|
|
zitadel:
|
|
configmapConfig:
|
|
Database:
|
|
Postgres:
|
|
Host: "pgbouncer.database.svc.cluster.local"
|
|
Port: 6432
|
|
MaxOpenConns: 20
|
|
MaxIdleConns: 10
|
|
```
|
|
|
|
## Next Steps
|
|
|
|
- [Configuration](./configuration) — Review all configuration options
|
|
- [Uninstalling](./uninstalling) — Remove Zitadel from your cluster
|