🥇A Google szerint a 7 legjobb konténeres üzemeltetési gyakorlat

Megjegyzés fordítás.: Az eredeti cikk szerzője Théo Chamley, a Google felhőarchitektusa. E blogbejegyzésben a Google Cloud számára rövid összefoglalót mutat be cégének részletesebb útmutatójából, amelyet „A konténerek üzemeltetésének legjobb gyakorlatai”. Ebben a Google szakértői összegyűjtötték a konténerek üzemeltetésének legjobb gyakorlatait a Google Kubernetes Engine használatának kontextusában, és ezeken túl is, széles téma spektrumot felölelve: a biztonságtól a naplózásig és monitorozásig. Tehát melyek a legfontosabb gyakorlatok a Google szerint a konténerekkel való munka során?

Kubernetes Engine (A Kubernetes alapú szolgáltatás a konténerizált alkalmazások futtatására a Google Cloudban — megjegyzés) — az egyik legjobb módja a skálázódást igénylő munkaterhelések futtatásának. Kubernetes Biztosítja a legtöbb alkalmazás zökkenőmentes működését, ha konténerizáltak. De ha azt szeretnéd, hogy az alkalmazás könnyen kezelhető legyen, és szeretnéd kihasználni a Kubernetes összes előnyét, akkor a legjobb gyakorlatokat kell követned. Ezek megkönnyítik az alkalmazás üzemeltetését, monitorozását és hibakeresését, valamint növelik a biztonságot.

Ebben a cikkben végigmegyünk azon, amit tudni és tenni érdemes a konténerek hatékony működéséhez a Kubernetesben. Azoknak, akik szeretnék részletesebben tanulmányozni, érdemes elolvasniuk a A konténerek üzemeltetésének legjobb gyakorlatai, és figyelniük korábbi bejegyzésünkre a konténer-építésről. 1. Használjátok a konténerek natív naplózási mechanizmusait

Ha az alkalmazás egy Kubernetes klaszterben fut, nem szükséges sok a naplóikhoz. A használt klaszterbe valószínűleg már be van építve egy központosított naplózási rendszer. Ha a Kubernetes Engine-t használod, ezt a

Stackdriver Logging felügyeli: Ha saját Kubernetes telepítést használsz, érdemes megvizsgálni a nyílt forráskódú megoldásunkat —. (Megjegyzés fordítás.Ne bonyolítsd az életed, és használd a konténerek natív naplózási mechanizmusait. Írj naplókat az stdout-ba és stderr-be — ezek automatikusan rögzítésre kerülnek, megőrzésre és indexelésre. loghouse.) Igény szerint a naplókat a

is írhatsz. Ez a megközelítés lehetővé teszi, hogy könnyen hozzáadj metainformációkat. A Stackdriver Loggingban így lehetőség nyílik a naplókban a metainformációk alapján való keresésre. JSON formátumban vannak.2. Győződj meg róla, hogy a konténerek stateless és immutable-k

2. Győződjön meg róla, hogy a tartályok stateless és immutable állapotúak.

A Kubernetes cluster's containers must be stateless and immutable for proper functioning. When these conditions are met, Kubernetes will be able to perform its tasks by creating and destroying application entities whenever and wherever necessary.

Stateless means that any state (persistent data of any kind) is stored outside the container. For this, depending on need, various types of external storage may be utilized: Cloud Storage, Persistent Disks, Redis, Amikor belépünk a Cloud SQL-be, újra választanunk kell: or other managed databases. (Megjegyzés fordítás.: You can read more about this in our article “Operátorok a Kubernetes számára: hogyan indítsunk el stateful alkalmazásokat».)

Immutable means that the container will not be modified during its lifetime: no updates, patches, or changes to configurations. If you need to update the application code or apply a patch, create a new image and deploy it. It is recommended to externalize container configurations (listening port, execution environment options, etc.) into Secrets és ConfigMap-ek. They can be updated without the need to build a new container image. For easy pipeline creation for image building, you can use Cloud Build. (Megjegyzés fordítás.: We use the Open Source tool dapp.)

An example of updating a Deployment configuration in Kubernetes using ConfigMap, mounted in pods as a config.

3. Avoid privileged containers

