‫Nu uw pods actief zijn, zult u
‫deze waarschijnlijk op een gegeven moment moeten blootstellen aan externe services.
‫Dat betekent dat ze op de een of andere manier verbindingen in
‫uw cluster of van buiten uw cluster kunnen accepteren.
‫In Kubernetes gebruiken we de opdracht kubectl exposure als een
‫van de manieren om een service te maken.
‫We hebben service al een paar keer eerder genoemd, maar laten we ervoor zorgen dat
‫we duidelijk zijn over wat een service is. Een service is een
‫eindpunt dat consistent is, zodat andere dingen binnen
‫of buiten het cluster er mogelijk toegang
‫toe hebben.
‫Wanneer u pods maakt in Kubernetes,
‫krijgen ze niet automatisch een DNS-naam voor externe connectiviteit
‫met een IP-adres, strak.
‫U zou dat willen doen door een service
‫te maken bovenop die bestaande pod.
‫Er zijn verschillende manieren om een service aan te
‫maken, naast dit bloot-commando.
‫Laten we ons concentreren op wat gebruikelijk is.
‫Het gemeenschappelijke hier is die kern-DNS.
‫Als je het je herinnert, noemden we dat eerder als een
‫van de kernfuncties van je besturingsvlak.
‫Die service wordt je DNS-server om de namen voor al deze
‫dingen op te lossen.
‫Bovendien, voor het kiezen van
‫het IP-adres en de poort en hoe
‫het dat doet, hoe het verkeer in wezen naar uw
‫service krijgt, is de taak van een van de
‫vier verschillende servicetypes. Laten we die nu eens doornemen en dan
‫zullen we enkele voorbeelden doornemen. Laten we beginnen met
‫het servicetype ClusterIP, dat de standaard is.
‫In dit geval is het belangrijkste aspect dat het alleen beschikbaar
‫is in het cluster.
‫Dit gaat echt over een Kubernetes-set
‫pods die praat met een andere set pods.
‫Dit krijgt zijn eigen DNS-stress, toch.
‫Dat wordt het DNS-adres in
‫het kern-DNS-controlevlak. Het krijgt een
‫IP-adres in die virtuele IP-adresruimte binnen het cluster.
‫Hierdoor kunnen uw andere pods die in het cluster
‫worden uitgevoerd, met deze service praten via de poort
‫van de service. Als je een Nginx-app
‫gebruikt en deze draaide op poort 80 toen je de service
‫maakte, kan die service-IP ook op poort 80 staan.
‫Dat houdt een soort van consistentie daar.
‫Als je erover nadenkt, lijkt dit erg op de manier waarop
‫je een service maakt in Swarm, nu services een beetje anders zijn
‫in Swarm. Ze hebben een
‫ander idee om zich heen.
‫Maar ze zijn in ieder geval consistent wanneer u een service maakt,
‫het geeft u dat interne IP op de load balancer,
‫als u het zich herinnert. Het draait het op de poort waar de app op staat.
‫In dit geval doen we iets soortgelijks, maar we
‫moeten deze maken met een bloot-commando of andere opties waar
‫we het later over zullen hebben.
‫De volgende hier is NodePort, die subtiel
‫anders is. Het is een beetje verwarrend out-of-the-box.
‫De ClusterIP is de standaard en werkt altijd
‫binnen de cluster.
‫Het heeft niets speciaals nodig. Er zijn
‫geen firewallregels buiten het cluster nodig om verkeer
‫naar het cluster te krijgen. Maar ClusterIP is alleen goed in het cluster.
‫Onthoud dat. ClusterIP, goed in het cluster.
‫Een NodePort is ontworpen voor iets
‫buiten het cluster om met uw service
‫te praten via de IP-adressen op de knooppunten zelf.
‫Wanneer u een NodePort maakt, krijgt u een hoge
‫poort op elk knooppunt dat aan deze service
‫is toegewezen.
‫Als je dat eenmaal hebt, kun je andere dingen bijwerken die je over
‫deze poort moet weten.
‫Deze poort wordt een hoge poort.
‫Je gaat bijvoorbeeld geen poort 80 gebruiken als je
‫dit type gebruikt. De sleutel tot deze twee is
‫dat ze altijd beschikbaar zijn in elk Kubernetes-cluster.
‫Of u nu een oplossing van een cloudleverancier gebruikt, of
‫uw eigen Kubernetes gebruikt, of een verpakte oplossing zoals
‫Docker Enterprise of Rancher implementeert.
‫Dit zijn degenen die altijd out-of-the-box zullen werken.
‫De volgende is het type load balancer.
‫Dit wordt meestal in de cloud gebruikt.
‫Het idee hier is dat je een externe
‫load balancer bestuurt via de Kubernetes-opdrachtregel, wat best
‫cool is.
‫In wezen is dit een heleboel automatisering.
‫Wat u hier doet, is op de
‫achtergrond, wanneer u deze load balancer maakt, gaat deze
‫automatisch de ClusterIP in NodePort maken, zodat
‫deze beschikbaar zijn. Dan gaat het
‫met het externe systeem praten. Misschien is het een AWS-load balancer
‫of een andere cloudleverancier. Deze komen in
‫principe van uw infrastructuurproviders en stellen Kubernetes in staat om
‫met hen te praten via een externe API en
‫ze voor u te configureren. Dus in het geval van
‫misschien een AWS-load balancer, wanneer u dit maakt,
‫maakt het niet alleen die NodePorts en ClusterIP's in de
‫backend, maar vertelt het ook de AWS-load balancer om met de
‫NodePorts te praten.
‫In wezen is dit gewoon automatisering, toch.
‫Dit helpt u een stap te besparen door een AWS-opdrachtregel of
‫webinterface uit te voeren om die load balancer automatisch voor
‫u in te stellen.
‫De twee afhaalrestaurants die ik voor deze heb, zijn om erover
‫na te denken, omdat dit alleen is voor verkeer dat vanuit een
‫externe bron in uw cluster komt.
‫Het vereist een infrastructuurprovider die Kubernetes de
‫mogelijkheid geeft om er op afstand mee te praten.
‫De laatste van de vier servicetypen is ExternalName.
‫Dit wordt minder vaak gebruikt en heeft
‫niet echt iets te maken met het regelen van
‫inkomend verkeer naar uw services.
‫Dit gaat meer over dingen in uw cluster die met
‫externe services moeten praten.
‫U wilt DNS-namen maken in
‫het kern-DNS-systeem, zodat uw cluster ExternalNames kan
‫omzetten die u misschien niet
‫extern beheert. Een van de redenen waarom
‫u ExternalName zou kunnen gebruiken, is wanneer
‫u dingen migreert. Bedenk of u een toepassing op afstand heeft.
‫Die externe toepassing buiten uw Kubernetes-cluster heeft
‫waarschijnlijk al een DNS-naam, strak.
‫Als je iets van die externe services naar
‫interne services gaat verplaatsen, kun je kijken
‫hoe je ExternalName kunt gebruiken
‫als vervanging om de DNS in je
‫Kubernetes-workflow te beheren. Je zou dan in feite
‫een enkele opdrachtregel van Kubernetes kunnen hebben in plaats van te
‫zeggen, oh ik moet de externe DNS ergens voor
‫wijzigen, dus ik moet een ander hulpprogramma voor die DNS-service uitvoeren.
‫Of misschien zelfs iets waar niet eens een
‫API achter zit. Misschien als een enterprise DNS
‫of iets dergelijks. U kunt dit
‫binnen uw clusters gebruiken, zodat services binnen uw clusters een
‫ander eindpunt beginnen op te lossen dan het externe eindpunt
‫dat ze eerder hadden. Ik merk dat ik het
‫eigenlijk alleen gebruik als ik moet veranderen
‫hoe mijn spullen uit mijn cluster komen naar een externe service, maar ik
‫heb geen manier om de DNS op afstand van die andere
‫dingen te regelen. Dus ik doe
‫het liever gewoon in Kubernetes en maak wat ExternalNames voor mijn spullen.
‫Als ik het vervolgens dynamisch wil wijzigen in Kubernetes
‫voor mijn spullen in mijn cluster, kan ik dat vrij gemakkelijk doen zonder met
‫iets anders te hoeven praten.
‫Oke. We gaan deze
‫vier servicetypen afronden, maar er is een andere manier waarop verkeer
‫in uw cluster kan komen.
‫Dat is via Ingress.
‫We zullen daar later over praten.
‫Dat is speciaal ontworpen voor HTTP-verkeer.
‫Als we bij die lezing komen, begrijp je waarom dat een
‫beetje anders is dan deze servicetypes.