"n. person responsible for scrubbing a ship's deck."

Deckschrubber inspects images of a Docker Registry and removes those older than a given age.

This blog offers some guidelines for running a production grade Kubernetes cluster in an environment like an on-premise data center or edge location.

What does it mean to be “production grade”?

The installation is secure
The deployment is managed with a repeatable and recorded process
Performance is predictable and consistent
Updates and configuration changes can be safely applied
Logging and monitoring is in place to detect and diagnose failures and resource shortages
Service is “highly available enough” considering available resources, including constraints on money, physical space, power, etc.
A recovery process is available, documented, and tested for use in the event of failures

In short, production grade means anticipating accidents and preparing for recovery with minimal pain and delay.

This article is directed at on-premise Kubernetes deployments on a hypervisor or bare-metal platform, facing finite backing resources compared to the expansibility of the major public clouds. However, some of these recommendations may also be useful in a public cloud if budget constraints limit the resources you choose to consume.

A single node bare-metal Minikube deployment may be cheap and easy, but is not production grade. Conversely, you’re not likely to achieve Google’s Borg experience in a retail store, branch office, or edge location, nor are you likely to need it.

This blog offers some guidance on achieving a production worthy Kubernetes deployment, even when dealing with some resource constraints.

gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system surface. It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel. The runsc runtime integrates with Docker and Kubernetes, making it simple to run sandboxed containers.

gVisor takes a distinct approach to container sandboxing and makes a different set of technical trade-offs compared to existing sandbox technologies, thus providing new tools and ideas for the container security landscape.

This first release of Kata Containers completes the merger of Intel’s Clear Containers and Hyper’s runV technologies, and delivers an OCI compatible runtime with seamless integration for container ecosystem technologies like Docker and Kubernetes.

A minimalistic and focused guide with common use cases, patterns, principles and practises for developing Cloud Native applications on Kubernetes.

“Cloud native” is a term used to describe applications designed specifically to run on a cloud-
based infrastructure. Typically, cloud-native applications are developed as loosely coupled
microservices running in containers managed by platforms. These applications anticipate
failure, and they run and scale reliably even when their underlying infrastructure is experiencing outages.
To offer such capabilities, cloud-native platforms impose a set of contracts and
constraints on the applications running on them. These contracts ensure that the applications
conform to certain constraints and allow the platforms to automate the management of the
containerized applications. Many organizations understand the necessity and importance of
becoming cloud native, but do not know where to start. Ensuring that cloud-native platforms
and the containerized applications that run on them work seamlessly together provides the
ability to anticipate failure and the reliability to run and scale even when the underlying
infrastructure experiences outages. This whitepaper describes a number of principles that
containerized applications must comply with in order to become good cloud-native citizens.

Adhering to these principles will help ensure that your applications are suitable for
automation in cloud-native platforms such as Kubernetes.

Containers are a great solution for consistent software deployments. When you start using containers in your environment, you and your team will quickly realise that you need a system which allows you to automate container operations. You need a system to keep your containers running when stuff breaks (which always happens, expect failure!), be able to scale up and down, and which is also extensible, so you can interact with it or built upon it to get the functionality you need. The most popular system for deploying, scaling and managing containerized applications is Kubernetes.

ksonnet is a framework for writing, sharing, and deploying Kubernetes application manifests. With its CLI, you can generate a complete application from scratch in only a few commands, or manage a complex system at scale.

Specifically, ksonnet allows you to:

Reuse common manifest patterns (within your app or from external libraries)
Customize manifests directly with powerful object concatenation syntax
Deploy app manifests to multiple environments
Diff across environments to compare two running versions of your app
Track the entire state of your app configuration in version controllable files

All of this results in a more iterative process for developing manifests, one that can be supplemented by continuous integration (CI).

Why Kargo?

Making Kubernetes operationally strong is a widely held priority and I track many deployment efforts around the project. The incubated Kargo project is of particular interest for me because it uses the popular Ansible toolset to build robust, upgradable clusters on both cloud and physical targets. I believe using tools familiar to operators grows our community.

This is the last post in a 4-part series about Kubernetes monitoring. Part 1 discusses how Kubernetes changes your monitoring strategies, Part 2 explores Kubernetes metrics and events you should monitor, Part 3 covers the different ways to collect that data, and this post details how to monitor Kubernetes performance with Datadog.

