☸ Basics Kubernetes Objects include:
Pod
Service
Persistent Volume
Namespace
Replica sets
Secrets
Configmaps
Deployments
Jobs
Daemonsets
Relationship between these objects
--> Pod manages containers
--> Replicaset manage pods
--> Services expose the pod process to the outside world.
--> Config maps and secrets help you configure pods.
☸ Fundamentals of Pod
👉 Pods are the smallest and simplest unit of deployment in Kubernetes.
👉 A pod can contain one or more containers that share the same network namespace and file system.
👉 Each pod is assigned a unique IP address that can be used for communication within the cluster.
👉 Pods are often managed by controllers like ReplicaSet or Deployment, which ensure the desired number of replicas are running at all times.
Here is an example of a basic pod YAML file:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
Once you have created your pod YAML file, you can use the kubectl apply command to deploy it to a Kubernetes cluster. For example, if the file is named my-pod.yaml, you can deploy it with the following command:
kubectl apply -f my-pod.yaml
☸ Replication Controller
A replication controller is an object that enables you to create multiple pods easily, then make sure that number of pods always exists.
If a pod create using RC, it will be automatically replaced if they crash, fail, or terminate.
☸ Replica Set
The replica set is a next-generation Replication Controller.
The replication controller only supports equality-based selectors whereas the replica set supports set-based selectors i.e. filtering according to a set of values.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
Once you have created your ReplicaSet YAML file, you can use the kubectl apply command to deploy it to a Kubernetes cluster. For example, if the file is named my-replicaset.yaml, you can deploy it with the following command:
kubectl apply -f my-replicaset.yaml
☸ Deployment & Rollback
A deployment object act as a supervisor for pods, giving you fine-grained control over how and when a new pod is Rolled updated or Rolled Back to a Previous state.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
To deploy the YAML file, you can use the kubectl apply command:
kubectl apply -f my-deployment.yaml
To perform a rollback in case of issues, you can use the kubectl rollout command. Kubernetes maintains a history of deployments, which can be rolled back to a previous version.
To see the history of the deployment, use the following command:
kubectl rollout history deployment/my-deployment
Failed Deployment
Your deployment may get stuck trying to deploy its newest Replicaset without ever completing it. This can occur due to some of the following factors.
* Insufficient Quota
* Readiness probe failures
* Image pull errors
* Insufficient Permission
* Limit Ranges
* Application runtime misconfiguration
☸ Kubernetes Networking addresses four concerns:-
🚀 Containers within a pod use networking to communicate via loopback.
🚀 Cluster networking provides communication between different pods.
🚀 The service resources let you expose an application running in pods to be reachable from outside your cluster.
🚀 You can also use services to publish services only for consumption inside your cluster.
🚀 Container-to-container communication on the same pod happens through localhost within the containers.
Now try to establish communication between two different pods within the same machine
--> Pod to Pod communication same worker node happens through Pod IP.
--> By default Pod's IP will not be accessible outside the node.
☸ Services
A service object is a logical bridge between pods and end users, which provides virtual IP (VIP).
Service allows clients to reliably connect to the containers running in the pod using the VIP.
The VIP is not an actual IP connected to a network interface, but its purpose is purely to forward traffic to one or more pods.
Services help to expose the VIP mapped to the pods & allow applications to receive traffic.
Services can be exposed in different ways by specifying a type in the service spec:
✏️ ClusterIP
✏️ NodePort
✏️ LoadBalancer
Note:- By default, service can run only between ports 30,000-32767
ClusterIP
Exposes VIP only reachable from within the cluster.
Mainly used to communicate between components of microservices.
NodePort
Makes a service accessible from outside the cluster.
Exposes the service on the same port of each selected node in the cluster using NAT.
LoadBalancer
LoadBalancer service is an extension of the NodePort service. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
Each cloud provider (AWS, Azure, GCP, etc) has its own native load balancer implementation. The cloud provider will create a load balancer, which then automatically routes requests to your Kubernetes Service.
☸ Ingress
In Kubernetes, Ingress is an API object that provides an external access point to the services in a cluster. It acts as a layer 7 load balancer that can route incoming traffic based on the URL path or hostname to the corresponding service.
Here's an example of a basic Ingress YAML file:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /app1
pathType: Prefix
backend:
service:
name: app1-service
port:
name: http
- path: /app2
pathType: Prefix
backend:
service:
name: app2-service
port:
name: http
To deploy the Ingress YAML file, you can use the kubectl apply command:
kubectl apply -f my-ingress.yaml
☸ Network Policies
In Kubernetes, Network Policies are a way to define rules for traffic flow between pods in a cluster. They allow you to specify which pods can communicate with each other and which ports they can use. Network Policies can be used to enforce security policies and prevent unauthorized access to pods and services.
Here's an example of a basic Network Policy YAML file:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: my-network-policy
spec:
podSelector:
matchLabels:
app: my-app
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: allowed-app
ports:
- protocol: TCP
port: 80
To deploy the Network Policy YAML file, you can use the kubectl apply command:
kubectl apply -f my-network-policy.yaml
Once the Network Policy object is created, it will restrict traffic flow between pods in the cluster based on the defined rules.
☸ DNS
In Kubernetes, DNS (Domain Name System) is used to resolve domain names to IP addresses within the cluster. This allows pods and services to communicate with each other using domain names, which are easier to remember than IP addresses.
By default, Kubernetes creates a DNS service and a DNS pod in the kube-system namespace. The DNS service is responsible for exposing the DNS endpoints to the cluster, and the DNS pod runs a DNS server that serves DNS requests for the cluster.
☸ CNI Plugins
In Kubernetes, CNI (Container Network Interface) plugins are used to provide networking support for pods. CNI is a specification that defines how networking should work for containers, and there are many different CNI plugins available for Kubernetes.
When a pod is created in Kubernetes, a network namespace is created for the pod. The CNI plugin is responsible for configuring the network namespace with the appropriate network interfaces and routes so that the pod can communicate with other pods and services in the cluster.
Great initiative by the #trainwithshubham community. Thank you Shubham Londhe
#devops #kubeweek #kubernetes #kubeweekchallenge
Thank You!! 😊