{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 bedste praksisser for containerdrift if\u00f8lge Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem. overs.<\/b>: Forfatteren af den originale artikel er Th\u00e9o Chamley, cloud-l\u00f8sningarkitekt hos Google. I dette blogindl\u00e6g for Google Cloud pr\u00e6senterede han et kort resum\u00e9 af en mere detaljeret vejledning fra hans virksomhed, kaldet \"Bedste praksis for drift af containere<\/a><\/noindex>\u00bb. I den har Google-specialister samlet de bedste praksisser for drift af containere i konteksten af brugen af Google Kubernetes Engine og mere, ber\u00f8rt et bredt spektrum af emner: fra sikkerhed til overv\u00e5gning og logf\u00f8ring. S\u00e5 hvilke praksisser i arbejdet med containere er mest vigtige if\u00f8lge Google?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (en Kubernetes-baseret service til at k\u00f8re containeriserede applikationer i Google Cloud \u2014 ft. overs.<\/b>)<\/i> \u2014 er en af de bedste m\u00e5der at k\u00f8re arbejdsbyrder, der har brug for skalering. Kubernetes<\/a><\/noindex> vil sikre problemfri drift for de fleste applikationer, hvis de er containeriserede. Men hvis du \u00f8nsker, at applikationen skal v\u00e6re nem at administrere og \u00f8nsker at drage fordel af alle fordelene ved Kubernetes, er det n\u00f8dvendigt at f\u00f8lge bedste praksis. De vil forenkle driften af applikationen, dens overv\u00e5gning og fejlfinding samt \u00f8ge sikkerheden.<\/p>\n

I denne artikel gennemg\u00e5r vi listen over det, du b\u00f8r vide og g\u00f8re for effektiv drift af containere i Kubernetes. For dem, der \u00f8nsker at dykke ned i detaljerne, er det v\u00e6rd at l\u00e6se materialet Bedste praksis for drift af containere<\/a><\/noindex>, samt tage et kig p\u00e5 vores tidligere indl\u00e6g<\/a><\/noindex> om bygning af containere.<\/p>\n

1. Brug indf\u00f8dte mekanismer til containerlogf\u00f8ring<\/h2>\n

\nHvis applikationen k\u00f8rer i et Kubernetes-kluster, kr\u00e6ves der ikke meget til logs. Et centraliseret logf\u00f8ringssystem er sandsynligvis allerede indbygget i det anvendte kluster. I tilf\u00e6lde af brug af Kubernetes Engine varetages dette af Stackdriver Logging<\/a><\/noindex>. (Bem. overs.<\/b>: Ved brug af en egen installation af Kubernetes anbefaler vi at se n\u00e6rmere p\u00e5 vores Open Source-l\u00f8sning \u2014 loghouse<\/a><\/noindex>.)<\/i> G\u00f8r ikke livet sv\u00e6rere for dig selv og brug de indf\u00f8dte mekanismer til containerlogf\u00f8ring. Skriv logs til stdout og stderr \u2014 de vil automatisk blive opsamlet, gemt og indekseret.<\/p>\n

Hvis \u00f8nskes, kan du ogs\u00e5 skrive logs til JSON-format<\/a><\/noindex>. Denne tilgang vil g\u00f8re det nemt at tilf\u00f8je metadata. Sammen med dem vil der i Stackdriver Logging v\u00e6re mulighed for at s\u00f8ge i logs ved hj\u00e6lp af disse metadata.<\/p>\n

2. S\u00f8rg for at containerne er stateless og immutable<\/h2>\n

\nFor the correct functioning of containers in a Kubernetes cluster, they must be stateless and immutable. When these conditions are met, Kubernetes will be able to perform its tasks by creating and destroying application entities as needed.<\/p>\n

Stateless<\/i> means that any state (permanent data of any kind) is stored outside the container. For this purpose, depending on needs, different types of external storage can be employed: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> or other managed databases. (Bem. overs.<\/b>: You can read more about this in our article \u201cOperatorer til Kubernetes: hvordan man k\u00f8rer stateful-applikationer.<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> means that the container will not be modified during its lifetime: no updates, patches, or configuration changes. If you need to update the application code or apply a patch, create a new image and deploy it. It is recommended to move container configuration (listening port, execution environment options, etc.) outside to Secrets<\/a><\/noindex> og ConfigMaps<\/a><\/noindex>. They can be updated without the need to build a new container image. For simple image building pipelines, you can use Cloud Build<\/a><\/noindex>. (Bem. overs.<\/b>: We use the open-source tool dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nExample of updating Deployment configuration in Kubernetes using a ConfigMap mounted in pods as config.<\/i><\/p>\n

3. Avoid privileged containers<\/h2>\n

\nDu k\u00f8rer ikke applikationer som root p\u00e5 dine servere, g\u00f8r du? Hvis en angriber f\u00e5r adgang til applikationen, f\u00e5r de root-adgang. De samme overvejelser g\u00e6lder for ikke at k\u00f8re privilegerede containere. Hvis der er behov for at \u00e6ndre indstillinger p\u00e5 v\u00e6rten, kan du give containeren specifikke capabilities<\/i> using the option securityContext<\/code><\/a><\/noindex> in Kubernetes. If you need to change sysctls<\/i>, Kubernetes has a separate annotation<\/a><\/noindex> for this. In general, try to maximize the use of init-<\/a><\/noindex> and sidecar containers for performing such privileged operations. They do not require availability for internal or external traffic.<\/p>\n

If you administer a cluster, you can use Pod Security Policy<\/a><\/noindex> for restrictions on the use of privileged containers.<\/p>\n

4. Avoid running as root<\/h2>\n

\nDer er allerede blevet sagt noget om privilegerede containere, men det vil v\u00e6re endnu bedre, hvis du ogs\u00e5 undg\u00e5r at k\u00f8re applikationer inde i containeren som root. Hvis en angriber finder en fjern-s\u00e5rbarhed med kodeudf\u00f8relsesmulighed i en applikation med root-adgang, og derefter finder en endnu ukendt s\u00e5rbarhed for at tr\u00e6nge ud af containeren, vil de f\u00e5 root-adgang p\u00e5 v\u00e6rten.<\/p>\n

Den bedste m\u00e5de at undg\u00e5 dette p\u00e5 er f\u00f8rst og fremmest at undg\u00e5 at k\u00f8re noget som root. Til dette kan du bruge direktivet USER<\/code> i Dockerfile<\/code> eller runAsUser<\/code> i Kubernetes. Clusteradministratoren kan ogs\u00e5 konfigurere tvingende adf\u00e6rd ved hj\u00e6lp af Pod Security Policy<\/a><\/noindex>.<\/p>\n

5. G\u00f8r applikationen let at overv\u00e5ge<\/h2>\n

\nLigesom logning er overv\u00e5gning en integreret del af applikationsstyring. En popul\u00e6r l\u00f8sning til overv\u00e5gning i Kubernetes-f\u00e6llesskabet er Prometheus<\/a><\/noindex> \u2014 et system, der automatisk opdager pods og tjenester, der kr\u00e6ver overv\u00e5gning. (Bem. overs.<\/b>: Se ogs\u00e5 vores detaljerede rapport<\/a><\/noindex> om overv\u00e5gning ved hj\u00e6lp af Prometheus og Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> kan overv\u00e5ge Kubernetes-klynger og inkluderer sin egen version af Prometheus til overv\u00e5gning af applikationer.<\/p>\n

\"7
\nKubernetes-overv\u00e5gningspanelet i Stackdriver<\/i><\/p>\n

For at Prometheus kan fungere korrekt, skal applikationen eksponere metrics p\u00e5 et HTTP-endpoint. Der er tilg\u00e6ngelige Prometheus-klientbiblioteker<\/a><\/noindex>. Det samme format bruges af andre v\u00e6rkt\u00f8jer som OpenCensus<\/a><\/noindex> og Istio<\/a><\/noindex>.<\/p>\n

6. G\u00f8r applikationens sundhedstilstand tilg\u00e6ngelig<\/h2>\n

\nForvaltningen af en applikation i produktion underst\u00f8ttes af dens evne til at rapportere sin tilstand til hele systemet. K\u00f8rer applikationen? Er den i orden? Klar til at modtage trafik? Hvordan opf\u00f8rer den sig? Den mest almindelige m\u00e5de at l\u00f8se dette problem p\u00e5 er implementeringen af sundhedschecks (health checks)<\/i>. Kubernetes har to typer af dem: liveness og readiness probes<\/a><\/noindex>.<\/p>\n

For liveness probe (livability checks)<\/i> skal applikationen have et HTTP-endpoint, der returnerer svaret \"200 OK\", hvis det fungerer, og dets grundl\u00e6ggende afh\u00e6ngigheder er opfyldt. For readiness probe (service readiness check)<\/i> applikationen skal have en anden HTTP-endpoint, der returnerer svaret \"200 OK\", hvis applikationen er sund, initialiseringstrinene er fuldf\u00f8rt, og enhver korrekt anmodning ikke f\u00f8rer til en fejl. Kubernetes vil kun dirigere trafik til containeren, n\u00e5r applikationen er klar i henhold til disse kontroller. To endpoints kan kombineres, hvis der ikke er nogen forskel mellem tilstandene for livbarhed (liveness) og beredskab (readiness).<\/p>\n

L\u00e6s mere om dette i den relevante artikel af Sandeep Dinesh, Developer Advocate fra Google: \u00abKubernetes bedste praksis: Ops\u00e6tning af sundhedstjek med klarheds- og livsgyldighedsprober<\/a><\/noindex>\u00bb.<\/p>\n

7. V\u00e6lg omhyggeligt billedversionen<\/h2>\n

\nDe fleste offentlige og private billeder bruger et taggingsystem, der ligner det, der er beskrevet i Best Practices for Building Containers<\/a><\/noindex>. Hvis billedet anvender et system t\u00e6t p\u00e5 semantisk versionering<\/a><\/noindex>, skal der tages hensyn til specifikationen af tagningen. For eksempel kan tagget latest<\/code> ofte flytte fra billede til billede \u2014 det kan ikke stole p\u00e5, hvis du har brug for forudsigelige og reproducerbare builds og installationer.<\/p>\n

Du kan bruge tagget X.Y.Z<\/code> (de er n\u00e6sten altid u\u00e6ndrede), men i s\u00e5 fald skal du holde \u00f8je med alle patches og opdateringer til billedet. Hvis det anvendte billede har tagget X.Y<\/code>, er det et godt valg af gylden mellemvej. Ved at v\u00e6lge det f\u00e5r du automatisk patches og samtidig baserer dig p\u00e5 en stabil version af applikationen.<\/p>\n

P.S. fra overs\u00e6tteren<\/h2>\n

\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n