By default istio uses k8s as registry, k8s service, endpoint corresponds to service, instance.
For some Spring Cloud services that are not yet connected to the Service Grid, the registry they use may be consul, how to make the Consumer service on the Service Grid to access the non-Service Grid Provider is a problem faced by the application during the Service Grid migration. istio itself provides some mechanisms to bring in external registries of services.
Note that the emphasis here is on not accessing the Service Grid, not not accessing k8s. The reason for this is that the application can access k8s without turning off the governance capabilities of Spring Cloud and still initiate registration with the consul. For such services, it is still not actually possible to manage on the service grid.
istio has gone through several stages of development for external registry support: intree support, MCP, MCP over XDS, and the final plan is to access through UDPA. The current istio code (1.10) is MCP over XDS access, although no official reference to the implementation is provided.
In addition to accessing consul as a registry at the same level as kubernetes, the community has another idea to map services on consul as service entry of istio with the help of service entry, and use the instance of consul service as workload entry, thus helping the service services on the grid to access services that are not on the service grid.
Use consul as a registry(intree)
The last intree version of istio to support consul as a registry was 1.7.8.
The following documents how to configure version 1.7.8 to use consul as a registry.
The consul service is deployed to the default namespace of k8s as a Deployment.
After deployment, call
/v1/catalog/services to find out that the consul service has been successfully registered.
Note that istio uses version 1.7.8. After deploying via demo profile, modify registries to Kubernetes+Consul, as well as add the address of the consul server.
The demo service is a howtodoinjava on example modified to set mainly the consul address.
Deploy the consul-student to the default namespace and you can see from the consul that the service has been registered successfully.
Deploy the debian service under istio-demo namespace. Since istio-demo has enabled istio support, the debian service pod will inject sidecar after deployment.
Login to the debian pod and request the student service via curl to simulate the behavior of the consumer.
- istio automatically adds
.service.consulsuffix by default for services accessed from consul, in this case
- You need to add the port number to access it, in this case 9098 specified by consul-student, i.e.
student-service.service.consul:9098. This differs from Spring Cloud in that SC does not need to be concerned with the port number of the Provider.
student-service.service.consulis not written to coredns and is temporarily solved by modifying the pod’s
/etc/hostsfile by assigning a random ip address to it with the purpose of directing traffic to envoy.
echo "126.96.36.199 student-service" >> /etc/hosts
Requests can be successfully initiated using curl.
Problem: After updating pod instance, sidecar does not update data. Disadvantage: istiod is updated in full even if the consul part service/instance is updated
service entry solution
Develop controller for consul, watch consul’s service changes, and generate service entry for service and workload entry for service’s instances.
The community has the consul2istio project, which implements the function of synchronizing service entry from consul to istio.
However, the project uses instance directly as endpoints of service entry instead of creating corresponding wle for instance, so it is not possible to select different wle according to the label of wle, which will encounter some problems when doing traffic governance: for example, it is not possible to set traffic governance for different versions of instance This will encounter some problems when doing traffic management: for example, it is impossible to set traffic management rules for different versions of instances for grayscale publishing.
The following is the service entry created by consul2istio after docking consul, you can see that its hosts are automatically added with
With istio’s own mechanism for accessing the registry still evolving rapidly, the idea of
consul2istio is actually quite worthwhile. In addition,
consul2istio can achieve incremental updates (watch consul changes, update each service entry separately).