Om du liknar de flesta människor använder du förmodligen resurser som fungerar utanför din kluster. Kanske använder du Taleo API för att skicka textmeddelanden eller analyserar bilder med Google Cloud Vision API.
Om du använder samma slutpunkt — en modul för att ta emot förfrågningar på serversidan i alla dina miljöer och inte planerar att flytta dina servrar till Kubernetes, så är det helt okej att ha tjänstens slutpunkt direkt i din kod. Men det finns många andra scenario. I den här serien "Bästa praxis för Kubernetes" får du veta hur du använder Kubernetes inbyggda mekanismer för att upptäcka tjänster både inuti och utanför klustret.
Som ett exempel på en vanlig extern tjänst kan man nämna en databas som fungerar utanför Kubernetes-klustret. I kontrast till sådana molndatabaser som Google Cloud Data Store eller Google Cloud Spanner, som använder en enda slutpunkt för alla slags åtkomst, har de flesta databaser separata slutpunkter för olika situationer.
En bästa praxis när man använder traditionella databaser som MySQL och MongoDB är vanligtvis att du ansluter till olika komponenter för olika miljöer. Du kan ha en stor maskin för produktionsdata och en mindre maskin för testmiljön. Var och en av dem har sin egen IP-adress eller domännamn, men du vill säkert inte ändra din kod när du går från en miljö till en annan. Istället för att hårdkoda dessa adresser kan du använda den inbyggda DNS-baserade tjänstupptäckten i Kubernetes för externa tjänster på samma sätt som för Kubernetes-nativa tjänster.
Anta att du kör en MongoDB-databas i Google Compute Engine. Du kommer att fastna i denna hybrida värld tills du lyckas flytta den till klustret.
Lyckligtvis kan du använda statiska Kubernetes-tjänster för att göra livet lite enklare. I detta exempel har jag skapat en MongoDB-server med hjälp av Google Cloud Launcher. Eftersom den är skapad i samma nätverk (eller VPC för Kubernetes-klustret), nås den via en högpresterande intern IP-adress.
I Google Cloud är detta standardinställningen, så du behöver inte göra några inställningar. Nu när det finns en IP-adress är nästa steg att skapa en tjänst. Du kan märka att det inte finns några podselektorer för denna tjänst. Det betyder att vi har skapat en tjänst som inte vet vart den ska skicka trafik. Detta kommer att möjliggöra att manuellt skapa ett endpoint-objekt som kommer att ta emot trafik från denna tjänst.
Ett exempel på kod visar att slutpunkterna definierar IP-adressen för databasen, med samma namn mongo som tjänsten.
Kubernetes kommer att använda alla IP-adresser för att hitta slutpunkterna, som om de vore vanliga Kubernetes-poddar, så nu kan du nå databasen med en enkel anslutningssträng till ovanstående namn mongodb://mongo. Det finns ingen anledning att använda IP-adresser i din kod.
Om IP-adresserna ändras i framtiden kan du enkelt uppdatera slutpunkterna med den nya IP-adressen, och dina applikationer behöver inte ändras på något annat sätt.
Om du använder en databas som ligger på en extern värd, har värdarna troligtvis gett dig en enhetlig resursidentifierare URI för anslutning. Så om du har fått en IP-adress kan du helt enkelt använda den tidigare metoden. Detta exempel visar att jag har två MongoDB-databaser som ligger på värden mLab.
Den ena är utvecklarens databas och den andra är produktionsdatabasen. Anslutningssträngarna för dessa databaser ser ut som följer – mLab ger dig en dynamisk URI och en dynamisk port. Som du ser är de olika.
För att abstrahera från detta, använder vi Kubernetes och ansluter till utvecklarens databas. Du kan skapa ett externt namn för Kubernetes-tjänsten, vilket ger dig en statisk tjänst som kommer att omdirigera trafik till den externa tjänsten.
Denna tjänst kommer att utföra en enkel CNAME-omdirigering på kärnnivå, vilket har minimal påverkan på prestandan. Tack vare detta kan du använda en enklare anslutningssträng.
Men eftersom det externa namnet använder en CNAME-omdirigering kan det inte utföra portomdirigeringar. Därför är denna lösning endast tillämplig för statiska portar och kan inte användas med dynamiska portar. Men den kostnadsfria mLab Free Tier tillhandahåller som standard en dynamisk portnummer till användaren, och detta kan du inte ändra. Det betyder att du behöver olika anslutningssträngar för dev och prod. Det negativa är att portnumret då måste hårdkodas. Hur får man då portomdirigering att fungera?
Första steget är att hämta IP-adressen från URI. Om du kör kommandot nslookup, hostname eller pingar URI kan du få IP-adressen till databasen. Om tjänsten returnerar flera IP-adresser kan alla dessa adresser användas i objektets slutpunkter.
Det är viktigt att komma ihåg att IP-adresserna i URI kan ändras utan förvarning, så de är ganska riskabla att använda i prod. Med en sådan IP-adress kan du ansluta till en fjärrdatabas utan att specificera porten. På så sätt utför Kubernetes-tjänsten portomdirigering ganska transparens.
Mapping, eller att matcha externa resurser med interna, ger dig möjlighet att flexibelt använda dessa tjänster inom klustret i framtiden, samtidigt som du minimerar ansträngningarna för refaktorering. Det underlättar också hantering och ger en förståelse för vilka externa tjänster ditt företag använder.
Fortsättningen kommer snart...
Lite reklam 🙂
Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, , en unik motsvarighet till entry-level servrar som vi har skapat för er: (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).
Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om
Källa: habr.com
