Networking is a central part of Kubernetes, but it can be challenging to understand exactly how it is expected to work.
Different Types of Kubernetes Networking
Communication between Containers: This type of networking involves multiple containers running in the same pod and sharing the same host network. Although each container has a different port, they share the same IP address, and communication occurs within the pod.
Communication between Pods: Pod-to-Pod communication in Kubernetes is based on each pod having its unique IP address. There are two types of Pod-to-Pod communication: Intra-node Pod Network and Inter-node Pod Network.
Intra-node Pod Network is when pods running on a single node communicate with each other. Since each pod gets its unique IP address from the local network, communication between pods on the same node is established by default. In other words, because they share the same host, they can communicate with each other without any additional configuration.
Inter-node Pod Network, on the other hand, refers to communication between pods running on different nodes. In this scenario, Kubernetes creates a network plugin to enable communication between the pods. The network plugin sets up routing tables, and the traffic is forwarded from any pod to any destination pod.
Communication between Pods and Services: Kubernetes Services provide a way to expose applications to the outside world and enable communication between pods and Services.
External-to-Service communications: Services are assigned a unique IP address and DNS name, which is used as the entry point for accessing the pods associated with the Service. Pods can communicate with Services by sending requests to the Service's virtual IP address, and Services can also be exposed to the outside world using different types of Service objects.
Services can also be exposed to the outside world using different types of Service objects such as NodePort, LoadBalancer, and ExternalName. These objects allow external clients to access the Service, which in turn routes the traffic to the pods based on the Service's configuration.
Services
Services provide a way to expose a set of pods to the network. A service is an abstract way to expose an application running on a set of Pods as a network service. A Service can be exposed in a variety of ways such as ClusterIP, NodePort, and LoadBalancer. ClusterIP is the default and provides a stable IP address for accessing the service from within the cluster. NodePort exposes the service on a port on each node of the cluster. LoadBalancer creates an external load balancer that routes traffic to the service. Services are an important component of Kubernetes networking as they provide a stable IP address and DNS name for accessing the application.
For example, suppose you have a set of Pods that each listen on TCP port 9376 and are labelled as app.kubernetes.io/name=MyApp. You can define a Service to publish that TCP listener:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Ingress
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.
Here is a simple example where an Ingress sends all its traffic to one Service:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80
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.
They allow you to 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.
See the NetworkPolicy reference for a full definition of the resource.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-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: myproject
- 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 a system for translating domain names into IP addresses.
Kubernetes creates DNS records for Services and Pods. You can contact Services with consistent DNS names instead of IP addresses.
Kubernetes publishes information about Pods and Services which is used to program DNS. Kubelet configures Pods' DNS so that running containers can lookup Services by name rather than IP.
CNI Plugins
The network model is implemented by the container runtime on each node. The most common container runtimes use Container Network Interface (CNI) plugins to manage their network and security capabilities. Many different CNI plugins exist from many different vendors. Kubernetes supports a variety of CNI plugins such as Calico, Flannel, and Weave. CNI plugins are important for configuring the network infrastructure of Kubernetes clusters.
Conclusion
Kubernetes networking enables the communication between nodes, pods, and services in a cluster, with each having its IP address and rules. It employs tools such as Services, Ingress, Network Policies, DNS and CNI plugins, service meshes, and load balancers to manage communication. Proper management of Kubernetes networking is essential for optimal performance, scalability, and security of modern cloud-native applications.
I hope that you have gained valuable knowledge in the area of Kubernetes networking today.
#Kubernetes #Devops #Trainwithshubham #Kubeweek #day2 #kubeweekchallenge #ContainerOrchestration #TechBlog #CloudNative