Best practices voor Kubernetes. In kaart brengen van externe diensten

Best practices voor Kubernetes. Kleine containers maken
Best practices voor Kubernetes. Organisatie van Kubernetes met naamruimte
Best practices voor Kubernetes. Validatie van Kubernetes Liveness met gereedheids- en livenesstests
Best practices voor Kubernetes. Resourceverzoeken en limieten instellen
Best practices voor Kubernetes. Correcte afsluiting Beëindigen

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

In het volgende codevoorbeeld ziet u dat de eindpunten het IP-adres voor de database bepalen met dezelfde mongo-naam als de service.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

Deze service voert eenvoudige CNAME-forwarding uit op kernelniveau met minimale impact op de prestaties. Hierdoor kunt u een eenvoudiger verbindingsreeks gebruiken.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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.

Best practices voor Kubernetes. In kaart brengen van externe diensten

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, cloud VPS voor ontwikkelaars vanaf $ 4.99, een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: De hele waarheid over VPS (KVM) E5-2697 v3 (6 kernen) 10 GB DDR4 480 GB SSD 1 Gbps vanaf $ 19 of hoe een server te delen? (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).

Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV vanaf $199 in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over Hoe infrastructuur corp te bouwen. klasse met het gebruik van Dell R730xd E5-2650 v4-servers ter waarde van 9000 euro voor een cent?

Bron: www.habr.com

Voeg een reactie