Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to deploy applications using StatefulSet in Rainbond. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

Component deployment type

You can choose to deploy the service using the StatefulSet resource type by changing the component deployment type in the other settings of the service component. Note the following before operation:

Component needs to be in a closed state

For service components with persistent storage, switching component deployment types will lead to changes in storage mount, so data backup must be done well.

Rainbond provides four component deployment types by default:

Stateful single instance: using StatefulSet to deploy services, you cannot scale instances horizontally. The number of instances is always 1.

Stateful multi-instance: using StatefulSet deployment service, the number of instances can be scaled horizontally

Stateless single instance: using Deployment to deploy services, you cannot scale instances horizontally. The number of instances is always 1.

Stateless multi-instance: with Deployment deployment service, the number of instances can be scaled horizontally

When you specify the component deployment type as StatefulSet in Rainbond, the service component embodies the following characteristics:

In the multi-instance state, all instances will be sequential, and the naming of the instances will be similar to gr6ec114-0 gr6ec114-1, which will be reflected in the whole lifecycle level, including sequential startup, update, restart and shutdown.

The hostname above will be resolvable in the cluster. Under the same team, try to execute nslookup gr6ec114-0 in any POD. Under different teams, you need to specify a namespace, and the full address of the resolvable address is: gr6ec114-0.gr6ec114.3be96e95700a480c9b37c6ef5daf3566.svc.cluster.local, where 3be96e95700a480c9b37c6ef5daf3566 is the namespace.

In a multi-instance state, the persistent storage of each instance is mounted separately, which means that persistent data is no longer shared between instances.

In the single instance state, when the update operation is performed, the instance will start a new instance after it is completely shut down, which means that the service will be interrupted.

In order to protect the consistency of persistent data, once the k8s node running stateful service loses contact with the management node, when it is in notready state, the instance of stateful service will not migrate automatically.

Overall, using StatefulSet resource types to deploy services brings new features while becoming a bit more rigid, but in the next discussion, you will find that these limitations make sense.

If you are careful, you will find that we bind the resource type of StatefulSet to "stateful". So, a new question arises: what is the "status" of the service.

Status of the service

Stateful service = stateless application + stateful data

As can be seen from the name of the stateful service, it is associated with the resource type of StatefulSet.

In terms of concept, it may be difficult to understand what stateful service is. Let me give you a few examples:

The most common stateful service is the database middleware of the DB class.

For common database Mysql, the same data can only be used by one Mysql program at the same time. After startup, Mysql will generate a unique lock file in its own data directory and "lock" the file. In this way, other Mysql programs that want to use this data will interrupt the startup process by finding that the lock file is "locked". The advantage of this is to ensure strong consistency of data, because the same data can only be read and written by the same Mysql application at the same time.

Recall that one of the features of the StatefulSet resource type is that each instance is mounted with independent persistent storage, which ensures that the Mysql service can be extended to multiple instances and will not be terminated and started because of locking files, but there is essentially no relationship between the instances because they do not share data with each other. Running Mysql as a stateful single instance seems to be the right choice.

The common database middleware with similar situation includes Mongo, Postgresql, Redis, Etcd and so on.

Another common stateful service scenario is the sticky Session provided by services of class Web.

This sticky Session is kept in memory in some cases to provide session persistence and is itself a kind of data. Once the service is extended to multiple instances, once the incorrect instance is accessed, the landing state will be lost because the Session cannot be found. Using IP Hash algorithm to distribute traffic in load balancer can solve this problem to some extent, and traffic from the same IP will be distributed to the specified instance. However, we prefer that the distribution of traffic is polled, so as to ensure that the load of each instance is similar, and there will not be a situation in which one instance has too much load and other instances have nothing to do.

Both stateful service scenarios point out that for stateful services, the data of different instances are independent of each other. Data is "status".

By comparison, stateless services are much more flexible. They do not persist data, or they support sharing of persistent data. For the client, the return of which instance is requested is consistent. This feature means that the number of instances of stateless services can be expanded at will to deal with traffic flexibly.

One of the biggest benefits of using cloud services is the flexibility and flexibility it provides to quickly expand instances to cope with peak traffic. From this point of view, we hope that services are "stateless". So a new question arises: can we remove the "state" of the service and make it stateless?

Handle the "status" of the service

The state of such Web services that use sticky Session to keep their login state can be removed.

The principle is relatively simple, the Session and Web applications are stripped off and stored in other middleware, such as Mysql, Redis, Memcached and other database middleware. Common Web frameworks on the market support this feature, and even use it as the default option, because it's so great!

After processing the Web service, it becomes a stateless service, and the number of instances can be expanded at will. No matter which instance the request from the client is assigned to, the login status is fetched to the backend database and the correct login status is returned. When deploying, you can choose stateless multiple instances to deploy, that is, to use the resource type of Deployment.

But for the database middleware of DB class, its state can not be removed at will.

The reason is that this kind of database middleware uses its own mechanism to ensure strong data consistency, such as Mysql's lock file mechanism, the specified instance can only read and write its own data. For this type of stateful service, a unique share of persistent data for each instance can be counted as a necessary condition. And expand the number of instances at will, will encounter a lot of fatal problems, such as data inconsistency, or program failure and so on. Can this type of stateful service be deployed only at a single point?

These database middleware manufacturers or communities are also very concerned about how to achieve high availability solutions to solve the above problems. Even the database middleware launched in recent years will be designed as a distributed architecture at the design stage. For example, Etcd defines itself as a reliable and highly consistent distributed key-value database. Internally, it uses the Raft protocol to conduct inter-instance elections to clarify the unified leader. For the older database middleware such as Mysql, there is also a master-slave cluster scheme based on Binlog replication.

Therefore, for this kind of service which can not remove the state, our idea and purpose is to follow the cluster scheme supported by itself to achieve high availability and the expansion of the number of instances.

When you actually deploy these cluster scenarios, it can be concluded that most cluster scenarios need to meet the following conditions:

Each instance mounts separate persistent data

Instances need to obtain each other's communication addresses for actions such as election or data synchronization, such as resolvable host names or domain names. Be sure to use the hostname or domain name instead of the instance IP when obtaining the address, because the hostname or domain name will not change as the instance is restarted, but the IP may change, which is important

The number of instances is required. In general, odd numbers such as 3, 5 and 7 are selected to ensure that the cluster will not have a brain fissure.

Recall that the feature of the StatefulSet resource type satisfies all of the above conditions, which is created for stateful service. So for this type of stateful service, its component deployment type should use stateful single / multiple instances anyway.

Rainbond cloud native application management platform to achieve micro-service architecture without changing the code, managing Kubernetes without learning containers, helping enterprises to implement applications on the cloud, and continuously delivering any enterprise applications to Kubernetes clusters, hybrid clouds, multi-clouds and other infrastructure. It is the supporting platform of Rainstore cloud native application store.

1. Rainbond official website

2. Installation and use of Rainbond

3. Complete Rainbond reference manual

The above is how to use StatefulSet to deploy applications in Rainbond shared by Xiaobian. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.