Shulou(Shulou.com)05/31 Report--

What are the general characteristics of Kubernetes stateless applications? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problems. Through this article, I hope you can solve this problem.

The micro-service standard, represented by 12 elements, provides a good guide to the characteristics of micro-service. However, when it comes to stateless business applications running on Kubernetes as containers, this standard is somewhat high-level-it values methods and architectures. If you only look at a "pleasing" Kubernetes application from an external perspective, what should be the characteristics of the application?

The dependency relationship is clear

Micro-service applications usually have a variety of external dependencies, such as database, cache, queue and other platform capabilities, or business dependent services, etc., so a healthy combination of micro-services must be able to handle dependencies.

The start-up order of micro-services is not fixed, and it is possible to update and restart independently. However, many applications connect only at startup, which requires that applications running on Kubernetes will not crash directly because the dependent service cannot be connected temporarily at startup; at the same time, they also have the ability to deal with this kind of reconnection at any time during operation.

Have the ability of self-test

Survival testing focuses on whether the process is active and whether it should be restarted; readiness testing represents service capacity and whether it should be stored in the load balancer pool of Service.

In the absence of a ready test, once the Pod starts successfully, K8s will send requests for relevant services to the instance. If the instance starts slowly, it may cause losses to the business. Similarly, survival and readiness tests should be carried out separately, for example, when the business is blocked, the instance is temporarily removed, but the service capacity can be gradually restored without restarting.

With regard to the previous dependency issues, in a micro-service environment, the readiness detection of a service should only focus on the situation of the application. The detection process should not include calls to dependent services-otherwise, the readiness checks of all other services that rely on failed services fail, resulting in large-scale failures.

Log collection and processing

Applications should not continue to output logs to local files, but should export to stdout and stderr

The cluster should provide unified log collection for stdout and stderr of the container. It is recommended to use Daemonset instead of Sidecar.

While collecting logs, the cluster should provide ES, Loki or other similar mechanisms to process logs, and its processing and storage capacity should have a preliminary plan.

The application log should provide a hierarchical switch to ensure that the same image can output different amounts and levels of log information in different environments.

Try to shut down gracefully

The container command entry should be able to receive the SIGTERM and pass it to the business master process if necessary

After receiving the SIGTERM signal, the application process should not shut down immediately, but deal with the rest of the traffic in transit.

Use Pod lifecycle tools such as preStop to accomplish specific tasks

Avoid using long connections and maintain the effectiveness of simple load balancing.

Fault prevention and response

Avoid running Deployment with a single Pod

Use Pod soft affinity to avoid being distributed on the same node as different Pod in Deployment

In case of an irrecoverable failure, the application should be allowed to crash and be restarted by K8s

Define PDB (Pod disruption budgets) and tell K8s to provide a minimum number of Pod for applications.

Resource usage

CPU and Requests of memory must be defined

Limits of memory must be defined

If there are different QoS requirements for different micro-services in the same cluster, different qosClass should be defined to avoid being expelled without distinction.

After reading the above, have you mastered the general characteristics of Kubernetes stateless applications? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.