This post is Part 3 of a 4-part series about Kubernetes monitoring. Part 1 discusses how Kubernetes changes your monitoring strategies, Part 2 explores Kubernetes metrics and events you should monitor, this post covers the different ways to collect that data, and Part 4 details how to monitor Kubernetes performance with Datadog.

This post is Part 2 of a 4-part series about Kubernetes monitoring. Part 1 discusses how Kubernetes changes your monitoring strategies, this post breaks down the key metrics to monitor, Part 3 covers the different ways to collect that data, and Part 4 details how to monitor Kubernetes performance with Datadog.

This post is Part 1 of a 4-part series about Kubernetes monitoring. Part 2 explores Kubernetes metrics and events you should monitor, Part 3 covers the different ways to collect that data, and Part 4 details how to monitor Kubernetes performance with Datadog.

Bootkube is a helper tool for launching self-hosted Kubernetes clusters.

When launched, bootkube will act as a temporary Kubernetes control-plane (api-server, scheduler, controller-manager), which operates long enough to bootstrap a replacement self-hosted control-plane.

Additionally, bootkube can be used to generate all of the necessary assets for use in bootstrapping a new cluster. These assets can then be modified to support any additional configuration options.

If you are interested in the design and details see the Kubernetes self-hosted design document which provides an architecture overview.

Every Kubernetes cluster has a cluster root Certificate Authority (CA). The CA is generally used by cluster components to validate the API server’s certificate, by the API server to validate kubelet client certificates, etc. To support this, the CA certificate bundle is distributed to every node in the cluster and is distributed as a secret attached to default service accounts. Optionally, your workloads can use this CA to establish trust. Your application can request a certificate signing using the certificates.k8s.io API using a protocol that is similar to the ACME draft.

Tectonic is built on pure-upstream Kubernetes but has an opinion on the best way to install and run a Kubernetes cluster. This project helps you install a Kubernetes cluster the "Tectonic Way". It provides good defaults, enables install automation, and is customizable to meet your infrastructure needs.

Goals of the project:

Installation of Self-Hosted Kubernetes Cluster
Secure by default (use TLS, RBAC by default, OIDC AuthN, etcd)
Automatable install process for scripts and CI/CD
Deploy Tectonic on any infrastructure (Amazon, Azure, OpenStack, GCP, etc)
Runs Tectonic on any OS (Container Linux, RHEL, CentOS, etc)
Customizable and modular (change DNS providers, security settings, etc)
HA by default (deploy all Kubernetes components HA, use etcd Operator)

Note: This repo does not yet haveTectonic is built on pure-upstream Kubernetes but has an opinion on the best way to install and run a Kubernetes cluster. This project helps you install a Kubernetes cluster the "Tectonic Way". It provides good defaults, enables install automation, and is customizable to meet your infrastructure needs.

Goals of the project:

Installation of Self-Hosted Kubernetes Cluster
Secure by default (use TLS, RBAC by default, OIDC AuthN, etcd)
Automatable install process for scripts and CI/CD
Deploy Tectonic on any infrastructure (Amazon, Azure, OpenStack, GCP, etc)
Runs Tectonic on any OS (Container Linux, RHEL, CentOS, etc)
Customizable and modular (change DNS providers, security settings, etc)
HA by default (deploy all Kubernetes components HA, use etcd Operator)

Note: This repo does not yet have all Tectonic Installer features imported. This will happen over the coming weeks as we are able to make some of the surrounding infrastructure public as well. This notice will be removed once the AWS and Baremetal graphical installer code has been fully integrated.

Checkout the ROADMAP for details on where the project is headed. all Tectonic Installer features imported. This will happen over the coming weeks as we are able to make some of the surrounding infrastructure public as well. This notice will be removed once the AWS and Baremetal graphical installer code has been fully integrated.

Checkout the ROADMAP for details on where the project is headed.

This guide walks through a bare-metal installation of Tectonic utilizing PXE-based tools.

rkt (pronounced "rock-it") is a CLI for running app containers on Linux. rkt is designed to be composable, secure, and fast.

Some of rkt's key features and goals include:

• First-class integration with init systems (systemd, upstart) and cluster orchestration tools (fleet, Kubernetes)
• Compatibility with other container software (e.g. rkt can run Docker images)
• Modular and extensible architecture (network configuration plugins, swappable execution engines based on systemd or QEMU/KVM)

Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops.