{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"De bedste Kubernetes-praksis. Oprettelse af sm\u00e5 containere","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De
\n
\nDet f\u00f8rste skridt i implementeringen af Kubernetes er at placere din applikation i en container. I denne serie vil vi se, hvordan man kan oprette et billede af en lille og sikker container.
\nMed Docker har det aldrig v\u00e6ret nemmere at oprette containerbilleder. Angiv et grundl\u00e6ggende billede, tilf\u00f8j dine \u00e6ndringer, og opret en container.<\/p>\n

\"De
\n
\nSelvom denne metode er god til at komme i gang, kan brugen af standard grundbilleder f\u00f8re til usikker drift med store billeder, der er fyldt med s\u00e5rbarheder.<\/a><\/noindex><\/p>\n

Desuden bruger de fleste billeder i Docker enten Debian eller Ubuntu som grundbillede, og selvom det sikrer fremragende kompatibilitet og nem tilpasning (Docker-filen fylder kun to linjer kode), kan grundbillederne tilf\u00f8je hundredvis af megabyte yderligere belastning til din container. For eksempel fylder en simpel node.js Go 'hello-world' applikation omkring 700 megabyte, mens st\u00f8rrelsen p\u00e5 selve din applikation kun er et par megabyte.<\/p>\n

\"De
\n
\nDermed er al denne ekstra belastning en spild af digital plads og en fremragende skjulested for s\u00e5rbarheder og sikkerhedsfejl. Lad os derfor se p\u00e5 to m\u00e5der at reducere st\u00f8rrelsen af containerbilledet. <\/p>\n

Den f\u00f8rste er at bruge grundbilleder af lille st\u00f8rrelse, og den anden er at bruge designm\u00f8nstret Builder Pattern. At bruge mindre grundbilleder er sandsynligvis den nemmeste m\u00e5de at reducere st\u00f8rrelsen p\u00e5 din container. Dit sprog eller den stak, du bruger, giver sandsynligvis et grundbillede af applikationen, der er meget mindre end standardbilledet. Lad os tage et kig p\u00e5 vores node.js container. <\/p>\n

\"De
\n
\nSom standard er st\u00f8rrelsen p\u00e5 Docker-billedet node:8 670 MB, mens st\u00f8rrelsen p\u00e5 node:8-alpine kun er 65 MB, alts\u00e5 ti gange mindre. Ved at bruge det mindre Alpine-billede reducerer du betydeligt st\u00f8rrelsen p\u00e5 din container. Alpine er en lille og let Linux-distribution, der er meget popul\u00e6r blandt Docker-brugere, da den er kompatibel med mange applikationer, mens den stadig holder containere sm\u00e5. I mods\u00e6tning til det standard Docker-billede \"node\" fjerner \"node:alpine\" mange hj\u00e6lpefiler og programmer, og efterlader kun de filer, der er n\u00f8dvendige for at k\u00f8re din applikation.<\/p>\n

For at skifte til et mindre basebillede skal du blot opdatere Docker-filen for at begynde at arbejde med det nye basebillede:<\/p>\n

\"De
\n
\nNu, i mods\u00e6tning til det gamle onbuild-billede, skal du kopiere din kode til containeren og installere eventuelle afh\u00e6ngigheder. I den nye Docker-fil starter containeren med billedet node:alpine, derefter oprettes der en mappe til koden, afh\u00e6ngighederne installeres via NPM-pakkeh\u00e5ndtereren, og til sidst startes server.js.<\/p>\n

\"De
\n
\nMed denne opdatering f\u00e5r du en container, der er ti gange mindre. Hvis dit programmeringssprog eller din stak ikke har en funktion til at reducere basebilledet, skal du bruge Alpine Linux. Det vil ogs\u00e5 give dig mulighed for helt at styre indholdet af containeren. At bruge sm\u00e5 basebilleder er en fantastisk m\u00e5de at hurtigt oprette sm\u00e5 containere p\u00e5. Men endnu mere reduktion kan opn\u00e5s ved at bruge Builder Pattern.<\/p>\n

\"De
\n
\nI fortolkningsbaserede sprog overf\u00f8res kildekoden f\u00f8rst til fortolkeren, hvorefter den udf\u00f8res direkte. I kompilering-sprog omdannes kildekoden p\u00e5 forh\u00e5nd til kompileret kode. Undervejs bruger kompileringen ofte v\u00e6rkt\u00f8jer, der faktisk ikke er n\u00f8dvendige for at k\u00f8re koden. Det betyder, at du kan fjerne disse v\u00e6rkt\u00f8jer helt fra den endelige container. Det kan g\u00f8res ved hj\u00e6lp af Builder Pattern.<\/p>\n

\"De
\n
\nKoden oprettes i den f\u00f8rste container og kompileres. Derefter pakkes den kompilerede kode i den endelige container uden kompilatorer og v\u00e6rkt\u00f8jer, der er n\u00f8dvendige for at kompilere denne kode. Lad os f\u00f8re en Go-applikation gennem denne proces. F\u00f8rst skifter vi fra onbuild-billedet til Alpine Linux.<\/p>\n

\"De
\n
\nI den nye Docker-fil starter containeren med billedet golang:alpine. Derefter opretter den en mappe til koden, kopierer den ind i kildekoden, bygger denne kildekode og k\u00f8rer applikationen. Denne container er meget mindre end onbuild-containeren, men den indeholder stadig kompilatoren og andre Go-v\u00e6rkt\u00f8jer, som vi i virkeligheden ikke har brug for. Derfor lad os simpelthen udtr\u00e6kke den kompilerede program og pakke den ind i vores egen container.<\/p>\n

\"De
\n
\nDu kan bem\u00e6rke noget m\u00e6rkeligt i denne Docker-fil: den indeholder to FROM-linjer. Den f\u00f8rste sektion p\u00e5 4 linjer ser pr\u00e6cis ud som den foreg\u00e5ende Docker-fil bortset fra, at den bruger n\u00f8gleordet AS til at give dette skridt et navn. I den n\u00e6ste sektion er der en ny FROM-linje, der g\u00f8r det muligt at starte et nyt billede, hvor vi i stedet for billedet golang:alpine bruger Raw alpine som basisbillede.<\/p>\n

Raw Alpine Linux har ingen installerede SSL-certifikater, hvilket vil f\u00f8re til, at de fleste API-opkald via HTTPS mislykkes, s\u00e5 lad os installere nogle rod-CA-certifikater.<\/p>\n

Og nu det mest interessante: for at kopiere den kompilerede kode fra den f\u00f8rste container til den anden kan vi simpelthen bruge COPY-kommandoen i den 5. linje i den anden sektion. Den vil kun kopiere \u00e9n applikationsfil og vil ikke ber\u00f8re Go-v\u00e6rkt\u00f8jerne. Den nye multi-stage Docker-fil vil indeholde et containerbillede, der kun fylder 12 megabyte, mens det oprindelige containerbillede var 700 megabyte, hvilket er en stor forskel!
\nDermed er brugen af sm\u00e5 basisbilleder og Builder Pattern fremragende metoder til at skabe containere i meget mindre st\u00f8rrelser uden meget arbejde.
\nM\u00e5ske findes der, afh\u00e6ngigt af applikationens stack, flere m\u00e5der at reducere st\u00f8rrelsen p\u00e5 billedet og containeren, men har sm\u00e5 containere virkelig en m\u00e5lelig fordel? Lad os se p\u00e5 to aspekter, hvor sm\u00e5 containere er ekstremt effektive \u2013 det er ydeevne og sikkerhed.<\/p>\n

For assessing performance growth, let's consider the duration of the container creation process, pushing it to the registry, and subsequently pulling it from there. You can see that a smaller container has undeniable advantages over a larger container.<\/p>\n

\"De
\n
\nDocker will cache layers, so subsequent builds will run very quickly. However, in many CI systems used for building and testing containers, layers are not cached, leading to significant time savings. As you can see, the build time for a large container, depending on your machine's power, ranges from 34 to 54 seconds, while using a smaller container optimized with the Builder Pattern reduces this to 23 to 28 seconds. For such operations, the performance gain will be 40-50%. So just think about how many times you build and test your code.<\/p>\n

Once the container is built, you need to push its image to a container registry to use it within your Kubernetes cluster. I recommend using the Google Container Registry.<\/p>\n

\"De
\n
\nBy using Google Container Registry (GCR), you only pay for the raw storage and network, with no additional charges for container management. It's private, secure, and very fast. GCR employs many tricks to speed up the pull operation. As you can see, pushing a Docker Container Image using go:onbuild takes between 15 and 48 seconds, depending on your computer's performance; the same operation with a smaller container takes between 14 and 16 seconds, with the speed advantage being threefold on less powerful machines. For larger machines, the time is fairly similar, as GCR uses a global cache for the shared image repository, meaning you generally don't need to load them. In low-power computers, the CPU becomes a bottleneck, making the advantages of using small containers much more pronounced.<\/p>\n

If you're using GCR, I highly recommend utilizing Google Container Builder (GCB) as part of your build system.<\/p>\n

\"De
\n
\nSom du kan se, muligg\u00f8r brugen af dette v\u00e6rkt\u00f8j langt bedre resultater i reduktionen af Build+Push operationens varighed end selv p\u00e5 en kraftfuld maskine \u2013 i dette tilf\u00e6lde fremskyndes bygge- og overf\u00f8rselsprocessen af containere til v\u00e6rten n\u00e6sten med det dobbelte. Desuden f\u00e5r du 120 minutters gratis bygge-tid hver dag, hvilket i de fleste tilf\u00e6lde opfylder behovene for oprettelse af containere. <\/p>\n

Den n\u00e6ste vigtigste m\u00e5lestok for ydeevne er udvindingshastigheden, eller download af containere (Pull). Og hvis du ikke er meget bekymret for den tid, der bruges til push-operationen, s\u00e5 p\u00e5virker varigheden af pull-processen alvorligt systemets samlede ydeevne. Antag, at du har et klynge best\u00e5ende af tre noder, og en af dem fejler. Hvis du bruger et administrationssystem, som f.eks. Google Kubernetes Engine, vil det automatisk erstatte den ikke-fungerende node med en ny. Men denne nye node vil v\u00e6re helt tom, og du skal overf\u00f8re alle dine containere til den for at f\u00e5 den til at fungere. Hvis pull-operationen tager lang tid, vil din klynge k\u00f8re med nedsat ydeevne hele den tid.<\/p>\n

Der er mange situationer, hvor dette kan ske: det kan v\u00e6re tilf\u00f8jelsen af en ny node til klyngen, opdatering af noderne eller endda skift til en ny container til udrulning. Derfor bliver minimering af pull-udvindingsprocessens tid en afg\u00f8rende faktor. Ubestridelig er det, at en lille container downloader betydeligt hurtigere end en stor. Hvis du bruger flere containere i en Kubernetes-klynge, kan tidsbesparelsen v\u00e6re meget betydelig.<\/p>\n

\"De
\n
\nSe p\u00e5 den medf\u00f8lgende sammenligning: pull-operationen med sm\u00e5 containere tager mellem 4-9 gange kortere tid afh\u00e6ngigt af maskinens ydeevne, end den samme operation der bruger go:onbuild. Brug af f\u00e6lles basisbilleder af sm\u00e5 containere accelererer markant den tid og hastighed, hvormed nye Kubernetes-noder kan udrulles og komme online.<\/p>\n

Lad os se p\u00e5 sp\u00f8rgsm\u00e5let om sikkerhed. Det anses for, at mindre containere er meget mere sikre end store, fordi de har en mindre overflade at angribe. Er det egentlig tilf\u00e6ldet? En af de mest nyttige funktioner ved Google Container Registry er muligheden for automatisk at scanne dine containere for s\u00e5rbarheder. For et par m\u00e5neder siden oprettede jeg b\u00e5de onbuild- og multi-stage containere, lad os derfor se, om der er nogle s\u00e5rbare punkter. <\/p>\n

\"De
\n
\nResultatet er imponerende: i den lille container blev der fundet kun 3 moderate s\u00e5rbarheder, mens der i den store var 16 kritiske og 376 andre s\u00e5rbarheder. Hvis vi ser p\u00e5 indholdet af den store container, kan vi se, at de fleste sikkerhedsproblemer ikke har noget at g\u00f8re med vores applikation, men relaterer sig til programmer, som vi slet ikke bruger. S\u00e5 n\u00e5r folk taler om en stor angrebsoverflade, er det pr\u00e6cis det, de mener. <\/p>\n

\"De
\n
\nKonklusionen er klar: skab sm\u00e5 containere, for de giver reelle fordele for ydeevnen og sikkerheden i dit system. <\/p>\n

De bedste Kubernetes-praksis. Organisering af Kubernetes med navnerum<\/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":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","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\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 praksisser for Kubernetes. Oprettelse af sm\u00e5 containere | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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. \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 | ProHoster","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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:28","updated":"2022-09-28 11:52:01","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\/82244","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=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}