ClusterIP

  • Only communication between the IP in the internal pods
  • Usually only for internal, but
    • We can use kubectl port-forward
    • kubectl proxy to expose dashboard
  • Not suitable for production

NodePort

  • We will open a port in the NODE of kubernetes
  • We will map between pod to the node kubernetes
  • This is not good since if the node change, we need to change the A record in DNS
  • Port Range: 30000 - 32000
kind: Service
apiVersion: v1
metadata:
	name: nginx
spec:
	type: NodePort
	ports:
		- name: web
		  port: 80
		  nodePort: 31600
	selector:
		app: nginx
  • We can use this for a demo to show

LoadBalancer

  • if we create this in the VPS, it will create the corresponding load balancer for example in AWS
  • This is the default method.
kind: Service
apiVersion: v1
metadata:
	name: nginx
spec:
	type: LoadBalancer
	ports:
		- name: web
		  port: 80
		  nodePort: 31600
	selector:
		app: nginx
  • Kubernetes will create each of those services and make very expensive :( so that’s why we have ingress

Ingress

  • Most complicated but most useful
    • Example
      • Nginx
      • kong
      • haproxy ingress
      • istio ingress
  • Smart router
  • Many different things
  • Path based and subdomain based routing
  • Only need to maintain 1 specific load balancer and let the controller inside the kubernetes do the rest