K
Q

What is the best way to organize a .net core app with nginx reverse proxy inside a kubernetes cluster?

8/21/2018

I want to deploy a .NET Core app with NGINX reverse proxy on Azure Kubernetes Service. What is the best way to organize the pods and containers?

  1. Two single-container pods, one pod for nginx and one pod for the app (.net-core/kestrel), so each one can scale independently of the other

  2. One multi-container pod, this single pod with two containers (one for nginx and one for the app)

  3. One single-container pod, a single container running both the nginx and the .net app

I would choose the 1st option, but I don't know if it is the right choice, would be great to know the the pros and cons of each option.

If I choose the 1st option, is it best to set affinity to put nginx pod in the same node that the app pod? Or anti-affinity so they deploy on different nodes? Or no affinity/anti-affinity at all?

-- lmcarreiro
asp.net-core
kubernetes
nginx

Similar Questions

FileNotFoundError: [Errno 2] No such file or directory: '/root/.kube/config' but file exists
Kubernetes API External Point Fail on Connection
Accesing nodejs process.env variables in CRA prod build in containerized Kubernetes deployment
Where to place kubernetes and dockerfiles
How to read stdout stderr logs in kubernetes within pod using filebeat or logstash,fluentd

1 Answer

8/21/2018

The best practice for inbound traffic in Kubernetes is to use the Ingress resource. This requires a bit of extra setup in AKS because there's no built-in ingress controller. You definitely don't want to do #2 because it's not flexible, and #3 is not possible to my knowledge.

The Kubernetes Ingress resource is a configuration file that manages reverse proxy rules for inbound cluster traffic. This allows you to surface multiple services as if they were a combined API.

To set up ingress, start by creating a public IP address in your auto-generated MC resource group:

az network public-ip create `
    -g MC_rg-name_cluster-name_centralus `
    -n cluster-name-ingress-ip `
    -l centralus `
    --allocation-method static `
    --dns-name cluster-name-ingress

Now create an ingress controller. This is required to actually handle the inbound traffic from your public IP. It sits and listens to the Kubernetes API Ingress updates, and auto-generates an nginx.conf file.

# Note: you'll have to install Helm and its service account prior to running this. See my GitHub link below for more information
helm install stable/nginx-ingress `
    --name nginx-ingress `
    --namespace default `
    --set controller.service.loadBalancerIP=ip.from.above.result `
    --set controller.scope.enabled=true `
    --set controller.scope.namespace="default" `
    --set controller.replicaCount=3

kubectl get service nginx-ingress-controller -n default -w

Once that's provisioned, make sure to use this annotation on your Ingress resource: kubernetes.io/ingress.class: nginx

If you'd like more information on how to set this up, please see this GitHub readme I put together this week. I've also included TLS termination with cert-manager, also installed with Helm.

-- brandon-barnett
Source: StackOverflow