Author: Caleb Lloyd

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.

Kubernetes Ingress is a powerful resource that can automate load balancing and SSL/TLS termination. The NGINX Ingress Controller is currently the only supported cloud-agnostic ingress controller for Kubernetes. A single ingress controller can be deployed to the cluster and service requests for all namespaces in a cluster. There is currently an outstanding issue where Ingress resources can only reference TLS secrets within their own namespace:

This can be a problem when a cluster has a wildcard certificate that needs to be used across multiple ingress resources in different namespaces. A prime example is a cluster that is setup to automatically request Let’s Encrypt wildcard certificates. In this blog post, we explain an approach for automatically reflecting TLS secrets to every namespace in the cluster.

Kubernetes Ingress is a powerful resource that can automate load balancing and SSL/TLS termination. Let’s Encrypt is a fantastic service that provides free SSL/TLS certificates. This is a comprehensive guide to provision automated Let’s Encrypt certificates for your Kubernetes Ingress using Kubernetes Jobs to generate and Cron Jobs to renew Let’s Encrypt certificates.

Microsoft has split Windows Server into 2 release channels: the Long-term Servicing Channel (LTSC), and the Semi-Annual Channel. Microsoft has in-depth documentation explaining each channel. The first Windows Server release to the Semi-Annual channel is out, called Windows Server, Version 1709.

Windows Server 1709 enables support for some long-awaited features for Windows Containers in Docker, but also includes a backwards compatibility breaking change that will force users to choose between portability and density with Windows Containers.

Docker just announced that they are adding support for Kubernetes as an orchestration layer in addition to Swarm. Kubernetes is a mature container orchestration system originally created at Google, called “Borg.” It enables organizations to securely scale container-based applications, in addition to many other features.
Kubernetes support is going to be deeply integrated with the Docker Engine, and will be available in both Docker CE and Docker EE. Docker will be releasing new versions of Docker for Windows and Docker for Mac so that developers can test running applications locally against the Kubernetes orchestration layer.