Category: Kubernetes

This series is intended to be a introductory look into Kubernetes. If your organization is interested in custom training around your infrastructure, please reach out to us at BoxBoat. We are both a Docker and Linux Foundation training partner and can provide onsite corporate training on Docker and Kubernetes.
Welcome to the first post in the BoxBoat Kubernetes Training Fundamentals course. We designed a blog and video series to get you familiar with the core tenants of Kubernetes and Docker container orchestration.

The runaway success of Kubernetes has created an ecosystem of tools to simplify the complexity of application development and deployment.
The majority of these tools exist as open-source projects maintained by a community of enthusiasts. However some, due to their popularity and the importance of the role they fulfill, gain additional recognition through adoption by the Cloud Native Computing Foundation.
In this post I discuss Helm, selected by the CNCF as a package manager providing an easy way to manage and publish software on Kubernetes.

Developing for Kubernetes can be a daunting task for any developer not familiar with the ecosystem. The developer needs to understand how to create spec files, author CI/CD scripts with a system such as Jenkins or CircleCI, and instrument logging and tracing. Knative aims to solve some of these issues, abstracting the details of building images away from the developer.
Knative helps developers build, deploy, and manage modern serverless workloads on Kubernetes.

BoxBoat is proud to announce our newest committment to delivering the best available container enablement services to our clients. We strive to hire and retain only the best of the best as BoxBoat team members; joining the Cloud Native Computing Foundation as a Silver Kubernetes Certified Service Provider recognizes this expertise. We are excited to continue our training, experience, and contribution to the Kubernetes community, as well as to our clients, with the support of the CNCF.

The Kubernetes ConfigMap resource is used to mount configuration files into pods. The Kubernetes Secret resource is used to mount secret files into pods. Both of these resources are commonly used when deploying a GitOps Configuration as Code workflow.

ConfigMap and Secret files inside of containers are updated automatically when the underlying ConfigMap or Secret is updated. If an application reads a ConfigMap or Secret value on startup, it may have a stale configuration after a ConfigMap or Secret is updated.

One approach for dealing with this is to add application logic to watch ConfigMap and Secret files for changes, and reconfigure the application on the fly. This can lead to complicated logic since objects using the old configuration will need to be detected and recreated.

Another approach is to trigger a rolling update of the Deployment when it’s dependent ConfigMaps and Secrets are updated. This blog post describes a solution that creates ConfigMaps and Secrets alongside a Deployment, and uses a hash of these resources to automatically trigger a rolling update if they have changed.