Relay components

A multicluster Solo Enterprise for Istio setup consists of one cluster that you install the management plane (management server) in, and one or more workload clusters that you register with the management server that act as the data plane (agent and service mesh). Note that the cluster that you install the management plane in often also runs workloads, such as a service mesh.

Management server

After installation, a deployment named gloo-mesh-mgmt-server runs the management server. For your workload clusters to communicate with the management server, the gloo-mesh-mgmt-server service is automatically set up as a service of type LoadBalancer on a default port of 9900/TCP. The management server is responsible for receiving and storing data about the state of each registered cluster from the agents in those clusters.

Management server replicas: By default, the management server is deployed with one replica. To increase availability, you can increase the number of replicas that you deploy in the management cluster.

Agents

After registration, a deployment named gloo-mesh-agent runs the agent on each workload cluster. The agent is exposed by the gloo-mesh-agent service on the default port 9977. The agents send snapshots of the resources from each workload cluster to the management server.

Agent replicas: You can add replicas of the agent for higher availability. In such case, leader election affects which processes the agents handle. All agent replicas, including the leader, handle the process to verify the cache clearing for CRD watch management. The leader agent handles the following processes:

  • Relay
  • Discovery
  • Certificate management
  • Pod bouncing

Relay communication

Communication between the management server and agents is initiated by the agents, which run in the workload clusters. The following sections outline the general flow of how the agents and server communicate.

Management server and agent communication

The relay architecture provides several options for how you can secure the connection between the management server and agents. For testing environments, Solo Enterprise for Istio generates self-signed TLS certificates that can be used to establish a simple or mutual TLS connection. For production environments, provide your own TLS certificates instead.

For an overview of supported options, see the Setup options.

Workload cluster registration

The following image shows the process for registering a workload cluster with the management server.

Figure: Registration of agents with the management server
Figure: Registration of agents with the management server

  1. During the workload cluster registration process, the agent in the workload cluster establishes a simple TLS connection to one of the management server replicas and sends a relay identity token. The relay identity token is a string value that is either generated during the installation of the management server and copied to the workload cluster, or provided by you in the form of a Kubernetes secret (mTLS setup) or environment variable (TLS setup) to the management server and agent.
  2. The management server verifies the relay identity token value. If the agent’s relay identity token matches the management server’s token, the management server registers the agent. In mTLS setups, the management server also issues a client TLS certificate and sends it to the agent.
  3. The agent initiates a TLS handshake. In mTLS setups, the agent verifies the identity of the management server and presents the client TLS certificate to prove its own identity. Only if both parties can be verified successfully, the TLS handshake is complete and the mTLS connection is established. In TLS setups, only the identity of the management server is verified.

After the connection is established, the agent gathers and sends its first discovery input snapshot. For more information about this process, see Resource snapshots.

Resource snapshots

The agents use input snapshots to send information about resources and services in each registered cluster to the management server.

Figure: Discovery input snapshots are sent by agents in each workload cluster to the management server
Figure: Discovery input snapshots are sent by agents in each workload cluster to the management server

  1. The agent in the workload cluster watches the resources that are created in the workload cluster. These resources include:
    • Discovered Kubernetes resources, such as Kubernetes services, deployments, replicasets, daemonsets, and statefulsets. Note that you can use Istio discovery selectors to ignore certain Kubernetes resources. Ignored resources are not included in the snapshot that is sent from the agent to the management server.
    • Discovered Istio resources, such as virtual services, destination rules, gateways, and service entries.
    • Internal resources that are computed in memory by each agent and pushed to the management server without being persisted in the workload cluster. Internal resources include:
      • Gateway resources, which contain information about gateway endpoints in the cluster.
      • IssuedCertificate and CertificateRequest resources, which are used in internal multi-step workflows that involve both the agent and the management server.
  2. The agent connects to one of the management server replicas and sends discovered resources as an input snapshot to the management server. The input snapshot represents the current state of all discovered entities.
  3. The management server saves the discovery input snapshot for all connected agents in the local memory.
  4. The management server saves the discovery input snapshots in Redis.

The Solo UI then reads data from the Redis cache to generate insights for your environment, and display those insights and resource information in the UI.