Networking

Article LINK is used for below notes

Localhost

Pod network

Each time a pod is spun up, Kubernetes pulls an available IP address from the pod network and assigns it to the pod before turning it on. Pods all appear to be on the same network and can communicate with each other over this network (by default).

Service network

So how then are pods expected to know where other pods are and communicate with each other? A Kubernetes Service is a definition that describes a domain name and which pods traffic is directed to. For example:

kind: Service
apiVersion: v1
metadata:
  name: web
  namespace: my-app
spec:
  selector:
    app: web-server
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

It will create web.my-app.svc.cluster.local DNS entry that resolves to an IP address on the service network. The service network is similar to the pod network, except that the IPs are assigned to services, not pods. The IP address of the service stays with the service until the service is deleted. The service IP assigned balances the load of traffic to all pods that match the service's spec.selector definition. In the previous example, any pod with metadata.labels.app equal to web-server, would be considered to send traffic to on port 80.

Most likely, your application depends on external services or applications. Instead of the IP address of those endpoints, use domain names and let Kubernetes worry about the actual IP. So instead of configuring your application to talk to https://172.30.102.188/stuff, configure it to talk to https://web.my-app.svc.cluster.local/stuff and let Kubernetes address the other needed networking tasks.

If your application exposes an endpoint, you should expect to create a Kubernetes service to expose it to the cluster. Also note that you can include any combination of ports and protocols in a single service in case you need to listen on multiple ports.

Ingress resource

Ingress is not a type of Kubernetes Service, but it works in conjunction with them. An ingress is a Kubernetes resource that allows HTTP/HTTPS traffic to be routed to services based on the HTTP routes in the request. It allows you to route https://my-domain.com/service_a to service_a.my-app.svc.cluster.local, and https://my-domain.com/service_b to service_b.my-app.svc.cluster.local.

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

Prerequisites

You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.

You may need to deploy an Ingress controller such as ingress-nginx. You can choose from a number of Ingress controllers.

Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress controllers operate slightly differently.