Services

Kubernetes Services are a type of Kubernetes resource that allows you to expose your application running in a Kubernetes cluster to the network. Services provide a stable IP address and DNS name that other applications can use to communicate with your application, regardless of where it's running within the cluster.

Services can be thought of as a logical abstraction layer that sits between your application and the network. When you create a service, you define a set of pods that the service should target, and Kubernetes automatically manages the routing and load balancing of traffic to those pods. Services can also be used to expose your application to the outside world by using a Kubernetes Ingress resource or by configuring a load balancer on your cloud provider.

There are several types of Kubernetes Services available, including ClusterIP, NodePort, LoadBalancer, and ExternalName. Each type provides a different way of exposing your application to the network, depending on your specific needs.

There are 4 types of Kubernetes Services :

1. ClusterIP Service: This is the default service type in Kubernetes. It provides a stable IP address and DNS name within the cluster to access the pods that are part of the service. This type of service is used for communication between microservices within the cluster.

2. NodePort Service: This service type exposes the service on a port on each node in the cluster, allowing external traffic to reach the service. This type of service is often used for development or testing purposes.

3. LoadBalancer Service: This type of service provides a public IP address that can be used to access the service from outside the cluster. It typically uses a cloud provider's load balancer to distribute traffic across the pods that are part of the service.

4. ExternalName Service: This type of service provides an alias for an external service outside of the cluster. It maps the service name to a DNS name or IP address, allowing you to access external services as if they were part of the cluster.

Each type of service is designed to meet specific needs for exposing your application to the network. By choosing the appropriate service type, you can ensure that your application is accessible to other applications both inside and outside of the Kubernetes cluster.

Kubernetes Network Policies

Kubernetes Network Policies are a type of resource that allow you to define how traffic flows between pods in a Kubernetes cluster. Network policies allow you to define rules that determine which pods are allowed to communicate with each other and how traffic should be allowed to flow between them.

Network policies use labels to select pods and can specify ingress (incoming) and egress (outgoing) traffic rules. For example, you can define a network policy that only allows traffic from a specific set of pods to reach another set of pods, or you can specify that certain ports are only accessible from specific pods.

Kubernetes network policies are implemented using a set of rules that are evaluated by the Kubernetes network plugin. The rules are defined using the Kubernetes NetworkPolicy API, and can be applied to specific namespaces or to the entire cluster.

By using network policies, you can control network traffic in your Kubernetes cluster and enforce security policies that limit communication between pods. This can help you to create a more secure and reliable application architecture in your Kubernetes environment.

Ingress and Egress are two types of traffic rules that can be defined in Kubernetes Network Policies:

Ingress and Egress are two types of traffic rules that can be defined in Kubernetes Network Policies:

1. Ingress traffic rules: These rules control incoming network traffic to a pod. They define which pods are allowed to receive traffic and from which pods that traffic can originate. For example, you can create a network policy that only allows incoming traffic to a database pod from a specific set of pods, such as your application pods.

2. Egress traffic rules: These rules control outgoing network traffic from a pod. They define which pods are allowed to send traffic and to which pods that traffic can be sent. For example, you can create a network policy that only allows outgoing traffic from a web server pod to a specific set of pods, such as a caching layer or a load balancer.

Both ingress and egress traffic rules are defined using the Kubernetes NetworkPolicy API. Rules can be defined based on various attributes, such as the source or destination IP address, pod labels, ports, or protocol. By defining these rules, you can control the flow of network traffic within your Kubernetes cluster and enforce security policies that limit communication between pods.

DNS in Kubernetes

DNS (Domain Name System) in Kubernetes is a way to provide a naming system for the services and pods running within a cluster. Kubernetes uses a built-in DNS service, called CoreDNS, to manage DNS resolution for cluster resources.

With Kubernetes DNS, you can refer to a service by its name, rather than its IP address, making it easier to manage and communicate between services within the cluster. Each service and pod in a Kubernetes cluster is assigned a unique DNS name, which is created using the service or pod name and the namespace in which it is running.

For example, if you have a service named "web" running in a namespace named "production", you can access the service using the DNS name "web.production.svc.cluster.local". Similarly, each pod in the cluster is assigned a unique DNS name in the form of "podname.podnamespace.pod.cluster.local".

By using DNS in Kubernetes, you can decouple the internal IP addresses of services and pods from their names, making it easier to manage and scale your applications. DNS also makes it easier to communicate between services and pods within a cluster, allowing you to use familiar naming conventions rather than relying on IP addresses.

CNI - Container Networking Interface

CNI stands for Container Networking Interface. It is a specification that defines how network plugins interact with container runtimes, such as Kubernetes.

In Kubernetes, CNI is used to provide networking functionality to pods running in a cluster. The CNI specification defines a set of APIs that network plugins must implement in order to be compatible with Kubernetes. These APIs allow the network plugin to configure the network interfaces of pods, as well as route traffic between pods and between pods and the outside world.

There are many different CNI plugins available for Kubernetes, each with their own unique features and capabilities. Some popular CNI plugins include Calico, Flannel, Weave Net, and Cilium.

By using CNI in Kubernetes, you can create a flexible and scalable networking infrastructure that is designed to meet the needs of your applications. CNI allows you to easily add or remove network plugins, switch between different network topologies, and implement advanced networking features such as load balancing, network segmentation, and network policies.