Policy as Code,Simplified!

Secure, automate, and operate all your infrastructure and applications with YAML and CEL based policies.

Every tenant gets their own isolated cluster. Nothing else.

With a few simple commands, you can create your first cluster and define how workloads are isolated — all with a lightweight vcluster.yaml config.

Images modify the name, tags and/or digest for images without creating patches.

One can change the image in the following ways (Refer the following example to know exactly how this is done):

• postgres:8 to my-registry/my-postgres:v1,
• nginx tag 1.7.9 to 1.8.0,
• image name my-demo-app to my-app,
• alpine’s tag 3.7 to a digest value

Upbound built Crossplane to help organizations build their platforms like the cloud vendors build theirs—with control planes. Crossplane is an open source, CNCF project built on the foundation of Kubernetes to orchestrate anything. Encapsulate policies, permissions, and other guardrails behind a custom API layer to enable consumers, whether human users, automated workflows, or AI agents, to self-service without needing to become an infrastructure expert.

Crossplane builds on the class leading Kubernetes control plane, extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just containers. By extending Kubernetes’ control model beyond containers, Crossplane enables a unified control layer for infrastructure. Because it shares a foundation with Kubernetes, Crossplane also integrates smoothly with the broader cloud-native ecosystem, allowing platforms to build automation and higher-level tooling without reinventing infrastructure fundamentals.

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?