The following is a brief overview of the basic building blocks — core resources — of Kubernetes, and an example on 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. We at Banzai Cloud also offer online and on-site training courses on Kubernetes and other related topics.

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

  • Deployments are for general purpose applications. Deployments ensure a replication count of the pods they are built on, and provide features like rolling updates.
  • StatefulSets are useful for legacy applications designed for permanent clusters, or heavily stateful applications like databases. StatefulSets provide guarantees about the ordering and uniqueness of pods.
  • DaemonSets ensure that the specified pods are running on every node (or on a specified set of nodes), which is useful for cluster-wide services.

There are some Kubernetes resources that are present in 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.

Create a new resource on a cluster 🔗︎

Once you have created a cluster, you can use Banzai CLI and kubectl to create the resources mentioned in the previous section. The following example creates a new pod.

  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 \
                        --generator=run-pod/v1kubectl 
    
  3. Check the pod resource just created.

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

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

Helm 🔗︎

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 solutions for managing, deploying, and templating resources needed for an application deployment, for example, kustomize, 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 on Helm charts.

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. (Optional) If you have multiple clusters, list your clusters to select the cluster where you’d like to deploy the WordPress application:

    banzai cluster list
    
  2. Start an interactive shell to the your cluster. You can use the banzai CLI to open a new shell session with the kubeconfig environment of your selected cluster:

    banzai cluster shell
    

    Select the cluster to connect from the terminal. Alternatively, you can use the banzai cluster --cluster=cluster-name shell command to select the cluster.

  3. The shell command opens a session to the cluster using your default shell. The Banzai CLI automatically installs the kubectl and helm commands on your cluster and adds them to the path. It also synchronizes the repository list with Pipeline so you can manage the same packages from the command line and the web interface.

    Helm is the de-facto package manager for Kubernetes, which helps you manage Kubernetes applications. You can install, upgrade, list, or delete applications. Read our blog for more information about Helm post.

  4. Update the Helm repository:

    helm repo update
    
  5. Install the WordPress chart using the helm client. The command you have to use differs depending on the type of cluster you are running Banzai Cloud Pipeline platform on. For example:

    Expected output: The login credentials for the installed WordPress instance are displayed, for example:

    Login with the following credentials to see your blog
    echo Username: banzai
    echo Password: $(kubectl get secret --namespace default demo-wordpress-release -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    

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

  6. List the deployments on the cluster and check their status:

    helm list
    
  7. (Optional) If you want to access the deployed application, open the WordPress service in a browser window by running the following command (as displayed in the Helm output).

    • If you have installed Banzai Cloud Pipeline to AWS:

      open http://$(kubectl get svc  demo-wordpress-release -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
      

      The WordPress page automatically opens in your default browser.

    • If you have installed Banzai Cloud Pipeline locally:

      kubectl port-forward --namespace default svc/demo-wordpress-release 8080:80
      

      Open the following address in your browser: http://127.0.0.1:8080/

  8. Finally if you don’t need the deployment anymore, simply delete it.

    helm uninstall demo-wordpress-release
    

What’s next? 🔗︎

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