Podtato-head demonstrates cloud-native application delivery scenarios using many different tools and services. It is intended to help application delivery support teams test and decide which mechanism(s) to use.

Several communicating services are defined in this project with as little additional logic as possible to enable you to focus on the delivery mechanisms themselves.

These communicating services are defined and containerized as encoded in the podtato-services directory. Each contains a simple HTTP server and Dockerfile. main is the externally-accessible endpoint; it communicates with the other services.

Within the delivery directory this set of services and container images is delivered in many different ways to enable you to compare and contrast them. Each delivery mechanism yields the same end result: an API service which communicates with other API services and returns HTML.

Following is the list of scenarios currently implemented. "Single" deployments mean the action effects the state of the resources only once at the time of invocation. "GitOps" deployments mean the action maintains (reconciles) the desired state periodically.

• Single deployment via Kubectl
• Single deployment via Helm
• Single deployment via Kustomize
• Single deployment via Ketch
• Single deployment via Kapp
• GitOps deployment via Flux
• GitOps deployment via ArgoCd
• Single canary deployment via Argo Rollouts
• Helm-based operator deployment
• Multi-Stage delivery with Keptn
• CNAB with Porter air-gapped deployment
• GitOps deployment via KubeVela
• GitOps deployment via Gimlet CLI

Other scenarios to be targeted in the future:

• multiple services in different version
• stateful workloads
• external dependencies
• feel free to create issues for use cases you are interested in

You can use any K8S cluster to run this project. If you do not have a K8S cluster at your disposal, you can quickly get a local one with kind.

NOTE: If you use a cluster with no access to external LoadBalancer (like a kind cluster), you may have to replace type: LoadBalancer by type: ClusterIP (or type: NodePort) in all files declaring a service definition :

# Update service type in all K8S manifests
find delivery -type f -name "*.yaml" -print0 | xargs -0 sed -i 's/type: LoadBalancer/type: ClusterIP/g'
# Update service type in all Helm values
find delivery -type f -name "*.yaml" -print0 | xargs -0 sed -i 's/serviceType: LoadBalancer/serviceType: ClusterIP/g'

See contributing.md.