Als u op de meeste mensen lijkt, gebruikt u waarschijnlijk middelen die buiten uw cluster functioneren. Misschien gebruikt u de Taleo API om sms-berichten te verzenden of analyseert u afbeeldingen met de Google Cloud Vision API.
Als u dezelfde endpoint gebruikt ā het ontvangspunt voor serveraanvragen in al uw omgevingen en niet van plan bent om uw servers naar Kubernetes te verplaatsen, is het volkomen normaal om de service-endpoint rechtstreeks in uw code te hebben. Er zijn echter veel andere scenario's. In deze serie 'Kubernetes Best Practices' leert u hoe u de ingebouwde mechanismen van Kubernetes kunt gebruiken voor serviceontdekking, zowel binnen als buiten het cluster.
Een voorbeeld van een veelgebruikte externe service is een database die buiten het Kubernetes-cluster draait. In tegenstelling tot cloud-databases zoals Google Cloud Data Store of Google Cloud Spanner, die Ć©Ć©n endpoint voor alle soorten toegang gebruiken, hebben de meeste databases aparte endpoints voor verschillende situaties.
Een best practice voor traditionele databases zoals MySQL en MongoDB houdt meestal in dat u verbinding maakt met verschillende componenten voor verschillende omgevingen. U kunt een krachtige machine hebben voor productiegegevens en een kleinere voor de testomgeving. Elke machine heeft zijn eigen IP-adres of domeinnaam, maar u wilt waarschijnlijk uw code niet wijzigen bij het overschakelen van de ene omgeving naar de andere. Daarom kunt u in plaats van deze adressen hardcoded in te voeren de ingebouwde DNS-gebaseerde serviceontdekking van Kubernetes gebruiken om externe diensten op dezelfde manier te ontdekken als inheemse Kubernetes-diensten.
Stel dat u een MongoDB-database draait in Google Compute Engine. U zult vastzitten in deze hybride wereld totdat u deze kunt verplaatsen naar het cluster.
Gelukkig kunt u statische Kubernetes-services gebruiken om het uzelf iets gemakkelijker te maken. In dit voorbeeld heb ik een MongoDB-server gemaakt met behulp van Google Cloud Launcher. Aangezien deze is gemaakt in hetzelfde netwerk (of VPC van het Kubernetes-cluster), is de toegang voorzien van een hoogpresterend intern IP-adres.
In Google Cloud is dit de standaardinstelling, dus je hoeft niets in te stellen. Nu er een IP-adres is, is de volgende stap het creƫren van een service. Je zult opmerken dat er geen podselectors voor deze service zijn. Dit betekent dat we een service hebben gecreƫerd die niet weet waar verkeer naartoe gestuurd moet worden. Dit maakt het mogelijk om handmatig een endpoint-object te creƫren dat het verkeer van deze service zal ontvangen.
Het volgende voorbeeld toont aan dat de endpoints het IP-adres voor de database definiƫren, met dezelfde naam mongo als de service.
Kubernetes zal alle IP-adressen gebruiken om de endpoints te vinden, alsof ze gewone Kubernetes-pods zijn, zodat je nu toegang kunt krijgen tot de database met behulp van een eenvoudige verbindingsstring naar de hierboven genoemde naam mongodb://mongo. Daarbij is er helemaal geen noodzaak om IP-adressen in je code te gebruiken.
Als in de toekomst de IP-adressen veranderen, kun je eenvoudig de endpoints bijwerken met het nieuwe IP-adres, en hoeven je toepassingen niet op enige andere manier aangepast te worden.
Als je een database gebruikt die gehost wordt door een externe host, hebben de hosteigenaars je waarschijnlijk een uniforme resource identifier URI gegeven voor de verbinding. Dus als je een IP-adres hebt gekregen, kun je gewoon de eerder genoemde methode gebruiken. Dit voorbeeld laat zien dat ik twee MongoDB-databases heb, die gehost worden door mLab.
Een daarvan is de ontwikkelaarsdatabase en de andere is de productie-database. De verbindingsstrings voor deze databases zijn als volgt ā mLab geeft je een dynamische URI en een dynamische poort. Zoals je kunt zien, zijn ze verschillend.
Om hiervan te abstraheren, gebruiken we Kubernetes en verbinden we met de ontwikkelaarsdatabase. Je kunt een externe naamservice in Kubernetes creƫren, wat je een statische service zal geven die verkeer naar de externe service doorstuurt.
Deze service zal een eenvoudige CNAME-omleiding op kernniveau uitvoeren, wat een minimale impact op de prestaties zal hebben. Hierdoor kun je een eenvoudigere verbindingsstring gebruiken.
Maar omdat de externe naam een CNAME-omleiding gebruikt, kan deze geen poorten opnieuw toewijzen. Daarom is deze oplossing alleen toepasbaar voor statische poorten en kan deze niet worden gebruikt met dynamische poorten. De gratis mLab Free Tier biedt standaard een dynamisch poortnummer aan de gebruiker, en dit kan niet worden gewijzigd. Dit betekent dat je verschillende verbindingsregelexemplaren nodig hebt voor dev en prod. Het nadeel is dat je het poortnummer hardcoded moet invoeren. Hoe kun je poorttoewijzing laten werken?
De eerste stap is het verkrijgen van het IP-adres uit de URI. Door het commando nslookup uit te voeren, de hostnaam of het URI te pingen, kun je het IP-adres van de database krijgen. Als de service je meerdere IP-adressen teruggeeft, kunnen al deze adressen worden gebruikt in de eindpunten van het object.
Je moet je realiseren dat de IP-adressen van de URI zonder voorafgaande kennisgeving kunnen veranderen, dus het is riskant om ze in prod te gebruiken. Met zo'n IP-adres kun je verbinding maken met een externe database zonder een poort op te geven. Op deze manier voert de Kubernetes-service vrij transparant poorttoewijzing uit.
Mapping, of het koppelen van externe bronnen aan interne, stelt je in staat deze services binnen het cluster in de toekomst flexibel te gebruiken met minimale inspanning voor refactoring. Het vergemakkelijkt ook het beheer en geeft inzicht in welke externe services jouw bedrijf gebruikt.
De voortzetting volgt zeer binnenkort...
Een beetje reclame š
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 ā 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB ā vanaf $99! Lees over hoe
Bron: habr.com
