otomi-core VS ingress-nginx

An example of a self-hosted Kubernetes-based PaaS is Otomi. Install Otomi on your Kubernetes cluster, compose your platform (by activating the required capabilities) and build, deploy and expose apps in just a couple of minutes. Heroku, but Kubernetes native and running on your own cluster.

This video shows some of the new features of Otomi version 0.19.0 that will be released in Week 11 2023. Follow us on GitHub and be the first to try it out: https://github.com/redkubes/otomi-core

Otomi

Kubernetes is 'only' a multi-node cluster kernel. Some call it the Linux of the cloud.

And because K8s is only a kernel, there are now over 2000+ (open source) projects, all adding some extra functionality to it. Be it for observability, security, or networking. But all of these projects don't really collaborate and end-users don't ask for maturity of individual projects, they want sets/stacks of projects that integrate well.

Now every company has created some Stack with applications and configurations for Kubernetes, all trying to reinvent the wheel and spending an often shocking $ in doing so.

So here is my take:

- Let's create a new category in the Cloud Native Computing Foundation (CNCF) landscape and call it Integrated Stacks for K8s

- To be accepted, a stack needs to provide an open integration framework for other projects to add/integrate their apps

- Just like aLinux distro, each stack is ideal for some specific use case(s)

- A stack can be installed in one run, contains integrated apps that work out-of-the-box, has a (web) UI that acts as a desktop environment to provide easy and secure access to all features. Call it a new user experience for Kubernetes

Wouldn't it be great to have a list of all Kubernetes stacks available that everyone can use (and contribute to)? Just like (in the Linux analogy) you can choose between Linux Mint, Fedora, or Ubuntu.

We already created the first: https://github.com/redkubes/otomi-core

ingress-nginx

The second one is a combination of tools: External DNS, cert-manager, and NGINX ingress. Using these as a stack, you can quickly deploy an application, making it available through a DNS with a TLS without much effort via simple annotations. When I first discovered External DNS, I was amazed at its quality.

resource "helm_release" "icrelease" { name = "nginx-ingress" repository = "https://kubernetes.github.io/ingress-nginx" chart = "ingress-nginx" version = "4.9.1" namespace = kubernetes_namespace.icnamespace.metadata[0].name set { name = "controller.ingressClassResource.default" value = "true" } }

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace -f custom/ghost/nginx.yaml

For example, if you chose Nginx Ingress, you will use some of its dozens of annotations that are not portable if you decide to switch to another Ingress implementation like Apache APISIX.

The controller is installed with helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

helm repo add jetstack https://charts.jetstack.io helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo add rancher-latest https://releases.rancher.com/server-charts/latest helm repo update helm repo list

Everything in the YAML snippets below — except for ingress configuration — relates to configuring the NGINX ingress controller. This includes customizing the default configuration.

Keep Documentation Handy: Always have the official NGINX Ingress documentation accessible.