Extension and customization of Istio

1, Istio and Kubernetes decoupling

For non-Kubernetes environments and no plans to migrate to Kubernetes for a long time, there is no need to use Istio-based Service Mesh solutions.However, if it is a multi-platform support scenario, for example, there are both Kubernetes environment users and non-Kubernetes environment users in the customer, in this case, Istio can be customized and modified to remove the strong coupling to Kubernetes and add support for other platforms..

The coupling of Istio to Kubernetes mainly includes the following aspects, so it needs to be adapted and modified in a targeted manner.

• API resource management is dependent on Kubernetes API Server

Resource management is where Istio relies most on Kubernetes.Istio's management of core resources is based on Kubernetes CRD, and uses kubectl as the command line operation entry, kubectl will call API Server, store resources in etcd, and trigger resource change event notifications through the Kubernetes CRD mechanism to notify careThe module of the Istio resource change event handles it accordingly.

Kubernetes provides a complete set of API resource management mechanisms through kubectl, API Server, etcd and Kubernetes CRD components, including resource additions, deletions and changes and resource change notifications.To bind Istio to Kubernetes, it is necessary to implement this set of API management methods by itself, and be platform-independent.

• Reliance on kube DNS at the communication access level

At the communication level, before the client sends a request, the virtual IP address of the service is obtained through DNS. Istio's DNS implementation follows the Kubernetes DNS solution (Kubernetes DNS is the key to Kubernetes network management.One ring), based on DNS, you can directly access the service through the service name.Therefore, at the communication level, it is necessary to decouple from Kubernetes at the DNS solution level and use a platform-independent DNS solution.

2. Platform-independent Istio support scheme

As the control plane, Istio mainly manages the service information and configuration information of the data plane Envoy. Therefore, the platform-independent Istio support solution mainly needs to provide a platform-independent configuration management center andService Registry.

Consul is an open source project for managing the configuration and service discovery of distributed systems. Compared with other distributed service discovery solutions such as ZooKeeper and etcd, Consul provides a one-stop solution.Built-in service discovery, health check, key/value storage, multi-data center solution, REST API interface and many other features.It is recommended to use Consul as a platform-independent configuration center and service discovery solution. Istio currently also provides basic support for Consul, but it is not yet mature, so it cannot be directly applied to the production environment.

3. RPC protocol extension support

Envoy currently focuses on providing support for HTTP1 and HTTP2, while support for the RPC protocol is still weak.In terms of RPC protocol, although support for Thrift protocol and Dubbo protocol is currently provided, the level of support is very weak, and it does not support common link management features, so they are not suitable for use in production environments.

If you need to add the corresponding RPC protocol extension to Envoy, you can refer to the specific implementation of the Thrift protocol under Envoy. First, define the Network Filter plug-in corresponding to the RPC protocol and register it statically through RegisterFactory.

In the entry function createFilterFactoryFromProtoTyped that must be implemented by the plug-in, the analysis of the corresponding configuration of the plug-in can be realized, such as routing-related configuration, and the plug-in protocol processing function must be registered with the filter manager through addFilter.

The specific protocol parsing logic is implemented in the OnData function of the plug-in, and the parameters required for routing are parsed, so that the corresponding Upstream node can be selected through the configured routing strategy, and then the Upstream node can be called to performdeal with accordingly.