Exposing Services in Kubernetes
Daar is verskillende maniere om dienste bloot te stel in Kubernetes sodat beide interne en eksterne eindpunte daartoe toegang kan verkry. Hierdie Kubernetes-konfigurasie is baie krities, aangesien die administrateur toegang kan gee aan aanvallers tot dienste waarop hulle nie toegang behoort te hê nie.
Outomatiese Opsomming
Voordat jy begin met die opsomming van die maniere waarop K8s dienste aan die publiek blootstel, moet jy weet dat as jy namespaces, dienste en ingresses kan lys, jy alles wat aan die publiek blootgestel is, kan vind met:
ClusterIP
'n ClusterIP-diens is die verstek Kubernetes diens. Dit gee jou 'n diens binne jou cluster wat ander programme binne jou cluster kan bereik. Daar is geen eksterne toegang nie.
Dit kan egter toegang verkry deur die gebruik van die Kubernetes Proxy:
Nou kan jy deur die Kubernetes API navigeer om dienste te bereik deur hierdie skema te gebruik:
http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/
Byvoorbeeld kan jy die volgende URL gebruik:
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
om toegang tot hierdie diens te verkry:
Hierdie metode vereis dat jy kubectl
uitvoer as 'n geautentiseerde gebruiker.
NodePort
Wanneer NodePort gebruik word, word 'n aangewese poort beskikbaar gestel op alle Nodes (wat die Virtuele Masjiene verteenwoordig). Verkeer wat na hierdie spesifieke poort gerig word, word dan sistematies geroeteer na die diens. Gewoonlik word hierdie metode nie aanbeveel nie as gevolg van sy nadele.
'n Voorbeeld van 'n NodePort-spesifikasie:
As jy die nodePort nie spesifiseer nie (dit is die poort wat oopgemaak sal word) sal 'n poort in die reeks 30000–32767 gebruik word.
LoadBalancer
Stel die Diens ekstern bloot deur gebruik te maak van 'n wolkverskaffer se balansstaaf. Op GKE sal dit 'n Network Load Balancer opstel wat jou 'n enkele IP-adres sal gee wat alle verkeer na jou diens sal stuur.
Jy moet vir 'n LoadBalancer per blootgestelde diens betaal, wat duur kan wees.
ExternalName
Van die dokumentasie: Dienste van die tipe ExternalName koppel 'n Diens aan 'n DNS-naam, nie aan 'n tipiese selekteerder soos my-service
of cassandra
. Jy spesifiseer hierdie Dienste met die spec.externalName
parameter.
Hierdie Diensdefinisie koppel byvoorbeeld die my-service
Diens in die prod
-naamruimte aan my.database.example.com
:
Wanneer jy die gasheer my-service.prod.svc.cluster.local
opsoek, gee die cluster DNS-diens 'n CNAME
-rekord terug met die waarde my.database.example.com
. Toegang tot my-service
werk op dieselfde manier as ander Dienste, maar met die kritieke verskil dat herleiing plaasvind op die DNS-vlak eerder as deur middel van proksies of deurstuur.
Eksterne IP's
Verkeer wat in die cluster inkom met die eksterne IP (as bestemmings-IP), op die Dienspoort, sal geroeteer word na een van die Diens-eindpunte. externalIPs
word nie deur Kubernetes bestuur nie en is die verantwoordelikheid van die cluster-administrator.
In die Diens-spesifikasie kan externalIPs
saam met enige van die ServiceTypes
gespesifiseer word. In die onderstaande voorbeeld kan "my-service
" deur kliënte benader word op "80.11.12.10:80
" (externalIP:port
)
Ingress
In teenstelling tot al die voorbeelde hierbo, is Ingress NIE 'n tipe diens nie. In plaas daarvan sit dit voor meerdere dienste en tree op as 'n "slim router" of toegangspunt tot jou groep.
Jy kan baie verskillende dinge doen met 'n Ingress, en daar is baie tipes Ingress-beheerders wat verskillende vermoëns het.
Die verstek GKE Ingress-beheerder sal 'n HTTP(S) Laaibalansier vir jou opstel. Dit sal jou in staat stel om beide pad-gebaseerde en subdomein-gebaseerde roetes na agterste dienste te stuur. Byvoorbeeld, jy kan alles op foo.joudomein.com na die foo-diens stuur, en alles onder die joudomein.com/bar/ pad na die bar-diens.
Die YAML vir 'n Ingress-voorwerp op GKE met 'n L7 HTTP Laaibalansier kan so lyk:
Verwysings
Last updated