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 daemonsets  or jobs

  1. Click the CREATE  button, and select Workload :

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 DEPLOY  button:

5. You should now be able to view your workload:

6. Here, you can view details and events related to this deployment:

YAML

Lets break down all of the components of the YAML configuration that we posted:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: postgres
  labels:
    app: postgres

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.

spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  strategy:
    type: Recreate


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.

  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - image: library/postgres:9.6-alpine
        name: postgres


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:
          tcpSocket:
            port: 5432
          initialDelaySeconds: 120
          periodSeconds: 30
        livenessProbe:
          tcpSocket:
            port: 5432
          initialDelaySeconds: 120
          periodSeconds: 30

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. 

The 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.

        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-creds
              key: POSTGRES_PASSWORD
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-creds
              key: POSTGRES_USER
        - name: POSTGRES_DB
          valueFrom:
            secretKeyRef:
              name: postgres-creds
              key: POSTGRES_DB
        - name: PGDATA
          valueFrom:
            configMapKeyRef:
              name: postgres-env-vars
              key: PGDATA


The env  section, dynamically sets environment variables, based upon configurations stored in configMaps  and secrets . The difference, is that secrets are encrypted, and base64 encoded.

        ports:
        - containerPort: 5432
          name: postgres


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.

(Note: this deployment depends on a pre-existing secret and configMap. You can find all of the YAML files necessary to run this workload, here.)

Did this answer your question?