De Kubernetes API is uw route naar het inspecteren en beheren van de activiteiten van uw cluster. U kunt de API gebruiken met de Kubectl CLI, tools zoals curl, of de officiële integratiebibliotheken voor populaire programmeertalen.
De API is ook beschikbaar voor toepassingen binnen uw cluster. Kubernetes-pods krijgen automatisch toegang tot de API en kunnen worden geverifieerd met behulp van een verstrekt serviceaccount. U voert interacties uit door de geïnjecteerde omgevingsvariabelen en certificaatbestanden te gebruiken om verbindingen te maken vanaf de client van uw keuze.
Waarom toegang krijgen tot de Kubernetes API binnen Pods?
Er zijn verschillende use-cases voor in-Pod API-toegang. Met deze techniek kunnen applicaties hun omgeving dynamisch inspecteren, Kubernetes-wijzigingen toepassen en controlevlakstatistieken verzamelen die prestatie-inzichten bieden.
Sommige organisaties ontwikkelen hun eigen tooling rond Kubernetes. Ze kunnen een speciale in-clustertoepassing implementeren die de API gebruikt om extra functionaliteit beschikbaar te maken. Werken vanuit het cluster kan veiliger zijn dan het doen van API-aanroepen vanuit een extern script, aangezien u uw omgeving niet hoeft te openen of serviceaccounts en authenticatietokens hoeft te delen.
De API-clientbibliotheken gebruiken
De eenvoudigste en aanbevolen methode om toegang te krijgen tot de Kubernetes-API vanuit een pod, is door een clientbibliotheek te gebruiken. Volledig ondersteunde opties zijn beschikbaar voor C, .NET, Go, Haskell, Java, JavaScript, Perl, Python en Ruby. Er zijn gelijkwaardige door de gemeenschap onderhouden oplossingen voor de meeste andere populaire programmeertalen.
De clientbibliotheken hebben ingebouwde ondersteuning voor het ontdekken van de clusteromgeving waarin ze worden uitgevoerd. Elke implementatie biedt een functie die u kunt aanroepen waarmee de bibliotheek wordt geconfigureerd om verbinding te maken met de juiste API-server.
Hier& #8217; is een voorbeeld van hoe u de Pods in uw cluster kunt weergeven in een Python-toepassing:
van kubernetes import client, config config.load_incluster_config() api = client.CoreV1Api() # Voer de nodige API-interacties uit # pods = api.list_pod_for_all_namespaces()
Deze aanpak is gemakkelijk om mee te werken en vereist geen handmatige configuratie. Soms kunt u echter geen clientbibliotheek gebruiken. In die gevallen is het nog steeds mogelijk om handmatig toegang te krijgen tot de API met behulp van het serviceaccount dat Kubernetes biedt.
Handmatige API-interacties uitvoeren
< p>Om de API aan te roepen, moet u twee dingen weten: de hostnaam in het cluster waarop deze wordt weergegeven, en het serviceaccounttoken dat uw Pod zal authenticeren.
De API-hostnaam is altijd kubernetes.default.svc. De Kubernetes DNS-provider zal deze naam omzetten naar de API-server van het besturingsvlak. Als alternatief kunt u de omgevingsvariabele $KUBERNETES_SERVICE_HOST gebruiken om het IP-adres van de API-server te ontdekken:
$ echo $KUBERNETES_SERVICE_HOST 10.96.0.1
De API's zijn alleen beschikbaar via HTTPS. U kunt het bestand met de certificeringsinstantie voor uw cluster vinden op /var/run/secrets/kubernetes.io/serviceaccount/ca.crt in uw pod. Kubernetes deponeert dit in het bestandssysteem telkens wanneer een nieuwe container wordt gemaakt.
U moet zich authenticeren om iets nuttigs met de API te bereiken. Kubernetes maakt een nieuw serviceaccount voor elke Pod en levert het token op /var/run/secrets/kubernetes.io/serviceaccount/token. Dit moet bij elk HTTP-verzoek worden opgenomen als een dragertoken in de Authorization-header.
Alles bij elkaar, hier is een voorbeeld van het maken van een standaard in-Pod Kubernetes API-verzoek met curl:
p>$ curl –cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H “Autorisatie: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)” https: //kubernetes.default.svc/api { “soort”: “APIVersions”, “versions”: [ “v1” ], “serverAddressByClientCIDRs”: [ { “clientCIDR”: “0.0.0.0/0”, “serverAddress”: “192.168.49.2:8443” } ]
De Kubernetes-server heeft gereageerd met de beschikbare API-versies. Dit bevestigt dat er een succesvolle verbinding tot stand is gebracht met behulp van de hostnaam kubernetes.default.svc en het opgegeven serviceaccount.
RBAC afhandelen
Hoewel een API-aanvraag is gedaan, zijn de meeste andere niet toegestaan als RBAC is ingeschakeld voor uw cluster. Nieuw gemaakte serviceaccounts ontvangen niet automatisch rollen, dus uw Pod kan geen beschermde API-eindpunten aanvragen.
U kunt dit oplossen door uw eigen Role-objecten te maken en deze te binden aan de serviceaccount dat aan uw Pods is verstrekt. Maak eerst een nieuwe rol:
apiVersion: rbac.authorization.k8s.io/v1soort: Rolmetadata: naamruimte: default naam: < /strong>demo-role regels: – apiGroups: [""]bronnen: ["pods" ] werkwoorden: ["get", "lijst"& #93;
Pas het toe op uw cluster met Kubectl:
$ kubectl apply -f role.yaml
Bind vervolgens de rol aan het serviceaccount:
apiVersion: rbac.authorization.k8s.io/v1soort: RoleBindingmetadata:naamruimte: default naam: demo-role-binding onderwerpen: – soort: ServiceAccount naam: default apiGroup: "" roleRef: soort: Rol naam: demo-rol apiGroup< /strong>: ""
Het standaard serviceaccount is geselecteerd als het onderwerp van de rolbinding. Pods worden altijd geleverd met dit serviceaccount, binnen het bereik van de naamruimte waarin ze zijn gemaakt. In dit voorbeeld wordt de standaardnaamruimte gebruikt, maar dit moet worden gewijzigd voor de Role- en RoleBinding-objecten als uw Pod in een andere naamruimte bestaat.
Voeg de RoleBinding toe aan uw cluster:
$ kubectl apply -f role-binding.yaml
Nu mogen uw pods andere pod-objecten ophalen en weergeven in de standaardnaamruimte. U kunt dit verifiëren door een API-verzoek te doen aan het Pods-eindpunt met namespaced:
$ curl –cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H “Autorisatie: Bearer $( cat /var/run/secrets/kubernetes.io/serviceaccount/token)” https://kubernetes.default.svc/api/v1/namespaces/default/pods { “kind”: “PodList”, “apiVersion”: ” v1″ … }
Pods kunnen hun eigen naamruimte identificeren door het /var/run/secrets/kubernetes.io/serviceaccount/namespace-bestand te lezen:
$ cat /var/run/secrets/kubernetes.io/serviceaccount/namespace default
Dit biedt een handige methode voor het interpoleren van de actieve naamruimte in eindpunt-URL's:
$ curl –cacert /var/run/secrets /kubernetes.io/serviceaccount/ca.crt -H “Autorisatie: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)” https://kubernetes.default.svc/api/v1/namespaces/$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods { “kind”: “PodList”, “apiVersion”: “v1” … }
Een ander serviceaccount kiezen
Kubernetes voorziet Pods automatisch van het standaardserviceaccount in hun naamruimte. U kunt in plaats daarvan optioneel een ander serviceaccount invoegen door het veld spec.serviceAccountName op uw pods in te stellen:
apiVersion: v1 soort: Podmetadata: naam: demo spec: serviceAccountName: demo-sa < p>In dit voorbeeld wordt de Pod geauthenticeerd als de demo-sa-token. U kunt dit serviceaccount handmatig maken en het de rollen koppelen die u nodig heeft.
$ kubernetes create serviceaccount demo-sa
Het serviceaccount moet in dezelfde naamruimte staan als de Pod.
Opting Out of Service Account Mounting
Automatische injectie van serviceaccounts is niet altijd wenselijk. Het kan een veiligheidsrisico vormen omdat een succesvol compromis met de Pod directe toegang biedt tot de API van uw Kubernetes-cluster. U kunt het koppelen van serviceaccounttokens uitschakelen met het spec.automountServiceAccountToken Pod-manifestveld:
apiVersion: v1 soort: Pod metagegevens:naam: demo spec: automountServiceAccountToken: false
Kubernetes injecteert het bestand /var/run/secrets/kubernetes.io/serviceaccount/token niet. Dit voorkomt dat de pod zich bij de Kubernetes-API verifieert, tenzij u handmatig inloggegevens opgeeft met een andere methode. Dit veld wordt ook ondersteund op serviceaccountobjecten, waardoor ze niet automatisch in een Pod kunnen worden gemount.
Als u wel serviceaccountkoppeling gebruikt, stelt u het juiste RBAC-beleid in om het token te beperken tot uw beoogde gebruiksscenario's . Het vermijden van zeer geprivilegieerde toegang vermindert het risico op schade als een aanvaller toegang krijgt tot uw Pod.
Samenvatting
Toegang tot de Kubernetes API-server vanuit uw cluster laat het draaien applicaties inspecteren en wijzigen aangrenzende workloads. U kunt extra functionaliteit toevoegen zonder uw cluster open te stellen voor externe API-toegang.
De officiële clientbibliotheken maken het eenvoudig om aan de slag te gaan, als ze geschikt zijn voor uw gebruik. In andere situaties moet u handmatig verzoeken indienen bij https://kubernetes.default.svc, waarbij u het bestand van de certificeringsinstantie en het serviceaccounttoken opgeeft dat Kubernetes in uw Pod-containers injecteert. Ongeacht de benadering die u gebruikt, moet het serviceaccount correct zijn geconfigureerd met RBAC-rolbindingen, zodat de Pod toestemming heeft om de beoogde acties uit te voeren.
LEES VOLGENDE
- › Wat is DLSS 3 en kunt u het gebruiken op bestaande hardware?
- › Onze favoriete controller voor pc-gaming kost vandaag slechts $ 45
- › NASA en SpaceX willen de Hubble-telescoop een duwtje in de rug geven
- › Wat is de “Klik van de Dood” in een HDD, en wat moet u doen?
- › Intel's RTX 3060 concurrent kost minder dan $300
- › Spotify vs. Audible: wat is beter voor audioboeken?