#kubernetes

Argo CD wraps the loop in an application-centric abstraction with a dashboard; Flux exposes the loop as a set of granular Kubernetes custom resources.

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.

Define workflows where each step in the workflow is a container. Model multi-step workflows as a sequence of tasks or capture the dependencies between tasks using a graph (DAG). Easily run compute intensive jobs for machine learning or data processing in a fraction of the time using Argo Workflows on Kubernetes. Run CI/CD pipelines natively on Kubernetes without configuring complex software development products.

This chart bootstraps a WordPress deployment on a Kubernetes cluster using the Helm package manager.

It also packages the Bitnami MariaDB chart which is required for bootstrapping a MariaDB deployment for the database requirements of the WordPress application, and the Bitnami Memcached chart that can be used to cache database queries.

❤️

Phoenix can be deployed on Kubernetes with PostgreSQL using kustomize.

Octopus takes over where your CI server ends, modelling the entire release orchestration process of software. This includes:

Release versioning
Environment promotion (beyond simple dev/test/prod workflows)
Deployment automation
Progressive software delivery (rolling deployments, blue/green, canary)
Configuration management
Approvals & ITSM integration
Deployment freezes
Coordinating deployments across projects and their dependencies

Decoupling the CI platform from the CD platform allows teams to bring their favorite CI tool - and most organizations have more than one - while we focus on giving you the most powerful best-of-breed CD capabilities. Octopus integrates with popular CI tools like GitHub Actions, Jenkins or TeamCity, letting them do what they do best - the CI part of the feedback loop. Octopus then takes over “artifact-forward”, and handles the release and deployment aspects of CD in advanced ways that no CI/CD tool can.

A simple, high-throughput file client for mounting an Amazon S3 bucket as a local file system.

This is a Container Storage Interface (CSI) for S3 (or S3 compatible) storage. This can dynamically allocate buckets and mount them via a fuse mount into any container.

the Mountpoint CSI driver presents an Amazon S3 bucket as a storage volume accessible by containers in your Kubernetes cluster

Karpenter observes the aggregate resource requests of unscheduled pods and makes decisions to launch and terminate nodes to minimize scheduling latencies and infrastructure cost.

The Grafana Kubernetes Monitoring Helm chart deploys a complete monitoring solution for your Cluster and applications running within it. The chart installs systems, such as Node Exporter and Grafana Alloy Operator, along with their configuration to make these systems run. These elements are kept up to date in the Kubernetes Monitoring Helm chart with a dependency updating system to ensure that the latest versions are used.

OpenCost is a vendor-neutral open source project for measuring and allocating cloud infrastructure and container costs in real time. Built by Kubernetes experts and supported by Kubernetes practitioners, OpenCost shines a light into the black box of Kubernetes spend.

collection of container images, helm charts and virtual machines for the most popular open source applications and services

Hardened secure images of popular open source software with Near-Zero Vulnerabilities

I find Helm to be against a fundamental principle of Kubernetes: Declarative Configuration (further rooted in Promise Theory).

While Helm is written in a mostly declarative-looking syntax, the control structures (among other things) result in it being procedural. The end result is that a helm chart and it's templates become deceptively complex and each value in the values file needs fresh new documentation - because it is unique to that one helm chart.

Usually you'll find something like this in a repo:

# values.yaml:
replicaCount: 2
image:
  repository: blah.com/hello_world
  tag: v10000
service:
  type: ClusterIP
  internalPort: 8000
ingress:
  enabled: false
...

It looks declarative, but in reality all of those inputs are just fed into some procedural code in the chart to be interpreted uniquely by that procedural code and producing anything.

Engineering & Operations Divergence

As a practical consequence, I find that this results in an Engineering organization increasingly being detached from Kubernetes and and relying on a set of "Kubernetes experts" and thinking that Kubernetes is so complex that only those experts can work with it. However, generally this isn't the case.

With entry-level knowledge of Kubernetes' Deployment, Pod, Service and maybe PersistantVolume and Ingress any software engineer can be competent in making changes to any app deployed in Kubernetes. This is probably ~1 day to learn the basics and I'd say comparable learning curve to docker compose. For someone comfortable in a docker compose file, then it will be even easier!

What's the Alternative?

The alternative is instead of putting a Helm chart into a repo, put plain Kubernetes yaml resources into your repo. At most you can use kustomize and overlays to adjust them further (e.g. to adjust environment variables for different environments).

So What's Helm Good For?

Helm is good if you're distributing a "packaged application" to others to run in Kubernetes. For example, someone packaging a Wordpress with a database, Helm makes sense. In a case like this, the the internals of how all these things work inside the cluster don't matter to you and you won't have any other Kubernetes resources deployed that are coupled to them (within the cluster), then the packager can simplify things for you and update things over time and the consumers of the package don't have to know or worry about the details.

However, this is fundamentally different from an engineering organization developing and operating their own application internally. In that case the "infrastructure" of the application, is just as important for engineers to be able to understand and maintain as it is for them to understand the code. Putting that infrastructure behind opaque code that spits out a bunch of resources dynamically at runtime only adds complexity to understanding the resources. You still must understand all those resources, but now you must understand the procedural code that deployed those resources too. So why not just maintain the resulting resources and stop writing more code to produce them?

I should switch from debian to this maybe.

The bitnami dudes suck. This looks like someone stepping up to fill the void!

Chainguard has released 40+ first-party Helm Charts, forked from Bitnami, that ensure compatibility while integrating with our catalog of 1,700+ secure, minimal, and continuously rebuilt container images. These charts provide stability, security, and compliance out of the box.