The "kubectl apply" Habit is Killing Your Uptime

It's 2022. If you are still SSH-ing into your production cluster to hotfix a ConfigMap, you aren't doing DevOps. You're doing Cowboy Ops. I've seen entire clusters in Oslo desynchronize because one well-meaning junior dev manually patched a service and forgot to commit the change. Two weeks later, the pod restarts, the manual patch vanishes, and the service 503s during peak traffic. It’s a nightmare scenario that is entirely preventable.

The solution isn't "be more careful." The solution is GitOps. Git becomes the single source of truth. If it's not in Git, it doesn't exist in the cluster. This approach is critical for Norwegian enterprises facing strict Datatilsynet audits and GDPR requirements under Schrems II. You need an audit trail for every single byte that changes in your infrastructure.

The Architecture: Pull vs. Push

Traditional CI/CD pipelines (Jenkins, older GitLab CI) use a "Push" model. The CI runner has cluster-admin credentials and pushes changes to the API server. This is a security risk. If your CI server is compromised, your production environment is wide open.

We are building a "Pull" model using ArgoCD. The controller sits inside your infrastructure (ideally on a dedicated management cluster or a hardened CoolVDS KVM instance) and watches the Git repository. It pulls changes. No cluster credentials ever leave your environment.

Prerequisites

• A Kubernetes Cluster (v1.23 recommended for stability in May 2022).
• A Git repository (GitLab or GitHub).
• A robust KVM VPS to host the GitOps controller or management tools. We use CoolVDS NVMe instances for this because ArgoCD's Redis cache benefits heavily from high IOPS.

Step 1: Deploying the Controller

First, we create a dedicated namespace. Do not pollute default. Efficiency demands organization.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Wait for the pods. If you are running on cheap, shared hosting, you might see CrashLoopBackOff here due to memory pressure. The ArgoCD repo-server component is hungry. On a CoolVDS 4GB RAM instance, it stabilizes instantly.

Pro Tip: In a production environment, never expose the ArgoCD dashboard via LoadBalancer without IP allow-listing. Use port-forwarding for internal access or an Ingress with strict OIDC authentication.

Step 2: Defining the Application

We don't click buttons in the UI. We write manifests. Here is a declarative `Application` definition that ensures your cluster matches the `main` branch of your repo.

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

The selfHeal: true flag is the magic. If someone manually deletes a deployment, ArgoCD detects the drift and recreates it immediately. It enforces the state defined in Git.

Step 3: Handling Secrets (The GDPR Pain Point)

You cannot commit raw secrets to Git. That is a firing offense. In 2022, the battle-tested standard is Bitnami Sealed Secrets. It uses asymmetric encryption. You encrypt with a public key (safe for Git), and the controller in the cluster decrypts with a private key (stored only in the cluster).

Install the client side tool kubeseal:

# Linux amd64
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.17.5/kubeseal-0.17.5-linux-amd64.tar.gz
tar -xvzf kubeseal-0.17.5-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Now, seal your database credentials:

kubectl create secret generic db-creds \
  --from-literal=password=SuperSecret123 \
  --dry-run=client -o yaml | \
  kubeseal --controller-name=sealed-secrets-controller \
  --controller-namespace=kube-system \
  --format yaml > sealed-secret.yaml

Commit sealed-secret.yaml. Even if your repo leaks, your data is safe.

Performance Tuning for High-Scale Ops

When you have hundreds of microservices, the GitOps controller constantly polls your Git repositories. This creates significant network and disk I/O overhead. We benchmarked this.

For a Norwegian fintech client, that 3.8-second difference caused a race condition during a blue/green deployment. Migrating the management plane to high-performance NVMe storage resolved the sync lag immediately.

Why Local Hosting Matters in 2022

Latency isn't just about disk speed; it's about physics. If your GitOps controller is in Frankfurt and your cluster is in Oslo, you are adding round-trip time to every synchronization check. Furthermore, keeping your management plane within Norway (or at least Northern Europe) simplifies compliance with Schrems II. You do not want your deployment metadata—which often reveals architecture secrets—traversing US-owned networks if you can avoid it.

CoolVDS offers that local stability. We provide the raw compute power needed to run these resource-intensive controllers without the "noisy neighbor" effect found in container-based VPS solutions. When you run a Kubernetes control plane, you need dedicated CPU cycles, not shared bursts.

Conclusion

GitOps is not a trend; it is the standard for sanity in 2022. It separates the human from the machine, providing an audit trail that satisfies even the strictest Norwegian auditors. But remember: your pipeline is only as reliable as the metal it runs on.

Don't let IOPS bottlenecks stall your deployments. Spin up a CoolVDS NVMe instance today and build a control plane that keeps up with your code.