Day-2-kubernetes

TLDR: This blog post provides a comprehensive overview of Kubernetes concepts including Pods, ReplicaSets, Deployments, Namespaces, and Services, explaining their roles and how to implement them effectively in a Kubernetes cluster.

Welcome back to our Kubernetes session! In this post, we will explore some fundamental concepts of Kubernetes, including Pods, ReplicaSets, Deployments, Namespaces, and Services. This overview will help both beginners and those looking to refresh their knowledge.

In Kubernetes, a Pod is the smallest deployable unit. It can contain one or more containers. Think of a Pod as a wrapper that encapsulates these containers. Each Pod has a default temporary space known as MTD (Mountable Temporary Directory).

Example of a Pod

Imagine a worker node in your cluster. Inside this worker node, you have a Pod that contains two containers. If the worker node goes down, both the Pod and its containers will also be unavailable. To avoid this, you should distribute Pods across multiple worker nodes to ensure high availability.

ReplicaSets: Ensuring Availability

To manage Pods effectively, Kubernetes uses ReplicaSets. A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. For instance, if you have three worker nodes, you can use a ReplicaSet to spread your Pods across these nodes automatically.

Versioning Example

Consider a scenario where you have an application version 1 running. When developers finish working on version 2, you want to deploy it while ensuring version 1 is removed. A ReplicaSet can manage this process, ensuring that the correct number of Pods are running and facilitating rolling updates.

Deployments: Managing Updates

Deployments are a higher-level abstraction that manages ReplicaSets. They allow you to define the desired state for your application and handle updates seamlessly. When you deploy a new version, the Deployment controller ensures that the old version is replaced with the new one without downtime.

Understanding Namespaces

Namespaces in Kubernetes provide a way to divide cluster resources between multiple users or teams. For example, if Team Alpha and Team Bravo are using the same Kubernetes cluster, they can create separate namespaces to avoid resource conflicts.

Resource Isolation

By using namespaces, you can apply resource limits and isolate processes. This is particularly useful in environments where multiple teams are working on different applications. You can create namespaces for development, testing, and production environments.

Running Commands Imperatively

In Kubernetes, you can deploy resources in two ways: imperatively and declaratively. The imperative way involves using commands directly in the terminal, while the declarative way uses YAML manifest files.

Creating Namespaces and Pods

To create namespaces, you can use the following command:

kubectl create ns alpha
kubectl create ns bravo

kubectl get ns

To deploy a Pod in a specific namespace, you can run:

Connecting to Pods

To connect to a Pod for testing, you can use port forwarding. This allows you to access the application running inside the Pod from your local machine.

Example of Port Forwarding

You can set up port forwarding with the following command:

kubectl port-forward pod/alpha1 8000:80 --namespace=alpha

This command forwards port 8000 on your local machine to port 80 on the Pod.

Exposing Applications with Services

To make your application accessible from outside the cluster, you need to expose it using a Service. Services provide stable endpoints for Pods and can route traffic to them.

Creating a Service

You can expose a Pod with the following command:

kubectl expose pod alpha1 --type=NodePort --port=8000 --target-port=80 --namespace=Alpha

This command creates a Service that maps an external port to the Pod's internal port.

kubectl run alpha1 -n alpha --image=kiran2361993/kubegame:v1 --dry-run=client -o yaml

Conclusion

In this session, we covered the essential components of Kubernetes: Pods, ReplicaSets, Deployments, Namespaces, and Services. Understanding these concepts is crucial for managing applications in a Kubernetes environment effectively.

Remember, practical experience is key to mastering Kubernetes. The more you practice, the easier it will be to handle real-time infrastructure and succeed in interviews. Thank you for joining this session, and I look forward to seeing you in the next one!

---

# automatically generate ymal file -> copy it and paste it in -> app.yml
kubectl run alpha1 -n alpha --image=kiran2361993/kubegame:v1 --dry-run=client -o yaml

# view available resource  -> [name,shortname,apiversion,namespaced,kind]
kubectl api-resources
kubectl api-resources --namespace=true

# doc 
kubectl explain pod
kubectl explain pod.metadata

#
echo '<paste ymal>'  | kubectl apply -f -  # alpha1 pod code is paste
kubectl get pods  # alpha1 pod is running
kubectl get pods -n alpha

# kubectx -> help to swtich between namespace

# installation
search kubectx on google ->github -> relase -> v0.95 -> kubens_v0.9.5_linux_x86_64.tar.gz

# right click -> copy link address -> https://github.com/ahmetb/kubectx/releases/download/v0.9.5/kubens_v0.9.5_linux_x86_64.tar.gz
cd /usr/local/bin
wget https://github.com/ahmetb/kubectx/releases/download/v0.9.5/kubens_v0.9.5_linux_x86_64.tar.gz
ls -al
tar zxvf kubens_v0.9.5_linux_x86_64.tar.gz
rm -rf kubens_v0.9.5_linux_x86_64.tar.gz
ls -al
cd ~

# switch namespace 
kubnes 
kubnes alpha # switched to alpha
alias ku-kubectl

#
echo '<paste ymal>'  | ku apply -f -  # alpha2  & alpha3 pod code is paste
ku get pods # alpha1,alpha2,alpha3 pods is running in alpha namespace
ku delete pods alpha2 alpha3
ku get pods # alpha1 pods is running in alpha namespace

# i want to connect to alpha1 pod without using services through local system --> kube-forwarding
cd ~/.kube/
ls -al
cat config  # view content of config -> copy it

## open lens app (for monitoring)
# file -> add cluster -> paste the above copy content of config file -> add clusters
# cloudvishwakarma.in (cluster name) -> click on it -> workloads -> overview -> pods 
# click on terminal -> 
kubectl -n alpha port-forward pod/alpha1 8000:80

# open it in browser -> localhost:8000 -> you can see application running

# now i want to expose the pod to external world so that all user can use it -> svc(services) --> type=Nodeport
ku get pods
ku get svc

kubectl expose pod alpha1 --port=8000 --target-port=80 --type=NodePort
ku get svc  # port -> 8000:32667/TCP

# now copy workernode dns ip (ec2) -> copy -> open browser paste ip -> <ip>:32667
# not able to access the ip of workernode -> so need to enable security group(inbould rules) of workernode
# custom Tcp ,32667, Anywhere-IPv4
#  <ip>:32667 -> now it can be accessed in browser

# if i delete the pod -> svc dont get deleted , svc will be present even pod is deleted
ku get pods -o wide
ku get svc -o wide

ku delete pods alpha1 #delete alpha1 pod from alpha namespace
ku describe svc # endpoint : <none>

echo '<paste ymal>'  | ku apply -f - #create alpha1 pod --> label : alpha1 
ku get pods -o wide # to see <pod-ip>
ku describe svc # endpoint : <pod-ip>:80 -> automatically get connected to pod, due to-> label

# declaritive way to deploy 
nano replicaset.yml    #replicas : 3
ku apply -f replicaset.yml  #so 1 stand-alone pod and 3 replicas is created (of stand-alone pod)
# any replica pod is deleted -> it recreates itself immediately
# any stand-alone pod is deleted -> it doesnot recreates itself