Glossary

Find definitions of key terms and concepts used in Tanzu Service Mesh Autoscaler.

Term	Definition
ASD	Autoscaling Definition is the custom resource definition unique to Tanzu Service Mesh and enables configuring the autoscaler. ASD is the short name for Definition.
autoscaling policy (autoscaler)	Defines the scale conditions for a service. When a set metric value, such as CPU Usage, latency or memory, is violated, the scaling policy comes into action.
custom resource	A custom resource is an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.
Custom Resource Definition (CRD)	The Custom Resource Definition API resource allows you to define custom resources. Defining a CRD object creates a custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource.
Definition	It is the name of the custom resource made specifically for Tanzu Service Mesh Service Autoscaler. It is sometimes referred to as Autoscaling Definition. Its plural form is definitions and its short name is asd.
Deployment	A Deployment provides declarative updates for Pods and ReplicaSets.
Istio	An open platform to connect, monitor, and secure microservices. Tanzu Service Mesh uses Istio to manage and secure the interaction of microservices.
Istio-injection	To take advantage of all Istio’s features, pods in the mesh must be running an Istio sidecar proxy. There are two ways of injecting the Istio sidecar into a pod: manually using the istioctl command or by enabling automatic Istio sidecar injection in the pod’s namespace.
kubectl	kubectl controls the Kubernetes cluster manager.
liveness probe	The kubelet uses liveness probes to know when to restart a container. For more information about liveness probes, see https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command.
manifest	Specification of a Kubernetes API object in JSON or YAML format. A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.
namespace	Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
readiness probe	Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to stop the application, but you don’t want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. For more information about readiness probes, see https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes.
service level objective (SLO)	A target value or range of values for a service level that is measured by a service level indicator (SLI). A natural structure for SLOs is SLI ≤ target or lower bound ≤ SLI ≤ upper bound. For example, we might decide that we will return search results "quickly," adopting an SLO that our average search request latency must be less than 100 milliseconds.