Zum Inhalt springen

Kubernetes

Rancher, RKE2, GitOps — Kubernetes aus dem eigenen Rechenzentrum.

Rancher

RKE2-Stack

Eigenes RZ

Infrastruktur

GitOps

Deployment-Modell

Beratung

+ Betrieb

Wir denken nicht in Schubladen — sondern in Containern.

Kubernetes ist für uns kein Buzzword, sondern Werkzeug. Wir bauen, betreiben und überwachen Cluster auf Rancher/RKE2 im eigenen Rechenzentrum — für Kunden die Infrastruktur brauchen, aber kein eigenes RZ betreiben wollen.

Cloud-Beratung — plattformunabhängig

Nicht jedes Projekt gehört ins eigene RZ. AWS, Azure oder Google Cloud — wir beraten plattformunabhängig und unterstützen mit Architektur-Review, Setup-Begleitung und Troubleshooting. Entscheidend ist die beste Lösung, nicht der Standort.

Cluster-Aufbau mit RKE2

RKE2 als Distribution, Rancher als Management-Layer, Cilium als CNI, CIS-Hardening ab Werk.

  • RKE2, Rancher, Cilium CNI
  • CIS-Hardening Profile
  • etcd-Snapshots alle 6h
  • Multi-Tenant-fähig

GitOps mit ArgoCD

Kein kubectl apply auf Produktion. ArgoCD synchronisiert den gewünschten Zustand aus Git — deklarativ, nachvollziehbar, versioniert.

  • ArgoCD & FluxCD
  • Automated Sync & Self-Heal
  • Rollback = git revert
  • Helm Values per Environment

Cluster-Konfiguration

RKE2-Konfiguration für einen neuen Server-Node — CIS-gehärtet, Cilium als CNI, etcd-Snapshots automatisch:

/etc/rancher/rke2/config.yaml

write-kubeconfig-mode: „0644“
tls-san:
  – k8s.weiss-system.de
  – 10.0.1.10
cni: cilium
disable:
  – rke2-ingress-nginx

etcd-snapshot-schedule-cron: „0 */6 * * *“
etcd-snapshot-retention: 12
profile: „cis-1.23“   # CIS Hardening

Deployments laufen deklarativ über Git. Push auf main → ArgoCD erkennt den Drift → synchronisiert → live:

argocd-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kunde-webapp
spec:
  source:
    repoURL: git.weiss-system.de/kunde/webapp
    targetRevision: main
    path: deploy/helm
  destination:
    namespace: kunde-prod
  syncPolicy:
    automated: { prune: true, selfHeal: true }

Monitoring & Alerting

Prometheus, Grafana, Alertmanager. Alerts die relevant sind — kein Alarm-Spam, sondern gezielte Benachrichtigung wenn es zählt.

  • Prometheus & Grafana Dashboards
  • PodCrashLoop, NodePressure, OOMKill
  • PagerDuty, Mail, Webhook
  • SLA-Dashboards & Kapazitätsplanung

Cloud-Beratung

AWS EKS, Azure AKS, Google GKE — wir helfen bei Architektur, Setup und Migration. Auch zurück ins eigene RZ, wenn die Cloud-Rechnung nicht mehr passt.

  • Architektur-Review & Planung
  • Hands-on Setup-Begleitung
  • Migration Cloud ↔ On-Premise
  • Kosten-Analyse & Optimierung

Helm Chart für eine typische Webapp — Autoscaling, Ingress mit Let’s Encrypt, Resource Limits:

values-prod.yaml

replicaCount: 3
image: registry.weiss-system.de/kunde/webapp:2.4.1
resources:
  requests: { cpu: 250m, memory: 256Mi }
  limits:   { cpu: „1“,  memory: 512Mi }

autoscaling:
  enabled: true
  minReplicas: 3 | maxReplicas: 12
  targetCPU: 70%

ingress: nginx + cert-manager
  host: app.kunde.de

Wenn es brennt

Cluster-Probleme löst man nicht mit Raten. Ein typischer Troubleshooting-Workflow:

kubectl — Troubleshooting

$ kubectl get pods –field-selector=status.phase!=Running
webapp-6d4f8b7c9-x2k4p  0/1  CrashLoopBackOff  14  47m

$ kubectl logs webapp-6d4f8b7c9-x2k4p –previous
FATAL: password authentication failed
Connection to database refused.

→ Ursache: Secret falsch. Korrigieren, Pod startet.

Strukturiertes Debugging statt Raten — wer den Stack kennt, findet die Ursache.

Kubernetes-Projekt geplant? Sprechen Sie mit uns über Ihr Setup