There's so much more to an application than just its straight runtime environment (Deployment). Things like the upgrade/rollout policy, templating multiple similar applications etc...
Open Application Model is a spec for component reuse.
Define ComponentDefinitions that takes in parameters
and outputs templated (CUE, Helm, raw) resources,
and compose / instantiate them with Applications.
KubeVela is an implementation of oam.
Update the Application
and KubeVela will create/update the underlying components for you.
Also does traffic shifting with AppDeployment(?)
kpt is like a fancier version of kustomize, take in any raw upstream source, add setters/substitutors, and apply with a safer(?) command.
Knative Serving has a Service type
which wraps routing and pod definition into a single resource,
handling scaling (scale to zero) and a bit of traffic routing.
flux watches Git repos / storage buckets / image registries, runs Helm / Kustomize templating and applies resulting resources.
Argo CD watches Git repos, runs templating tools and applies resulting resources.
Like flux, but at a bigger scale (multicluster, users, workspaces, ui).
KUDO
define your app wth Go templating for resources
and an operator.yaml describing steps to take during create / update / delete.
Pass in values through a parameters.yaml and apply with a kubectl kudo cli.
Basically a fancier version of Helm 2...
These manage traffic routing to new versions of your deployments.
A Rollout
is CRD that is basically a Deployment with extra fields to reference Services
to manage the upgrade lifecycle.
Editing a live, existing Rollout
will result in a new ReplicaSets being created,
traffic being routed to it, before final promotion.
Flagger takes a different approach,
instead watching a Deployment or DaemonSet and creating a "stable" primary clone.
Traffic is routed to the primary clone and temporarily diverted during upgrades.
why run all these separate components when it could be just one big monolith?
keptn takes in a helm chart, and on trigger (cli, CloudEvents?) runs through a gauntlet of rollouts / tests before deploying with custom steps. After deploying, continuously monitor and trigger more custom steps to handle problems.