Kubernetes Networking
Topics Are:
Services, Ingress, Network Policies, DNS, CNI Plugins
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 Service
ClusterIP Services are used for communication between Pods within the same Kubernetes cluster.
The Service gets exposed on a static IP that's unique within the cluster. When you make a request to that IP, the Service takes care of redirecting traffic to one of the Pods it's associated with. And if there's more than one Pod, the Service will automatically balance the traffic, so no single Pod gets bogged down by too many requests.
Here is an example of a .yaml file describing a ClusterIP Service object:
apiVersion: v1
kind: Service
metadata:
name: nginx-clusterip
spec:
type: ClusterIP
selector:
run: app-nginx
ports:
- port: 80
protocol: TCP
This YAML file defines a Kubernetes Service object of type ClusterIP. Below is an explanation of the important fields in the file:
NodePort Service
The NodePort Service is useful when you need to?expose your application to external clients. This means all traffic that is coming from?outside of the cluster.
When you create a NodePort Service, Kubernetes opens a port (in the range of 30000 and 32767) on all of its worker nodes. Note that the same port number is used across all of them. All traffic incoming to the worker node's IP address, and that specific port, is redirected to a Pod linked with that Service.
apiVersion: v1
kind: Service
metadata:
name: nginx-nodeport
spec:
type: NodePort
selector:
run: app-nginx
ports:
- nodePort: 30001
port: 80
targetPort: 80
This YAML file defines a Kubernetes Service object of type "NodePort". The "selector" block instructs the NodePort Service to send incoming traffic to one of the Pods with this label. In this case, the "run: app-nginx" label.
In the "ports" block, we have defined three ports:
LoadBalancer Service
A LoadBalancer Service is another way you can?expose your application to external clients. However,?it only works when you're using Kubernetes on a cloud platform that supports this Service type.
The LoadBalancer Service detects the cloud computing platform on which the cluster is running and creates an appropriate load balancer in the cloud provider’s infrastructure. The load balancer will have its own unique, publicly accessible IP address. For example, if the cluster is running on?Amazon Web Services?(AWS), the Service will create an Elastic Load Balancer (ELB) to distribute incoming traffic across multiple nodes in the cluster.
apiVersion: v1
kind: Service
metadata:
name: nginx-load-balancer
spec:
type: LoadBalancer
selector:
run: app-nginx
ports:
- port: 80
targetPort: 80
This LoadBalancer Service will be named "nginx-load-balancer". The traffic it receives on?port: 80?will be sent to one of the Pods labeled?run: app-nginx, on?targetPort: 80?of those Pods.
ExternalName Service
An ExternalName Service in Kubernetes is useful when you have a service that is running outside your Kubernetes cluster, such as a database, and you want to access it from within your cluster.
apiVersion: v1
kind: Service
metadata:
name: db-prod
spec:
type: ExternalName
externalName: db-prod.example.com
The following is an explanation of the key fields:
领英推荐
Kubernetes Ingress
It is the same in the Kubernetes world as well. Ingress means the traffic that enters the cluster and egress is the traffic that exits the cluster.
Ingress is a native Kubernetes resource like pods, deployments, etc. Using ingress, you can?maintain the DNS routing configurations. The ingress controller does the actual routing by reading the routing rules from ingress objects stored in etcd.
Kubernetes Ingress Resource
The Kubernetes Ingress resource is a native kubernetes resource where you specify the DNS routing rules. This means, that you map the external DNS traffic to the internal Kubernetes service endpoints.
It requires an ingress controller for routing the rules specified in the ingress object. Let’s have a look at a very basic ingress resource.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
namespace: dev
spec:
rules:
- host: test.apps.example.com
http:
paths:
- backend:
serviceName: hello-service
servicePort: 80
The above declaration means, that all calls to?test.apps.example.com?should hit the service named?hello-service?residing in the dev namespace.
As you can see, all it has is routing rules. You can add multiple routing endpoints for path-based routing, you can add TLS configuration, etc.
Kubernetes Network Policies
This is?Kubernetes?assets that control the traffic between?pods. Kubernetes network policy lets developers?secure?access to and from their applications. This is how we can?restrict?a user for access.
Any request that is successfully?authenticated?(including an anonymous request) is then?authorized. The default?authorization?mode is?always?allowed, which allows all?requests. In Kubernetes, you must be?authenticated?(logged in) before your request can be?authorized?(granted permission to access).
Network Policy In Pods
All Pods in Kubernetes communicate with each other which are present in the cluster. By default all Pods are?non-isolated?however Pods become?isolated?by having a Kubernetes Network Policy in Kubernetes. Once we have it in a?namespace?choosing a specific pod, that will restrict all the incoming and outing traffic of the pods.
Network Policy Specification
PodSelector –?Each of these includes a?pod selector?that selects the grouping of pods to which the policy applies. This selects particular Pods in the same namespace as the Kubernetes Network Policy which should be allowed as ingress sources or egress destinations.
Policy Types –?indicates which sorts of arrangements are remembered for this approach,?Ingress,?or?Egress.
Ingress –?Each Network Policies may include a list of allowed ingress rules. This includes inbound traffic whitelist rules.
Egress –?Each Network Policy may include a list of allowed egress rules. This includes outbound traffic whitelist rules.
DNS :
Kubernetes creates DNS records for Services and Pods. You can contact Services with consistent DNS names instead of IP addresses. Kubelet configures Pods' DNS so that running containers can lookup Services by name rather than IP.
CNI PLUGINS:
Container Network Interface, a Cloud Native Computing Foundation venture, comprises of detail and?libraries?for writing plugins to configure network interfaces in?Linux containers
Thanks For Reading!!!!!
DevOps Engineer | Linux | Jenkins | AWS | Ansible | Terraform | Docker | Kubernetes | Git/Github
1 年Very informative :)
AWS Community Builder | Cloud DevOps Engineer | CKA Certified | 4x AWS Certified | Terraform Certified | 9+ Yrs experience in IT | Python | Linux | Kubernetes | Docker | Jenkins | Ansible |Git
1 年Day2 Completed ??
Software Developer | Python | Django | Mysql | Devops
1 年Git Hub Link: https://lnkd.in/gUy3tZzf
AWS Community Builder | Cloud DevOps Engineer | CKA Certified | 4x AWS Certified | Terraform Certified | 9+ Yrs experience in IT | Python | Linux | Kubernetes | Docker | Jenkins | Ansible |Git
1 年Anup Ghattikar Useful blog with all details as per challenge. Thanks for sharing. Keep going.