Eerlijk zullen we alles delen?

Sudo Friday Kubernetes OpenShift API Priority and Fairness APF FlowSchemas PriorityLevelConfigurations
  Wander Boessenkool

De API servers op Kubernetes clusters (en dus ook OpenShift) zijn gelimiteerd op het aantal acties dat ze gelijktijdig uit willen voeren. Kom je hierboven, dan zegt de API server gewoon “NEE”.

Sinds Kubernetes 1.20 kun je daarentegen wel bepalen hoe belangrijk dingen zijn. Want: Alle API requests zijn gelijk, maar sommige API requests zijn gelijker dan anderen. Wel is het natuurlijk noodzakelijk dat we wel alle soorten requests worden afgehandeld, we moeten wel eerlijk blijven…

In deze video laat Wander zien hoe je op een Kubernetes cluster gebruik kunt maken van “API Priority and Fairness” (APF) , door het opzetten van PriorityLevelConfigurations en FlowSchemas. Hiermee worden API requests ingedeeld in “Flows”, en iedere flow zit gekoppeld aan een prioriteits niveau. Op deze manier worden inkomende requests verdeeld op een manier dat de queues van elk prioriteits niveau en flow aan de beurt komen, maar op een manier dat sommige flows wel belangrijker kunnen zijn dan anderen.

Linkjes

Gerelateerde posts

Argo Rollouts op OpenShift

Argo Rollouts op OpenShift Met Argo Rollouts kun je Deployment objecten vervangen door Rollout objecten die meer controle geven over hoe updates aan een Deployment uitgerold worden. Langzaam aan met Canaries, atomisch met Green-Blue changeover, en meer. Dit alles kan automatisch gebeuren, met handmatige promotie stappen, combinaties daarvan, en zelfs met probes die kijken of een nieuwe versie goed werkt.

Openshift Vertical Pod Autoscalers

Één van de uitdagingen die wij vaak zien bij klanten op het gebied van platform management is het “right-sizen” van applicaties; Het goed zetten van de requests en limits voor applicaties zodat ze altijd aan resources kunnen gebruiken wat ze nodig hebben, maar niet onnodig veel aanvragen dat niet door de rest van de applicaties op het cluster gebruikt kan worden. Naast educatie van applicatie teams, een belangrijke stap, kan het ook handig zijn om teams (geautomatiseerde) adviezen te geven over de “juiste” instellingen voor hun applicaties. Een tool die daarbij kan helpen is de Vertical Pod Autoscaler van OpenShift.

OpenShift Root zonder Root

Met de release van OpenShift 4.17 is er een feature in Technology Preview gekomen waar Wander al heel lang op zat te wachten: User Namespaces. User Namespaces hebben niks te maken met Kubernetes Namespaces, maar met Linux Kernel Namespaces. Met User Namespaces kan een container een ander idee hebben van wat user ids zijn dan het onderliggende OS. Zo kan een proces in een container denken root te zijn, en alle rechten hebben (binnen de container) die daarbij horen, maar buiten de container stiekem een ander UID hebben. Dit is hetzelfde principe als met Rootless Podman, maar nu beschikbaar (als beta) op Kubernetes, en dus ook op OpenShift. Met deze feature hoeven cluster beheerders minder vaak uitzonderingen te maken voor onder andere COTS applicaties door toegang to verlenen tot de anyuid of nonroot Security Context Constraints (SCC), wat kan leiden tot een beter security posture.