<p>We are running an API server on GKE (google kubernetes engine). We handle our authorization using Google Cloud Endpoints and API keys. We whitelist certain IP addresses on every API key. In order to make this work we had to change over from a loadbalancer to a ingress controller for exposing our API server. The IP whitelisting does not work with the loadbalancer service. Now we have an ingress setup similar to this:</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: echo-app-nodeport
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: esp-echo
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "RESERVED_IP"
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  backend:
    serviceName: echo-app-nodeport
    servicePort: 80
</code></pre>

<p>This setup functions fine and the IP whitelisting works. Now my concern lies primarily with the NodePort that seems needed in order to make the ingress controller work. I read multiple sources <a href="https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0" rel="noreferrer">[1]</a><a href="https://oteemo.com/2017/12/12/think-nodeport-kubernetes/" rel="noreferrer">[2]</a> that strongly advise against using NodePorts for exposing your application. Yet most examples I find use this NodePort + Ingress combo. Can we safely use this setup or should we migrate towards an other ingress controller (NGINX, Traefik,..) ?</p>

<p>You can have only ClusterIP type service for all your workload pods and have one LoadBalancer service to expose the ingress controller itself outside the cluster.That way you can completely avoid NodePort service.</p>
