# Kubernetes Networking

🚀Kubernetes Networking Model:

➡ Kubernetes uses a flat networking model where each Pod receives a unique IP address. This model simplifies communication between Pods, allowing them to interact as if they were on the same physical or virtual machine. Key aspects of this model include:

💡 Pod Communication: Pods can communicate with all other Pods across nodes without the need for Network Address Translation (NAT).

💡 Shared Network Namespace: Containers within a Pod share the same network namespace, allowing them to communicate over [localhost](http://localhost) and share the same IP address.

💡 Dynamic Port Allocation: Kubernetes abstracts port management, reducing complexity by eliminating the need for manual port mapping between containers and hosts.

🚀Services:

➡ Services in Kubernetes are abstractions that define a logical set of Pods and a policy for accessing them. They provide stable endpoints for clients, enabling seamless communication despite the ephemeral nature of Pods. Key features include:

💡 Load Balancing: Services automatically distribute traffic among Pods based on defined selectors.

💡 Types of Services: Kubernetes supports various service types, including 

1.) ClusterIP(internal access)

2.) NodePort(external access)

3.) LoadBalancer (cloud provider integration) to expose Pods to the network

💡 Service Discovery: Services are discoverable via DNS, allowing clients to connect using a consistent service name rather than individual Pod IPs.

🚀Ingress:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1723574133735/5ab98dc9-3eed-48a5-b7b4-b5d0a1b51ecb.png align="center")

➡ Ingress is a collection of rules that allow external HTTP/S traffic to reach services within a Kubernetes cluster. It acts as a reverse proxy, providing:

💡 Path-Based Routing: Ingress can direct traffic to different services based on the request path or hostname.

💡 TLS Termination: Ingress can handle SSL/TLS termination, simplifying secure communication.

💡 Ingress Controllers: To implement Ingress rules, an Ingress controller must be deployed in the cluster, which manages the routing based on the defined rules.

Types of Ingress

1. Single Service Ingress :
    
    This type of Ingress exposes a single service to external users. It typically includes a default backend that handles requests that do not match any specific rules. This configuration is straightforward and is useful when only one service needs to be accessible externally.
    
2. Simple Fan-out Ingress:
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1723574726538/d92d42d8-d648-4e05-934b-93e7ff54bbf2.png align="center")
    
    This Ingress type allows routing to multiple services based on the request type, all under a single IP address. It simplifies traffic management by reducing the number of load balancers needed, making it easier to direct traffic to various services within the cluster.
    
3. Name-based Virtual Hosting
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1723574418934/e483fc7b-c61b-4b7a-a84c-f90c5b64285f.png align="center")
    
    Name-based virtual hosting enables routing of HTTP traffic to multiple hostnames using the same IP address. This type of Ingress evaluates the host header before applying routing rules, allowing different services to be accessed through different domain names on the same IP.
    
4. Ingress Controllers :
    
    To implement Ingress resources, a Kubernetes cluster must have an Ingress controller running. These controllers act as load balancers and reverse proxies, directing traffic according to the rules defined in the Ingress resource. Popular Ingress controllers include:
    
    a) Nginx Ingress Controller
    
    b) Traefik
    
    c) HAProxy Ingress Controller
    
    d) AWS Application Load Balancer Controller
    
    e) Azure Application Gateway Ingress Controller
    
    These controllers can be configured to manage traffic effectively, providing features such as SSL termination, load balancing, and advanced routing capabilities
    

🚀Network Policies:

➡ Network Policies are crucial for securing communication within a Kubernetes cluster. They define rules for traffic flow at the IP address or port level, allowing administrators to control which Pods can communicate with each other. Key points include:

💡 Isolation: Network Policies can restrict traffic between Pods, enhancing security by limiting exposure.

💡 Policy Enforcement: To utilize Network Policies, the cluster must employ a CNI plugin that supports their enforcement.

🚀DNS in Kubernetes:

➡ Kubernetes includes a built-in DNS service that facilitates service discovery. Each service and Pod is assigned a DNS name, making it easier for applications to locate and connect to them. Important aspects include:

💡 Service DNS Names: Services are accessible via DNS names like [my-svc.my](http://my-svc.my)\-namespace.svc.cluster-domain.example.

💡 CoreDNS: The DNS service is typically implemented using CoreDNS, which operates as a Pod within the cluster.

💡 DNS Search Paths: Pods are configured to use the DNS service with search paths that include their namespace and the cluster's default domain, simplifying service access.

🚀Container Network Interface (CNI) Plugins:

➡ CNI plugins are essential for managing network connectivity in Kubernetes. They provide the necessary interfaces for adding and removing network interfaces for Pods. Key points include:

💡 Variety of CNI Plugins: There are numerous CNI plugins available, each offering different features. Common plugins include Calico, Flannel, and Weave Net.

💡 Advanced Features: Some CNI plugins provide advanced capabilities such as network policy enforcement, IP address management (IPAM), and integration with cloud provider networking services.