The GitOps Manual: Zero-Downtime Deployments and Compliance in Norway

If you are still SSHing into your production servers to run kubectl apply -f deployment.yaml, you are essentially writing your own resignation letter, one keystroke at a time. I have seen it happen too often: a senior engineer tired from a week of sprints decides to manually patch a live cluster on a Friday afternoon. A typo in the indentation, a missing environment variable, and suddenly the load balancer is routing traffic to a black hole. In 2024, manual intervention in production environments isn't just a bad practice; it is an operational liability that costs companies millions. The shift to GitOps isn't about following a trend; it is about establishing a deterministic, auditable, and automated path to production that survives the chaos of real-world infrastructure.

The philosophy is simple: Git is the single source of truth. Not your terminal history, not the runbook on Confluence, and certainly not the memory of the sysadmin who just left for vacation. Everything from the application code to the infrastructure definitions and network policies must reside in version control. When the state of the cluster deviates from the state defined in Git—whether due to a manual change or bit rot—the system must detect it and correct it. This is drift detection, and it is the heartbeat of a resilient system. For teams operating in Norway and the broader European market, this goes beyond stability. With strict enforcement of GDPR and the Schrems II ruling, having a complete, tamper-proof audit trail of exactly who changed what and when is not optional. It is a legal safeguard.

The Core Loop: CI vs. CD Separation

A common misconception I see in junior DevOps implementations is conflating Continuous Integration (CI) with Continuous Delivery (CD). In a robust GitOps workflow, your CI pipeline (Jenkins, GitLab CI, GitHub Actions) should have zero access to your Kubernetes cluster credentials. Giving your CI runner cluster-admin privileges is a security nightmare waiting to happen. Instead, the CI process should result in a build artifact—usually a Docker image pushed to a registry—and a commit to a configuration repository updating the image tag. That is where CI ends. The CD controller, running inside your cluster, observes that Git repository and pulls the changes in.

Pro Tip: Never use the latest tag in production. It defeats the purpose of immutability. If you need to roll back, latest is ambiguous. Always use semantic versioning or the commit SHA (e.g., v1.2.4-a1b2c3d) to ensure you know exactly what code is running. The rollback mechanism in GitOps is simply git revert.

Defining the State with Kustomize

Raw YAML manifests are unmanageable at scale. You end up copying and pasting the same deployment.yaml for staging, production, and dev, leading to configuration drift. In 2024, Kustomize remains the superior tool for Kubernetes-native configuration management because it avoids the templating complexity of Helm for internal services. It allows you to have a base configuration and overlays for specific environments.

Here is how a typical production overlay structure looks for a high-traffic service hosted on a Norwegian node:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../../base

namePrefix: prod-

patches:
- path: replicas.yaml
- path: resources.yaml

images:
- name: my-app-image
  newName: registry.coolvds.com/my-org/backend
  newTag: v2.4.1

And the corresponding resource patch to ensure Quality of Service (QoS) guarantees:

# overlays/production/resources.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  template:
    spec:
      containers:
      - name: app
        resources:
          requests:
            memory: "2Gi"
            cpu: "1000m"
          limits:
            memory: "4Gi"
            cpu: "2000m"

The Executioner: ArgoCD

For the CD agent, ArgoCD is the de facto standard in 2024. It visualizes your application topology and provides the drift detection we discussed earlier. When deploying ArgoCD on CoolVDS infrastructure, we leverage the low-latency connectivity to the NIX (Norwegian Internet Exchange). A CD controller needs to constantly poll Git repositories and container registries. If your network I/O is sluggish, your "time to sync" increases, delaying critical hotfixes. Running this on high-performance NVMe storage ensures that the internal Redis cache ArgoCD uses remains snappy, even when managing hundreds of applications.

Below is a declarative Application manifest. This file tells ArgoCD what to sync and where. Notice the selfHeal policy—this is the "auto-correct" feature that wipes out manual changes.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'git@github.com:my-org/infra-config.git'
    targetRevision: HEAD
    path: overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Handling Secrets in GitOps

The elephant in the room with GitOps is secrets management. You cannot commit cleartext passwords to Git. In 2024, the most robust pattern is using External Secrets Operator combined with a secure vault (like HashiCorp Vault) or, for simpler setups, Sealed Secrets. Sealed Secrets allows you to encrypt a secret on your local machine using the cluster's public key, which can only be decrypted by the controller running inside the cluster.

# Install Sealed Secrets client
kubeseal --fetch-cert > mycert.pem

# Encrypt a secret
kubectl create secret generic db-creds --from-literal=password=SuperSecret123 --dry-run=client -o yaml | \
  kubeseal --cert=mycert.pem --format=yaml > sealed-secret.yaml

This sealed-secret.yaml is safe to commit to your public repository.

Infrastructure Performance & Compliance

Implementing GitOps introduces overhead. You are running additional controllers (ArgoCD, undefined ingress controllers, monitoring sidecars) that consume compute resources. I have seen developers try to squeeze a full K8s stack onto cheap, oversold VPS instances from budget providers, only to face CrashLoopBackOff errors because the underlying CPU steal time was too high. Kubernetes control planes are sensitive to latency.

This is where the choice of underlying metal becomes architectural, not just financial. We utilize KVM virtualization at CoolVDS to ensure strict resource isolation. When your GitOps operator triggers a sync of 50 microservices simultaneously, the I/O demand spikes. Shared filesystems on budget hosting choke here. Our NVMe-based storage arrays handle high IOPS (Input/Output Operations Per Second) effortlessly, ensuring that etcd latency remains low and the cluster state converges in seconds, not minutes.

Furthermore, for Norwegian businesses, Datatilsynet (The Norwegian Data Protection Authority) is increasingly scrutinizing where data processing occurs. By hosting your GitOps control plane and your production workloads on servers physically located in Oslo, you drastically reduce the legal complexity regarding data transfer outside the EEA. You own the stack, from the metal up to the manifest.

Conclusion

GitOps is more than a workflow; it is a discipline. It forces you to document your infrastructure in code, secure your secrets, and automate your deployments. It removes the "human error" factor from the critical path. But software is only as good as the hardware it runs on. A fragile network or a noisy neighbor can break even the most perfect ArgoCD setup.

If you are ready to build a pipeline that respects both engineering rigor and data sovereignty, you need a foundation that doesn't blink under load. Don't let slow I/O kill your deployment velocity.

Deploy a high-performance KVM instance on CoolVDS today and build your GitOps fortress on solid ground.