Helm Integration

High Availability Configuration

Configure TigerAccess for high availability with multiple replicas and pod anti-affinity.

# values.yaml - HA configuration
auth:
  replicas: 3
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: tigeraccess-auth
          topologyKey: kubernetes.io/hostname

proxy:
  replicas: 3
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: tigeraccess-proxy
          topologyKey: kubernetes.io/hostname

resources:
  auth:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2000m
      memory: 4Gi

External Database Configuration

Connect TigerAccess to an external PostgreSQL database instead of deploying one in the cluster.

# values.yaml - External DB
postgresql:
  enabled: false

externalDatabase:
  host: postgres.example.com
  port: 5432
  database: tigeraccess
  username: tigeraccess
  existingSecret: tigeraccess-db-credentials
  existingSecretPasswordKey: password

# Create secret with database password
kubectl create secret generic tigeraccess-db-credentials \
  --namespace tigeraccess \
  --from-literal=password='your-secure-password'

Custom TLS Certificates

Use your own TLS certificates for secure communication instead of auto-generated certificates.

# Create TLS secret from your certificates
kubectl create secret tls tigeraccess-tls \
  --namespace tigeraccess \
  --cert=/path/to/tls.crt \
  --key=/path/to/tls.key

# values.yaml - Custom TLS
ingress:
  enabled: true
  className: nginx
  tls:
    enabled: true
    existingSecret: tigeraccess-tls
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod

Update and Rollback

Upgrade TigerAccess to a new version or rollback to a previous release if needed.

# Upgrade to new version
helm upgrade tigeraccess tigeraccess/tigeraccess \
  --namespace tigeraccess \
  --values values.yaml \
  --version 1.1.0

# Check upgrade status
helm history tigeraccess -n tigeraccess

# Rollback to previous version
helm rollback tigeraccess 1 -n tigeraccess

# Uninstall (with data preservation)
helm uninstall tigeraccess -n tigeraccess --keep-history

What Kubernetes versions are supported by the TigerAccess Helm chart?

The TigerAccess Helm chart supports Kubernetes 1.24+ and is tested on major cloud providers (EKS, GKE, AKS) as well as on-premises distributions like OpenShift and Rancher. We recommend using Kubernetes 1.26 or later for the best experience.

Can I use my own PostgreSQL and Redis instances?

Yes. The Helm chart allows you to disable the bundled PostgreSQL and Redis deployments and connect to external instances. Configure the externalDatabase and externalRedis sections in your values.yaml file with connection details.

How do I customize resource requests and limits?

Resource requests and limits can be customized in the values.yaml file under the resources section for each component (auth, proxy, agent). We provide sensible defaults for production deployments, but you should adjust based on your workload.

Does the Helm chart support automatic certificate management?

Yes. The chart integrates with cert-manager for automatic TLS certificate provisioning and renewal. You can also bring your own certificates by creating a TLS secret and referencing it in the ingress configuration.

How do I integrate the Helm deployment with my existing monitoring stack?

The chart includes ServiceMonitor resources for Prometheus integration and can export metrics in Prometheus format. Configure the metrics section in values.yaml to enable monitoring and set up dashboards in Grafana.

Can I deploy TigerAccess across multiple namespaces or clusters?

Yes. For multi-namespace deployments, you can install separate releases with different configurations. For multi-cluster deployments, use the same Helm chart in each cluster and configure cluster peering in the auth service configuration.