We’ll iterate over the basic building blocks — core resources — offered by Kubernetes, then show how to use Helm to manage your deployments.

If these don’t sound familiar, we suggest you to enroll to an introductory course, for example Linux Foundation’s training. Banzai Cloud can also arrange an on-site training for your team.

Building blocks

The smallest unit of workload in Kubernetes is the Pod, which wraps one or more running containers, that together serve as a single instance of a functional unit of your application, for example an application server instance. Production servies are rarely defined at the level of pods, because they provide no fail-over and scaling behavior. That’s where Kubernetes Deployments and their alternatives, StatefulSets and DaemonSets come into the picture.

Deployment is for general purpose applications, and ensures a replication count of the pods it’s built on, and provides features like rolling updates. Stateful sets are useful for legacy applications designed for permanent clusters, or heavily stateful applications like databases by providing guarantees about the ordering and uniqueness of pods. DaemonSets ensure that the specified pods are running on all or a well-defined set of nodes, which is the most useful for cluster-wide services.

There are a few Kubernetes resources that are present on most real-world deployments, like Services that define network endpoints for your components, PersistentVolumes and PersistentVolumeClaims that allocate persistent storage that can be mounted to pods, or ConfigMaps and Secrets that provide a way to supply configuration and sensitive data for your applications.

Once you have a cluster you can use Banzai CLI and kubectl to create the above mentioned resources.

  1. Start an interactive shell for your cluster:

    banzai cluster shell
  2. Create a pod for httpbin:

    kubectl run httpbin --image=kennethreitz/httpbin:latest \
                        --port=80 \
  3. Check the pod resurce just created:

    kubectl get pod httpbin -o yaml
  4. Start a proxy in the background, and try the deployed application:

    kubectl proxy &
    curl http://localhost:8001/api/v1/namespaces/default/pods/httpbin/proxy/ip
    kill %1


Most applications consist of several resources (for example a deployment for the application server, a service that publishes it, and another deployment for the database server, which persist data using a persistent volume claim).

Furthermore if you want to deploy the same application with slightly different configurations you would have a lot of duplications in your configuration. There are several a few solutions for managing, deploying and templating resources needed for an application deployment, like kustomize, Ksonnet, or Helm.

Helm became the de-facto standard package manager in the Kubernetes ecosystem, with lots of high quality charts for different applications from different sources. If you want to learn more about Helm or you want to create your own charts — check out our blog series about this.

You can deploy your Helm releases either with Banzai CLI or the Banzai Cloud Pipeline web UI. Let’s take a look at the steps of deploying a Helm chart to your cluster.

  1. Start an interactive shell for your cluster:

    banzai cluster shell

    The shell command starts an interactive shell prepared for configuring the selected cluster. It defines a custom helm command, which initializes and sets a new $HELM_HOME environment, and takes care of executing the Helm binary that matches the server component (Tiller) that is deployed to the cluster. Moreover it synchronizes the repository list with Pipeline so you can manage the same packages from the command line and the web.

  2. Optionally, list and update the configured repositories.

    helm repo list
    helm repo update
  3. Install a Wordpress deployment:

    helm install --name my-wordpress stable/wordpress --set wordpressUsername=banzai --set wordpressPassword=banzai

    To distinguish releases from each other Helm attaches a release name to every deployment. You can specify it with the --name option or let Helm generate one. Helm Charts are identified by [repository name]/[chart-name]:[version].

  4. You can list deployments on the cluster and check their status:

    helm list 
  5. Finally if you don’t need the deployment anymore, simply delete it.

    helm delete my-wordpress

What’s next?

Write your own chart based on our blog series, or learn about the service mesh.