Stateless ArgoCD для bare-metal Kubernetes на Proxmox

kubectl delete pod argocd-application-controller-0 --force --grace-period=0 -n argocd

controller:
  dynamicClusterDistribution: true
  replicas: 1

global:
  tolerations:
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 90
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 90

#!/usr/bin/env bash
# Strict mode:
# -e exit on any command failure
# -u fail on undefined variables
# -o pipefail fail if any command in a pipeline fails
set -euo pipefail
NAMESPACE="argocd"
VALUES_FILE="values-ha-stateless.yaml"
echo "🚀 Adding ArgoCD Helm repository..."
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
echo "📦 Installing/Upgrading ArgoCD in namespace $NAMESPACE..."
helm upgrade --install argocd argo/argo-cd \
  --namespace $NAMESPACE \
  --create-namespace \
  -f argocd/$VALUES_FILE
echo "✅ Installation completed. Checking pods..."
kubectl get pods -n $NAMESPACE

# High Availability (HA) Stateless ArgoCD Configuration
#
# This configuration addresses a critical edge case: with default ArgoCD installation,
# when worker nodes are shut down or become unreachable, ArgoCD pods can hang on
# those nodes for up to 5 minutes (default tolerationSeconds), causing service
# unavailability. This configuration reduces eviction time to 90 seconds and ensures
# proper pod distribution across nodes for high availability.
#
global:
  # Fast controller eviction from dead/unreachable nodes (90 seconds)
  #
  # PROBLEM: Default ArgoCD tolerations allow pods to stay on unreachable/not-ready
  # nodes for 300 seconds (5 minutes). When workers are shut down for maintenance,
  # ArgoCD pods remain scheduled on those nodes, causing:
  # - Service unavailability (UI/API unreachable)
  # - Sync operations fail
  # - No automatic recovery until node comes back or timeout expires
  #
  # SOLUTION: Reduce tolerationSeconds to 90 seconds so Kubernetes evicts pods
  # from dead nodes quickly and reschedules them on healthy nodes.
  #
  # This ensures ArgoCD remains available even when nodes are shut down for
  # maintenance or in case of node failures.
  tolerations:
    - key: "node.kubernetes.io/unreachable"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 90 # Evict after 90s instead of default 300s
    - key: "node.kubernetes.io/not-ready"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 90 # Evict after 90s instead of default 300s
controller:
  # Convert controller from StatefulSet to Deployment for stateless operation
  #
  # CRITICAL ISSUE WITH STATEFULSET: StatefulSet can hang indefinitely when a node
  # becomes unreachable:
  #
  # - When a node with StatefulSet pod becomes unreachable, the pod enters
  #   "Terminating" state but cannot be fully deleted because Kubernetes cannot
  #   communicate with the node to gracefully terminate the pod
  # - StatefulSet will NOT create a replacement pod until the old pod is fully
  #   deleted (unlike Deployment which can create new pods immediately)
  # - If the node never comes back or is permanently lost, the StatefulSet pod
  #   can remain in "Terminating" state forever, leaving the service unavailable
  # - Manual intervention (force delete pod, delete node object) is required
  #
  #
  # WHY THIS NON-STANDARD CONFIGURATION:
  #
  # ArgoCD Helm chart does NOT provide a direct option to use Deployment instead
  # of StatefulSet. The chart's architecture assumes StatefulSet by default for
  # the controller, which makes sense for traditional deployments with persistent
  # storage and stable network identities.
  #
  # However, the chart exposes an ALPHA feature called "dynamicClusterDistribution"
  # that happens to use Deployment under the hood. This feature was designed for
  # dynamic cluster sharding (rebalancing managed clusters across controller
  # replicas), but it also changes the controller from StatefulSet to Deployment.
  #
  # FEATURE IS STABLE ENOUGH: Despite being marked "alpha", the Deployment
  # behavior itself is stable. The "alpha" label refers to the dynamic sharding
  # algorithm, not the Deployment vs StatefulSet choice. For single-replica
  # deployments (replicas: 1), the sharding aspect is irrelevant anyway.
  #
  # NOTE: With replicas: 1, the dynamic sharding feature is effectively disabled
  # (no clusters to distribute), so we're only using this flag to get Deployment
  # behavior, not for its intended sharding purpose.
  dynamicClusterDistribution: true
  replicas: 1
repoServer:
  # Repository server handles Git repository operations (clone, fetch, etc.)
  #
  # WHY 3 REPLICAS: High availability - if one node fails, other repo servers
  # continue serving requests. With 3 replicas and podAntiAffinity, we ensure
  # one repo server per node, so a single node failure doesn't take down all
  # repository operations.
  #
  # POD ANTI-AFFINITY: Ensures repo servers are distributed across different
  # nodes. This prevents all replicas from being on the same node, which would
  # cause complete service loss if that node is shut down (the edge case we're
  # solving). With requiredDuringSchedulingIgnoredDuringExecution, Kubernetes
  # will not schedule multiple repo servers on the same node.
  replicas: 3 # One per node for HA
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-repo-server
          topologyKey: "kubernetes.io/hostname" # Distribute across nodes
server:
  # ArgoCD server provides UI and API endpoints
  #
  # WHY 3 REPLICAS: High availability for UI/API access. With 3 replicas and
  # podAntiAffinity, we ensure the server is always available even when a node
  # is shut down. Load balancer can route traffic to remaining healthy instances.
  #
  # WITHOUT THIS: Default single replica on one node means if that node is shut
  # down, ArgoCD UI/API becomes completely unavailable until the node returns or
  # pod is manually rescheduled (the edge case we're solving).
  #
  # POD ANTI-AFFINITY: Distributes server instances across nodes, preventing
  # all servers from being on the same node. Combined with fast tolerations,
  # ensures service remains available during node maintenance or failures.
  replicas: 3 # UI/API always available without waiting for migration
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-server
          topologyKey: "kubernetes.io/hostname" # Distribute across nodes
redis:
  # Redis cache for ArgoCD session storage and caching
  #
  # STATELESS CONFIGURATION: Disable persistent volumes for stateless operation
  #
  # NOTE: According to official ArgoCD chart, redis.persistentVolume.enabled: false
  # disables persistent volumes. The redis-ha subchart will use default storage
  # (emptyDir) when persistent volumes are disabled.
  enabled: true
  # Disable persistent volumes for stateless operation
  persistentVolume:
    enabled: false

kubectl port-forward svc/argocd-server -n argocd 8080:443

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d;
echo