Initially developed by Datawire, Telepresence is a new open-source tool supported by the CNCF (Cloud Native Computing Foundation). It allows developers to run local software while connected to a remote Kubernetes cluster. The application uses a two-way network proxy to simulate TCP connections, environmental variables, and other volumes of services as local processes. This link allows for remote work to be accomplished while seemingly local to the cluster via the proxied connection.
The web-based Kubernetes console is an interface that provides information about the state of the Kubernetes cluster. The dashboard is also used for deploying containerized applications as well as for general cluster resource management. Traditionally, kubectl is primarily used in the terminal for nearly all cluster related tasks. Still, it is useful to have a visual representation of our cluster in a user-friendly interface. To install the dashboard, kubectl needs to be installed and running on the server.
Istio is an open-source service mesh that makes it easier for a team to create a network or server cluster of deployed services. Istio provides several vital services consistently across a mesh network such as:
A service mesh is a layer of communication and control between applications or microservices and the network stack they typically communicate over. This layer controls communication and helps microservices share data. This service-to-service interaction is governed by logic built into the service mesh layer. Simply put, microservices are small or partial applications, or individual functions, and the network stack is the physical networking layer.
How is a Service Mesh Achieved?
Typically, a service mesh is implemented via sidecars. These sidecars are usually attached to every microservice on your network. The service mesh abstracts communication between microservices into these sidecars and the sidecars communicate with one another in a mesh topology.
Because most modern apps are now smaller than their predecessors, they have shrunken the communication logic written into each app, microservice, function, etc. With one or two microservices, or maybe even a dozen, the communication logic generally isn’t difficult to deal with. At scale, or when you have hundreds of such apps, a service mesh can be thought of as ‘required’.
So, a service mesh consists of the following components:
A communication layer of control between apps or microservices
The network stack they typically communicate over
Abstracts communication and implements ‘sidecars’ with every microservice