Deploying applications to kubernetes the proper way

Deploying apps to Kubernetes with a reverse proxy ingress resource.

Deploying applications to kubernetes the proper way

In a previous post I mentioned that would share the proper method of deploying Helm applications with an ingress. This post will detail the process of creating the ingress and using it for some common operations that would be required of a web server.

Tools required

  1. kubectl CLI v1.15+
  2. helm CLI v3.0+

Two general practices

I follow some best practices that generally make a cluster more robust. I'm not sure if these industry standards, but they seem to make sense to I implement them in the clusters I maintain.

First is create namespaces to logically separate the applications being deployed. I generally use namepsaces for the dev, staging, and live environments within my clusters. Certain objects in Kubernetes can be scoped to a namespace which is the next reason I use namespaces in this way.

Second, create an ingress per publicly accessible namespace. This helps make the whole cluster more robust. One global ingress has the disadvantage of negatively affecting every public facing application on the cluster if it malfunctions. A namespaced ingress means only the applications in that namespace are affected if that ingress malfunctions. The disadvantage here is that, if you have many namespaces, you'll have to maintain many ingresses.

Creating namespaces

Creating namespaces is super easy. We only need to the kubectl CLI and one simple command to create one namespace. We use the following command to create the namespace

kubectl create namespace dev

Shameless plug

If you like content on this blog you can support us by using the DO referral link to sign up and get free credit. And you'll support us as well.

Referral link: https://m.do.co/c/590c0c82c1fc

Also you can subscribe directly signing up for free, or support us with a small monthly or yearly fee. Simply click the button at the bottom right corner.


Creating namespaced ingress

Now let's use helm to create an ingress that is specific to the namespace that we created earlier. I will using the Kubernetes maintained ingress-nginx. It is generally reliable, performant, and provides/exposes the general functionality that is most commonly required. Let's install it

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm --namespace=dev install ingress-nginx/ingress-nginx --set="controller.scope.enabled=true,controller.scope.namespace=dev"

The above command will install the ingress object on the namespace specified in the --set parameter. This ingress will only be responsible for applications deployed to the dev namepsace. It will create a load balancer on whichever cloud platform you're hosting your cluster on.

Using some common functionalities

Now I will go through some common usage of the ingress and modifying it's behaviour using annotations.

First you can use the following annotation in your application's ingress resource to register it on the deployed ingress.

kubernetes.io/ingress.class: nginx

Second, if you want to increase the size of the upload body size.

nginx.ingress.kubernetes.io/proxy-body-size: 50m

Last, if you want to redirect from or to www subdomain of you site. You must create host of you main domain in the your application's ingress recourse with the base and www subdomain. Then you can enable the redirect behaviour with the following.

nginx.ingress.kubernetes.io/from-to-www-redirect: "true"

There are many more customisations that you can make using annotations or even a Kubernetes ConfigMap.


Subscribe

I will making this content like this and more so please consider supporting me by subscribing.

Sign up by using the button at the bottom right corner. Also conider supporting with a small monthly fee.

Happy Hacking :)