Uploaded image for project: 'Multicloud'
  1. Multicloud
  2. MULTICLOUD-914

Design Internal architecture for generating ISTIO configuration

XMLWordPrintable

      The distributed traffic controller will be implemented as a plugin to k8s-plugin. Below are the tasks required to be done.

      INTENT Manipulation

      1. Develop a high-level overview of how the connectivity intent would be stored and interpreted by the traffic controller and document the same on_WIKI_
      2. Develop the internal implementation of how the intent is stored in a backend(mongo?) and how it can be exposed (For development purpose). At this stage, the stored connectivity intent (stored as service records) is not required to be exposed to any microservice (Even Multi-cluster scheduler)
      3. Investigate the required interfaces for communication with the REST APIs endpoints.

      ISTIO CONFIG GENERATION PER CLUSTER BASIS

      1. Develop and implement the distributed traffic controller plugin - probably go templates of helm charts of istio configurations (gateway, virtualservice, destinationrules, serviceentry, RBAC (servicerole and servicerolebinding) and any other istio configurations necessary )
      2. Develop mechanism to generate the istio configuration per cluster basis when the Resource installer calls the Traffic controller API with the configuration information of each cluster. The generated API must be sent to the Resource installer to apply in each cluster.

      Internal Design details
      Guidelines that need to kept in mind
      Support for metrics that can be retrieved by Prometheus
      Support for Jaeger distributed tracing by including opentracing libraries around HTTP calls.
      Support for logging that is understood by fluentd
      Mutual exclusion of database operations (keeping internal modules accessing database records simultaneously and also by replication entities of the scheduler micro-service).
      Resilience - ensure that the information returned by controllers is not lost as the synchronization of resources to remote edge clouds can take hours or even days when the edge is not up and running and possibility of restart of scheduler micro service in the meantime.
      Concurrency - Support multiple operations at a time and even synchronizing resources in various edge clouds in parallel.
      Performance - Avoiding file system operations as much as possible.

            yizhouxu yizhouxu
            pramod pramod
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: