Dum vi komencas krei pli kaj pli da servoj de Kubernetes, taskoj kiuj estas komence simplaj komencas fariĝi pli kompleksaj. Ekzemple, evoluteamoj ne povas krei servojn aŭ deplojojn sub la sama nomo. Se vi havas milojn da balgoj, simple listigi ilin prenos multe da tempo, des malpli ĝuste administri ilin. Kaj ĉi tio estas nur la pinto de la glacimonto.
Ni rigardu kiel la nomspaco faciligas administri Kubernetes-resursojn. Kio do estas nomspaco? Nomspaco povas esti konsiderata kiel virtuala areto ene de via Kubernetes areto. Vi povas havi plurajn nomspacojn izolitaj unu de la alia ene de ununura Kubernetes-grupo. Ili vere povas helpi vin kaj viajn teamojn kun organizo, sekureco kaj eĉ sistema rendimento.
Ĉe la plej multaj Kubernetes-distribuoj, la areto eliras el la skatolo kun nomspaco nomata "defaŭlte". Fakte estas tri nomspacoj, kiujn Kubernetes traktas: defaŭlta, kube-sistemo kaj kube-publika. Nuntempe, Kube-public ne estas uzata tre ofte.
Lasi la kube-nomspacon sola estas bona ideo, precipe en administrita sistemo kiel Google Kubernetes Engine. Ĝi uzas la "defaŭltan" nomspacon kiel la lokon kie viaj servoj kaj aplikoj estas kreitaj. Estas absolute nenio speciala pri ĝi, krom ke Kubernetes estas agordita el la skatolo por uzi ĝin, kaj vi ne povas forigi ĝin. Ĉi tio estas bonega por komenci kaj malaltefikajn sistemojn, sed mi ne rekomendus uzi la defaŭltan nomspacon ĉe grandaj prodsistemoj. En ĉi-lasta kazo, unu disvolva teamo povas facile reverki la kodon de iu alia kaj rompi la laboron de alia teamo sen eĉ rimarki ĝin.
Tial vi devus krei plurajn nomspacojn kaj uzi ilin por segmenti viajn servojn en regeblajn unuojn. Nomspaco povas esti kreita per ununura komando. Se vi volas krei nomspacon nomitan testo, tiam uzu la komandon $ kubectl create namespace test aŭ simple kreu YAML-dosieron kaj uzu ĝin kiel ajnan alian rimedon de Kubernetes.
Vi povas vidi ĉiujn nomspacojn uzante la komandon $kubectl get namespace.
Post kiam ĝi estas farita, vi vidos tri enkonstruitajn nomspacojn kaj novan nomspacon nomitan "testo". Ni rigardu simplan YAML-dosieron por krei pod. Vi rimarkos, ke ne estas mencio de nomspaco.
Se vi uzas kubectl por ruli ĉi tiun dosieron, ĝi kreos la mypod-modulon en la nuntempe aktiva nomspaco. Ĉi tio estos la defaŭlta nomspaco ĝis vi ŝanĝos ĝin. Estas 2 manieroj diri al Kubernetes en kiu nomspaco vi volas krei vian rimedon. La unua maniero estas uzi nomspaca flago dum kreado de rimedo.
La dua maniero estas specifi la nomspacon en la YAML-deklaro.
Se vi specifas nomspacon en YAML, la rimedo ĉiam estos kreita en tiu nomspaco. Se vi provas uzi alian nomspacon dum vi uzas la nomspacon, la komando malsukcesos. Nun se vi provos trovi vian pod, vi ne povos fari tion.
Ĉi tio okazas ĉar ĉiuj komandoj estas ekzekutitaj ekster la nuntempe aktiva nomspaco. Por trovi vian podon, vi devas uzi nomspacon, sed ĉi tio malnoviĝas rapide, precipe se vi estas programisto en teamo, kiu uzas sian propran nomspacon kaj ne volas uzi tiun flagon por ĉiu unuopa komando. Ni vidu kiel ni povas ripari ĉi tion.
El la skatolo, via aktiva nomspaco nomiĝas defaŭlta. Se vi ne specifas nomspacon en la rimedo YAML, tiam ĉiuj Kubernetes-komandoj uzos ĉi tiun aktivan defaŭltan nomspacon. Bedaŭrinde, provi administri la aktivan nomspacon uzante kubectl povas malsukcesi. Tamen, ekzistas tre bona ilo nomata Kubens, kiu faciligas ĉi tiun procezon. Kiam vi rulas la komandon kubens, vi vidas ĉiujn nomspacojn kun la aktiva nomspaco emfazita.
Por ŝanĝi la aktivan nomspacon al la testa nomspaco, vi simple rulu la testan komandon $kubens. Se vi poste rulas la komandon $kubens denove, vi vidos, ke nova aktiva nomspaco nun estas asignita - test.
Ĉi tio signifas, ke vi ne bezonas la nomspacon flagon por vidi la pod en la testa nomspaco.
Tiel la nomspacoj estas kaŝitaj unu de la alia, sed ne izolitaj unu de la alia. Servo en unu nomspaco povas sufiĉe facile komuniki kun servo en alia nomspaco, kio ofte estas tre utila. La kapablo komuniki trans malsamaj nomspacoj signifas, ke la servo de viaj programistoj povas komuniki kun la servo de alia dev-teamo en malsama nomspaco.
Kutime, kiam via aplikaĵo volas aliri Kubernetes-servon, vi uzas la enkonstruitan DNS-malkovran servon kaj simple donas al via aplikaĵo la nomon de la servo. Tamen, farante tion, vi povas krei servon sub la sama nomo en pluraj nomspacoj, kio ne estas akceptebla.
Feliĉe, ĉi tio estas facile ĉirkaŭiri uzante la vastigitan formon de la DNS-adreso. Servoj en Kubernetes elmontras siajn finpunktojn uzante komunan DNS-ŝablonon. Ĝi aspektas kiel ĉi tio:
Kutime, vi nur bezonas la servonomon kaj DNS aŭtomate determinos la plenan adreson.
Tamen, se vi bezonas aliri servon en malsama nomspaco, simple uzu la servonomon plus la nomspacan nomon:
Ekzemple, se vi volas konektiĝi al serva datumbazo en prova nomspaco, vi povas uzi la adresdatumbazon database.test
Se vi volas konektiĝi al la serva datumbazo en la prod nomspaco, vi uzas database.prod.
Se vi vere volas izoli kaj limigi nomspacan aliron, Kubernetes permesas vin fari tion uzante Kubernetes-Retajn Politikojn. Mi parolos pri tio en la venonta epizodo.
Ofte oni demandas min, kiom da nomspacoj mi kreu kaj por kia celo? Kio estas administrita datumo?
Se vi kreas tro da nomspacoj, ili nur malhelpos vian vojon. Se estas tro malmultaj el ili, vi perdos ĉiujn avantaĝojn de tia solvo. Mi pensas, ke estas kvar ĉefaj etapoj, kiujn ĉiu kompanio trairas kiam kreas sian organizan strukturon. Depende de la stadio de evoluo en kiu troviĝas via projekto aŭ kompanio, vi eble volas adopti taŭgan nomspacan strategion.
Imagu, ke vi estas parto de malgranda teamo, kiu laboras pri disvolvado de 5-10 mikroservoj kaj vi povas facile kunvenigi ĉiujn programistojn en unu ĉambro. En ĉi tiu situacio, havas sencon ruli ĉiujn prod-servojn en la defaŭlta nomspaco. Kompreneble, por pli da fleksebleco, vi povas uzi 2 nomspacojn - aparte por prod kaj dev. Kaj plej verŝajne vi testas vian disvolviĝon en via loka komputilo uzante ion kiel Minikube.
Ni diru, ke aferoj ŝanĝiĝas kaj vi nun havas rapide kreskantan teamon laborantan pri pli ol 10 mikroservoj samtempe. Venas tempo, kiam necesas uzi plurajn aretojn aŭ nomspacojn, aparte por prod kaj dev. Vi povas dividi la teamon en plurajn subteamojn por ke ĉiu el ili havu siajn proprajn mikroservojn kaj ĉiu el ĉi tiuj teamoj povas elekti sian propran nomspacon por faciligi la procezon de administrado de programaro-disvolviĝo kaj liberigo.
Ĉar ĉiu grupano akiras sciojn pri kiel la sistemo kiel tutaĵo funkcias, fariĝas pli kaj pli malfacile kunordigi ĉiun ŝanĝon kun ĉiuj aliaj programistoj. Provi ŝpini plenan stakon sur via loka maŝino fariĝas pli malfacila ĉiutage.
En grandaj kompanioj, programistoj ĝenerale ne scias, kiu precize laboras pri kio. Teamoj komunikas uzante servajn kontraktojn aŭ uzas servan mesh-teknologion, kiu aldonas abstraktan tavolon tra la reto, kiel la agorda ilo Istio. Provi prizorgi tutan stakon loke simple ne eblas.Mi tre rekomendas uzi daŭran liveran (KD) platformon kiel Spinnaker ĉe Kubernetes. Do, venas punkto, kie ĉiu komando certe bezonas sian propran nomspacon. Ĉiu teamo eĉ povas elekti plurajn nomspacojn por la dev-medio kaj la prod-medio.
Fine, ekzistas grandaj entreprenaj kompanioj, en kiuj unu grupo de programistoj eĉ ne scias pri la ekzisto de aliaj grupoj. Tia firmao ĝenerale povas dungi triapartajn programistojn, kiuj interagas kun ĝi per bone dokumentitaj APIoj. Ĉiu tia grupo enhavas plurajn teamojn kaj plurajn mikroservojn. En ĉi tiu kazo, vi devas uzi ĉiujn ilojn, pri kiuj mi parolis antaŭe.
Programistoj ne devus mane deploji servojn kaj ne devus havi aliron al nomspacoj kiuj ne koncernas ilin. En ĉi tiu etapo, estas konsilinde havi plurajn aretojn por redukti la "eksplodan radiuson" de malbone agorditaj aplikoj, por simpligi fakturajn procezojn kaj administradon de rimedoj.
Tiel, taŭga uzo de nomspacoj fare de via organizo permesas vin fari Kubernetes pli regebla, kontrolebla, sekura kaj fleksebla.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com