You’re not running applications as root on your servers, are you? If an attacker breaches the application, they gain root access. The same considerations apply to avoid running privileged containers. If host settings need to be changed, you can grant the container specific permissions capabilities using the option a konténernek van egy paramétere in Kubernetes. If you need to change sysctls, Kubernetes has a specific annotation for this. In general, try to maximize the use of init- and sidecar containers for performing such privileged operations. They do not require availability for either internal or external traffic.

If you administer a cluster, you can leverage Pod Biztonsági Politika for restrictions on the use of privileged containers.

4. Avoid running as root

A privilegizált konténerekről már beszéltünk, de még jobb, ha emellett nem indít alkalmazásokat root-jogosultsággal a konténerben. Ha a támadó egy, a root-jogosultsággal rendelkező alkalmazásban távoli, kódvégrehajtási sebezhetőséget talál, és képes a konténer határait átugrani egy eddig ismeretlen sebezhetőségen keresztül, root jogosultságot szerez a gazda rendszeren.

A legjobb módja ennek elkerülésére, hogy először ne indítson semmit root-jogosultsággal. Ehhez használhatja a következő direktívát USER be. Dockerfile vagy runAsUser a Kubernetes-ben. A klaszteradminisztrátor szintén beállíthatja a kötelező viselkedést a következővel: Pod Biztonsági Politika.

5. Tegye az alkalmazást könnyen monitorozhatóvá

A naplózáshoz hasonlóan a monitorozás is elengedhetetlen része az alkalmazás kezelésének. A Kubernetes közösség népszerű monitorozási megoldása a Prometheus — egy rendszer, amely automatikusan felfedezi azokat a podokat és szolgáltatásokat, amelyek monitorozásra szorulnak. (Megjegyzés fordítás.: Lásd még részletes jelentésünket a Prometheus és Kubernetes általi monitorozásról.) A Stackdriver képes monitorozni a Kubernetes klasztereket, és tartalmaz egy a Prometheus saját verzióját az alkalmazások monitorozására.

A Kubernetes monitorozási panel a Stackdriverben

A Prometheus azt várja el, hogy az alkalmazás HTTP endpointon keresztül küldje el a metrikákat. Ehhez elérhetők Prometheus klienskönyvtárak. Ugyanezt a formát használják más eszközök, mint például OpenCensus és Istio.

6. Tegye elérhetővé az alkalmazás egészségi állapotát

Az alkalmazás production környezetben történő kezeléséhez szükséges, hogy képes legyen tájékoztatni a rendszer egészét az állapotáról. Futtatva van az alkalmazás? Rendben van? Kész a forgalom fogadására? Hogyan teljesít? A probléma legelterjedtebb megoldása az egészségügyi ellenőrzések megvalósítása (health checks). A Kubernetesnek kétféle van: liveness és readiness probes.

A liveness probenál (életképességi ellenőrzés) az alkalmazásnak HTTP endpointdal kell rendelkeznie, amely „200 OK” választ ad, ha működik és alapvető függőségei teljesülnek. A readiness probenál (készenléti ellenőrzés) Az alkalmazásnak egy másik HTTP végponttal kell rendelkeznie, amely "200 OK" választ ad, ha az alkalmazás egészséges állapotban van, az inicializálási lépések teljesültek, és bármely érvényes kérés nem vezet hibához. A Kubernetes csak akkor irányítja a forgalmat a konténerre, ha az alkalmazás készenlétét ezek a ellenőrzések igazolják. Két végpont összevonható, ha nincs különbség a liveness és readiness állapotok között.

További részleteket olvashat Sandeep Dinesh, a Google fejlesztői képviselője által írt megfelelő cikkben: „Kubernetes legjobb gyakorlatok: Egészségügyi ellenőrzések beállítása készenlét és liveness próbákkal».

7. Gondosan válassza ki a kép verzióját

A legtöbb nyilvános és privát kép egy, a Best Practices for Building Containerscímű cikkben leírtákhoz hasonló címkézési rendszert használ. ha a kép címkézése közel áll aszemantikus verziózás latest módszerhez, figyelembe kell venni a címkézés sajátosságait. Például a címke

gyakran mozoghat egy képről a másikra - nem lehet rá számítani, ha előre látható és reprodukálható build-ekszre van szüksége. Használhatja a címkét X.Y.Z , (ezek szinte mindig változatlanok), azonban ebben az esetben nyomon kell követnie az összes javítást és frissítést a képen. Ha a használt kép rendelkezik a címkévelX.Y