This document describes some controller patterns built on top of the controller-runtime/kubebuilder tooling to help simplify how the controller code is written and organized. It does that by creating some abstractions and patterns to reduce the cognitive load while reading and writing controller code. Some of these are inspired by the ideas from the cluster API (CAPI) controllers, modified to fit the needs of flux controllers because of the differences in the domain of operations. Familiarity with controller code structure created by the kubebuilder scaffold is assumed.
This document describes how the checker tool (CLI and library) can perform Kubernetes object status conditions and generations check as per [kstatus][kstatus_doc].
Before running the tests, the checker is provided with some context about the controller:
- The status conditions it supports with their polarity and priority of the conditions.
The [kstatus document][kstatus_doc] describes a few concepts related to the status conditions and a few standard conditions that controllers can implement. This document tries to provide more details about the status conditions with various examples to describe the mechanics of how the conditions work, what they mean and what we can expected from them.
Starting with an example of status conditions:
Locking down a linux machine is getting easier by the day. Recent advancements in systemd-boot have enabled a host of features to help users ensure that their machines have not been tampered with. This guide provides a walkthrough of how to turn on many of these features during installation, as well as reasoning for why certain features help improve security.
The steps laid out below draw on a wide variety of existing resources, and in places I'll point to them rather than attempt to regurgitate full explanations of the various security components. The most significant one, which I highly encourage everyone to read, is Rod Smith's site about secure boot, which is the most comprehensive and cogent explanation of UEFI, boot managers and boot loaders, and secure boot. Another incredibly useful resources is Safeboot, which encapsulates many of the setup steps below in a Debian application.
(This is not a particularly complete nor finished doc, but I'll share it as a gist anyway.)
In this document:
package kubernetes | |
name = input.metadata.name | |
kind = input.kind | |
is_service { | |
kind = "Service" | |
} |
FROM ubuntu | |
RUN apt-get update -y && apt-get install -y gcc | |
RUN ( \ | |
echo '#define _GNU_SOURCE'; \ | |
echo '#include <fcntl.h>'; \ | |
echo '#include <stdio.h>'; \ | |
echo '#include <unistd.h>'; \ | |
\ | |
echo 'char *getenv(const char *__name) {'; \ |
Creating a release of a free software project with PGP signatures is quite simple, especially if you have everything set up already. This guide uses GnuPG, but it should be roughly applicable to OpenPGP or other implementations. For completeness, I've included a (very) short introduction to how to create a PGP key and how PGP works.
At Vimeo, on the transcoding team, we work a lot with Go, and a lot with C, for various tasks such as media ingest. This means we use CGO quite extensively, and consequently, have run into bits that are perhaps not very well documented, if at all. Below is my effort to document some of the problems we've run into, and how we fixed or worked around them.
Many of these are obviously wrong in retrospect, but hindsight is 20/20, and these problems do exist in many codebases currently.
Some are definitely ugly, and I much welcome better solutions! Tweet me at @daemon404 if you have any, or have your own CGO story/tips, please! I'd love to learn of them.
Table of Contents