Als u net als de meeste mensen bent, gebruikt u waarschijnlijk bronnen die buiten uw cluster worden uitgevoerd. Misschien gebruikt u de Taleo API om sms-berichten te verzenden, of analyseert u afbeeldingen met de Google Cloud Vision API.
Als u in al uw omgevingen hetzelfde verzoekeindpunt aan de serverzijde gebruikt en niet van plan bent uw servers naar Kubernetes te migreren, dan is het prima om een service-eindpunt in uw code te hebben. Er zijn echter veel andere scenario's voor de ontwikkeling van evenementen. In deze serie Kubernetes Best Practices leert u hoe u de ingebouwde mechanismen van Kubernetes kunt gebruiken om services zowel binnen als buiten het cluster te ontdekken.
Een voorbeeld van een veel voorkomende externe service is een database die buiten een Kubernetes-cluster draait. In tegenstelling tot clouddatabases zoals Google Cloud Data Store of Google Cloud Spanner, die één enkel eindpunt gebruiken voor alle toegang, hebben de meeste databases afzonderlijke eindpunten voor verschillende omstandigheden.
Best practices voor het gebruik van traditionele databases zoals MySQL en MongoDB betekenen meestal dat u verbinding maakt met verschillende componenten voor verschillende omgevingen. U kunt een grote machine hebben voor productiegegevens en een kleinere machine voor de testomgeving. Elk van hen heeft zijn eigen IP-adres of domeinnaam, maar u wilt waarschijnlijk uw code niet wijzigen wanneer u van de ene omgeving naar de andere verhuist. Dus in plaats van deze adressen hard te coderen, kunt u de ingebouwde DNS-gebaseerde externe servicedetectie van Kubernetes op dezelfde manier gebruiken als native Kubernetes-services.
Stel dat u een MongoDB-database gebruikt op Google Compute Engine. Je blijft vastzitten in deze hybride wereld totdat het je lukt om deze over te brengen naar het cluster.
Gelukkig kunt u statische Kubernetes-services gebruiken om uw leven een beetje gemakkelijker te maken. In dit voorbeeld heb ik een MongoDB-server gemaakt met Google Cloud Launcher. Omdat het op hetzelfde netwerk (of Kubernetes-cluster VPC) is gemaakt, is het toegankelijk via een krachtig intern IP-adres.
Dit is de standaardinstelling op Google Cloud, u hoeft dus niets te configureren. Nu u een IP-adres heeft, is de eerste stap het creëren van een dienst. Het is u misschien opgevallen dat er geen pod-selectors zijn voor deze service. Dat wil zeggen, we hebben een service gemaakt die niet weet waar het verkeer naartoe moet worden gestuurd. Hierdoor kunt u handmatig een eindpuntobject maken dat verkeer van deze service ontvangt.
In het volgende codevoorbeeld ziet u dat de eindpunten het IP-adres voor de database bepalen met dezelfde mongo-naam als de service.
Kubernetes zal alle IP-adressen gebruiken om eindpunten te vinden alsof het gewone Kubernetes-pods zijn, dus nu hebt u toegang tot de database met een eenvoudige verbindingsreeks naar de bovenstaande naam mongodb://mongo. Het is helemaal niet nodig om IP-adressen in uw code te gebruiken.
Als IP-adressen in de toekomst veranderen, kunt u uw eindpunten eenvoudig bijwerken met het nieuwe IP-adres en hoeven uw applicaties op geen enkele manier verder te worden aangepast.
Als u een database gebruikt die wordt gehost op een externe host, hebben de eigenaren van de host u waarschijnlijk een Uniform Resource Identifier-URI gegeven waarmee u verbinding kunt maken. Als u dus een IP-adres heeft gekregen, kunt u gewoon de vorige methode gebruiken. Dit voorbeeld laat zien dat ik twee MongoDB-databases heb die worden gehost op een mlab-host.
De ene is de ontwikkelaarsdatabase en de andere is de productiedatabase. De verbindingsreeksen voor deze databases zien er als volgt uit: mlab biedt u een dynamische URI en een dynamische poort. Zoals je kunt zien, zijn ze verschillend.
Om dit weg te nemen, laten we Kubernetes gebruiken en verbinding maken met de ontwikkelaarsdatabase. U kunt een externe Kubernetes-servicenaam maken, waarmee u een statische service krijgt die verkeer doorstuurt naar de externe service.
Deze service voert eenvoudige CNAME-forwarding uit op kernelniveau met minimale impact op de prestaties. Hierdoor kunt u een eenvoudiger verbindingsreeks gebruiken.
Maar omdat de externe naam CNAME-forwarding gebruikt, kan deze geen port forwarding uitvoeren. Daarom is deze oplossing alleen van toepassing op statische poorten en kan niet worden gebruikt met dynamische poorten. Maar mlab Free Tier geeft de gebruiker standaard een dynamisch poortnummer en u kunt dit niet wijzigen. Dit betekent dat u verschillende verbindingsopdrachtregels nodig hebt voor dev en prod. Het slechte is dat je hiervoor het poortnummer hard moet coderen. Dus hoe zorg je ervoor dat port forwarding werkt?
De eerste stap is het verkrijgen van het IP-adres uit de URI. Als u nslookup of hostnaam uitvoert of de URI pingt, kunt u het IP-adres van de database verkrijgen. Als de service u meerdere IP-adressen retourneert, kunnen al deze adressen worden gebruikt op de eindpunten van het object.
Eén ding om in gedachten te houden is dat IP-URI's zonder voorafgaande kennisgeving kunnen veranderen, waardoor het gebruik ervan in productie behoorlijk riskant is. Met dit IP-adres kunt u verbinding maken met een externe database zonder een poort op te geven. De Kubernetes-service voert port forwarding dus vrij transparant uit.
Het in kaart brengen, of het toewijzen van externe bronnen aan interne bronnen, geeft u de flexibiliteit om deze services in de toekomst binnen het cluster te gebruiken, terwijl de refactoring-inspanningen tot een minimum worden beperkt. Het maakt het ook eenvoudiger om te beheren en inzicht te geven in welke externe diensten uw bedrijf gebruikt.
Wordt zeer binnenkort vervolgd...
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen,
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier
Bron: www.habr.com