OpenShift Logging 6.x – Requests & Limits anpassen

Grundprinzip: Wer hier schraubt, schraubt an der CR

Alle Workloads im Namespace openshift-logging werden von Operatoren reconciled. Anpassungen an Requests und Limits erfolgen deshalb immer an der zuständigen Custom Resource – nie am Deployment, StatefulSet oder DaemonSet darunter.

Wer steuert was?

Workload	Gesteuert durch	Anpassbar?	Wie
Collector (Vector DaemonSet)	`ClusterLogForwarder`	ja	`spec.collector.resources`
LogFileMetricExporter	`LogFileMetricExporter` CR	ja	`spec.resources`
Loki-Komponenten	`LokiStack` CR	nein	nur indirekt über `spec.size`
`useRequestsAsLimits`	`LokiStack` CR	teilweise	Limits = Requests (Guaranteed QoS), Tech Preview
cluster-logging-operator Pod	OLM	möglich	`Subscription.spec.config.resources`
loki-operator Pod	OLM	möglich	`Subscription.spec.config.resources`
Direkte Edits an Workloads	Operator-Reconciliation	nein	wird zurückgesetzt

Zu den Loki-Komponenten zählen ingester, distributor, querier, query-frontend, index-gateway, compactor, gateway und ruler. Der loki-operator läuft meist in openshift-operators-redhat.

Der Edit, der nie ankommt: oc edit deployment geht durch, der Pod startet neu, alles wirkt erledigt – und beim nächsten Reconcile setzt der Operator die Werte kommentarlos zurück. Kein Fehler, kein Event, nur stiller Rückbau. Der scheinbare Ausweg managementState: Unmanaged ist unsupported.

Collector = Stellschraube, Loki = Konfektionsgröße. Beim Collector dreht man einzelne Werte, bei Loki wählt man nur die T-Shirt-Size.

Collector: ClusterLogForwarder

Das Vector-DaemonSet gehört dem ClusterLogForwarder. Requests und Limits stehen dort unter spec.collector.resources – der supported Weg, einzelne Werte frei zu wählen.

Resources am Collector setzen

Änderung an der CR, der Operator rollt das DaemonSet selbst neu aus – bei einem DaemonSet also ein Restart auf jedem Node.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  collector:
    resources:
      requests:
        cpu: 500m
        memory: 64Mi
      limits:
        cpu: "2"
        memory: 2Gi

LogFileMetricExporter

Der Exporter hat seine eigene CR – und dort ein reguläres spec.resources-Feld. Gleiches Muster wie beim Collector, nur eine Ebene höher im Pfad.

Resources am Exporter setzen

apiVersion: logging.openshift.io/v1alpha1
kind: LogFileMetricExporter
metadata:
  name: instance
  namespace: openshift-logging
spec:
  resources:
    requests:
      cpu: 200m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 256Mi

LokiStack: nur die Größe wählen

Das LokiStack-CRD kennt unter spec.template.<component> nur replicas, nodeSelector, tolerations und podAntiAffinity – kein resources-Feld (im Loki-Operator-Quellcode verifiziert). Requests, Limits, Replicas und PodDisruptionBudgets bestimmt vollständig das Size-Profil.

Size-Profil umstellen

Wer mehr oder weniger Ressourcen für Loki will, wählt eine andere Größe – Werte einzeln tunen ist nicht vorgesehen. Der Red-Hat-KB-Artikel „Modify the default CPU, memory and PVC requested by Lokistack" (access.redhat.com/solutions/7051529) kommt zum selben Fazit.

oc -n openshift-logging edit lokistack logging-loki

spec:
  size: 1x.extra-small   # 1x.demo | 1x.pico | 1x.extra-small | 1x.small | 1x.medium

Resize ist kein stiller Klick: Die Umstellung löst einen Rolling Restart aller Loki-Komponenten aus – ins Wartungsfenster legen. Und die PVCs werden dabei nicht automatisch vergrößert: Die Size steht auf „größer“, der Storage bleibt klein, und das fällt erst auf, wenn er vollläuft.

Hinweis: Die Ausnahme useRequestsAsLimits setzt Limits = Requests und erzwingt damit Guaranteed QoS – aktuell Tech Preview.

Operator-Pods: der OLM-Mechanismus

Auch die Operatoren selbst haben einen Chef: OLM. Falls deren Pods angepasst werden müssen (selten), geht das über spec.config.resources in der jeweiligen Subscription – direkte Edits am Operator-Deployment setzt OLM zurück.

Resources über die Subscription setzen

Gilt für cluster-logging-operator und loki-operator gleichermaßen; letzterer liegt meist in openshift-operators-redhat.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
spec:
  config:
    resources:
      requests:
        cpu: 100m
        memory: 256Mi

Es sind Hausmeister über Hausmeistern: Der Logging-Operator räumt hinter seinen Workloads auf, OLM räumt hinter den Operatoren auf. Wer etwas ändern will, redet immer mit der nächsthöheren Etage – nie mit dem Zimmer selbst.

Sizing prüfen: reicht die gewählte Größe?

Ob z. B. 1x.extra-small (100 GB/Tag) genügt, entscheidet das reale Ingest-Volumen. Gemessen wird an der Quelle – über die Vector-Metrik, nicht über Loki-Distributor-Metriken.

Ingest-Volumen per PromQL messen

vector_component_sent_bytes_total{component_id=~"output_default_lokistack.*"}

Die Metrik zählt, was der Collector tatsächlich Richtung LokiStack schickt – die ehrlichste Grundlage für die Size-Entscheidung.