The ingress control carries a responsibility of the control plane and the data plane. There is a process in the control, and this process assumes the ability of reverse proxy. When any request is sent, it will be received by nginx and forwarded , the rules based on it are dynamically configured by the ingress control, so the control is the control plane, and nginx itself is its data plane.
When talking about istio, it will also be divided into data plane and control plane. The control plane is istio itself. istio will have various control plane components, such as istiod, which has a flow control controller, which will monitor istio related Some objects and k8s status objects, it will assemble all routing configuration information changes into envoy configuration based on these objects, and then push them to envoy.
Envoy is our data plane component in istio. All requests are sent to envoy, and then forwarded to the back-end server by envoy.
Comparison of mainstream seven-layer proxy software
http2 is recognized by the industry and deployed more and more widely. Compared with http1.x, http2 has some obvious advantages. Because it is connection multiplexing, the demand for links on the entire network will be much smaller.
Then the connection is multiplexed, so the transmission performance will be much higher. Many components of k8s are based on grpc and http2.
Envoy has very complete support when making technology selection. Whether it is upstream or downstream, both directions are based on http2, but nginx is unidirectional.
Handle graceful termination: When one of your applications receives some requests, we need to restart or stop the process. At that moment, there are often some requests that are sent to the server but have not been processed yet. The reason for this is to be graceful Termination is to give these requests some time for them to be processed. Then exit gracefully, so that the client will not feel some errors caused by a sudden restart.
Connection draining means that when the static configuration is reloaded, the old process does not exit, and the new process starts up through the shared memory, and then copies the socket in the old process to the new process. Then the old process will continue to process the connection that has been connected. After all the connected requests are processed, it will exit the old process and then smoothly transition to the new process.
In this way, during the restart process, the customer is not aware of it, because it is a smooth transition, and Envoy supports this function very well.
The above is that envoy has a strong advantage in terms of capability level.
Advantages of Envoy
performance:
While possessing a large number of features, Envoy provides extremely high throughput and low tail latency variance while consuming relatively little CPU and RAM.
Envoy can provide very high throughput, and then only contribute a little delay, and the overhead of resource cpu memory is relatively small.
Scalability:
Envoy provides rich pluggable filter capabilities at both L4 and L7, allowing users to easily add functions that are not available in the open source version.
You can write many plugins. You can write your own plug-ins through c++ rust language code. When any data packets are accepted by envoy, in addition to envoy's built-in logic to process these data packets, the plug-in logic you write can also perform some additional operations on these data packets. processing, which makes envoy's capabilities very easy to expand, you can add your own packet processing capabilities on the basis of envoy's original logic.
API configurability:
· Envoy provides a set of management APIs that can be implemented through control plane services. If the control plane implements all APIs, it is possible to run Envoy on the entire infrastructure using a common bootstrap configuration. All further configuration changes are propagated dynamically through the management server in a seamless fashion, so Envoy never needs to be restarted. This makes Envoy a general purpose data plane, and when combined with a sufficiently complex control plane, it will greatly reduce the complexity of overall operation and maintenance.
Before envoy came out, other proxy software only supported the configuration of static files, and the process needed to be restarted for the static configuration files to take effect. In the past, there was no problem with this mode at low frequencies. k8s is a dynamic environment. Nodes will fail, pods will fail over, and ip will change. There is also flexibility to increase or decrease the number of pod instances, so that the configuration file will be frequently modified, and if the static restart process takes effect, your application process will always restart.
Is there a more elegant way? A more lightweight way is the pioneering capability provided by envoy. That is, the API is configurable. In addition to envoy can read the local configuration file for hot restart, it can also be configured in the basic configuration file and accept the management of another address. When the configuration is updated and the configuration is loaded, then I will go to That address requires a configuration list. In this way, you can statically go to the remote network address to request a configuration list without restarting the process. As long as the configuration list is generated and pushed to the envoy side, the configuration will take effect immediately.
For example, if a pod is always redy or not redy all the time, then you only need to make a dynamic change to the envoy configuration in the remote control server. This dynamic change needs to be pushed to the envoy side, so that the envoy side can take effect in time.
Envoy thread mode
Envoy is a single-process mode, and some proxy software is a multi-process mode, that is, it will start many processes, but for envoy, it is a single process, first of all, it will start multiple threads, one process but multiple threads, multi-threaded The most important thing is the main thread. The main thread is responsible for coordination. It is equivalent to a management thread. It does not specifically process data packets. The main thread will start some sub-threads, and the sub-threads are responsible for monitoring, filtering and forwarding these requests.
If a client initiates a connection request, once the request is accepted by the listener, it will have a binding relationship with the specific worker thread, that is, the sub-thread, then the entire life cycle of the connection will be closely related to the sub-thread bound.
That is to say, as long as the connection is still there, it will not change threads. The advantage of this is that there is no need to coordinate between threads, and each thread handles a fixed connection. In this way, they are independent of each other, so that the design of the program is relatively simple. Does not involve multi-thread coordination, does not involve locks, thread safety and other issues.
Envoy will first define whether it is a static or dynamic resource. The so-called static resource is directly effective by placing the configuration file or envoy reading the configuration file. This is static.
Dynamic means that the configuration part will define the configuration of this part and what address it should go to pull the configuration
