nginx

Prometheus: exposing Prometheus/Grafana as Ingress for kube-prometheus-stack

The kube-prometheus-stack bundles Prometheus, Grafana, and AlertManager for monitoring a Kubernetes cluster. By default, the Ingress of these services is disabled.  In this article I will show you how to expose these services with NGINX Ingress either via subdomain (e.g. prometheus.my.domain) or web context (e.g. my.domain/prometheus). You would not want to expose these monitoring applications Prometheus: exposing Prometheus/Grafana as Ingress for kube-prometheus-stack

Kubernetes: kustomize overlay to enrich a base resource

With kustomize built into the kubectl CLI since version 1.14, there is little reason not to take advantage of this overlay system to deploy components to your Kubernetes cluster. Kustomize has the advantage that it is purpose built to understand and validate yaml and Kubernetes CRD, as opposed to bespoke templating solutions using sed/envsubst, Ansible, Kubernetes: kustomize overlay to enrich a base resource

Kubernetes: ingress-nginx-controller-admission error, x509 certificate signed by unknown authority

If you delete the entire nginx namespace and reinstall again via helm chart, your nginx admission controller may throw a “x509 certificate signed by unknown authority” message when you attempt to create an nginx ingress. This will happen regardless if the ingress is using http only or secure https.  And also whether or not the Kubernetes: ingress-nginx-controller-admission error, x509 certificate signed by unknown authority

Terraform: creating a Kubernetes cluster on DigitalOcean with public NGINX ingress

Updated Aug 2023: tested with Kubernetes 1.25 and ingress-nginx 1.8.1 Creating a Kubernetes cluster on DigitalOcean can be done manually using its web Control Panel, but for automation purposes it is better to use Terraform. In this article, we will use Terraform to create a Kubernetes cluster on DigitalOcean infrastructure. We will then use helm Terraform: creating a Kubernetes cluster on DigitalOcean with public NGINX ingress

Kubernetes: K3s with multiple metalLB endpoints and nginx ingress controllers

Updated March 2023: using K3s 1.26 and MetalLB 0.13.9 By default, K3s uses the Traefik ingress controller and Klipper service load balancer to expose services.  But this can be replaced with a MetalLB load balancer and NGINX ingress controller. But a single NGINX ingress controller is sometimes not sufficient.  For example, the primary ingress may Kubernetes: K3s with multiple metalLB endpoints and nginx ingress controllers

Kubernetes: microk8s with multiple metalLB endpoints and nginx ingress controllers

Out-of-the-box, microk8s has add-ons that make it easy to enable MetalLB as a network load balancer as well as an NGINX ingress controller. But a single ingress controller is often not sufficient.  For example, the primary ingress may be serving up all public traffic to your customers.  But a secondary ingress might be necessary to Kubernetes: microk8s with multiple metalLB endpoints and nginx ingress controllers

Kubernetes: detecting the installed version of nginx ingress

If you need to determine the version of the nginx ingress controller deployed, then you can invoke the ingress controller binary with the ‘–version’ flag. But this binary is located in the ingress-nginx-controller pod, so do a ‘kubectl exec’ like below. # namespace of your nginx ingress ingress_ns=”default” # find running pod podname=$(kubectl get pods Kubernetes: detecting the installed version of nginx ingress

Nginx: Using Nginx for SSL termination on Ubuntu

Nginx is a popular reverse proxy and load balancer that focuses on level 7 (application) traffic.  A common pattern is allowing Nginx to be the fronting SSL-termination point, and then Nginx determines which pooled backend server is best available to serve the request.