{"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\/en\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 best practices for operating containers according to Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note: translation.<\/b>: The author of the original article is Th\u00e9o Chamley, a Google Cloud solutions architect. In this blog post for Google Cloud, he presented a brief summary of a more detailed guide by his company titled 'Best Practices for Operating Containers<\/a><\/noindex>.' In it, Google professionals compiled the best practices for operating containers in the context of using Google Kubernetes Engine and beyond, covering a wide range of topics: from security to monitoring and logging. So, what practices are considered most important for working with containers according to Google?<\/i><\/p>\n

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

Kubernetes Engine<\/a><\/noindex> (a Kubernetes-based service for running containerized applications in Google Cloud \u2014 translator's note.<\/b>)<\/i> \u2014 is one of the best ways to run workloads that require scaling. Kubernetes<\/a><\/noindex> It will ensure the smooth operation of most applications if they are containerized. However, if you want your application to be easy to manage, and if you want to take advantage of all the benefits of Kubernetes, it is essential to follow best practices. They will simplify application operation, monitoring, debugging, and enhance security.<\/p>\n

In this article, we will go over a list of what you should know and do for the effective functioning of containers in Kubernetes. Those wishing to delve deeper into the details should read the material Best Practices for Operating Containers<\/a><\/noindex>, as well as take a look at our earlier post<\/a><\/noindex> on building containers.<\/p>\n

1. Use native container mechanisms for logging<\/h2>\n

\nIf the application is running in a Kubernetes cluster, not much is needed for logging. A centralized logging system is likely already built into the cluster used. In the case of using Kubernetes Engine, this is handled by Stackdriver Logging<\/a><\/noindex>. (Note: translation.<\/b>: If you are using your own Kubernetes installation, we recommend checking out our Open Source solution \u2014 loghouse<\/a><\/noindex>.)<\/i> Don't complicate your life and use native container logging mechanisms. Write logs to stdout and stderr\u2014they will be automatically captured, stored, and indexed.<\/p>\n

If desired, you can also write logs to JSON format<\/a><\/noindex>. This approach will make it easy to add metadata to them. Along with this, the ability to search logs using this metadata will appear in Stackdriver Logging.<\/p>\n

2. Ensure that containers are stateless and immutable<\/h2>\n

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

Stateless<\/i> means that any state (persistent data of any kind) is stored outside the container. To this end, depending on requirements, various types of external storage may be used: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> or other managed databases. (Note: translation.<\/b>: Read more about this in our article \u201cOperators for Kubernetes: how to run stateful applications<\/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 externalize container configuration (listening port, execution environment options, etc.) into Secrets<\/a><\/noindex> and ConfigMaps<\/a><\/noindex>. They can be updated without needing to build a new container image. For easy creation of image build pipelines, you can use Cloud Build<\/a><\/noindex>. (Note: translation.<\/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 configuration<\/i><\/p>\n

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

\nYou are not running applications under root on your servers, are you? If an attacker gains access to the application, they will have root privileges. The same considerations apply to not running privileged containers. If there is a need to change settings on the host, specific permissions can be granted to the container. capabilities<\/i> using the option securityContext<\/code><\/a><\/noindex> in Kubernetes. If it is necessary to modify sysctls<\/i>, Kubernetes has a dedicated annotation<\/a><\/noindex> for this. Generally, try to utilize init-<\/a><\/noindex> and sidecar containers for performing such privileged operations. They do not need to be reachable for internal or external traffic.<\/p>\n

If you administer a cluster, you can take advantage of Pod Security Policy<\/a><\/noindex> for limitations on using privileged containers.<\/p>\n

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

\nWe've already discussed privileged containers, but it would be even better if, in addition to that, you do not run applications inside the container under root. If an attacker finds a remote vulnerability with code execution in an application running with root privileges, they could escape the container through an unknown vulnerability and gain root access on the host.<\/p>\n

The best way to avoid this is, first and foremost, not to run anything under root. You can achieve this by using the directive. USER<\/code> downward API support (simultaneously with this in Dockerfile<\/code> or runAsUser<\/code> in Kubernetes. The cluster administrator can also enforce behavior using Pod Security Policy<\/a><\/noindex>.<\/p>\n

5. Make the application easy to monitor<\/h2>\n

\nLike logging, monitoring is an integral part of application management. A popular solution for monitoring in the Kubernetes community is Prometheus<\/a><\/noindex> \u2014 a system that automatically discovers pods and services that need monitoring. (Note: translation.<\/b>: See also our detailed report<\/a><\/noindex> on monitoring with Prometheus and Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> can monitor Kubernetes clusters and includes its own version of Prometheus for monitoring applications.<\/p>\n

\"7
\nThe Kubernetes monitoring dashboard in Stackdriver<\/i><\/p>\n

expects the application to expose metrics at an HTTP endpoint. There are Prometheus client libraries<\/a><\/noindex>. The same format is used by other tools such as OpenCensus<\/a><\/noindex> and Istio<\/a><\/noindex>.<\/p>\n

6. Make the application's health status accessible<\/h2>\n

\nManaging an application in production is aided by its ability to report its status to the system. Is the application running? Is it healthy? Is it ready to accept traffic? How is it behaving? The most common approach to address this is to implement health checks (health checks)<\/i>. Kubernetes has two types of them: liveness and readiness probes<\/a><\/noindex>.<\/p>\n

For a liveness probe (liveness check)<\/i> the application must have an HTTP endpoint that returns a \"200 OK\" response if it is functioning and its critical dependencies are met. For a readiness probe (readiness check)<\/i> The application should have a separate HTTP endpoint that returns a \"200 OK\" response if the application is healthy, initialization steps are complete, and any valid request does not result in an error. Kubernetes will direct traffic to the container only when the application is ready according to these checks. Two endpoints can be combined if there is no difference between the liveness and readiness states.<\/p>\n

You can read more about this in the relevant article by Sandeep Dinesh, Developer Advocate at Google: \"Kubernetes best practices: Setting up health checks with readiness and liveness probes<\/a><\/noindex>\u00bb.<\/p>\n

7. Choose the image version carefully<\/h2>\n

\nMost public and private images use a tagging system similar to what is described in Best Practices for Building Containers<\/a><\/noindex>. If the image uses a system similar to semantic versioning<\/a><\/noindex>, the specifics of tagging should be considered. For example, a tag latest<\/code> may frequently move from image to image \u2014 it cannot be relied upon if you need predictable and reproducible builds and installations.<\/p>\n

You can use the tag X.Y.Z<\/code> (they are almost always unchanged); however, in this case, track all patches and updates to the image. If the image you\u2019re using has a tag X.Y<\/code>, it is a good compromise. By choosing it, you automatically receive patches while relying on a stable version of the application.<\/p>\n

P.S. from the translator<\/h2>\n

\nAlso read in our blog:<\/p>\n