registry

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 mesh

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.

consul Deployment

The consul service is deployed to the default namespace of k8s as a Deployment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: consul
  name: consul
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: consul
  template:
    metadata:
      labels:
        app: consul
    spec:
      containers:
      - image: consul:1.8.4
        name: consul
        ports:
        - containerPort: 8500
          protocol: TCP

After deployment, call /v1/catalog/services to find out that the consul service has been successfully registered.

1
2
3
4
curl  10.102.67.37:8500/v1/catalog/services
{
    "consul": []
}

istio configuration

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.

1
2
3
4
5
6
7
8
9
istiod´╝Ü
    spec:
      containers:
      - args:
        - discovery
        - --consulserverURL=10.102.67.37:8500
        - --registries=Kubernetes,Consul
        - --monitoringAddr=:15014
        - --log_output_level=default:info

Validation

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.

1
2
3
4
5
curl  10.102.67.37:8500/v1/catalog/services
{
    "consul": [],
    "student-service": []
}

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.

Note that.

  • istio automatically adds .service.consul suffix by default for services accessed from consul, in this case student-services.service.consul.
  • 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.consul is not written to coredns and is temporarily solved by modifying the pod’s /etc/hosts file by assigning a random ip address to it with the purpose of directing traffic to envoy. echo "1.1.1.1 student-service" >> /etc/hosts

Requests can be successfully initiated using curl.

1
2
[root@debian-77dc9c5f4f-vvxq4 /]# curl student-service.service.consul:9098/getStudentDetailsForSchool/abcschool
[{"name":"Sajal","className":"Class IV"},{"name":"Lokesh","className":"Class V"}]

Problems/Drawbacks

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 .service.consul suffix.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  labels:
    manager: Aeraki
    registry: consul
  name: student-service.service.consul
  namespace: istio-system
spec:
  endpoints:
  - address: 10.244.6.42
    labels: {}
    locality: dc1
    ports:
      tcp: 9098
  hosts:
  - student-service.service.consul
  location: MESH_INTERNAL
  ports:
  - name: tcp
    number: 9098
    protocol: TCP
    targetPort: 9098
  resolution: STATIC

control pannel

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).