This is a guide for launching a simple
deployment workload on Containership Cloud. Most of this document will also apply to alternate workload types, such as
- Click the
CREATEbutton, and select
2. Select a cluster where the workload will be launched:
3. Enter the deployment YAML, or drag & drop an existing deployment file into the following screen:
4. When you are finished defining your deployment, click the
5. You should now be able to view your workload:
6. Here, you can view details and events related to this deployment:
Lets break down all of the components of the YAML configuration that we posted:
In the metadata, we define identifying properties of the workload. The metadata also sets the API version, and defines the workload as a
deployment type resource.
In the section above, we tell Kubernetes to schedule a single instance of this pod, identified by the
app: postgres label. The strategy-type of
Recreate tells Kubernetes to terminate all existing instances of this pod, before any new instances are created. This strategy may be useful for development environments, where you are frequently updating environment variables, and do not care about brief downtime during the rollout.
- image: library/postgres:9.6-alpine
In the Pod Template, we set the container image that the pod will run to postgres:9.6-alpine , and assign it the name
postgres . The pod also has it's own
metadata field, where identifying labels can be set.
readinessProbe s and
livenessProbe s are used as health checks, to ensure that the pod is ready to accept connections. In this case, both probes are configured to wait 2 minutes before executing any health checks. This is to give the container enough time to initialize. After two minutes, the
livenessProbe will execute a TCP request, to port
5432 , at an interval of every 30 seconds. If the pod does not return a successful response, then it is considered unhealthy, and will be automatically restarted.
readinessProbe executes the same health check, at the same interval, but instead of restarting the container upon failure, it prevents the container from receiving traffic through a service (for example, a load balancer), until the pod returns a successful response. This is useful for situations where a pod is temporarily overloaded, and would prevent it from returning invalid responses to clients. When this health check recovers, traffic will continue to be routed through the service.
- name: POSTGRES_PASSWORD
- name: POSTGRES_USER
- name: POSTGRES_DB
- name: PGDATA
env section, dynamically sets environment variables, based upon configurations stored in
secrets . The difference, is that secrets are encrypted, and base64 encoded.
- containerPort: 5432
Finally, we tell Kubernetes to expose the container's port
5432 , and name it
postgres, so that we can reference it in other resources, such as a service.