Reprint this article without reference: wechat official account EAWorld, rights reserved.
Quote:
Previously deployed applications or services are self-contained and will not be affected by other services. That is changing with DevOps. Because the application or service itself involves more and more components. DevOps connects applications or services and their components to keep them running.
Directory:
First, traditional high availability
2. Overview of DevOps
Traditional high availability architecture
4. Changes made by DevOps
First, traditional high availability
In traditional production mode, services such as applications, middleware, and databases need to be highly available. To avoid downtime of business services.
Common deployment methods include active/standby service deployment, service cluster deployment, and high availability solution in two or three centers.
Common indicators of high availability, as well as service downtime.
https://en.wikipedia.org/wiki/Mean_time_between_failures
MTBF = MTTF + MTTR
365*24*(1-0.99)=87.6, in actual circumstances of course, the shorter the failure time, the better
System availability ratio = MTTF/MTBF
2. Overview of DevOps
1. The change DevOps brings is that the entire deployment process is automated and the deployment cycle is shorter. The focus of development and operations has also changed. Developers can go from submitting the code to seeing the changes in a fraction of the time.
2. In the real world, because DevOps connects multiple application services, many people argue that the components that DevOps connects must be highly available. This is where the problem arises, making a big difference to an architecture that was simple and clear.
3. The changes that DevOps brings are different from traditional high availability.
Traditional high availability architecture
Note: Simply make Gitlab service master/slave, or master/master method. Such Gitlab services have gone from a single point to a slightly more complex architecture.
As a result, our Harbor has become highly available, and when devOPS is connected, operation and maintenance becomes complicated. Of course, DevOps can concatenate many more components, but these are just two examples.
4. Changes made by DevOps
In the DevOps era, the requirements for components change as DevOps becomes highly available in series. Because DevOps is cascades, they want all components to be either highly available or distributed, and they want all services to be decoupled.
As can be seen from the figure, the APP layer is simply distributed. This is probably a typical architecture that we often deploy. The APP layer is simply designed in a distributed way. Other components still use the traditional cluster deployment mode, but in this deployment mode, increased the difficulty of operation and maintenance.
Complex distribution looks simpler on the diagram than simple distribution. But in practice it’s going to be difficult. Because APP, Cache, DB, Storage and so on are distributed, such complexity puts forward high requirements for architecture, and also increases the difficulty for operation and maintenance. There’s less on the picture, but there’s a lot more complicated distribution than that.
Maybe clustering is distributed. Maybe clustering is just a solution to high availability, while distribution is a solution to high concurrency, high performance problems, or maybe clustering is part of distribution. Everyone has their own understanding, your own business, needs, etc.
Another technique that can help with distributed deployment is container technology. Through Kubernetes to achieve their requirements of the application of high availability and application of the partial type.
With the advent of microservices and DevOps, containerized microservices and DevOps are better implemented. The highly available Kubernetes provides us with the basic container platform and container scheduling capabilities. Kubernetes is inherently fault tolerant.
You might say that scaling out is not a highly available architecture. However, if you consider the changing resource requirements of your business, you will find that kubernetes deployment is very beneficial to you. When traffic surges, you can take advantage of Kubernetes’ ability to scale horizontally. Instead of starting from scratch.
At the same time, the reliable monitoring of Kubernetes itself is very important for the high availability system. Using many commercial software or many open source tools for integration and even self-development can grasp the overall business status and system status. Additional open source software such as Promethus can also be used to monitor business conditions.
Author’s point of view: what suits you is the most suitable for you.
-
Not all services are suitable for container deployment
-
Highly available options need to fit their system
-
As DevOps cascades through the cycle, it also requires us to make changes.
Selected questions:
Question 1: Why wouldn’t Devops have two projects instead of paAS?
A: Because DevOps in my opinion is a series function, the two should be positioned differently.
Question 2: What problem does DevOps solve? Which cloud-oriented architecture is the best fit?
A: The role of DevOps in the development – test – pre-launch – production continuum. Cloud computing architecture is a very big concept, specific to their own needs.
Question 3: Does K8s have high requirements for the network? Where are the bottlenecks?
A: K8S has network requirements. The k8S network is under a lot of pressure when running to a certain number of pods, so in the new version k8S has started to support IPVS or direct route like Flannel to reduce the overhead of the network. The K8S does not currently have vertical expansion.
Q4: Does Jenkins use K8S as a framework? Is there a way to implement multi-master?
A: No. K8s can only guarantee automatic reconstruction in case of Jenkins service error.
Q5: What types of services are not suitable for container deployment?
Answer: Such as database Oracle, DB2, etc.
Recommended reading
Design of an automated deployment framework in the DevOps platform
DevOps platform implementation construction management details
New features of universal Devops version 5.2 are released
