Kubernetes: Deployment the CESSDA way

Overview

Teaching: 5 min
Exercises: 20 min
Questions
  • How do I get my Coffee Machine into the 'real' CESSDA Café?
Objectives
  • Deployment via CESSDA Jenkins

Deploying your Machine to the CESSDA Café

So far we have been applying the Kubernetes setup manually (with the help of some scripts). Now we’ll do it through the CESSDA Jenkins.

The CESSDA Café is deployed using the respective deployment repository.

You will notice that it has folders similar to the ones we created above, including the scripts we used. Let’s create the $component_name/k8s and just copy the $component_name/k8s/template-service.yaml we created above.

For the $component_name/k8s/template-deployment.yaml, we’ll add a few options:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENTNAME
  namespace: NAMESPACE
  labels:
    app: DEPLOYMENTNAME
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: DEPLOYMENTNAME
      annotations:
        fluentbit.io/parser: json
    spec:
      containers:
        - name: DEPLOYMENTNAME
          image: IMAGETAG
          imagePullPolicy: Always
          ports:
            - containerPort: 1337
          livenessProbe:
            httpGet:
              path: /healthcheck
              port: 1337
            initialDelaySeconds: 300
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /healthcheck
              port: 1337
            initialDelaySeconds: 5
            timeoutSeconds: 5
      nodeSelector:
        cloud.google.com/gke-nodepool: default-pool
  selector:
    matchLabels:
      app: DEPLOYMENTNAME

You’ll notice that we added fluentbit.io/parser: json to tell the log parser that we’re writing JSON. You will need to check the docs if you are using a different format.

We also added the imagePullPolicy: Always which is Best Practice and a nodeSelector. The latter influences which of the VMs this pod is deployed to. As this is neither memory- nor i/o-intensive component, we’re using the default. Note: The nodeSelector is the first GCP specific option.

Finally, the livenessProbe and readinessProbe are used by Kubernetes to monitor the pod’s status. Omit these, if you haven’t implemented them.

Next, we need to add our component statement to the Jenkinsfile of the deployment repository. Locate the list_of_components array and add your’s to the list. While you have the file open, take a look at what it does: Setting up some variables, applying the misc-creation.sh and then looping through the components and calling component-creation.sh for each.

Commiting the deployment repository will add you component to the Café.

Finally, to re-deploy your own machine on any change, you need to edit your own Jenkinsfile and add a call to the deployment script:

stage('Deploy Docker image'){
    steps{
        build job: '../cessda.cafe.deployment/master', parameters: [string(name: 'image_tag', value: "${image_tag}"), string(name: 'component', value: "${component_name}")], wait: false
    }
}