{"id":82223,"date":"2020-05-20T13:42:34","date_gmt":"2020-05-20T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen"},"modified":"2020-05-20T13:42:34","modified_gmt":"2020-05-20T11:42:34","slug":"luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","title":{"rendered":"De bedste Kubernetes-praksis. Organisering af Kubernetes med navnerum","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De bedste Kubernetes-praksis. Oprettelse af sm\u00e5 containere<\/a><\/noindex><\/p>\n

N\u00e5r du begynder at oprette flere og flere Kubernetes-tjenester, bliver de enkle opgaver, der engang var enkle, mere komplekse. For eksempel kan udviklingsteams ikke oprette tjenester eller implementeringer med det samme navn. Hvis du har tusind pods, vil det tage lang tid bare at opregne dem, for ikke at n\u00e6vne at sikre ordentlig administration. Og dette er kun toppen af isbjerget.<\/p>\n

Lad os se p\u00e5, hvordan navneomr\u00e5der g\u00f8r det lettere at administrere Kubernetes-ressourcer. S\u00e5 hvad er et navneomr\u00e5de? Et navneomr\u00e5de kan betragtes som et virtuelt kluster inden for dit Kubernetes-kluster. Du kan have flere isolerede navneomr\u00e5der inden for et enkelt Kubernetes-kluster. De kan virkelig hj\u00e6lpe dig og dine teams med organisering, sikkerhed og endda systemets pr\u00e6station.<\/p>\n

\"De
\n
\nI de fleste Kubernetes-distributioner kommer klustret \"ud af boksen\" med et navneomr\u00e5de, der hedder \"default\". Der findes faktisk tre navneomr\u00e5der, som Kubernetes besk\u00e6ftiger sig med: default, kube-system og kube-public. I \u00f8jeblikket bruges kube-public ikke s\u00e5 ofte.<\/a><\/noindex><\/p>\n

\"De
\n
\nDet er en god id\u00e9 ikke at r\u00f8re ved kube-navneomr\u00e5det, is\u00e6r i et administreret system som Google Kubernetes Engine. Det bruger \"default\"-navneomr\u00e5det som stedet, hvor dine tjenester og applikationer oprettes. Der er absolut ikke noget specielt ved det, bortset fra at Kubernetes \"ud af boksen\" er konfigureret til at bruge det, og du kan ikke slette det. Det er godt til at komme i gang og til systemer med lav kapacitet, men jeg vil ikke anbefale at bruge default-navneomr\u00e5det i st\u00f8rre produktionssystemer. I sidstn\u00e6vnte tilf\u00e6lde kan et udviklingsteam nemt overskrive en andens kode og forstyrre et andet teams arbejde uden at v\u00e6re klar over det.<\/p>\n

Derfor b\u00f8r du skabe flere navneomr\u00e5der og bruge dem til at segmentere dine tjenester i administrerede enheder. Et navneomr\u00e5de kan oprettes med en enkelt kommando. Hvis du vil oprette et navneomr\u00e5de med navnet test, skal du bruge kommandoen $ kubectl create namespace test eller blot oprette en YAML-fil og bruge den ligesom enhver anden Kubernetes-ressource.<\/p>\n

\"De
\n
\nFor at se alle navneomr\u00e5der kan du bruge kommandoen $ kubectl get namespace. <\/p>\n

\"De
\n
\nN\u00e5r du har udf\u00f8rt dette, vil du se tre indbyggede navnerum og et nyt navnerum ved navn \u00abtest\u00bb. Lad os se p\u00e5 en enkel YAML-fil, der er beregnet til at oprette en pod. Du vil bem\u00e6rke, at der ikke er nogen omtale af navnerummet i den.<\/p>\n

\"De
\n
\nHvis du bruger kubectl til at k\u00f8re denne fil, vil den oprette modulet mypod i det aktuelle aktive navnerum. Dette vil v\u00e6re standardnavnerummet, indtil du \u00e6ndrer det. Der er to m\u00e5der at fort\u00e6lle Kubernetes, hvilket navnerum du \u00f8nsker at oprette din ressource i. Den f\u00f8rste m\u00e5de er at bruge navnerum-flaget, n\u00e5r du opretter ressourcen. <\/p>\n

\"De
\n
\nDen anden m\u00e5de er at angive navnerummet i YAML-deklarationen.<\/p>\n

\"De
\n
\nHvis du angiver navnerummet i YAML, vil ressourcen altid blive oprettet i dette navnerum. Hvis du fors\u00f8ger at bruge et andet navnerum med navnerum-flaget, vil kommandoen fejle. Nu, hvis du pr\u00f8ver at finde din pod, vil du ikke v\u00e6re i stand til at g\u00f8re det. <\/p>\n

\"De
\n
\nDette skyldes, at alle kommandoer k\u00f8res uden for det aktuelle aktive navnerum. For at finde din pod skal du bruge navnerum-flaget, men det kan hurtigt blive besv\u00e6rligt, is\u00e6r hvis du arbejder som udvikler i en gruppe, der bruger sit eget navnerum og ikke \u00f8nsker at bruge dette flag for hver enkelt kommando. Lad os se p\u00e5, hvordan vi kan l\u00f8se dette.<\/p>\n

\"De
\n
\nSom standard hedder dit aktive navnerum default. Hvis du ikke angiver navnerum i YAML-ressourcen, vil alle Kubernetes-kommandoer bruge dette aktive default-navnerum. Desv\u00e6rre kan det v\u00e6re vanskeligt at h\u00e5ndtere det aktive navnerum med kubectl. Men der er et rigtig godt v\u00e6rkt\u00f8j kaldet Kubens, der g\u00f8r denne proces meget lettere. N\u00e5r du k\u00f8rer kommandoen kubens, kan du se alle navnerum med det aktive navnerum fremh\u00e6vet. <\/p>\n

\"De
\n
\nFor at skifte det aktive navnerum til navnerummet test skal du blot k\u00f8re kommandoen $ kubens test. Hvis du derefter igen skriver kommandoen $ kubens, kan du se, at det nu fremh\u00e6ver det nye aktive navnerum \u2013 test.<\/p>\n

\"De
\n
\nDet betyder, at du ikke har brug for et navneomr\u00e5deflag for at se pod'en i navneomr\u00e5det test.<\/p>\n

\"De
\n
\nP\u00e5 denne m\u00e5de er navneomr\u00e5der skjult for hinanden, men ikke isoleret fra hinanden. En tjeneste fra et navneomr\u00e5de kan ganske let kommunikere med en tjeneste i et andet navneomr\u00e5de, hvilket ofte er meget nyttigt. Muligheden for kommunikation mellem forskellige navneomr\u00e5der betyder, at din udviklerteams tjeneste kan interagere med en tjeneste fra et andet dev-team i et andet navneomr\u00e5de.<\/p>\n

Som regel, n\u00e5r din applikation \u00f8nsker at f\u00e5 adgang til en Kubernetes-tjeneste, bruger du den indbyggede DNS-opdagelsestjeneste og angiver blot tjenestens navn til din applikation. Men du kan dog oprette en tjeneste med samme navn i flere navneomr\u00e5der, hvilket ikke er tilladt. <\/p>\n

\"De
\n
\nHeldigvis er det nemt at omg\u00e5 dette ved at bruge den udvidede form af DNS-adressen. Tjenester i Kubernetes eksponerer deres slutpunkter ved hj\u00e6lp af et f\u00e6lles DNS-m\u00f8nster. Det ser omtrent s\u00e5dan ud:<\/p>\n

\"De
\n
\nSom regel beh\u00f8ver du kun tjenestens navn, og DNS vil automatisk bestemme den fulde adresse. <\/p>\n

\"De
\n
\nMen hvis du har brug for at f\u00e5 adgang til en tjeneste i et andet navneomr\u00e5de, skal du blot bruge tjenestens navn plus navneomr\u00e5det:<\/p>\n

\"De
\n
\nFor eksempel, hvis du \u00f8nsker at oprette forbindelse til databasen for tjenesten i testnavneomr\u00e5det, kan du bruge database.test<\/p>\n

\"De
\n
\nHvis du derimod \u00f8nsker at oprette forbindelse til databasen for tjenesten i navneomr\u00e5det prod, bruger du database.prod.<\/p>\n

\"De
\n
\nHvis du virkelig \u00f8nsker at isolere og begr\u00e6nse adgangen til navneomr\u00e5det, tillader Kubernetes det ved hj\u00e6lp af Kubernetes Netv\u00e6rkspolitikker. Dette vil jeg tale om i den n\u00e6ste serie. <\/p>\n

Jeg bliver ofte spurgt, hvor mange navneomr\u00e5der der skal oprettes, og til hvilke form\u00e5l? Hvad udg\u00f8r et administreret datastykke?<\/p>\n

Hvis du opretter for mange navnerum, vil de blot v\u00e6re til hinder for dig. Hvis derimod er de for f\u00e5, mister du alle fordelene ved en s\u00e5dan l\u00f8sning. Jeg mener, at der er fire grundl\u00e6ggende faser, som hver virksomhed gennemg\u00e5r i processen med at opbygge sin organisationsstruktur. Afh\u00e6ngigt af udviklingsstadiet for dit projekt eller din virksomhed, kan du anvende en passende strategi for oprettelse af navnerum.<\/p>\n

Forestil dig, at du er en del af et lille team, der arbejder p\u00e5 udviklingen af 5-10 mikrotjenester, og du nemt kan samle alle udviklerne i et rum. I denne situation giver det mening at k\u00f8re alle prod-tjenester i navnerummet default. Selvf\u00f8lgelig, for mere fleksibilitet kan du bruge 2 navnerum \u2014 et til prod og et til dev. Og sandsynligvis tester du din udvikling p\u00e5 din lokale computer ved hj\u00e6lp af noget som Minikube. <\/p>\n

Antag, at omst\u00e6ndighederne har \u00e6ndret sig, og nu har du et hurtigt voksende team, der samtidig arbejder p\u00e5 mere end 10 mikrotjenester. Der kommer et tidspunkt, hvor det er n\u00f8dvendigt at bruge flere klynger eller navnerum, separat til prod og dev. Du kan opdele teamet i flere undergrupper, s\u00e5 hver af dem har sine egne mikrotjenester, og hver af disse grupper kan v\u00e6lge sit eget navnerum for at lette styringen af udviklings- og udgivelsesprocessen.<\/p>\n

\"De
\n
\nEfterh\u00e5nden som hver medlem af teamet f\u00e5r en forst\u00e5else for, hvordan systemet fungerer, bliver det sv\u00e6rere og sv\u00e6rere at koordinere hvert \u00e6ndring med de andre udviklere. At fors\u00f8ge at rulle den komplette stak ud p\u00e5 din lokale computer bliver hver dag mere udfordrende. <\/p>\n

I store store so they don\u2019t know who works on what. Teams communicate through service contracts or use Service mesh technology, which adds a layer of abstraction over the network, like the configuration tool Istio. Attempting to run the entire stack locally is simply impossible. I strongly recommend using a continuous delivery (CD) platform like Spinnaker in Kubernetes. Thus, the moment comes when each team certainly needs its own namespace. Each team can even choose multiple namespaces for the dev and prod environments. <\/p>\n

Finally, there are large entrepreneurial companies where one group of developers doesn\u2019t even know about the existence of other groups. Such a company may even hire third-party developers who interact through well-documented APIs. Each of these groups has several teams and multiple microservices. In this case, it is necessary to use all the tools I mentioned earlier.<\/p>\n

\"De
\n
\nProgrammers should not deploy services manually and should not have access to namespaces that are not relevant to them. At this stage, it is reasonable to have multiple clusters to reduce the 'blast radius' of badly configured applications, to simplify billing processes, and to manage resources.<\/p>\n

Thus, the proper use of namespaces by your organization allows Kubernetes to be more manageable, controllable, secure, and flexible.<\/p>\n

De bedste Kubernetes-praksis. Kontrol af Kubernetes' levedygtighed med Readiness- og Liveness-tests<\/a><\/noindex><\/p>\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Lidt reklame \ud83d\ude42<\/h3>\n

\nTak fordi du bliver hos os. Kan du lide vores artikler? \u00d8nsker du at se flere interessante materialer? St\u00f8t os ved at bestille eller anbefale os til dine bekendte, cloud VPS til udviklere fra 4,99 $<\/a><\/noindex>, en unik analog til entry-level servere, som vi har designet til dig:<\/b> Alt om VPS (KVM) E5-2697 v3 (6 kerner) 10 GB DDR4 480 GB SSD 1 Gbps fra 19 $ eller hvordan man deler serveren korrekt?<\/a><\/noindex> (tilg\u00e6ngelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).<\/p>\n

Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam?<\/b> Kun hos os 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB fra 199 $<\/a><\/noindex> i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $!<\/b><\/b> L\u00e6s om hvordan man bygger enterprise-infrastruktur ved hj\u00e6lp af Dell R730xd E5-2650 v4 servere til 9000 euro for en br\u00f8kdel af prisen?<\/a><\/noindex>
\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u041f\u043e \u043c\u0435\u0440\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u0432\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442\u0435 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438 \u0431\u043e\u043b\u044c\u0448\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 Kubernetes, \u043f\u0440\u043e\u0441\u0442\u044b\u0435 \u043f\u043e \u043d\u0430\u0447\u0430\u043b\u0443 \u0437\u0430\u0434\u0430\u0447\u0438 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0442 \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u0442\u044c\u0441\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u043d\u0435 \u043c\u043e\u0433\u0443\u0442 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0436\u0431\u044b \u0438\u043b\u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u0434 \u043e\u0434\u043d\u0438\u043c \u0438 \u0442\u0435\u043c \u0436\u0435 \u0438\u043c\u0435\u043d\u0435\u043c. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0442\u044b\u0441\u044f\u0447\u0438 \u043f\u043e\u0434\u043e\u0432, \u0438\u0445 \u043f\u0440\u043e\u0441\u0442\u043e\u0435 \u043f\u0435\u0440\u0435\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u0435 \u0437\u0430\u0439\u043c\u0435\u0442 \u043a\u0443\u0447\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u043d\u0435 \u0433\u043e\u0432\u043e\u0440\u044f \u043e \u0442\u043e\u043c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82224,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82223","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Bedste praksis for Kubernetes. Organisation af Kubernetes med navnerum | ProHoster","description":"Bedste praksis for Kubernetes.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f Kubernetes \u0441 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e\u043c \u0438\u043c\u0435\u043d | ProHoster","og:description":"\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-20T11:42:34+00:00","article:modified_time":"2020-05-20T11:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82223","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:41:29","updated":"2022-09-29 19:27:31","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=82223"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82223\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/82224"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=82223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=82223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=82223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}