Security is an essential and a core part of operations and thus keeping secrets secured is vital. Unfortunately, for many an organization, this is often not a priority.

The lack of zeal toward managing secrets is likely related toward the complexity involved. Managing configuration artifacts have well established patterns using change configuration (Puppet, Chef, Ansible, Salt Stack) tools, using service discovery with KV stores (etcd, Consul, Zookeeper), or through simpler means like environment vars and config files.

When the configuration artifacts are secrets, called secrets artifacts, you have to not only encrypt the secrets, but also secure who or what…

The two most often neglected domains of cloud operations are security and o11y (observability). This should come as no surprise because adding security, such as encryption-in-transit with mutual TLS (where both client and server verify each other), and adding traffic monitoring and tracing on short lived transitory pods is by its very nature complex.

What if you could add automation for both security and o11y in less than 15 minutes of effort?

The solution to all of this complexity involves deploying a service mesh, and as unbelievable as it seems, the above statement can really happen with Linkerd.

This article…

Network policies in Kubernetes are essentially firewalls for pods. By default, pods are accessible from anywhere with no protections. If you like to to use network policies, you’ll need to install a network plugin that supports this feature. This article will demonstrate how to use this feature with Calico network plugin on AKS.

Default Kubenet network plugin

The default network plugin for AKS as well as many other Kubernetes implementations is kubenet:

a very basic, simple network plugin, on Linux only. It does not, of itself, implement more advanced features like cross-node networking or network policy (ref)

Though the kubenet network plugin is limited…

A private container registry is useful for building, well, private images, but it is also invaluable republish images that may not be otherwise available, due to outages or low availability, such images on the Quay registry in the last few years, or less reliable registries like GHCR (GitHub Container Registry).

In this article, we will cover using Azure Container Registry with Azure Kubernetes Service. Separately these components by themselves are not too complex, but combined together, logistically, process of deploying applications can get complex.

What this article will cover

This article will cover building a Python client that will connect to the Dgraph distributed graph…

This article details how to secure web traffic using TLS with a certificate from a trusted CA and a public domain. This will use Let’s Encrypt through a popular Kubernetes add-on cert-manager.

In this article we’ll use the following components:

• Azure resources: AKS, Azure DNS zone
• Kubernetes add-ons: cert-manager, external-dns, ingress-nginx
• Example applications: hello-kubernetes, Dgraph (dgraph helm chart)

Overview of cert-manager

One common scenario for securing web applications or services, it to have encrypted traffic with TLS certificates, where the encryption will be terminated at the load balancer. Before the arrival of Kubernetes, nginx was a popular solution for this process.

On the…

This article covers adding an ingress controller called ingress-nginx to AKS (Azure Kubernetes Service). An ingress is a reverse proxy that allows routing web traffic to appropriate targeted services using a single load balancer.

Using example applications (Dgraph and hello-kubernetes), this article covers configuring an ingress to route traffic by an FQDN host name, which is configured automatically in Azure DNS using external-dns.

This article will configure the following components:

• Azure Cloud resources: AKS and Azure DNS Zone
• Kubernetes resources: ingress-nginx and ExternalDNS
• Example applications: hello-kubernetes and Dgraph.

Articles in the Series

These articles are part of a series, and below is a list…

Update (2021年06月28日): removed envsubt & terraform for simplicity

This article covers using ExternalDNS to automate updating DNS records when applications are deployed on Kubernetes. This is needed if you wish to use a public endpoint and would prefer a friendlier DNS name rather than a public IP address.

This article will configure the following components:

• Azure cloud resources: Azure DNS Zone and AKS
• Kubernetes add-ons: ExternalDNS
• Examples: hello-kubernetes and Dgraph (Dgraph helm chart)

Blog Source Code

The blog source code for this article has instructions for using other tools like Terraform (terraform) for cloud resources and gettext (envsubst) for using the shell as…

After creating a system with a public IP, you can add a friendly DNS name to reference this such as appvm.example.com.

Terraform can automatically create or update DNS records for many services: Azure DNS, AWS Route53, Google Cloud DNS, GoDaddy, CloudFlare, etc.

Once you purchased a domain name, such as through a service like GoDaddy, you have a few options for automating DNS:

1. update records for your domain (e.g. example.com) directly with GoDaddy DNS servers
2. create a subdomain, e.g. dev.example.com, and have Azure DNS manage records for your subdomain, e.g. dev.example.com.
3. update records for your domain, e.g. example.com, …