Kubernetes Services

• Services logically connect pods across the cluster to enable networking between them.

• The lifetime of an individual pod cannot be relied upon; everything from their IP addresses to their very existence are prone to change.

• Kubernetes doesn’t treat its pods as unique, long-running instances; if a pod encounters an issue and dies, it’s Kubernetes’ job to replace it so that the application doesn’t experience any downtime.

• Services make sure that even after a pod(back-end) dies because of a failure, the newly created pods will be reached by its dependency pods(front-end) via services. In this case, front-end applications always find the backend applications via a simple service(using service name or IP address) irrespective of their location in the cluster.

• Services point to pods directly using labels. Services do not point to deployments or ReplicaSets. So, all pods with the same label gets attached to the same service.

• 3 types: ClusterIP, NodePort and LoadBalancer.

1 - Cluster IP

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080

• ClusterIP service is the default Kubernetes service.

• It gives you a service inside your cluster that other apps inside your cluster can access.

• It restricts access to the application within the cluster itself and no external access.

• Useful when a front-end app wants to communicate with back-end.

• Each ClusterIP service gets a unique IP address inside the cluster.

• Similar to --links in Docker.

2 - NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: http
    port: 80
    targetPort: 8080
    protocol: TCP
    nodePort: 30000

• NodePort opens a specific port on all the Nodes in the cluster and forwards any traffic that is received on this port to internal services.

• Useful when front-end pods are to be exposed outside the cluster for users to access it.

• NodePort is built on top of the ClusterIP service by exposing the ClusterIP service outside of the cluster.

• NodePort must be within the port range 30000- 32767

• If you don’t specify this port, a random port will be assigned. It is recommended to let k8s auto-assign this port.

3 - Load Balancer

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  selector:
    app: my-app
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
  externalTrafficPolicy: Cluster

• A LoadBalancer service is the standard way to expose a Kubernetes service to the internet.

• All traffic on the port you specify will be forwarded to the service.

• There is no filtering, no routing, etc. This means you can send almost any kind of traffic to it, like HTTP, TCP, UDP or WebSocket's.

• The application can be reached using the external IP assigned by the LoadBalancer.

• The LoadBalancer will forward the traffic to the available nodes in the cluster on the nodePort assigned to the service.

4 - ExternalName

• ExternalName services are a type of service in Kubernetes that provide a way to refer to external services by DNS name.

• They allow you to expose an external service to your Kubernetes cluster without actually creating a Kubernetes service for it.

• This is commonly used to create a service within Kubernetes to represent an external datastore like a database that runs externally to Kubernetes.

• You can use that ExternalName service (as a local service) when Pods from one namespace to talk to a service in another namespace.

Ingress:

• In Kubernetes, Ingress is an API object that provides a way to expose HTTP and HTTPS routes from outside the cluster to services within the cluster. It acts as a reverse proxy, routing incoming requests to the appropriate backend service based on the requested URL.

• Ingress lets you consolidate your routing rules into a single resource and expose multiple services under the same IP address, using the same load balancers.

• Ingress also enables the configuration of resilience (time-outs, rate limiting), content-based routing, authentication and much more.

  

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-ingress
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
        - host: my-app.com
          http:
            paths:
              - path: /api
                pathType: Prefix
                backend:
                  service:
                    name: my-service
                    port:
                      name: http
  

Network Policies:

• Kubernetes Network Policies can be used to control traffic flow at the IP address or port level.

• Network Policies can be used to control ingress and egress traffic, restrict traffic to specific pods, and restrict traffic based on the source or destination IP address.

• Network Policies are important for securing the network infrastructure of Kubernetes clusters.

• Network policies specify how a pod is allowed to communicate with network "entities". These entities can be identified through other pods, namespaces, or IP blocks.

• When defining a NetworkPolicy, a selector is used to specify what traffic is allowed to and from pods that match the selector. IP-based NetworkPolicies are created based on CIDR ranges.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: example-network-policy
      namespace: default
    spec:
      podSelector:
        matchLabels:
          role: db
      policyTypes:
        - Ingress
        - Egress
      ingress:
        - from:
            - ipBlock:
                cidr: 172.17.0.0/16
                except:
                  - 172.17.1.0/24
            - namespaceSelector:
                matchLabels:
                  project: Devops-Project
            - podSelector:
                matchLabels:
                  role: frontend
          ports:
            - protocol: TCP
              port: 6379
      egress:
        - to:
            - ipBlock:
                cidr: 10.0.0.0/24
          ports:
            - protocol: TCP
              port: 5978
  

DNS:

• DNS (Domain Name System) is used to provide a consistent way to access services within the cluster, regardless of their IP address or the Pod's location.

• Kubernetes deploys a DNS server (CoreDNS or kube-dns) in the cluster, which automatically creates DNS records for each Service and Pod.

• When a Pod needs to communicate with another Pod or Service within the cluster, it can use the DNS name to resolve the corresponding IP address.

• This allows Pods to communicate with each other without having to hard-code IP addresses or rely on other forms of discovery.

CNI plugins:

• A Container Network Interface (CNI) plugin is a software component that provides networking functionality to containers in a Kubernetes cluster.

• It is responsible for configuring the network interfaces of containers and managing network connectivity between them.

• CNI plugins are designed to be pluggable, which means that different plugins can be used depending on the specific networking requirements of the cluster.

• This allows for flexibility and enables integration with a wide range of networking solutions.

---

Thanks 😊

Happy Learning!!

Vishal Ranmale

https://www.linkedin.com/in/vishal-ranmale-907307114/