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

This article introduces the relevant knowledge of "how to master Envoy". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Envoy responding to the call of the times

Envoy is a stand-alone software with reverse proxy and load balancing functions, which belongs to the same kind of software as Nginx and Haproxy. Compared with Nginx and Haproxy, Envoy has an important feature: its own configuration API.

Load balancing software, such as Nginx and Haproxy, seldom changes the configuration when the software is running, even if the configuration file is occasionally modified and reloaded with commands such as reload, it can meet the needs.

After the emergence of PaaS or container management system represented by Kubernetes, IT system evolves along the route of "specialization of labor division and fewer people doing more homogeneous things". In the current evolution process, the capabilities of reverse proxy and load balancing are centrally managed and provided.

This evolution is embodied in Kubernetes as all the services in the ingress proxy cluster as the exit of the cluster, and in the ServiceMesh represented by istio as the flow of flow of agent software scattered everywhere under the control of the same center. Whether as an exit of Kubernetes or as a node in Mesh, the component that undertakes the traffic forwarding function needs to complete a challenge: frequently update the configuration during operation.

The frequency of updates in the new scene is N times per second, which far exceeds the weekly, monthly and even annual update frequency in previous scenarios. In this case, the way of hot loading configuration files is obviously slow and cumbersome. Some projects have developed a component with API function to generate configuration files and trigger hot loading, so as to give traditional load balancer software such as Nginx and Haproxy the ability to update configuration at high frequency.

But wouldn't it be popular to have a software native with a configuration API that focuses on the data plane and exists as a reliable third party that allows the control plane to focus on rule management?

Envoy is such a software. Note that this is just an account of the background, not for envoy. Nginx, haproxy, and so on are updating the evolution to adapt to the changes in the scene.

Cluster, Listener and Filter

The functions and details of Envoy are complicated, but as long as you figure out the use of Cluster, Listener and Filter, you have a good grasp of the general direction.

Cluster is a group of IP, which is equivalent to upstream in Nginx. The load balance policy is set in cluster, and the cluster can be either IP or domain name:

A difficult configuration file

The configuration file of Envoy is the biggest difficulty in understanding Envoy from scratch. Its configuration is complicated and lacks a systematic introduction.

When envoy starts, the configuration file is specified with-c and is divided into the following sections:

{"node": {"id": "...", "cluster": "," metadata ":" {...} "," locality ":" {...} "," build_version ":"... "}," static_resources ": {" listeners ": []," clusters ": []," secrets ": []} "dynamic_resources": {"lds_config": "{...}", "cds_config": "{...}", "ads_config": "{...}"}, "cluster_manager": {"local_cluster_name": "...", "outlier_detection": "{...}", "upstream_bind_config": "{...}" "load_stats_config": "{...}"}, "hds_config": {"api_type": "...", "cluster_names": [], "grpc_services": [], "refresh_delay": "{...}", "request_timeout": "{...}", "rate_limit_settings": "{...}"} "flags_path": "...", "stats_sinks": [{"name": "...", "config": "{...}"}], "stats_config": {"stats_tags": [], "use_all_default_tags": "{...}", "stats_matcher": "{...}"} "stats_flush_interval": "{...}", "watchdog": {"miss_timeout": "{...}", "megamiss_timeout": "{...}", "kill_timeout": "{...}", "multikill_timeout": "{...}"}, "tracing": {"http": "{...}"} "rate_limit_service": {"grpc_service": "{...}"}, "runtime": {"symlink_root": "...", "subdirectory": "...", "override_subdirectory": "..."}, "admin": {"access_log_path": "...", "profile_path": "..." "address": "{...}"}, "overload_manager": {"refresh_interval": "{...}", "resource_monitors": [], "actions": []}}

Viewing the default configuration file in the envoy container helps you build perceptual awareness, as follows:

Admin: access_log_path: / tmp/admin_access.log address: socket_address: protocol: TCP address: 127.0.0.1 port_value: 9901static_resources: listeners:-name: listener_0 address: socket_address: protocol: TCP address: 0.0.0.0 port_value: 10000 filter_chains:-filters:-name: envoy.http_ Connection_manager typed_config: "@ type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager stat_prefix: ingress_http route_config: name: local_route virtual_hosts:-name: local_service domains: ["*"] routes: -match: prefix: "/" route: host_rewrite: www.google.com cluster: service_google http_filters:-name: envoy.router clusters:-name: service_google connect_timeout: 0.25s type: LOGICAL_DNS # Comment out the following line to test on V6 networks dns _ lookup_family: V4_ONLY lb_policy: ROUND_ROBIN load_assignment: cluster_name: service_google endpoints:-lb_endpoints:-endpoint: address: socket_address: address: www.google.com port_value: 443 tls_context: sni: www.google.com

Mastering the configuration file of envoy is a key step in grasping this software. How can we master the configuration of envoy? Of course we have mastered all the configuration details, but most of the time we don't need to. We just need to know where the documents that reflect all the details of the configuration file are in real time, and leave the rest to time and curiosity:

Filter who plays the leading role

It can almost be said that the most frequently mentioned envoy functions in practical applications are provided by filter. Filter is one processing link after another when the traffic flows in the envoy. Each link will interpret some information and make some judgments, which will affect the processing of the next link.

Both Cluster and Listener have the location of filter, and some filter are more complex and implement sub-filter, such as HttpConnectionManager, which specializes in dealing with http protocol.

These filter names are a good illustration of what envoy can do, http, thrift, dubbo, zookeeper, mysql, mongo, redis, don't they look tempting?

What's going on with dynamic configuration?

One of the big selling points of envoy is that it comes with its own configuration API, but it's hard to use its own API. Envoy took the lead in proposing the use of a unified data-plane-api, defined a set of API standards, and expected to be widely recognized and adopted. From the choice of the new Api gateway and ServiceMesh open source projects, this strategy is effective.

Go-controller-plane is the go language implementation of data-plane-api proposed by envoy, which can be used to send configurations to envoy. The usage of this library is not clear in a few words. First, we can clarify the relationship between the following three items: envoy is the stand-alone software envoy,data-plane-api is the API interface standard, and go-control-plane is the implementation of the API interface standard.

This is the end of "how to master Envoy". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.