At the core of the Deployments Module is the Service Configuration
commonly called services
.
You can think of services
as an equivalent of Pods
in Kubernetes.
Space Cloud only supports running stateless services as of now.
Each service
describes the following:
Each service requires an id. These ids need to be unique inside a project. Services can be accessed internally using the domain name Space Cloud generates from this service id.
The format for the domains goes as: <service-id>.<project-id>.svc.cluster.local
.
For example, if you create a service by the id myapp
inside the project myproject
, the domain generated would read as myapp.myproject.svc.cluster.local
.
Note: This is true for the docker driver as well.
A service
is composed of one or more tasks. You can see each task as an equivalent of Containers
in each Pod
.
Currently, Mission Control lets you create a single task in each service. For creating multiple tasks per service, use the
space-cli
.
There are several cases when you would need to club several tasks together into one service.
Space Cloud automatically injects an istio-proxy
and metrics-proxy
when using the Kubernetes driver.
You specify the following for each task.
8080
).Space Cloud makes you explicitly define the upstream services your service depends on. All upstream services in the project are accessible by default.
Whitelists are a way to describe service to service communication policies. As the name implies, it restricts downstream services from accessing the current service.